idnits 2.17.1 draft-ietf-cat-kerberos-revisions-04.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 6883 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 146 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 1803 instances of too long lines in the document, the longest one being 4 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 2016: '... extensions[4] TicketExtensions OPTIONAL...' RFC 2119 keyword, line 2027: '... starttime[6] KerberosTime OPTIONAL,...' RFC 2119 keyword, line 2029: '... renew-till[8] KerberosTime OPTIONAL,...' RFC 2119 keyword, line 2030: '... caddr[9] HostAddresses OPTIONAL,...' RFC 2119 keyword, line 2031: '... authorization-data[10] AuthorizationData OPTIONAL...' (62 more instances...) -- The abstract seems to indicate that this document updates RFC1510, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2102 has weird spacing: '... future expan...' == Line 2106 has weird spacing: '...LE flag is n...' == Line 2107 has weird spacing: '...rpreted by t...' == Line 2109 has weird spacing: '... flag tells...' == Line 2110 has weird spacing: '...s OK to issue...' == (141 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: -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 25, 1999) is 8889 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: '15' is mentioned on line 1142, but not defined == Missing Reference: '0' is mentioned on line 6584, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 2011, but not defined == Missing Reference: 'APPLICATION 3' is mentioned on line 2020, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 2413, but not defined == Missing Reference: 'APPLICATION 10' is mentioned on line 2493, but not defined == Missing Reference: 'APPLICATION 12' is mentioned on line 2494, but not defined == Missing Reference: 'APPLICATION 11' is mentioned on line 3040, but not defined == Missing Reference: 'APPLICATION 13' is mentioned on line 3041, but not defined == Missing Reference: 'APPLICATION 26' is mentioned on line 3054, but not defined == Missing Reference: 'APPLICATION 14' is mentioned on line 3146, but not defined == Missing Reference: 'APPLICATION 15' is mentioned on line 3215, but not defined == Missing Reference: 'APPLICATION 20' is mentioned on line 3278, but not defined == Missing Reference: 'APPLICATION 21' is mentioned on line 3356, but not defined == Missing Reference: 'APPLICATION 22' is mentioned on line 3411, but not defined == Missing Reference: 'APPLICATION 29' is mentioned on line 3418, but not defined == Missing Reference: 'APPLICATION 30' is mentioned on line 3523, but not defined == Missing Reference: '36' is mentioned on line 6859, but not defined == Missing Reference: 'ISO3309' is mentioned on line 4220, but not defined == Missing Reference: 'MD492' is mentioned on line 3859, but not defined == Missing Reference: 'Horowitz' is mentioned on line 3972, but not defined == Missing Reference: 'RFC 1779' is mentioned on line 4456, but not defined ** Obsolete undefined reference: RFC 1779 (Obsoleted by RFC 2253, RFC 3494) == Missing Reference: 'Westerlund' is mentioned on line 4612, but not defined == Missing Reference: 'RFC1883' is mentioned on line 4550, but not defined ** Obsolete undefined reference: RFC 1883 (Obsoleted by RFC 2460) == Missing Reference: 'RFC1884' is mentioned on line 4551, but not defined ** Obsolete undefined reference: RFC 1884 (Obsoleted by RFC 2373) == Missing Reference: 'Danielsson' is mentioned on line 4612, but not defined == Missing Reference: 'RFC 2253' is mentioned on line 4844, but not defined ** Obsolete undefined reference: RFC 2253 (Obsoleted by RFC 4510, RFC 4514) == Unused Reference: 'IS3309' is defined on line 5162, but no explicit reference was found in the text == Unused Reference: 'KBC96' is defined on line 5175, but no explicit reference was found in the text == Unused Reference: 'TM' is defined on line 6682, but no explicit reference was found in the text == Unused Reference: '27' is defined on line 6825, but no explicit reference was found in the text == Unused Reference: '29' is defined on line 6828, but no explicit reference was found in the text == Unused Reference: '31' is defined on line 6831, but no explicit reference was found in the text == Unused Reference: '37' is defined on line 6868, but no explicit reference was found in the text == Unused Reference: '38' is defined on line 6871, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'NT94' -- Possible downref: Non-RFC (?) normative reference: ref. 'MNSS87' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNS88' -- Possible downref: Non-RFC (?) normative reference: ref. 'NS78' -- Possible downref: Non-RFC (?) normative reference: ref. 'DS81' -- Possible downref: Non-RFC (?) normative reference: ref. 'KNT92' -- Possible downref: Non-RFC (?) normative reference: ref. 'Neu93' -- Possible downref: Non-RFC (?) normative reference: ref. 'DS90' -- Possible downref: Non-RFC (?) normative reference: ref. 'LGDSR87' -- Possible downref: Non-RFC (?) normative reference: ref. 'X509-88' ** Downref: Normative reference to an Not Issued RFC: RFC 26 (ref. 'Pat92') -- Possible downref: Non-RFC (?) normative reference: ref. 'DES77' -- Possible downref: Non-RFC (?) normative reference: ref. 'DESM80' -- Possible downref: Non-RFC (?) normative reference: ref. 'SG92' -- Possible downref: Non-RFC (?) normative reference: ref. 'IS3309' ** Obsolete normative reference: RFC 1320 (ref. 'MD4-92') (Obsoleted by RFC 6150) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5-92') -- Unexpected draft version: The latest known version of draft-ietf-ipsec-hmac-md5 is -00, but you're referring to -01. ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-hmac-md5 (ref. 'KBC96') -- Possible downref: Normative reference to a draft: ref. 'Horowitz96' -- No information found for draft-horowitz-kerb-key-derivation - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'HorowitzB96' -- Unexpected draft version: The latest known version of draft-ietf-ipsec-hmac-md5 is -00, but you're referring to -01. (However, the state information for draft-ietf-ipsec-hmac-md5 is not up-to-date. The last update was unsuccessful) -- Duplicate reference: draft-ietf-ipsec-hmac-md5, mentioned in 'Krawczyk96', was also mentioned in 'KBC96'. ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-hmac-md5 (ref. 'Krawczyk96') -- Possible downref: Non-RFC (?) normative reference: ref. 'TM' -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' -- Possible downref: Non-RFC (?) normative reference: ref. '22' -- Possible downref: Non-RFC (?) normative reference: ref. '23' -- Possible downref: Non-RFC (?) normative reference: ref. '24' -- Possible downref: Non-RFC (?) normative reference: ref. '25' -- Possible downref: Non-RFC (?) normative reference: ref. '27' -- Possible downref: Non-RFC (?) normative reference: ref. '29' -- Possible downref: Non-RFC (?) normative reference: ref. '31' -- Possible downref: Non-RFC (?) normative reference: ref. '32' -- Possible downref: Non-RFC (?) normative reference: ref. '33' -- Possible downref: Non-RFC (?) normative reference: ref. '35' -- Possible downref: Non-RFC (?) normative reference: ref. '37' -- Possible downref: Non-RFC (?) normative reference: ref. '38' -- Possible downref: Non-RFC (?) normative reference: ref. '39' -- Possible downref: Non-RFC (?) normative reference: ref. '40' Summary: 22 errors (**), 0 flaws (~~), 46 warnings (==), 59 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 June 25, 1999 5 Expires December 25, 1999 6 draft-ietf-cat-kerberos-revisions-04.txt 8 The Kerberos Network Authentication Service (V5) 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. Internet-Drafts are working documents 14 of the Internet Engineering Task Force (IETF), its areas, and its working 15 groups. Note that other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months and 19 may be updated, replaced, or obsoleted by other documents at any time. It is 20 inappropriate to use Internet- Drafts as reference material or to cite them 21 other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. To learn the current status of any 28 Internet-Draft, please check the '1id-abstracts.txt' listing contained in 29 the Internet-Drafts Shadow Directories. 31 The distribution of this memo is unlimited. It is filed as 32 draft-ietf-cat-kerberos-revisions-04.txt, and expires December 25th, 1999. 33 Please send comments to: krb-protocol@MIT.EDU 35 ABSTRACT 37 This document provides an overview and specification of Version 5 of the 38 Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol 39 and its intended use that require more detailed or clearer explanation than 40 was provided in RFC1510. This document is intended to provide a detailed 41 description of the protocol, suitable for implementation, together with 42 descriptions of the appropriate use of protocol messages and fields within 43 those messages. 45 This document is not intended to describe Kerberos to the end user, system 46 administrator, or application developer. Higher level papers describing 47 Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88], 48 are available elsewhere. 50 OVERVIEW 52 This INTERNET-DRAFT describes the concepts and model upon which the Kerberos 53 network authentication system is based. It also specifies Version 5 of the 54 Kerberos protocol. 56 Neuman, Ts'o, Kohl Expires: 25 December, 57 1999 59 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 60 1999 62 The motivations, goals, assumptions, and rationale behind most design 63 decisions are treated cursorily; they are more fully described in a paper 64 available in IEEE communications [NT94] and earlier in the Kerberos portion 65 of the Athena Technical Plan [MNSS87]. The protocols have been a proposed 66 standard and are being considered for advancement for draft standard through 67 the IETF standard process. Comments are encouraged on the presentation, but 68 only minor refinements to the protocol as implemented or extensions that fit 69 within current protocol framework will be considered at this time. 71 Requests for addition to an electronic mailing list for discussion of 72 Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-request@MIT.EDU. 73 This mailing list is gatewayed onto the Usenet as the group 74 comp.protocols.kerberos. Requests for further information, including 75 documents and code availability, may be sent to info-kerberos@MIT.EDU. 77 BACKGROUND 79 The Kerberos model is based in part on Needham and Schroeder's trusted 80 third-party authentication protocol [NS78] and on modifications suggested by 81 Denning and Sacco [DS81]. The original design and implementation of Kerberos 82 Versions 1 through 4 was the work of two former Project Athena staff 83 members, Steve Miller of Digital Equipment Corporation and Clifford Neuman 84 (now at the Information Sciences Institute of the University of Southern 85 California), along with Jerome Saltzer, Technical Director of Project 86 Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other members 87 of Project Athena have also contributed to the work on Kerberos. 89 Version 5 of the Kerberos protocol (described in this document) has evolved 90 from Version 4 based on new requirements and desires for features not 91 available in Version 4. The design of Version 5 of the Kerberos protocol was 92 led by Clifford Neuman and John Kohl with much input from the community. The 93 development of the MIT reference implementation was led at MIT by John Kohl 94 and Theodore T'so, with help and contributed code from many others. Since 95 RFC1510 was issued, extensions and revisions to the protocol have been 96 proposed by many individuals. Some of these proposals are reflected in this 97 document. Where such changes involved significant effort, the document cites 98 the contribution of the proposer. 100 Reference implementations of both version 4 and version 5 of Kerberos are 101 publicly available and commercial implementations have been developed and 102 are widely used. Details on the differences between Kerberos Versions 4 and 103 5 can be found in [KNT92]. 105 1. Introduction 107 Kerberos provides a means of verifying the identities of principals, (e.g. a 108 workstation user or a network server) on an open (unprotected) network. This 109 is accomplished without relying on assertions by the host operating system, 110 without basing trust on host addresses, without requiring physical security 111 of all the hosts on the network, and under the assumption that packets 112 traveling along the network can be read, modified, and inserted at will[1]. 113 Kerberos performs authentication under these conditions as a trusted 114 third-party authentication service by using conventional (shared secret key 115 [2] cryptography. Kerberos extensions have been proposed and implemented 116 that provide for the use of public key cryptography during certain phases of 117 the authentication protocol. These extensions provide for authentication of 119 Neuman, Ts'o, Kohl Expires: 25 December, 120 1999 122 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 123 1999 125 users registered with public key certification authorities, and allow the 126 system to provide certain benefits of public key cryptography in situations 127 where they are needed. 129 The basic Kerberos authentication process proceeds as follows: A client 130 sends a request to the authentication server (AS) requesting 'credentials' 131 for a given server. The AS responds with these credentials, encrypted in the 132 client's key. The credentials consist of 1) a 'ticket' for the server and 2) 133 a temporary encryption key (often called a "session key"). The client 134 transmits the ticket (which contains the client's identity and a copy of the 135 session key, all encrypted in the server's key) to the server. The session 136 key (now shared by the client and server) is used to authenticate the 137 client, and may optionally be used to authenticate the server. It may also 138 be used to encrypt further communication between the two parties or to 139 exchange a separate sub-session key to be used to encrypt further 140 communication. 142 Implementation of the basic protocol consists of one or more authentication 143 servers running on physically secure hosts. The authentication servers 144 maintain a database of principals (i.e., users and servers) and their secret 145 keys. Code libraries provide encryption and implement the Kerberos protocol. 146 In order to add authentication to its transactions, a typical network 147 application adds one or two calls to the Kerberos library directly or 148 through the Generic Security Services Application Programming Interface, 149 GSSAPI, described in separate document. These calls result in the 150 transmission of the necessary messages to achieve authentication. 152 The Kerberos protocol consists of several sub-protocols (or exchanges). 153 There are two basic methods by which a client can ask a Kerberos server for 154 credentials. In the first approach, the client sends a cleartext request for 155 a ticket for the desired server to the AS. The reply is sent encrypted in 156 the client's secret key. Usually this request is for a ticket-granting 157 ticket (TGT) which can later be used with the ticket-granting server (TGS). 158 In the second method, the client sends a request to the TGS. The client uses 159 the TGT to authenticate itself to the TGS in the same manner as if it were 160 contacting any other application server that requires Kerberos 161 authentication. The reply is encrypted in the session key from the TGT. 162 Though the protocol specification describes the AS and the TGS as separate 163 servers, they are implemented in practice as different protocol entry points 164 within a single Kerberos server. 166 Once obtained, credentials may be used to verify the identity of the 167 principals in a transaction, to ensure the integrity of messages exchanged 168 between them, or to preserve privacy of the messages. The application is 169 free to choose whatever protection may be necessary. 171 To verify the identities of the principals in a transaction, the client 172 transmits the ticket to the application server. Since the ticket is sent "in 173 the clear" (parts of it are encrypted, but this encryption doesn't thwart 174 replay) and might be intercepted and reused by an attacker, additional 175 information is sent to prove that the message originated with the principal 176 to whom the ticket was issued. This information (called the authenticator) 177 is encrypted in the session key, and includes a timestamp. The timestamp 178 proves that the message was recently generated and is not a replay. 179 Encrypting the authenticator in the session key proves that it was generated 180 by a party possessing the session key. Since no one except the requesting 181 principal and the server know the session key (it is never sent over the 182 network in the clear) this guarantees the identity of the client. 183 the authentication protocol. These extensions provide for authentication of 185 Neuman, Ts'o, Kohl Expires: 25 December, 186 1999 188 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 189 1999 191 The integrity of the messages exchanged between principals can also be 192 guaranteed using the session key (passed in the ticket and contained in the 193 credentials). This approach provides detection of both replay attacks and 194 message stream modification attacks. It is accomplished by generating and 195 transmitting a collision-proof checksum (elsewhere called a hash or digest 196 function) of the client's message, keyed with the session key. Privacy and 197 integrity of the messages exchanged between principals can be secured by 198 encrypting the data to be passed using the session key contained in the 199 ticket or the subsession key found in the authenticator. 201 The authentication exchanges mentioned above require read-only access to the 202 Kerberos database. Sometimes, however, the entries in the database must be 203 modified, such as when adding new principals or changing a principal's key. 204 This is done using a protocol between a client and a third Kerberos server, 205 the Kerberos Administration Server (KADM). There is also a protocol for 206 maintaining multiple copies of the Kerberos database. Neither of these 207 protocols are described in this document. 209 1.1. Cross-Realm Operation 211 The Kerberos protocol is designed to operate across organizational 212 boundaries. A client in one organization can be authenticated to a server in 213 another. Each organization wishing to run a Kerberos server establishes its 214 own 'realm'. The name of the realm in which a client is registered is part 215 of the client's name, and can be used by the end-service to decide whether 216 to honor a request. 218 By establishing 'inter-realm' keys, the administrators of two realms can 219 allow a client authenticated in the local realm to prove its identity to 220 servers in other realms[3]. The exchange of inter-realm keys (a separate key 221 may be used for each direction) registers the ticket-granting service of 222 each realm as a principal in the other realm. A client is then able to 223 obtain a ticket-granting ticket for the remote realm's ticket-granting 224 service from its local realm. When that ticket-granting ticket is used, the 225 remote ticket-granting service uses the inter-realm key (which usually 226 differs from its own normal TGS key) to decrypt the ticket-granting ticket, 227 and is thus certain that it was issued by the client's own TGS. Tickets 228 issued by the remote ticket-granting service will indicate to the 229 end-service that the client was authenticated from another realm. 231 A realm is said to communicate with another realm if the two realms share an 232 inter-realm key, or if the local realm shares an inter-realm key with an 233 intermediate realm that communicates with the remote realm. An 234 authentication path is the sequence of intermediate realms that are 235 transited in communicating from one realm to another. 237 Realms are typically organized hierarchically. Each realm shares a key with 238 its parent and a different key with each child. If an inter-realm key is not 239 directly shared by two realms, the hierarchical organization allows an 240 authentication path to be easily constructed. If a hierarchical organization 241 is not used, it may be necessary to consult a database in order to construct 242 an authentication path between realms. 244 Although realms are typically hierarchical, intermediate realms may be 245 bypassed to achieve cross-realm authentication through alternate 246 authentication paths (these might be established to make communication 247 between two realms more efficient). It is important for the end-service to 248 the authentication protocol. These extensions provide for authentication of 250 Neuman, Ts'o, Kohl Expires: 25 December, 251 1999 253 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 254 1999 256 know which realms were transited when deciding how much faith to place in 257 the authentication process. To facilitate this decision, a field in each 258 ticket contains the names of the realms that were involved in authenticating 259 the client. 261 The application server is ultimately responsible for accepting or rejecting 262 authentication and should check the transited field. The application server 263 may choose to rely on the KDC for the application server's realm to check 264 the transited field. The application server's KDC will set the 265 TRANSITED-POLICY-CHECKED flag in this case. The KDC's for intermediate 266 realms may also check the transited field as they issue 267 ticket-granting-tickets for other realms, but they are encouraged not to do 268 so. A client may request that the KDC's not check the transited field by 269 setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but not 270 required to honor this flag. 272 1.2. Authorization 274 As an authentication service, Kerberos provides a means of verifying the 275 identity of principals on a network. Authentication is usually useful 276 primarily as a first step in the process of authorization, determining 277 whether a client may use a service, which objects the client is allowed to 278 access, and the type of access allowed for each. Kerberos does not, by 279 itself, provide authorization. Possession of a client ticket for a service 280 provides only for authentication of the client to that service, and in the 281 absence of a separate authorization procedure, it should not be considered 282 by an application as authorizing the use of that service. 284 Such separate authorization methods may be implemented as application 285 specific access control functions and may be based on files such as the 286 application server, or on separately issued authorization credentials such 287 as those based on proxies [Neu93] , or on other authorization services. 289 Applications should not be modified to accept the issuance of a service 290 ticket by the Kerberos server (even by an modified Kerberos server) as 291 granting authority to use the service, since such applications may become 292 vulnerable to the bypass of this authorization check in an environment if 293 they interoperate with other KDCs or where other options for application 294 authentication (e.g. the PKTAPP proposal) are provided. 296 1.3. Environmental assumptions 298 Kerberos imposes a few assumptions on the environment in which it can 299 properly function: 301 * 'Denial of service' attacks are not solved with Kerberos. There are 302 places in these protocols where an intruder can prevent an application 303 from participating in the proper authentication steps. Detection and 304 solution of such attacks (some of which can appear to be nnot-uncommon 305 'normal' failure modes for the system) is usually best left to the 306 human administrators and users. 307 * Principals must keep their secret keys secret. If an intruder somehow 308 steals a principal's key, it will be able to masquerade as that 309 principal or impersonate any server to the legitimate principal. 310 * 'Password guessing' attacks are not solved by Kerberos. If a user 311 chooses a poor password, it is possible for an attacker to successfully 312 mount an offline dictionary attack by repeatedly attempting to decrypt, 313 with successive entries from a dictionary, messages obtained which are 314 encrypted under a key derived from the user's password. 315 the authentication protocol. These extensions provide for authentication of 317 Neuman, Ts'o, Kohl Expires: 25 December, 318 1999 320 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 321 1999 323 * Each host on the network must have a clock which is 'loosely 324 synchronized' to the time of the other hosts; this synchronization is 325 used to reduce the bookkeeping needs of application servers when they 326 do replay detection. The degree of "looseness" can be configured on a 327 per-server basis, but is typically on the order of 5 minutes. If the 328 clocks are synchronized over the network, the clock synchronization 329 protocol must itself be secured from network attackers. 330 * Principal identifiers are not recycled on a short-term basis. A typical 331 mode of access control will use access control lists (ACLs) to grant 332 permissions to particular principals. If a stale ACL entry remains for 333 a deleted principal and the principal identifier is reused, the new 334 principal will inherit rights specified in the stale ACL entry. By not 335 re-using principal identifiers, the danger of inadvertent access is 336 removed. 338 1.4. Glossary of terms 340 Below is a list of terms used throughout this document. 342 Authentication 343 Verifying the claimed identity of a principal. 344 Authentication header 345 A record containing a Ticket and an Authenticator to be presented to a 346 server as part of the authentication process. 347 Authentication path 348 A sequence of intermediate realms transited in the authentication 349 process when communicating from one realm to another. 350 Authenticator 351 A record containing information that can be shown to have been recently 352 generated using the session key known only by the client and server. 353 Authorization 354 The process of determining whether a client may use a service, which 355 objects the client is allowed to access, and the type of access allowed 356 for each. 357 Capability 358 A token that grants the bearer permission to access an object or 359 service. In Kerberos, this might be a ticket whose use is restricted by 360 the contents of the authorization data field, but which lists no 361 network addresses, together with the session key necessary to use the 362 ticket. 363 Ciphertext 364 The output of an encryption function. Encryption transforms plaintext 365 into ciphertext. 366 Client 367 A process that makes use of a network service on behalf of a user. Note 368 that in some cases a Server may itself be a client of some other server 369 (e.g. a print server may be a client of a file server). 370 Credentials 371 A ticket plus the secret session key necessary to successfully use that 372 ticket in an authentication exchange. 373 KDC 374 Key Distribution Center, a network service that supplies tickets and 375 temporary session keys; or an instance of that service or the host on 376 which it runs. The KDC services both initial ticket and ticket-granting 377 ticket requests. The initial ticket portion is sometimes referred to as 378 the Authentication Server (or service). The ticket-granting ticket 379 portion is sometimes referred to as the ticket-granting server (or 380 service). 381 the authentication protocol. These extensions provide for authentication of 383 Neuman, Ts'o, Kohl Expires: 25 December, 384 1999 386 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 387 1999 389 Kerberos 390 Aside from the 3-headed dog guarding Hades, the name given to Project 391 Athena's authentication service, the protocol used by that service, or 392 the code used to implement the authentication service. 393 Plaintext 394 The input to an encryption function or the output of a decryption 395 function. Decryption transforms ciphertext into plaintext. 396 Principal 397 A uniquely named client or server instance that participates in a 398 network communication. 399 Principal identifier 400 The name used to uniquely identify each different principal. 401 Seal 402 To encipher a record containing several fields in such a way that the 403 fields cannot be individually replaced without either knowledge of the 404 encryption key or leaving evidence of tampering. 405 Secret key 406 An encryption key shared by a principal and the KDC, distributed 407 outside the bounds of the system, with a long lifetime. In the case of 408 a human user's principal, the secret key is derived from a password. 409 Server 410 A particular Principal which provides a resource to network clients. 411 The server is sometimes refered to as the Application Server. 412 Service 413 A resource provided to network clients; often provided by more than one 414 server (for example, remote file service). 415 Session key 416 A temporary encryption key used between two principals, with a lifetime 417 limited to the duration of a single login "session". 418 Sub-session key 419 A temporary encryption key used between two principals, selected and 420 exchanged by the principals using the session key, and with a lifetime 421 limited to the duration of a single association. 422 Ticket 423 A record that helps a client authenticate itself to a server; it 424 contains the client's identity, a session key, a timestamp, and other 425 information, all sealed using the server's secret key. It only serves 426 to authenticate a client when presented along with a fresh 427 Authenticator. 429 2. Ticket flag uses and requests 431 Each Kerberos ticket contains a set of flags which are used to indicate 432 various attributes of that ticket. Most flags may be requested by a client 433 when the ticket is obtained; some are automatically turned on and off by a 434 Kerberos server as required. The following sections explain what the various 435 flags mean, and gives examples of reasons to use such a flag. 437 2.1. Initial and pre-authenticated tickets 439 The INITIAL flag indicates that a ticket was issued using the AS protocol 440 and not issued based on a ticket-granting ticket. Application servers that 441 want to require the demonstrated knowledge of a client's secret key (e.g. a 442 password-changing program) can insist that this flag be set in any tickets 443 they accept, and thus be assured that the client's key was recently 444 presented to the application client. 446 the authentication protocol. These extensions provide for authentication of 448 Neuman, Ts'o, Kohl Expires: 25 December, 449 1999 451 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 452 1999 454 The PRE-AUTHENT and HW-AUTHENT flags provide addition information about the 455 initial authentication, regardless of whether the current ticket was issued 456 directly (in which case INITIAL will also be set) or issued on the basis of 457 a ticket-granting ticket (in which case the INITIAL flag is clear, but the 458 PRE-AUTHENT and HW-AUTHENT flags are carried forward from the 459 ticket-granting ticket). 461 2.2. Invalid tickets 463 The INVALID flag indicates that a ticket is invalid. Application servers 464 must reject tickets which have this flag set. A postdated ticket will 465 usually be issued in this form. Invalid tickets must be validated by the KDC 466 before use, by presenting them to the KDC in a TGS request with the VALIDATE 467 option specified. The KDC will only validate tickets after their starttime 468 has passed. The validation is required so that postdated tickets which have 469 been stolen before their starttime can be rendered permanently invalid 470 (through a hot-list mechanism) (see section 3.3.3.1). 472 2.3. Renewable tickets 474 Applications may desire to hold tickets which can be valid for long periods 475 of time. However, this can expose their credentials to potential theft for 476 equally long periods, and those stolen credentials would be valid until the 477 expiration time of the ticket(s). Simply using short-lived tickets and 478 obtaining new ones periodically would require the client to have long-term 479 access to its secret key, an even greater risk. Renewable tickets can be 480 used to mitigate the consequences of theft. Renewable tickets have two 481 "expiration times": the first is when the current instance of the ticket 482 expires, and the second is the latest permissible value for an individual 483 expiration time. An application client must periodically (i.e. before it 484 expires) present a renewable ticket to the KDC, with the RENEW option set in 485 the KDC request. The KDC will issue a new ticket with a new session key and 486 a later expiration time. All other fields of the ticket are left unmodified 487 by the renewal process. When the latest permissible expiration time arrives, 488 the ticket expires permanently. At each renewal, the KDC may consult a 489 hot-list to determine if the ticket had been reported stolen since its last 490 renewal; it will refuse to renew such stolen tickets, and thus the usable 491 lifetime of stolen tickets is reduced. 493 The RENEWABLE flag in a ticket is normally only interpreted by the 494 ticket-granting service (discussed below in section 3.3). It can usually be 495 ignored by application servers. However, some particularly careful 496 application servers may wish to disallow renewable tickets. 498 If a renewable ticket is not renewed by its expiration time, the KDC will 499 not renew the ticket. The RENEWABLE flag is reset by default, but a client 500 may request it be set by setting the RENEWABLE option in the KRB_AS_REQ 501 message. If it is set, then the renew-till field in the ticket contains the 502 time after which the ticket may not be renewed. 504 the authentication protocol. These extensions provide for authentication of 506 Neuman, Ts'o, Kohl Expires: 25 December, 507 1999 509 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 510 1999 512 2.4. Postdated tickets 514 Applications may occasionally need to obtain tickets for use much later, 515 e.g. a batch submission system would need tickets to be valid at the time 516 the batch job is serviced. However, it is dangerous to hold valid tickets in 517 a batch queue, since they will be on-line longer and more prone to theft. 518 Postdated tickets provide a way to obtain these tickets from the KDC at job 519 submission time, but to leave them "dormant" until they are activated and 520 validated by a further request of the KDC. If a ticket theft were reported 521 in the interim, the KDC would refuse to validate the ticket, and the thief 522 would be foiled. 524 The MAY-POSTDATE flag in a ticket is normally only interpreted by the 525 ticket-granting service. It can be ignored by application servers. This flag 526 must be set in a ticket-granting ticket in order to issue a postdated ticket 527 based on the presented ticket. It is reset by default; it may be requested 528 by a client by setting the ALLOW-POSTDATE option in the KRB_AS_REQ message. 529 This flag does not allow a client to obtain a postdated ticket-granting 530 ticket; postdated ticket-granting tickets can only by obtained by requesting 531 the postdating in the KRB_AS_REQ message. The life (endtime-starttime) of a 532 postdated ticket will be the remaining life of the ticket-granting ticket at 533 the time of the request, unless the RENEWABLE option is also set, in which 534 case it can be the full life (endtime-starttime) of the ticket-granting 535 ticket. The KDC may limit how far in the future a ticket may be postdated. 537 The POSTDATED flag indicates that a ticket has been postdated. The 538 application server can check the authtime field in the ticket to see when 539 the original authentication occurred. Some services may choose to reject 540 postdated tickets, or they may only accept them within a certain period 541 after the original authentication. When the KDC issues a POSTDATED ticket, 542 it will also be marked as INVALID, so that the application client must 543 present the ticket to the KDC to be validated before use. 545 2.5. Proxiable and proxy tickets 547 At times it may be necessary for a principal to allow a service to perform 548 an operation on its behalf. The service must be able to take on the identity 549 of the client, but only for a particular purpose. A principal can allow a 550 service to take on the principal's identity for a particular purpose by 551 granting it a proxy. 553 The process of granting a proxy using the proxy and proxiable flags is used 554 to provide credentials for use with specific services. Though conceptually 555 also a proxy, user's wishing to delegate their identity for ANY purpose must 556 use the ticket forwarding mechanism described in the next section to forward 557 a ticket granting ticket. 559 The PROXIABLE flag in a ticket is normally only interpreted by the 560 ticket-granting service. It can be ignored by application servers. When set, 561 this flag tells the ticket-granting server that it is OK to issue a new 562 ticket (but not a ticket-granting ticket) with a different network address 563 based on this ticket. This flag is set if requested by the client on initial 564 authentication. By default, the client will request that it be set when 565 requesting a ticket granting ticket, and reset when requesting any other 566 ticket. 568 the authentication protocol. These extensions provide for authentication of 570 Neuman, Ts'o, Kohl Expires: 25 December, 571 1999 573 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 574 1999 576 This flag allows a client to pass a proxy to a server to perform a remote 577 request on its behalf, e.g. a print service client can give the print server 578 a proxy to access the client's files on a particular file server in order to 579 satisfy a print request. 581 In order to complicate the use of stolen credentials, Kerberos tickets are 582 usually valid from only those network addresses specifically included in the 583 ticket[4]. When granting a proxy, the client must specify the new network 584 address from which the proxy is to be used, or indicate that the proxy is to 585 be issued for use from any address. 587 The PROXY flag is set in a ticket by the TGS when it issues a proxy ticket. 588 Application servers may check this flag and at their option they may require 589 additional authentication from the agent presenting the proxy in order to 590 provide an audit trail. 592 2.6. Forwardable tickets 594 Authentication forwarding is an instance of a proxy where the service is 595 granted complete use of the client's identity. An example where it might be 596 used is when a user logs in to a remote system and wants authentication to 597 work from that system as if the login were local. 599 The FORWARDABLE flag in a ticket is normally only interpreted by the 600 ticket-granting service. It can be ignored by application servers. The 601 FORWARDABLE flag has an interpretation similar to that of the PROXIABLE 602 flag, except ticket-granting tickets may also be issued with different 603 network addresses. This flag is reset by default, but users may request that 604 it be set by setting the FORWARDABLE option in the AS request when they 605 request their initial ticket- granting ticket. 607 This flag allows for authentication forwarding without requiring the user to 608 enter a password again. If the flag is not set, then authentication 609 forwarding is not permitted, but the same result can still be achieved if 610 the user engages in the AS exchange specifying the requested network 611 addresses and supplies a password. 613 The FORWARDED flag is set by the TGS when a client presents a ticket with 614 the FORWARDABLE flag set and requests a forwarded ticket by specifying the 615 FORWARDED KDC option and supplying a set of addresses for the new ticket. It 616 is also set in all tickets issued based on tickets with the FORWARDED flag 617 set. Application servers may choose to process FORWARDED tickets differently 618 than non-FORWARDED tickets. 620 2.7. Other KDC options 622 There are two additional options which may be set in a client's request of 623 the KDC. The RENEWABLE-OK option indicates that the client will accept a 624 renewable ticket if a ticket with the requested life cannot otherwise be 625 provided. If a ticket with the requested life cannot be provided, then the 626 KDC may issue a renewable ticket with a renew-till equal to the the 627 requested endtime. The value of the renew-till field may still be adjusted 628 by site-determined limits or limits imposed by the individual principal or 629 server. 631 The ENC-TKT-IN-SKEY option is honored only by the ticket-granting service. 632 It indicates that the ticket to be issued for the end server is to be 633 encrypted in the session key from the a additional second ticket-granting 634 ticket provided with the request. See section 3.3.3 for specific details. 636 the authentication protocol. These extensions provide for authentication of 638 Neuman, Ts'o, Kohl Expires: 25 December, 639 1999 641 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 642 1999 644 3. Message Exchanges 646 The following sections describe the interactions between network clients and 647 servers and the messages involved in those exchanges. 649 3.1. The Authentication Service Exchange 651 Summary 652 Message direction Message type Section 653 1. Client to Kerberos KRB_AS_REQ 5.4.1 654 2. Kerberos to client KRB_AS_REP or 5.4.2 655 KRB_ERROR 5.9.1 657 The Authentication Service (AS) Exchange between the client and the Kerberos 658 Authentication Server is initiated by a client when it wishes to obtain 659 authentication credentials for a given server but currently holds no 660 credentials. In its basic form, the client's secret key is used for 661 encryption and decryption. This exchange is typically used at the initiation 662 of a login session to obtain credentials for a Ticket-Granting Server which 663 will subsequently be used to obtain credentials for other servers (see 664 section 3.3) without requiring further use of the client's secret key. This 665 exchange is also used to request credentials for services which must not be 666 mediated through the Ticket-Granting Service, but rather require a 667 principal's secret key, such as the password-changing service[5]. This 668 exchange does not by itself provide any assurance of the the identity of the 669 user[6]. 671 The exchange consists of two messages: KRB_AS_REQ from the client to 672 Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these 673 messages are described in sections 5.4.1, 5.4.2, and 5.9.1. 675 In the request, the client sends (in cleartext) its own identity and the 676 identity of the server for which it is requesting credentials. The response, 677 KRB_AS_REP, contains a ticket for the client to present to the server, and a 678 session key that will be shared by the client and the server. The session 679 key and additional information are encrypted in the client's secret key. The 680 KRB_AS_REP message contains information which can be used to detect replays, 681 and to associate it with the message to which it replies. Various errors can 682 occur; these are indicated by an error response (KRB_ERROR) instead of the 683 KRB_AS_REP response. The error message is not encrypted. The KRB_ERROR 684 message contains information which can be used to associate it with the 685 message to which it replies. The lack of encryption in the KRB_ERROR message 686 precludes the ability to detect replays, fabrications, or modifications of 687 such messages. 689 Without preautentication, the authentication server does not know whether 690 the client is actually the principal named in the request. It simply sends a 691 reply without knowing or caring whether they are the same. This is 692 acceptable because nobody but the principal whose identity was given in the 693 request will be able to use the reply. Its critical information is encrypted 694 in that principal's key. The initial request supports an optional field that 695 can be used to pass additional information that might be needed for the 696 initial exchange. This field may be used for preauthentication as described 697 in section [hl<>]. 699 the authentication protocol. These extensions provide for authentication of 701 Neuman, Ts'o, Kohl Expires: 25 December, 702 1999 704 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 705 1999 707 3.1.1. Generation of KRB_AS_REQ message 709 The client may specify a number of options in the initial request. Among 710 these options are whether pre-authentication is to be performed; whether the 711 requested ticket is to be renewable, proxiable, or forwardable; whether it 712 should be postdated or allow postdating of derivative tickets; and whether a 713 renewable ticket will be accepted in lieu of a non-renewable ticket if the 714 requested ticket expiration date cannot be satisfied by a non-renewable 715 ticket (due to configuration constraints; see section 4). See section A.1 716 for pseudocode. 718 The client prepares the KRB_AS_REQ message and sends it to the KDC. 720 3.1.2. Receipt of KRB_AS_REQ message 722 If all goes well, processing the KRB_AS_REQ message will result in the 723 creation of a ticket for the client to present to the server. The format for 724 the ticket is described in section 5.3.1. The contents of the ticket are 725 determined as follows. 727 3.1.3. Generation of KRB_AS_REP message 729 The authentication server looks up the client and server principals named in 730 the KRB_AS_REQ in its database, extracting their respective keys. If 731 required, the server pre-authenticates the request, and if the 732 pre-authentication check fails, an error message with the code 733 KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate the 734 requested encryption type, an error message with code KDC_ERR_ETYPE_NOSUPP 735 is returned. Otherwise it generates a 'random' session key[7]. 737 If there are multiple encryption keys registered for a client in the 738 Kerberos database (or if the key registered supports multiple encryption 739 types; e.g. DES-CBC-CRC and DES-CBC-MD5), then the etype field from the AS 740 request is used by the KDC to select the encryption method to be used for 741 encrypting the response to the client. If there is more than one supported, 742 strong encryption type in the etype list, the first valid etype for which an 743 encryption key is available is used. The encryption method used to respond 744 to a TGS request is taken from the keytype of the session key found in the 745 ticket granting ticket. [***I will change the example keytypes to be 3DES 746 based examples 7/14***] 748 When the etype field is present in a KDC request, whether an AS or TGS 749 request, the KDC will attempt to assign the type of the random session key 750 from the list of methods in the etype field. The KDC will select the 751 appropriate type using the list of methods provided together with 752 information from the Kerberos database indicating acceptable encryption 753 methods for the application server. The KDC will not issue tickets with a 754 weak session key encryption type. 756 If the requested start time is absent, indicates a time in the past, or is 757 within the window of acceptable clock skew for the KDC and the POSTDATE 758 option has not been specified, then the start time of the ticket is set to 759 the authentication server's current time. If it indicates a time in the 760 future beyond the acceptable clock skew, but the POSTDATED option has not 761 been specified then the error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise 762 the requested start time is checked against the policy of the local realm 763 (the administrator might decide to prohibit certain types or ranges of 764 postdated tickets), and if acceptable, the ticket's start time is set as 765 the authentication protocol. These extensions provide for authentication of 767 Neuman, Ts'o, Kohl Expires: 25 December, 768 1999 770 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 771 1999 773 requested and the INVALID flag is set in the new ticket. The postdated 774 ticket must be validated before use by presenting it to the KDC after the 775 start time has been reached. 777 The expiration time of the ticket will be set to the minimum of the 778 following: 780 * The expiration time (endtime) requested in the KRB_AS_REQ message. 781 * The ticket's start time plus the maximum allowable lifetime associated 782 with the client principal (the authentication server's database 783 includes a maximum ticket lifetime field in each principal's record; 784 see section 4). 785 * The ticket's start time plus the maximum allowable lifetime associated 786 with the server principal. 787 * The ticket's start time plus the maximum lifetime set by the policy of 788 the local realm. 790 If the requested expiration time minus the start time (as determined above) 791 is less than a site-determined minimum lifetime, an error message with code 792 KDC_ERR_NEVER_VALID is returned. If the requested expiration time for the 793 ticket exceeds what was determined as above, and if the 'RENEWABLE-OK' 794 option was requested, then the 'RENEWABLE' flag is set in the new ticket, 795 and the renew-till value is set as if the 'RENEWABLE' option were requested 796 (the field and option names are described fully in section 5.4.1). 798 If the RENEWABLE option has been requested or if the RENEWABLE-OK option has 799 been set and a renewable ticket is to be issued, then the renew-till field 800 is set to the minimum of: 802 * Its requested value. 803 * The start time of the ticket plus the minimum of the two maximum 804 renewable lifetimes associated with the principals' database entries. 805 * The start time of the ticket plus the maximum renewable lifetime set by 806 the policy of the local realm. 808 The flags field of the new ticket will have the following options set if 809 they have been requested and if the policy of the local realm allows: 810 FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. If the new 811 ticket is post-dated (the start time is in the future), its INVALID flag 812 will also be set. 814 If all of the above succeed, the server formats a KRB_AS_REP message (see 815 section 5.4.2), copying the addresses in the request into the caddr of the 816 response, placing any required pre-authentication data into the padata of 817 the response, and encrypts the ciphertext part in the client's key using the 818 requested encryption method, and sends it to the client. See section A.2 for 819 pseudocode. 821 3.1.4. Generation of KRB_ERROR message 823 Several errors can occur, and the Authentication Server responds by 824 returning an error message, KRB_ERROR, to the client, with the error-code 825 and e-text fields set to appropriate values. The error message contents and 826 details are described in Section 5.9.1. 828 the authentication protocol. These extensions provide for authentication of 830 Neuman, Ts'o, Kohl Expires: 25 December, 831 1999 833 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 834 1999 836 3.1.5. Receipt of KRB_AS_REP message 838 If the reply message type is KRB_AS_REP, then the client verifies that the 839 cname and crealm fields in the cleartext portion of the reply match what it 840 requested. If any padata fields are present, they may be used to derive the 841 proper secret key to decrypt the message. The client decrypts the encrypted 842 part of the response using its secret key, verifies that the nonce in the 843 encrypted part matches the nonce it supplied in its request (to detect 844 replays). It also verifies that the sname and srealm in the response match 845 those in the request (or are otherwise expected values), and that the host 846 address field is also correct. It then stores the ticket, session key, start 847 and expiration times, and other information for later use. The 848 key-expiration field from the encrypted part of the response may be checked 849 to notify the user of impending key expiration (the client program could 850 then suggest remedial action, such as a password change). See section A.3 851 for pseudocode. 853 Proper decryption of the KRB_AS_REP message is not sufficient to verify the 854 identity of the user; the user and an attacker could cooperate to generate a 855 KRB_AS_REP format message which decrypts properly but is not from the proper 856 KDC. If the host wishes to verify the identity of the user, it must require 857 the user to present application credentials which can be verified using a 858 securely-stored secret key for the host. If those credentials can be 859 verified, then the identity of the user can be assured. 861 3.1.6. Receipt of KRB_ERROR message 863 If the reply message type is KRB_ERROR, then the client interprets it as an 864 error and performs whatever application-specific tasks are necessary to 865 recover. 867 3.2. The Client/Server Authentication Exchange 869 Summary 870 Message direction Message type Section 871 Client to Application server KRB_AP_REQ 5.5.1 872 [optional] Application server to client KRB_AP_REP or 5.5.2 873 KRB_ERROR 5.9.1 875 The client/server authentication (CS) exchange is used by network 876 applications to authenticate the client to the server and vice versa. The 877 client must have already acquired credentials for the server using the AS or 878 TGS exchange. 880 3.2.1. The KRB_AP_REQ message 882 The KRB_AP_REQ contains authentication information which should be part of 883 the first message in an authenticated transaction. It contains a ticket, an 884 authenticator, and some additional bookkeeping information (see section 885 5.5.1 for the exact format). The ticket by itself is insufficient to 886 authenticate a client, since tickets are passed across the network in 887 cleartext[DS90], so the authenticator is used to prevent invalid replay of 888 tickets by proving to the server that the client knows the session key of 889 the ticket and thus is entitled to use the ticket. The KRB_AP_REQ message is 890 referred to elsewhere as the 'authentication header.' 892 the authentication protocol. These extensions provide for authentication of 894 Neuman, Ts'o, Kohl Expires: 25 December, 895 1999 897 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 898 1999 900 3.2.2. Generation of a KRB_AP_REQ message 902 When a client wishes to initiate authentication to a server, it obtains 903 (either through a credentials cache, the AS exchange, or the TGS exchange) a 904 ticket and session key for the desired service. The client may re-use any 905 tickets it holds until they expire. To use a ticket the client constructs a 906 new Authenticator from the the system time, its name, and optionally an 907 application specific checksum, an initial sequence number to be used in 908 KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in 909 negotiations for a session key unique to this particular session. 910 Authenticators may not be re-used and will be rejected if replayed to a 911 server[LGDSR87]. If a sequence number is to be included, it should be 912 randomly chosen so that even after many messages have been exchanged it is 913 not likely to collide with other sequence numbers in use. 915 The client may indicate a requirement of mutual authentication or the use of 916 a session-key based ticket by setting the appropriate flag(s) in the 917 ap-options field of the message. 919 The Authenticator is encrypted in the session key and combined with the 920 ticket to form the KRB_AP_REQ message which is then sent to the end server 921 along with any additional application-specific information. See section A.9 922 for pseudocode. 924 3.2.3. Receipt of KRB_AP_REQ message 926 Authentication is based on the server's current time of day (clocks must be 927 loosely synchronized), the authenticator, and the ticket. Several errors are 928 possible. If an error occurs, the server is expected to reply to the client 929 with a KRB_ERROR message. This message may be encapsulated in the 930 application protocol if its 'raw' form is not acceptable to the protocol. 931 The format of error messages is described in section 5.9.1. 933 The algorithm for verifying authentication information is as follows. If the 934 message type is not KRB_AP_REQ, the server returns the KRB_AP_ERR_MSG_TYPE 935 error. If the key version indicated by the Ticket in the KRB_AP_REQ is not 936 one the server can use (e.g., it indicates an old key, and the server no 937 longer possesses a copy of the old key), the KRB_AP_ERR_BADKEYVER error is 938 returned. If the USE-SESSION-KEY flag is set in the ap-options field, it 939 indicates to the server that the ticket is encrypted in the session key from 940 the server's ticket-granting ticket rather than its secret key[10]. Since it 941 is possible for the server to be registered in multiple realms, with 942 different keys in each, the srealm field in the unencrypted portion of the 943 ticket in the KRB_AP_REQ is used to specify which secret key the server 944 should use to decrypt that ticket. The KRB_AP_ERR_NOKEY error code is 945 returned if the server doesn't have the proper key to decipher the ticket. 947 The ticket is decrypted using the version of the server's key specified by 948 the ticket. If the decryption routines detect a modification of the ticket 949 (each encryption system must provide safeguards to detect modified 950 ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY error is returned 951 (chances are good that different keys were used to encrypt and decrypt). 953 The authenticator is decrypted using the session key extracted from the 954 decrypted ticket. If decryption shows it to have been modified, the 955 KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the client 956 from the ticket are compared against the same fields in the authenticator. 957 If they don't match, the KRB_AP_ERR_BADMATCH error is returned (they might 958 the authentication protocol. These extensions provide for authentication of 960 Neuman, Ts'o, Kohl Expires: 25 December, 961 1999 963 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 964 1999 966 not match, for example, if the wrong session key was used to encrypt the 967 authenticator). The addresses in the ticket (if any) are then searched for 968 an address matching the operating-system reported address of the client. If 969 no match is found or the server insists on ticket addresses but none are 970 present in the ticket, the KRB_AP_ERR_BADADDR error is returned. 972 If the local (server) time and the client time in the authenticator differ 973 by more than the allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW 974 error is returned. If the server name, along with the client name, time and 975 microsecond fields from the Authenticator match any recently-seen such 976 tuples, the KRB_AP_ERR_REPEAT error is returned[11]. The server must 977 remember any authenticator presented within the allowable clock skew, so 978 that a replay attempt is guaranteed to fail. If a server loses track of any 979 authenticator presented within the allowable clock skew, it must reject all 980 requests until the clock skew interval has passed. This assures that any 981 lost or re-played authenticators will fall outside the allowable clock skew 982 and can no longer be successfully replayed (If this is not done, an attacker 983 could conceivably record the ticket and authenticator sent over the network 984 to a server, then disable the client's host, pose as the disabled host, and 985 replay the ticket and authenticator to subvert the authentication.). If a 986 sequence number is provided in the authenticator, the server saves it for 987 later use in processing KRB_SAFE and/or KRB_PRIV messages. If a subkey is 988 present, the server either saves it for later use or uses it to help 989 generate its own choice for a subkey to be returned in a KRB_AP_REP message. 991 The server computes the age of the ticket: local (server) time minus the 992 start time inside the Ticket. If the start time is later than the current 993 time by more than the allowable clock skew or if the INVALID flag is set in 994 the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Otherwise, if the 995 current time is later than end time by more than the allowable clock skew, 996 the KRB_AP_ERR_TKT_EXPIRED error is returned. 998 If all these checks succeed without an error, the server is assured that the 999 client possesses the credentials of the principal named in the ticket and 1000 thus, the client has been authenticated to the server. See section A.10 for 1001 pseudocode. 1003 Passing these checks provides only authentication of the named principal; it 1004 does not imply authorization to use the named service. Applications must 1005 make a separate authorization decisions based upon the authenticated name of 1006 the user, the requested operation, local acces control information such as 1007 that contained in a .k5login or .k5users file, and possibly a separate 1008 distributed authorization service. 1010 3.2.4. Generation of a KRB_AP_REP message 1012 Typically, a client's request will include both the authentication 1013 information and its initial request in the same message, and the server need 1014 not explicitly reply to the KRB_AP_REQ. However, if mutual authentication 1015 (not only authenticating the client to the server, but also the server to 1016 the client) is being performed, the KRB_AP_REQ message will have 1017 MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message is 1018 required in response. As with the error message, this message may be 1019 encapsulated in the application protocol if its "raw" form is not acceptable 1020 to the application's protocol. The timestamp and microsecond field used in 1021 the reply must be the client's timestamp and microsecond field (as provided 1022 in the authenticator)[12]. If a sequence number is to be included, it should 1023 be randomly chosen as described above for the authenticator. A subkey may be 1024 the authentication protocol. These extensions provide for authentication of 1026 Neuman, Ts'o, Kohl Expires: 25 December, 1027 1999 1029 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 1030 1999 1032 included if the server desires to negotiate a different subkey. The 1033 KRB_AP_REP message is encrypted in the session key extracted from the 1034 ticket. See section A.11 for pseudocode. 1036 3.2.5. Receipt of KRB_AP_REP message 1038 If a KRB_AP_REP message is returned, the client uses the session key from 1039 the credentials obtained for the server[13] to decrypt the message, and 1040 verifies that the timestamp and microsecond fields match those in the 1041 Authenticator it sent to the server. If they match, then the client is 1042 assured that the server is genuine. The sequence number and subkey (if 1043 present) are retained for later use. See section A.12 for pseudocode. 1045 3.2.6. Using the encryption key 1047 After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and server 1048 share an encryption key which can be used by the application. The 'true 1049 session key' to be used for KRB_PRIV, KRB_SAFE, or other 1050 application-specific uses may be chosen by the application based on the 1051 subkeys in the KRB_AP_REP message and the authenticator[14]. In some cases, 1052 the use of this session key will be implicit in the protocol; in others the 1053 method of use must be chosen from several alternatives. We leave the 1054 protocol negotiations of how to use the key (e.g. selecting an encryption or 1055 checksum type) to the application programmer; the Kerberos protocol does not 1056 constrain the implementation options, but an example of how this might be 1057 done follows. 1059 One way that an application may choose to negotiate a key to be used for 1060 subequent integrity and privacy protection is for the client to propose a 1061 key in the subkey field of the authenticator. The server can then choose a 1062 key using the proposed key from the client as input, returning the new 1063 subkey in the subkey field of the application reply. This key could then be 1064 used for subsequent communication. To make this example more concrete, if 1065 the encryption method in use required a 56 bit key, and for whatever reason, 1066 one of the parties was prevented from using a key with more than 40 unknown 1067 bits, this method would allow the the party which is prevented from using 1068 more than 40 bits to either propose (if the client) an initial key with a 1069 known quantity for 16 of those bits, or to mask 16 of the bits (if the 1070 server) with the known quantity. The application implementor is warned, 1071 however, that this is only an example, and that an analysis of the 1072 particular crytosystem to be used, and the reasons for limiting the key 1073 length, must be made before deciding whether it is acceptable to mask bits 1074 of the key. 1076 With both the one-way and mutual authentication exchanges, the peers should 1077 take care not to send sensitive information to each other without proper 1078 assurances. In particular, applications that require privacy or integrity 1079 should use the KRB_AP_REP response from the server to client to assure both 1080 client and server of their peer's identity. If an application protocol 1081 requires privacy of its messages, it can use the KRB_PRIV message (section 1082 3.5). The KRB_SAFE message (section 3.4) can be used to assure integrity. 1084 the authentication protocol. These extensions provide for authentication of 1086 Neuman, Ts'o, Kohl Expires: 25 December, 1087 1999 1089 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 1090 1999 1092 3.3. The Ticket-Granting Service (TGS) Exchange 1094 Summary 1095 Message direction Message type Section 1096 1. Client to Kerberos KRB_TGS_REQ 5.4.1 1097 2. Kerberos to client KRB_TGS_REP or 5.4.2 1098 KRB_ERROR 5.9.1 1100 The TGS exchange between a client and the Kerberos Ticket-Granting Server is 1101 initiated by a client when it wishes to obtain authentication credentials 1102 for a given server (which might be registered in a remote realm), when it 1103 wishes to renew or validate an existing ticket, or when it wishes to obtain 1104 a proxy ticket. In the first case, the client must already have acquired a 1105 ticket for the Ticket-Granting Service using the AS exchange (the 1106 ticket-granting ticket is usually obtained when a client initially 1107 authenticates to the system, such as when a user logs in). The message 1108 format for the TGS exchange is almost identical to that for the AS exchange. 1109 The primary difference is that encryption and decryption in the TGS exchange 1110 does not take place under the client's key. Instead, the session key from 1111 the ticket-granting ticket or renewable ticket, or sub-session key from an 1112 Authenticator is used. As is the case for all application servers, expired 1113 tickets are not accepted by the TGS, so once a renewable or ticket-granting 1114 ticket expires, the client must use a separate exchange to obtain valid 1115 tickets. 1117 The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from the 1118 client to the Kerberos Ticket-Granting Server, and a reply (KRB_TGS_REP or 1119 KRB_ERROR). The KRB_TGS_REQ message includes information authenticating the 1120 client plus a request for credentials. The authentication information 1121 consists of the authentication header (KRB_AP_REQ) which includes the 1122 client's previously obtained ticket-granting, renewable, or invalid ticket. 1123 In the ticket-granting ticket and proxy cases, the request may include one 1124 or more of: a list of network addresses, a collection of typed authorization 1125 data to be sealed in the ticket for authorization use by the application 1126 server, or additional tickets (the use of which are described later). The 1127 TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted in the 1128 session key from the ticket-granting ticket or renewable ticket, or if 1129 present, in the sub-session key from the Authenticator (part of the 1130 authentication header). The KRB_ERROR message contains an error code and 1131 text explaining what went wrong. The KRB_ERROR message is not encrypted. The 1132 KRB_TGS_REP message contains information which can be used to detect 1133 replays, and to associate it with the message to which it replies. The 1134 KRB_ERROR message also contains information which can be used to associate 1135 it with the message to which it replies, but the lack of encryption in the 1136 KRB_ERROR message precludes the ability to detect replays or fabrications of 1137 such messages. 1139 3.3.1. Generation of KRB_TGS_REQ message 1141 Before sending a request to the ticket-granting service, the client must 1142 determine in which realm the application server is registered[15]. If the 1143 client does not already possess a ticket-granting ticket for the appropriate 1144 realm, then one must be obtained. This is first attempted by requesting a 1145 ticket-granting ticket for the destination realm from a Kerberos server for 1146 which the client does posess a ticket-granting ticket (using the KRB_TGS_REQ 1147 message recursively). The Kerberos server may return a TGT for the desired 1148 realm in which case one can proceed. Alternatively, the Kerberos server may 1149 return a TGT for a realm which is 'closer' to the desired realm (further 1150 the authentication protocol. These extensions provide for authentication of 1152 Neuman, Ts'o, Kohl Expires: 25 December, 1153 1999 1155 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 1156 1999 1158 along the standard hierarchical path), in which case this step must be 1159 repeated with a Kerberos server in the realm specified in the returned TGT. 1160 If neither are returned, then the request must be retried with a Kerberos 1161 server for a realm higher in the hierarchy. This request will itself require 1162 a ticket-granting ticket for the higher realm which must be obtained by 1163 recursively applying these directions. 1165 Once the client obtains a ticket-granting ticket for the appropriate realm, 1166 it determines which Kerberos servers serve that realm, and contacts one. The 1167 list might be obtained through a configuration file or network service or it 1168 may be generated from the name of the realm; as long as the secret keys 1169 exchanged by realms are kept secret, only denial of service results from 1170 using a false Kerberos server. 1172 As in the AS exchange, the client may specify a number of options in the 1173 KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ message, providing 1174 an authentication header as an element of the padata field, and including 1175 the same fields as used in the KRB_AS_REQ message along with several 1176 optional fields: the enc-authorization-data field for application server use 1177 and additional tickets required by some options. 1179 In preparing the authentication header, the client can select a sub-session 1180 key under which the response from the Kerberos server will be encrypted[16]. 1181 If the sub-session key is not specified, the session key from the 1182 ticket-granting ticket will be used. If the enc-authorization-data is 1183 present, it must be encrypted in the sub-session key, if present, from the 1184 authenticator portion of the authentication header, or if not present, using 1185 the session key from the ticket-granting ticket. 1187 Once prepared, the message is sent to a Kerberos server for the destination 1188 realm. See section A.5 for pseudocode. 1190 3.3.2. Receipt of KRB_TGS_REQ message 1192 The KRB_TGS_REQ message is processed in a manner similar to the KRB_AS_REQ 1193 message, but there are many additional checks to be performed. First, the 1194 Kerberos server must determine which server the accompanying ticket is for 1195 and it must select the appropriate key to decrypt it. For a normal 1196 KRB_TGS_REQ message, it will be for the ticket granting service, and the 1197 TGS's key will be used. If the TGT was issued by another realm, then the 1198 appropriate inter-realm key must be used. If the accompanying ticket is not 1199 a ticket granting ticket for the current realm, but is for an application 1200 server in the current realm, the RENEW, VALIDATE, or PROXY options are 1201 specified in the request, and the server for which a ticket is requested is 1202 the server named in the accompanying ticket, then the KDC will decrypt the 1203 ticket in the authentication header using the key of the server for which it 1204 was issued. If no ticket can be found in the padata field, the 1205 KDC_ERR_PADATA_TYPE_NOSUPP error is returned. 1207 Once the accompanying ticket has been decrypted, the user-supplied checksum 1208 in the Authenticator must be verified against the contents of the request, 1209 and the message rejected if the checksums do not match (with an error code 1210 of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or not 1211 collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM). If the 1212 checksum type is not supported, the KDC_ERR_SUMTYPE_NOSUPP error is 1213 returned. If the authorization-data are present, they are decrypted using 1214 the sub-session key from the Authenticator. 1216 If any of the decryptions indicate failed integrity checks, the 1217 KRB_AP_ERR_BAD_INTEGRITY error is returned. 1218 the authentication protocol. These extensions provide for authentication of 1220 Neuman, Ts'o, Kohl Expires: 25 December, 1221 1999 1223 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 1224 1999 1226 3.3.3. Generation of KRB_TGS_REP message 1228 The KRB_TGS_REP message shares its format with the KRB_AS_REP (KRB_KDC_REP), 1229 but with its type field set to KRB_TGS_REP. The detailed specification is in 1230 section 5.4.2. 1232 The response will include a ticket for the requested server. The Kerberos 1233 database is queried to retrieve the record for the requested server 1234 (including the key with which the ticket will be encrypted). If the request 1235 is for a ticket granting ticket for a remote realm, and if no key is shared 1236 with the requested realm, then the Kerberos server will select the realm 1237 "closest" to the requested realm with which it does share a key, and use 1238 that realm instead. This is the only case where the response from the KDC 1239 will be for a different server than that requested by the client. 1241 By default, the address field, the client's name and realm, the list of 1242 transited realms, the time of initial authentication, the expiration time, 1243 and the authorization data of the newly-issued ticket will be copied from 1244 the ticket-granting ticket (TGT) or renewable ticket. If the transited field 1245 needs to be updated, but the transited type is not supported, the 1246 KDC_ERR_TRTYPE_NOSUPP error is returned. 1248 If the request specifies an endtime, then the endtime of the new ticket is 1249 set to the minimum of (a) that request, (b) the endtime from the TGT, and 1250 (c) the starttime of the TGT plus the minimum of the maximum life for the 1251 application server and the maximum life for the local realm (the maximum 1252 life for the requesting principal was already applied when the TGT was 1253 issued). If the new ticket is to be a renewal, then the endtime above is 1254 replaced by the minimum of (a) the value of the renew_till field of the 1255 ticket and (b) the starttime for the new ticket plus the life 1256 (endtime-starttime) of the old ticket. 1258 If the FORWARDED option has been requested, then the resulting ticket will 1259 contain the addresses specified by the client. This option will only be 1260 honored if the FORWARDABLE flag is set in the TGT. The PROXY option is 1261 similar; the resulting ticket will contain the addresses specified by the 1262 client. It will be honored only if the PROXIABLE flag in the TGT is set. The 1263 PROXY option will not be honored on requests for additional ticket-granting 1264 tickets. 1266 If the requested start time is absent, indicates a time in the past, or is 1267 within the window of acceptable clock skew for the KDC and the POSTDATE 1268 option has not been specified, then the start time of the ticket is set to 1269 the authentication server's current time. If it indicates a time in the 1270 future beyond the acceptable clock skew, but the POSTDATED option has not 1271 been specified or the MAY-POSTDATE flag is not set in the TGT, then the 1272 error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the ticket-granting 1273 ticket has the MAY-POSTDATE flag set, then the resulting ticket will be 1274 postdated and the requested starttime is checked against the policy of the 1275 local realm. If acceptable, the ticket's start time is set as requested, and 1276 the INVALID flag is set. The postdated ticket must be validated before use 1277 by presenting it to the KDC after the starttime has been reached. However, 1278 in no case may the starttime, endtime, or renew-till time of a newly-issued 1279 postdated ticket extend beyond the renew-till time of the ticket-granting 1280 ticket. 1282 the authentication protocol. These extensions provide for authentication of 1284 Neuman, Ts'o, Kohl Expires: 25 December, 1285 1999 1287 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 1288 1999 1290 If the ENC-TKT-IN-SKEY option has been specified and an additional ticket 1291 has been included in the request, the KDC will decrypt the additional ticket 1292 using the key for the server to which the additional ticket was issued and 1293 verify that it is a ticket-granting ticket. If the name of the requested 1294 server is missing from the request, the name of the client in the additional 1295 ticket will be used. Otherwise the name of the requested server will be 1296 compared to the name of the client in the additional ticket and if 1297 different, the request will be rejected. If the request succeeds, the 1298 session key from the additional ticket will be used to encrypt the new 1299 ticket that is issued instead of using the key of the server for which the 1300 new ticket will be used[17]. 1302 If the name of the server in the ticket that is presented to the KDC as part 1303 of the authentication header is not that of the ticket-granting server 1304 itself, the server is registered in the realm of the KDC, and the RENEW 1305 option is requested, then the KDC will verify that the RENEWABLE flag is set 1306 in the ticket, that the INVALID flag is not set in the ticket, and that the 1307 renew_till time is still in the future. If the VALIDATE option is rqeuested, 1308 the KDC will check that the starttime has passed and the INVALID flag is 1309 set. If the PROXY option is requested, then the KDC will check that the 1310 PROXIABLE flag is set in the ticket. If the tests succeed, and the ticket 1311 passes the hotlist check described in the next paragraph, the KDC will issue 1312 the appropriate new ticket. 1314 3.3.3.1. Checking for revoked tickets 1316 Whenever a request is made to the ticket-granting server, the presented 1317 ticket(s) is(are) checked against a hot-list of tickets which have been 1318 canceled. This hot-list might be implemented by storing a range of issue 1319 timestamps for 'suspect tickets'; if a presented ticket had an authtime in 1320 that range, it would be rejected. In this way, a stolen ticket-granting 1321 ticket or renewable ticket cannot be used to gain additional tickets 1322 (renewals or otherwise) once the theft has been reported. Any normal ticket 1323 obtained before it was reported stolen will still be valid (because they 1324 require no interaction with the KDC), but only until their normal expiration 1325 time. 1327 The ciphertext part of the response in the KRB_TGS_REP message is encrypted 1328 in the sub-session key from the Authenticator, if present, or the session 1329 key key from the ticket-granting ticket. It is not encrypted using the 1330 client's secret key. Furthermore, the client's key's expiration date and the 1331 key version number fields are left out since these values are stored along 1332 with the client's database record, and that record is not needed to satisfy 1333 a request based on a ticket-granting ticket. See section A.6 for pseudocode. 1335 3.3.3.2. Encoding the transited field 1337 If the identity of the server in the TGT that is presented to the KDC as 1338 part of the authentication header is that of the ticket-granting service, 1339 but the TGT was issued from another realm, the KDC will look up the 1340 inter-realm key shared with that realm and use that key to decrypt the 1341 ticket. If the ticket is valid, then the KDC will honor the request, subject 1342 to the constraints outlined above in the section describing the AS exchange. 1343 The realm part of the client's identity will be taken from the 1344 ticket-granting ticket. The name of the realm that issued the 1345 ticket-granting ticket will be added to the transited field of the ticket to 1346 be issued. This is accomplished by reading the transited field from the 1347 ticket-granting ticket (which is treated as an unordered set of realm 1348 the authentication protocol. These extensions provide for authentication of 1350 Neuman, Ts'o, Kohl Expires: 25 December, 1351 1999 1353 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 1354 1999 1356 names), adding the new realm to the set, then constructing and writing out 1357 its encoded (shorthand) form (this may involve a rearrangement of the 1358 existing encoding). 1360 Note that the ticket-granting service does not add the name of its own 1361 realm. Instead, its responsibility is to add the name of the previous realm. 1362 This prevents a malicious Kerberos server from intentionally leaving out its 1363 own name (it could, however, omit other realms' names). 1365 The names of neither the local realm nor the principal's realm are to be 1366 included in the transited field. They appear elsewhere in the ticket and 1367 both are known to have taken part in authenticating the principal. Since the 1368 endpoints are not included, both local and single-hop inter-realm 1369 authentication result in a transited field that is empty. 1371 Because the name of each realm transited is added to this field, it might 1372 potentially be very long. To decrease the length of this field, its contents 1373 are encoded. The initially supported encoding is optimized for the normal 1374 case of inter-realm communication: a hierarchical arrangement of realms 1375 using either domain or X.500 style realm names. This encoding (called 1376 DOMAIN-X500-COMPRESS) is now described. 1378 Realm names in the transited field are separated by a ",". The ",", "\", 1379 trailing "."s, and leading spaces (" ") are special characters, and if they 1380 are part of a realm name, they must be quoted in the transited field by 1381 preced- ing them with a "\". 1383 A realm name ending with a "." is interpreted as being prepended to the 1384 previous realm. For example, we can encode traversal of EDU, MIT.EDU, 1385 ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as: 1387 "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". 1389 Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, that they 1390 would not be included in this field, and we would have: 1392 "EDU,MIT.,WASHINGTON.EDU" 1394 A realm name beginning with a "/" is interpreted as being appended to the 1395 previous realm[18]. If it is to stand by itself, then it should be preceded 1396 by a space (" "). For example, we can encode traversal of /COM/HP/APOLLO, 1397 /COM/HP, /COM, and /COM/DEC as: 1399 "/COM,/HP,/APOLLO, /COM/DEC". 1401 Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they 1402 they would not be included in this field, and we would have: 1404 "/COM,/HP" 1406 A null subfield preceding or following a "," indicates that all realms 1407 between the previous realm and the next realm have been traversed[19]. Thus, 1408 "," means that all realms along the path between the client and the server 1409 have been traversed. ",EDU, /COM," means that that all realms from the 1410 client's realm up to EDU (in a domain style hierarchy) have been traversed, 1411 and that everything from /COM down to the server's realm in an X.500 style 1412 has also been traversed. This could occur if the EDU realm in one hierarchy 1413 shares an inter-realm key directly with the /COM realm in another hierarchy. 1415 the authentication protocol. These extensions provide for authentication of 1417 Neuman, Ts'o, Kohl Expires: 25 December, 1418 1999 1420 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 1421 1999 1423 3.3.4. Receipt of KRB_TGS_REP message 1425 When the KRB_TGS_REP is received by the client, it is processed in the same 1426 manner as the KRB_AS_REP processing described above. The primary difference 1427 is that the ciphertext part of the response must be decrypted using the 1428 session key from the ticket-granting ticket rather than the client's secret 1429 key. See section A.7 for pseudocode. 1431 3.4. The KRB_SAFE Exchange 1433 The KRB_SAFE message may be used by clients requiring the ability to detect 1434 modifications of messages they exchange. It achieves this by including a 1435 keyed collision-proof checksum of the user data and some control 1436 information. The checksum is keyed with an encryption key (usually the last 1437 key negotiated via subkeys, or the session key if no negotiation has 1438 occured). 1440 3.4.1. Generation of a KRB_SAFE message 1442 When an application wishes to send a KRB_SAFE message, it collects its data 1443 and the appropriate control information and computes a checksum over them. 1444 The checksum algorithm should be a keyed one-way hash function (such as the 1445 RSA- MD5-DES checksum algorithm specified in section 6.4.5, or the DES MAC), 1446 generated using the sub-session key if present, or the session key. 1447 Different algorithms may be selected by changing the checksum type in the 1448 message. Unkeyed or non-collision-proof checksums are not suitable for this 1449 use. 1451 The control information for the KRB_SAFE message includes both a timestamp 1452 and a sequence number. The designer of an application using the KRB_SAFE 1453 message must choose at least one of the two mechanisms. This choice should 1454 be based on the needs of the application protocol. 1456 Sequence numbers are useful when all messages sent will be received by one's 1457 peer. Connection state is presently required to maintain the session key, so 1458 maintaining the next sequence number should not present an additional 1459 problem. 1461 If the application protocol is expected to tolerate lost messages without 1462 them being resent, the use of the timestamp is the appropriate replay 1463 detection mechanism. Using timestamps is also the appropriate mechanism for 1464 multi-cast protocols where all of one's peers share a common sub-session 1465 key, but some messages will be sent to a subset of one's peers. 1467 After computing the checksum, the client then transmits the information and 1468 checksum to the recipient in the message format specified in section 5.6.1. 1470 3.4.2. Receipt of KRB_SAFE message 1472 When an application receives a KRB_SAFE message, it verifies it as follows. 1473 If any error occurs, an error code is reported for use by the application. 1475 The message is first checked by verifying that the protocol version and type 1476 fields match the current version and KRB_SAFE, respectively. A mismatch 1477 generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The 1478 application verifies that the checksum used is a collision-proof keyed 1479 checksum, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. If 1480 the sender's address was included in the control information, the recipient 1481 the authentication protocol. These extensions provide for authentication of 1483 Neuman, Ts'o, Kohl Expires: 25 December, 1484 1999 1486 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 1487 1999 1489 verifies that the operating system's report of the sender's address matches 1490 the sender's address in the message, and (if a recipient address is 1491 specified or the recipient requires an address) that one of the recipient's 1492 addresses appears as the recipient's address in the message. A failed match 1493 for either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp and 1494 usec and/or the sequence number fields are checked. If timestamp and usec 1495 are expected and not present, or they are present but not current, the 1496 KRB_AP_ERR_SKEW error is generated. If the server name, along with the 1497 client name, time and microsecond fields from the Authenticator match any 1498 recently-seen (sent or received[20] ) such tuples, the KRB_AP_ERR_REPEAT 1499 error is generated. If an incorrect sequence number is included, or a 1500 sequence number is expected but not present, the KRB_AP_ERR_BADORDER error 1501 is generated. If neither a time-stamp and usec or a sequence number is 1502 present, a KRB_AP_ERR_MODIFIED error is generated. Finally, the checksum is 1503 computed over the data and control information, and if it doesn't match the 1504 received checksum, a KRB_AP_ERR_MODIFIED error is generated. 1506 If all the checks succeed, the application is assured that the message was 1507 generated by its peer and was not modi- fied in transit. 1509 3.5. The KRB_PRIV Exchange 1511 The KRB_PRIV message may be used by clients requiring confidentiality and 1512 the ability to detect modifications of exchanged messages. It achieves this 1513 by encrypting the messages and adding control information. 1515 3.5.1. Generation of a KRB_PRIV message 1517 When an application wishes to send a KRB_PRIV message, it collects its data 1518 and the appropriate control information (specified in section 5.7.1) and 1519 encrypts them under an encryption key (usually the last key negotiated via 1520 subkeys, or the session key if no negotiation has occured). As part of the 1521 control information, the client must choose to use either a timestamp or a 1522 sequence number (or both); see the discussion in section 3.4.1 for 1523 guidelines on which to use. After the user data and control information are 1524 encrypted, the client transmits the ciphertext and some 'envelope' 1525 information to the recipient. 1527 3.5.2. Receipt of KRB_PRIV message 1529 When an application receives a KRB_PRIV message, it verifies it as follows. 1530 If any error occurs, an error code is reported for use by the application. 1532 The message is first checked by verifying that the protocol version and type 1533 fields match the current version and KRB_PRIV, respectively. A mismatch 1534 generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The 1535 application then decrypts the ciphertext and processes the resultant 1536 plaintext. If decryption shows the data to have been modified, a 1537 KRB_AP_ERR_BAD_INTEGRITY error is generated. If the sender's address was 1538 included in the control information, the recipient verifies that the 1539 operating system's report of the sender's address matches the sender's 1540 address in the message, and (if a recipient address is specified or the 1541 recipient requires an address) that one of the recipient's addresses appears 1542 as the recipient's address in the message. A failed match for either case 1543 generates a KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the 1544 sequence number fields are checked. If timestamp and usec are expected and 1545 not present, or they are present but not current, the KRB_AP_ERR_SKEW error 1546 is generated. If the server name, along with the client name, time and 1547 the authentication protocol. These extensions provide for authentication of 1549 Neuman, Ts'o, Kohl Expires: 25 December, 1550 1999 1552 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 1553 1999 1555 microsecond fields from the Authenticator match any recently-seen such 1556 tuples, the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence 1557 number is included, or a sequence number is expected but not present, the 1558 KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and usec or 1559 a sequence number is present, a KRB_AP_ERR_MODIFIED error is generated. 1561 If all the checks succeed, the application can assume the message was 1562 generated by its peer, and was securely transmitted (without intruders able 1563 to see the unencrypted contents). 1565 3.6. The KRB_CRED Exchange 1567 The KRB_CRED message may be used by clients requiring the ability to send 1568 Kerberos credentials from one host to another. It achieves this by sending 1569 the tickets together with encrypted data containing the session keys and 1570 other information associated with the tickets. 1572 3.6.1. Generation of a KRB_CRED message 1574 When an application wishes to send a KRB_CRED message it first (using the 1575 KRB_TGS exchange) obtains credentials to be sent to the remote host. It then 1576 constructs a KRB_CRED message using the ticket or tickets so obtained, 1577 placing the session key needed to use each ticket in the key field of the 1578 corresponding KrbCredInfo sequence of the encrypted part of the the KRB_CRED 1579 message. 1581 Other information associated with each ticket and obtained during the 1582 KRB_TGS exchange is also placed in the corresponding KrbCredInfo sequence in 1583 the encrypted part of the KRB_CRED message. The current time and, if 1584 specifically required by the application the nonce, s-address, and r-address 1585 fields, are placed in the encrypted part of the KRB_CRED message which is 1586 then encrypted under an encryption key previosuly exchanged in the KRB_AP 1587 exchange (usually the last key negotiated via subkeys, or the session key if 1588 no negotiation has occured). 1590 3.6.2. Receipt of KRB_CRED message 1592 When an application receives a KRB_CRED message, it verifies it. If any 1593 error occurs, an error code is reported for use by the application. The 1594 message is verified by checking that the protocol version and type fields 1595 match the current version and KRB_CRED, respectively. A mismatch generates a 1596 KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then 1597 decrypts the ciphertext and processes the resultant plaintext. If decryption 1598 shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is 1599 generated. 1601 If present or required, the recipient verifies that the operating system's 1602 report of the sender's address matches the sender's address in the message, 1603 and that one of the recipient's addresses appears as the recipient's address 1604 in the message. A failed match for either case generates a 1605 KRB_AP_ERR_BADADDR error. The timestamp and usec fields (and the nonce field 1606 if required) are checked next. If the timestamp and usec are not present, or 1607 they are present but not current, the KRB_AP_ERR_SKEW error is generated. 1609 If all the checks succeed, the application stores each of the new tickets in 1610 its ticket cache together with the session key and other information in the 1611 corresponding KrbCredInfo sequence from the encrypted part of the KRB_CRED 1612 message. 1614 the authentication protocol. These extensions provide for authentication of 1616 Neuman, Ts'o, Kohl Expires: 25 December, 1617 1999 1619 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 1620 1999 1622 4. The Kerberos Database 1624 The Kerberos server must have access to a database contain- ing the 1625 principal identifiers and secret keys of principals to be authenticated[21]. 1627 4.1. Database contents 1629 A database entry should contain at least the following fields: 1631 Field Value 1633 name Principal's identifier 1634 key Principal's secret key 1635 p_kvno Principal's key version 1636 max_life Maximum lifetime for Tickets 1637 max_renewable_life Maximum total lifetime for renewable Tickets 1639 The name field is an encoding of the principal's identifier. The key field 1640 contains an encryption key. This key is the principal's secret key. (The key 1641 can be encrypted before storage under a Kerberos "master key" to protect it 1642 in case the database is compromised but the master key is not. In that case, 1643 an extra field must be added to indicate the master key version used, see 1644 below.) The p_kvno field is the key version number of the principal's secret 1645 key. The max_life field contains the maximum allowable lifetime (endtime - 1646 starttime) for any Ticket issued for this principal. The max_renewable_life 1647 field contains the maximum allowable total lifetime for any renewable Ticket 1648 issued for this principal. (See section 3.1 for a description of how these 1649 lifetimes are used in determining the lifetime of a given Ticket.) 1651 A server may provide KDC service to several realms, as long as the database 1652 representation provides a mechanism to distinguish between principal records 1653 with identifiers which differ only in the realm name. 1655 When an application server's key changes, if the change is routine (i.e. not 1656 the result of disclosure of the old key), the old key should be retained by 1657 the server until all tickets that had been issued using that key have 1658 expired. Because of this, it is possible for several keys to be active for a 1659 single principal. Ciphertext encrypted in a principal's key is always tagged 1660 with the version of the key that was used for encryption, to help the 1661 recipient find the proper key for decryption. 1663 When more than one key is active for a particular principal, the principal 1664 will have more than one record in the Kerberos database. The keys and key 1665 version numbers will differ between the records (the rest of the fields may 1666 or may not be the same). Whenever Kerberos issues a ticket, or responds to a 1667 request for initial authentication, the most recent key (known by the 1668 Kerberos server) will be used for encryption. This is the key with the 1669 highest key version number. 1671 the authentication protocol. These extensions provide for authentication of 1673 Neuman, Ts'o, Kohl Expires: 25 December, 1674 1999 1676 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 1677 1999 1679 4.2. Additional fields 1681 Project Athena's KDC implementation uses additional fields in its database: 1683 Field Value 1685 K_kvno Kerberos' key version 1686 expiration Expiration date for entry 1687 attributes Bit field of attributes 1688 mod_date Timestamp of last modification 1689 mod_name Modifying principal's identifier 1691 The K_kvno field indicates the key version of the Kerberos master key under 1692 which the principal's secret key is encrypted. 1694 After an entry's expiration date has passed, the KDC will return an error to 1695 any client attempting to gain tickets as or for the principal. (A database 1696 may want to maintain two expiration dates: one for the principal, and one 1697 for the principal's current key. This allows password aging to work 1698 independently of the principal's expiration date. However, due to the 1699 limited space in the responses, the KDC must combine the key expiration and 1700 principal expiration date into a single value called 'key_exp', which is 1701 used as a hint to the user to take administrative action.) 1703 The attributes field is a bitfield used to govern the operations involving 1704 the principal. This field might be useful in conjunction with user 1705 registration procedures, for site-specific policy implementations (Project 1706 Athena currently uses it for their user registration process controlled by 1707 the system-wide database service, Moira [LGDSR87]), to identify whether a 1708 principal can play the role of a client or server or both, to note whether a 1709 server is appropriate trusted to recieve credentials delegated by a client, 1710 or to identify the 'string to key' conversion algorithm used for a 1711 principal's key[22]. Other bits are used to indicate that certain ticket 1712 options should not be allowed in tickets encrypted under a principal's key 1713 (one bit each): Disallow issuing postdated tickets, disallow issuing 1714 forwardable tickets, disallow issuing tickets based on TGT authentication, 1715 disallow issuing renewable tickets, disallow issuing proxiable tickets, and 1716 disallow issuing tickets for which the principal is the server. 1718 The mod_date field contains the time of last modification of the entry, and 1719 the mod_name field contains the name of the principal which last modified 1720 the entry. 1722 4.3. Frequently Changing Fields 1724 Some KDC implementations may wish to maintain the last time that a request 1725 was made by a particular principal. Information that might be maintained 1726 includes the time of the last request, the time of the last request for a 1727 ticket-granting ticket, the time of the last use of a ticket-granting 1728 ticket, or other times. This information can then be returned to the user in 1729 the last-req field (see section 5.2). 1731 Other frequently changing information that can be maintained is the latest 1732 expiration time for any tickets that have been issued using each key. This 1733 field would be used to indicate how long old keys must remain valid to allow 1734 the continued use of outstanding tickets. 1736 the authentication protocol. These extensions provide for authentication of 1738 Neuman, Ts'o, Kohl Expires: 25 December, 1739 1999 1741 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 1742 1999 1744 4.4. Site Constants 1746 The KDC implementation should have the following configurable constants or 1747 options, to allow an administrator to make and enforce policy decisions: 1749 * The minimum supported lifetime (used to determine whether the 1750 KDC_ERR_NEVER_VALID error should be returned). This constant should 1751 reflect reasonable expectations of round-trip time to the KDC, 1752 encryption/decryption time, and processing time by the client and 1753 target server, and it should allow for a minimum 'useful' lifetime. 1754 * The maximum allowable total (renewable) lifetime of a ticket 1755 (renew_till - starttime). 1756 * The maximum allowable lifetime of a ticket (endtime - starttime). 1757 * Whether to allow the issue of tickets with empty address fields 1758 (including the ability to specify that such tickets may only be issued 1759 if the request specifies some authorization_data). 1760 * Whether proxiable, forwardable, renewable or post-datable tickets are 1761 to be issued. 1763 5. Message Specifications 1765 The following sections describe the exact contents and encoding of protocol 1766 messages and objects. The ASN.1 base definitions are presented in the first 1767 subsection. The remaining subsections specify the protocol objects (tickets 1768 and authenticators) and messages. Specification of encryption and checksum 1769 techniques, and the fields related to them, appear in section 6. 1771 Optional field in ASN.1 sequences 1773 For optional integer value and date fields in ASN.1 sequences where a 1774 default value has been specified, certain default values will not be allowed 1775 in the encoding because these values will always be represented through 1776 defaulting by the absence of the optional field. For example, one will not 1777 send a microsecond zero value because one must make sure that there is only 1778 one way to encode this value. 1780 Additional fields in ASN.1 sequences 1782 Implementations receiving Kerberos messages with additional fields present 1783 in ASN.1 sequences should carry the those fields through, unmodified, when 1784 the message is forwarded. Implementations should not drop such fields if the 1785 sequence is reencoded. 1787 5.1. ASN.1 Distinguished Encoding Representation 1789 All uses of ASN.1 in Kerberos shall use the Distinguished Encoding 1790 Representation of the data elements as described in the X.509 specification, 1791 section 8.7 [X509-88]. 1793 5.3. ASN.1 Base Definitions 1795 The following ASN.1 base definitions are used in the rest of this section. 1796 Note that since the underscore character (_) is not permitted in ASN.1 1797 names, the hyphen (-) is used in its place for the purposes of ASN.1 names. 1799 Realm ::= GeneralString 1800 PrincipalName ::= SEQUENCE { 1801 name-type[0] INTEGER, 1802 name-string[1] SEQUENCE OF GeneralString 1803 } 1804 the authentication protocol. These extensions provide for authentication of 1806 Neuman, Ts'o, Kohl Expires: 25 December, 1807 1999 1809 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 1810 1999 1812 Kerberos realms are encoded as GeneralStrings. Realms shall not contain a 1813 character with the code 0 (the ASCII NUL). Most realms will usually consist 1814 of several components separated by periods (.), in the style of Internet 1815 Domain Names, or separated by slashes (/) in the style of X.500 names. 1816 Acceptable forms for realm names are specified in section 7. A PrincipalName 1817 is a typed sequence of components consisting of the following sub-fields: 1819 name-type 1820 This field specifies the type of name that follows. Pre-defined values 1821 for this field are specified in section 7.2. The name-type should be 1822 treated as a hint. Ignoring the name type, no two names can be the same 1823 (i.e. at least one of the components, or the realm, must be different). 1824 This constraint may be eliminated in the future. 1825 name-string 1826 This field encodes a sequence of components that form a name, each 1827 component encoded as a GeneralString. Taken together, a PrincipalName 1828 and a Realm form a principal identifier. Most PrincipalNames will have 1829 only a few components (typically one or two). 1831 KerberosTime ::= GeneralizedTime 1832 -- Specifying UTC time zone (Z) 1834 The timestamps used in Kerberos are encoded as GeneralizedTimes. An encoding 1835 shall specify the UTC time zone (Z) and shall not include any fractional 1836 portions of the seconds. It further shall not include any separators. 1837 Example: The only valid format for UTC time 6 minutes, 27 seconds after 9 pm 1838 on 6 November 1985 is 19851106210627Z. 1840 HostAddress ::= SEQUENCE { 1841 addr-type[0] INTEGER, 1842 address[1] OCTET STRING 1843 } 1845 HostAddresses ::= SEQUENCE OF HostAddress 1847 The host adddress encodings consists of two fields: 1849 addr-type 1850 This field specifies the type of address that follows. Pre-defined 1851 values for this field are specified in section 8.1. 1852 address 1853 This field encodes a single address of type addr-type. 1855 The two forms differ slightly. HostAddress contains exactly one address; 1856 HostAddresses contains a sequence of possibly many addresses. 1858 AuthorizationData ::= SEQUENCE OF SEQUENCE { 1859 ad-type[0] INTEGER, 1860 ad-data[1] OCTET STRING 1861 } 1863 ad-data 1864 This field contains authorization data to be interpreted according to 1865 the value of the corresponding ad-type field. 1866 ad-type 1867 This field specifies the format for the ad-data subfield. All negative 1868 values are reserved for local use. Non-negative values are reserved for 1869 registered use. 1871 the authentication protocol. These extensions provide for authentication of 1873 Neuman, Ts'o, Kohl Expires: 25 December, 1874 1999 1876 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 1877 1999 1879 Each sequence of type and data is refered to as an authorization element. 1880 Elements may be application specific, however, there is a common set of 1881 recursive elements that should be understood by all implementations. These 1882 elements contain other elements embedded within them, and the interpretation 1883 of the encapsulating element determines which of the embedded elements must 1884 be interpreted, and which may be ignored. Definitions for these common 1885 elements may be found in Appendix B. 1887 TicketExtensions ::= SEQUENCE OF SEQUENCE { 1888 te-type[0] INTEGER, 1889 te-data[1] OCTET STRING 1890 } 1892 te-data 1893 This field contains opaque data that must be caried with the ticket to 1894 support extensions to the Kerberos protocol including but not limited 1895 to some forms of inter-realm key exchange and plaintext authorization 1896 data. See appendix C for some common uses of this field. 1897 te-type 1898 This field specifies the format for the te-data subfield. All negative 1899 values are reserved for local use. Non-negative values are reserved for 1900 registered use. 1902 APOptions ::= BIT STRING 1903 -- reserved(0), 1904 -- use-session-key(1), 1905 -- mutual-required(2) 1907 TicketFlags ::= BIT STRING 1908 -- reserved(0), 1909 -- forwardable(1), 1910 -- forwarded(2), 1911 -- proxiable(3), 1912 -- proxy(4), 1913 -- may-postdate(5), 1914 -- postdated(6), 1915 -- invalid(7), 1916 -- renewable(8), 1917 -- initial(9), 1918 -- pre-authent(10), 1919 -- hw-authent(11), 1920 -- transited-policy-checked(12), 1921 -- ok-as-delegate(13) 1923 KDCOptions ::= BIT STRING 1924 -- reserved(0), 1925 -- forwardable(1), 1926 -- forwarded(2), 1927 -- proxiable(3), 1928 -- proxy(4), 1929 -- allow-postdate(5), 1930 -- postdated(6), 1931 -- unused7(7), 1932 -- renewable(8), 1933 -- unused9(9), 1934 -- unused10(10), 1935 the authentication protocol. These extensions provide for authentication of 1937 Neuman, Ts'o, Kohl Expires: 25 December, 1938 1999 1940 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 1941 1999 1943 -- unused11(11), 1944 -- unused12(12), 1945 -- unused13(13), 1946 -- disable-transited-check(26), 1947 -- renewable-ok(27), 1948 -- enc-tkt-in-skey(28), 1949 -- renew(30), 1950 -- validate(31) 1952 ASN.1 Bit strings have a length and a value. When used in Kerberos for the 1953 APOptions, TicketFlags, and KDCOptions, the length of the bit string on 1954 generated values should be the smallest number of bits needed to include the 1955 highest order bit that is set (1), but in no case less than 32 bits. The 1956 ASN.1 representation of the bit strings uses unnamed bits, with the meaning 1957 of the individual bits defined by the comments in the specification above. 1958 Implementations should accept values of bit strings of any length and treat 1959 the value of flags corresponding to bits beyond the end of the bit string as 1960 if the bit were reset (0). Comparison of bit strings of different length 1961 should treat the smaller string as if it were padded with zeros beyond the 1962 high order bits to the length of the longer string[23]. 1964 LastReq ::= SEQUENCE OF SEQUENCE { 1965 lr-type[0] INTEGER, 1966 lr-value[1] KerberosTime 1967 } 1969 lr-type 1970 This field indicates how the following lr-value field is to be 1971 interpreted. Negative values indicate that the information pertains 1972 only to the responding server. Non-negative values pertain to all 1973 servers for the realm. If the lr-type field is zero (0), then no 1974 information is conveyed by the lr-value subfield. If the absolute value 1975 of the lr-type field is one (1), then the lr-value subfield is the time 1976 of last initial request for a TGT. If it is two (2), then the lr-value 1977 subfield is the time of last initial request. If it is three (3), then 1978 the lr-value subfield is the time of issue for the newest 1979 ticket-granting ticket used. If it is four (4), then the lr-value 1980 subfield is the time of the last renewal. If it is five (5), then the 1981 lr-value subfield is the time of last request (of any type). If it is 1982 (6), then the lr-value subfield is the time when the password will 1983 expire. 1984 lr-value 1985 This field contains the time of the last request. the time must be 1986 interpreted according to the contents of the accompanying lr-type 1987 subfield. 1989 See section 6 for the definitions of Checksum, ChecksumType, EncryptedData, 1990 EncryptionKey, EncryptionType, and KeyType. 1992 5.3. Tickets and Authenticators 1994 This section describes the format and encryption parameters for tickets and 1995 authenticators. When a ticket or authenticator is included in a protocol 1996 message it is treated as an opaque object. 1998 the authentication protocol. These extensions provide for authentication of 2000 Neuman, Ts'o, Kohl Expires: 25 December, 2001 1999 2003 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 2004 1999 2006 5.3.1. Tickets 2008 A ticket is a record that helps a client authenticate to a service. A Ticket 2009 contains the following information: 2011 Ticket ::= [APPLICATION 1] SEQUENCE { 2012 tkt-vno[0] INTEGER, 2013 realm[1] Realm, 2014 sname[2] PrincipalName, 2015 enc-part[3] EncryptedData, 2016 extensions[4] TicketExtensions OPTIONAL 2017 } 2019 -- Encrypted part of ticket 2020 EncTicketPart ::= [APPLICATION 3] SEQUENCE { 2021 flags[0] TicketFlags, 2022 key[1] EncryptionKey, 2023 crealm[2] Realm, 2024 cname[3] PrincipalName, 2025 transited[4] TransitedEncoding, 2026 authtime[5] KerberosTime, 2027 starttime[6] KerberosTime OPTIONAL, 2028 endtime[7] KerberosTime, 2029 renew-till[8] KerberosTime OPTIONAL, 2030 caddr[9] HostAddresses OPTIONAL, 2031 authorization-data[10] AuthorizationData OPTIONAL 2032 } 2033 -- encoded Transited field 2034 TransitedEncoding ::= SEQUENCE { 2035 tr-type[0] INTEGER, -- must be 2036 registered 2037 contents[1] OCTET STRING 2038 } 2040 The encoding of EncTicketPart is encrypted in the key shared by Kerberos and 2041 the end server (the server's secret key). See section 6 for the format of 2042 the ciphertext. 2044 tkt-vno 2045 This field specifies the version number for the ticket format. This 2046 document describes version number 5. 2047 realm 2048 This field specifies the realm that issued a ticket. It also serves to 2049 identify the realm part of the server's principal identifier. Since a 2050 Kerberos server can only issue tickets for servers within its realm, 2051 the two will always be identical. 2052 sname 2053 This field specifies all components of the name part of the server's 2054 identity, including those parts that identify a specific instance of a 2055 service. 2056 enc-part 2057 This field holds the encrypted encoding of the EncTicketPart sequence. 2058 extensions 2059 [*** This change is still subject to discussion. Several alternatives 2060 for this - including none at all - will be distributed to the cat and 2061 krb-protocol mailing lists before the Oslo IETF, and an alternative 2062 will be selected and the spec modified by 7/14/99 ***] This optional 2063 field contains a sequence of extentions that may be used to carry 2064 information that must be carried with the ticket to support several 2065 the authentication protocol. These extensions provide for authentication of 2067 Neuman, Ts'o, Kohl Expires: 25 December, 2068 1999 2070 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 2071 1999 2073 extensions, including but not limited to plaintext authorization data, 2074 tokens for exchanging inter-realm keys, and other information that must 2075 be associated with a ticket for use by the application server. See 2076 Appendix C for definitions of some common extensions. 2078 Note that some older versions of Kerberos did not support this field. 2079 Because this is an optional field it will not break older clients, but 2080 older clients might strip this field from the ticket before sending it 2081 to the application server. This limits the usefulness of this ticket 2082 field to environments where the ticket will not be parsed and 2083 reconstructed by these older Kerberos clients. 2085 If it is known that the client will strip this field from the ticket, 2086 as an interim measure the KDC may append this field to the end of the 2087 enc-part of the ticket and append a traler indicating the lenght of the 2088 appended extensions field. (this paragraph is open for discussion, 2089 including the form of the traler). 2090 flags 2091 This field indicates which of various options were used or requested 2092 when the ticket was issued. It is a bit-field, where the selected 2093 options are indicated by the bit being set (1), and the unselected 2094 options and reserved fields being reset (0). Bit 0 is the most 2095 significant bit. The encoding of the bits is specified in section 5.2. 2096 The flags are described in more detail above in section 2. The meanings 2097 of the flags are: 2099 Bit(s) Name Description 2101 0 RESERVED 2102 Reserved for future expansion of this 2103 field. 2105 1 FORWARDABLE 2106 The FORWARDABLE flag is normally only 2107 interpreted by the TGS, and can be 2108 ignored by end servers. When set, this 2109 flag tells the ticket-granting server 2110 that it is OK to issue a new ticket- 2111 granting ticket with a different network 2112 address based on the presented ticket. 2114 2 FORWARDED 2115 When set, this flag indicates that the 2116 ticket has either been forwarded or was 2117 issued based on authentication involving 2118 a forwarded ticket-granting ticket. 2120 3 PROXIABLE 2121 The PROXIABLE flag is normally only 2122 interpreted by the TGS, and can be 2123 ignored by end servers. The PROXIABLE 2124 flag has an interpretation identical to 2125 that of the FORWARDABLE flag, except 2126 that the PROXIABLE flag tells the 2127 ticket-granting server that only non- 2128 ticket-granting tickets may be issued 2129 with different network addresses. 2131 the authentication protocol. These extensions provide for authentication of 2133 Neuman, Ts'o, Kohl Expires: 25 December, 2134 1999 2136 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 2137 1999 2139 4 PROXY 2140 When set, this flag indicates that a 2141 ticket is a proxy. 2143 5 MAY-POSTDATE 2144 The MAY-POSTDATE flag is normally only 2145 interpreted by the TGS, and can be 2146 ignored by end servers. This flag tells 2147 the ticket-granting server that a post- 2148 dated ticket may be issued based on this 2149 ticket-granting ticket. 2151 6 POSTDATED 2152 This flag indicates that this ticket has 2153 been postdated. The end-service can 2154 check the authtime field to see when the 2155 original authentication occurred. 2157 7 INVALID 2158 This flag indicates that a ticket is 2159 invalid, and it must be validated by the 2160 KDC before use. Application servers 2161 must reject tickets which have this flag 2162 set. 2164 8 RENEWABLE 2165 The RENEWABLE flag is normally only 2166 interpreted by the TGS, and can usually 2167 be ignored by end servers (some particu- 2168 larly careful servers may wish to disal- 2169 low renewable tickets). A renewable 2170 ticket can be used to obtain a replace- 2171 ment ticket that expires at a later 2172 date. 2174 9 INITIAL 2175 This flag indicates that this ticket was 2176 issued using the AS protocol, and not 2177 issued based on a ticket-granting 2178 ticket. 2180 10 PRE-AUTHENT 2181 This flag indicates that during initial 2182 authentication, the client was authenti- 2183 cated by the KDC before a ticket was 2184 issued. The strength of the pre- 2185 authentication method is not indicated, 2186 but is acceptable to the KDC. 2188 11 HW-AUTHENT 2189 This flag indicates that the protocol 2190 employed for initial authentication 2191 required the use of hardware expected to 2192 be possessed solely by the named client. 2193 The hardware authentication method is 2194 selected by the KDC and the strength of 2195 the method is not indicated. 2197 the authentication protocol. These extensions provide for authentication of 2199 Neuman, Ts'o, Kohl Expires: 25 December, 2200 1999 2202 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 2203 1999 2205 12 TRANSITED This flag indicates that the KDC for the 2206 POLICY-CHECKED realm has checked the transited field 2207 against a realm defined policy for 2208 trusted certifiers. If this flag is 2209 reset (0), then the application server 2210 must check the transited field itself, 2211 and if unable to do so it must reject 2212 the authentication. If the flag is set 2213 (1) then the application server may skip 2214 its own validation of the transited 2215 field, relying on the validation 2216 performed by the KDC. At its option the 2217 application server may still apply its 2218 own validation based on a separate 2219 policy for acceptance. 2221 13 OK-AS-DELEGATE This flag indicates that the server (not 2222 the client) specified in the ticket has 2223 been determined by policy of the realm 2224 to be a suitable recipient of 2225 delegation. A client can use the 2226 presence of this flag to help it make a 2227 decision whether to delegate credentials 2228 (either grant a proxy or a forwarded 2229 ticket granting ticket) to this server. 2230 The client is free to ignore the value 2231 of this flag. When setting this flag, 2232 an administrator should consider the 2233 Security and placement of the server on 2234 which the service will run, as well as 2235 whether the service requires the use of 2236 delegated credentials. 2238 14 ANONYMOUS 2239 This flag indicates that the principal 2240 named in the ticket is a generic princi- 2241 pal for the realm and does not identify 2242 the individual using the ticket. The 2243 purpose of the ticket is only to 2244 securely distribute a session key, and 2245 not to identify the user. Subsequent 2246 requests using the same ticket and ses- 2247 sion may be considered as originating 2248 from the same user, but requests with 2249 the same username but a different ticket 2250 are likely to originate from different 2251 users. 2253 15-31 RESERVED 2254 Reserved for future use. 2256 key 2257 This field exists in the ticket and the KDC response and is used to 2258 pass the session key from Kerberos to the application server and the 2259 client. The field's encoding is described in section 6.2. 2260 crealm 2261 This field contains the name of the realm in which the client is 2262 registered and in which initial authentication took place. 2263 the authentication protocol. These extensions provide for authentication of 2265 Neuman, Ts'o, Kohl Expires: 25 December, 2266 1999 2268 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 2269 1999 2271 cname 2272 This field contains the name part of the client's principal identifier. 2273 transited 2274 This field lists the names of the Kerberos realms that took part in 2275 authenticating the user to whom this ticket was issued. It does not 2276 specify the order in which the realms were transited. See section 2277 3.3.3.2 for details on how this field encodes the traversed realms. 2278 When the names of CA's are to be embedded inthe transited field (as 2279 specified for some extentions to the protocol), the X.500 names of the 2280 CA's should be mapped into items in the transited field using the 2281 mapping defined by RFC2253. 2282 authtime 2283 This field indicates the time of initial authentication for the named 2284 principal. It is the time of issue for the original ticket on which 2285 this ticket is based. It is included in the ticket to provide 2286 additional information to the end service, and to provide the necessary 2287 information for implementation of a `hot list' service at the KDC. An 2288 end service that is particularly paranoid could refuse to accept 2289 tickets for which the initial authentication occurred "too far" in the 2290 past. This field is also returned as part of the response from the KDC. 2291 When returned as part of the response to initial authentication 2292 (KRB_AS_REP), this is the current time on the Ker- beros server[24]. 2293 starttime 2294 This field in the ticket specifies the time after which the ticket is 2295 valid. Together with endtime, this field specifies the life of the 2296 ticket. If it is absent from the ticket, its value should be treated as 2297 that of the authtime field. 2298 endtime 2299 This field contains the time after which the ticket will not be honored 2300 (its expiration time). Note that individual services may place their 2301 own limits on the life of a ticket and may reject tickets which have 2302 not yet expired. As such, this is really an upper bound on the 2303 expiration time for the ticket. 2304 renew-till 2305 This field is only present in tickets that have the RENEWABLE flag set 2306 in the flags field. It indicates the maximum endtime that may be 2307 included in a renewal. It can be thought of as the absolute expiration 2308 time for the ticket, including all renewals. 2309 caddr 2310 This field in a ticket contains zero (if omitted) or more (if present) 2311 host addresses. These are the addresses from which the ticket can be 2312 used. If there are no addresses, the ticket can be used from any 2313 location. The decision by the KDC to issue or by the end server to 2314 accept zero-address tickets is a policy decision and is left to the 2315 Kerberos and end-service administrators; they may refuse to issue or 2316 accept such tickets. The suggested and default policy, however, is that 2317 such tickets will only be issued or accepted when additional 2318 information that can be used to restrict the use of the ticket is 2319 included in the authorization_data field. Such a ticket is a 2320 capability. 2322 Network addresses are included in the ticket to make it harder for an 2323 attacker to use stolen credentials. Because the session key is not sent 2324 over the network in cleartext, credentials can't be stolen simply by 2325 listening to the network; an attacker has to gain access to the session 2326 key (perhaps through operating system security breaches or a careless 2327 user's unattended session) to make use of stolen tickets. 2329 the authentication protocol. These extensions provide for authentication of 2331 Neuman, Ts'o, Kohl Expires: 25 December, 2332 1999 2334 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 2335 1999 2337 It is important to note that the network address from which a 2338 connection is received cannot be reliably determined. Even if it could 2339 be, an attacker who has compromised the client's workstation could use 2340 the credentials from there. Including the network addresses only makes 2341 it more difficult, not impossible, for an attacker to walk off with 2342 stolen credentials and then use them from a "safe" location. 2343 authorization-data 2344 The authorization-data field is used to pass authorization data from 2345 the principal on whose behalf a ticket was issued to the application 2346 service. If no authorization data is included, this field will be left 2347 out. Experience has shown that the name of this field is confusing, and 2348 that a better name for this field would be restrictions. Unfortunately, 2349 it is not possible to change the name of this field at this time. 2351 This field contains restrictions on any authority obtained on the basis 2352 of authentication using the ticket. It is possible for any principal in 2353 posession of credentials to add entries to the authorization data field 2354 since these entries further restrict what can be done with the ticket. 2355 Such additions can be made by specifying the additional entries when a 2356 new ticket is obtained during the TGS exchange, or they may be added 2357 during chained delegation using the authorization data field of the 2358 authenticator. 2360 Because entries may be added to this field by the holder of 2361 credentials, it is not allowable for the presence of an entry in the 2362 authorization data field of a ticket to amplify the priveleges one 2363 would obtain from using a ticket. 2365 The data in this field may be specific to the end service; the field 2366 will contain the names of service specific objects, and the rights to 2367 those objects. The format for this field is described in section 5.2. 2368 Although Kerberos is not concerned with the format of the contents of 2369 the sub-fields, it does carry type information (ad-type). 2371 By using the authorization_data field, a principal is able to issue a 2372 proxy that is valid for a specific purpose. For example, a client 2373 wishing to print a file can obtain a file server proxy to be passed to 2374 the print server. By specifying the name of the file in the 2375 authorization_data field, the file server knows that the print server 2376 can only use the client's rights when accessing the particular file to 2377 be printed. 2379 A separate service providing authorization or certifying group 2380 membership may be built using the authorization-data field. In this 2381 case, the entity granting authorization (not the authorized entity), 2382 obtains a ticket in its own name (e.g. the ticket is issued in the name 2383 of a privelege server), and this entity adds restrictions on its own 2384 authority and delegates the restricted authority through a proxy to the 2385 client. The client would then present this authorization credential to 2386 the application server separately from the authentication exchange. 2388 Similarly, if one specifies the authorization-data field of a proxy and 2389 leaves the host addresses blank, the resulting ticket and session key 2390 can be treated as a capability. See [Neu93] for some suggested uses of 2391 this field. 2393 The authorization-data field is optional and does not have to be 2394 included in a ticket. 2396 the authentication protocol. These extensions provide for authentication of 2398 Neuman, Ts'o, Kohl Expires: 25 December, 2399 1999 2401 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 2402 1999 2404 5.3.2. Authenticators 2406 An authenticator is a record sent with a ticket to a server to certify the 2407 client's knowledge of the encryption key in the ticket, to help the server 2408 detect replays, and to help choose a "true session key" to use with the 2409 particular session. The encoding is encrypted in the ticket's session key 2410 shared by the client and the server: 2412 -- Unencrypted authenticator 2413 Authenticator ::= [APPLICATION 2] SEQUENCE { 2414 authenticator-vno[0] INTEGER, 2415 crealm[1] Realm, 2416 cname[2] PrincipalName, 2417 cksum[3] Checksum OPTIONAL, 2418 cusec[4] INTEGER, 2419 ctime[5] KerberosTime, 2420 subkey[6] EncryptionKey OPTIONAL, 2421 seq-number[7] INTEGER OPTIONAL, 2422 authorization-data[8] AuthorizationData OPTIONAL 2423 } 2425 authenticator-vno 2426 This field specifies the version number for the format of the 2427 authenticator. This document specifies version 5. 2428 crealm and cname 2429 These fields are the same as those described for the ticket in section 2430 5.3.1. 2431 cksum 2432 This field contains a checksum of the the applica- tion data that 2433 accompanies the KRB_AP_REQ. 2434 cusec 2435 This field contains the microsecond part of the client's timestamp. Its 2436 value (before encryption) ranges from 0 to 999999. It often appears 2437 along with ctime. The two fields are used together to specify a 2438 reasonably accurate timestamp. 2439 ctime 2440 This field contains the current time on the client's host. 2441 subkey 2442 This field contains the client's choice for an encryption key which is 2443 to be used to protect this specific application session. Unless an 2444 application specifies otherwise, if this field is left out the session 2445 key from the ticket will be used. 2446 seq-number 2447 This optional field includes the initial sequence number to be used by 2448 the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to 2449 detect replays (It may also be used by application specific messages). 2450 When included in the authenticator this field specifies the initial 2451 sequence number for messages from the client to the server. When 2452 included in the AP-REP message, the initial sequence number is that for 2453 messages from the server to the client. When used in KRB_PRIV or 2454 KRB_SAFE messages, it is incremented by one after each message is sent. 2455 Sequence numbers fall in the range of 0 through 2^32 - 1 and wrap to 2456 zero following the value 2^32 - 1. 2458 For sequence numbers to adequately support the detection of replays 2459 they should be non-repeating, even across connection boundaries. The 2460 initial sequence number should be random and uniformly distributed 2461 the authentication protocol. These extensions provide for authentication of 2463 Neuman, Ts'o, Kohl Expires: 25 December, 2464 1999 2466 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 2467 1999 2469 across the full space of possible sequence numbers, so that it cannot 2470 be guessed by an attacker and so that it and the successive sequence 2471 numbers do not repeat other sequences. 2472 authorization-data 2473 This field is the same as described for the ticket in section 5.3.1. It 2474 is optional and will only appear when additional restrictions are to be 2475 placed on the use of a ticket, beyond those carried in the ticket 2476 itself. 2478 5.4. Specifications for the AS and TGS exchanges 2480 This section specifies the format of the messages used in the exchange 2481 between the client and the Kerberos server. The format of possible error 2482 messages appears in section 5.9.1. 2484 5.4.1. KRB_KDC_REQ definition 2486 The KRB_KDC_REQ message has no type of its own. Instead, its type is one of 2487 KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is for an initial 2488 ticket or an additional ticket. In either case, the message is sent from the 2489 client to the Authentication Server to request credentials for a service. 2491 The message fields are: 2493 AS-REQ ::= [APPLICATION 10] KDC-REQ 2494 TGS-REQ ::= [APPLICATION 12] KDC-REQ 2496 KDC-REQ ::= SEQUENCE { 2497 pvno[1] INTEGER, 2498 msg-type[2] INTEGER, 2499 padata[3] SEQUENCE OF PA-DATA OPTIONAL, 2500 req-body[4] KDC-REQ-BODY 2501 } 2503 PA-DATA ::= SEQUENCE { 2504 padata-type[1] INTEGER, 2505 padata-value[2] OCTET STRING, 2506 -- might be encoded AP-REQ 2507 } 2509 KDC-REQ-BODY ::= SEQUENCE { 2510 kdc-options[0] KDCOptions, 2511 cname[1] PrincipalName OPTIONAL, 2512 -- Used only in AS-REQ 2513 realm[2] Realm, -- Server's realm 2514 -- Also client's in AS-REQ 2515 sname[3] PrincipalName OPTIONAL, 2516 from[4] KerberosTime OPTIONAL, 2517 till[5] KerberosTime OPTIONAL, 2518 rtime[6] KerberosTime OPTIONAL, 2519 nonce[7] INTEGER, 2520 etype[8] SEQUENCE OF INTEGER, 2521 -- EncryptionType, 2522 -- in preference order 2523 addresses[9] HostAddresses OPTIONAL, 2524 enc-authorization-data[10] EncryptedData OPTIONAL, 2525 -- Encrypted AuthorizationData 2526 -- encoding 2527 additional-tickets[11] SEQUENCE OF Ticket OPTIONAL 2528 } 2530 the authentication protocol. These extensions provide for authentication of 2532 Neuman, Ts'o, Kohl Expires: 25 December, 2533 1999 2535 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 2536 1999 2538 The fields in this message are: 2540 pvno 2541 This field is included in each message, and specifies the protocol 2542 version number. This document specifies protocol version 5. 2543 msg-type 2544 This field indicates the type of a protocol message. It will almost 2545 always be the same as the application identifier associated with a 2546 message. It is included to make the identifier more readily accessible 2547 to the application. For the KDC-REQ message, this type will be 2548 KRB_AS_REQ or KRB_TGS_REQ. 2549 padata 2550 The padata (pre-authentication data) field contains a sequence of 2551 authentication information which may be needed before credentials can 2552 be issued or decrypted. In the case of requests for additional tickets 2553 (KRB_TGS_REQ), this field will include an element with padata-type of 2554 PA-TGS-REQ and data of an authentication header (ticket-granting ticket 2555 and authenticator). The checksum in the authenticator (which must be 2556 collision-proof) is to be computed over the KDC-REQ-BODY encoding. In 2557 most requests for initial authentication (KRB_AS_REQ) and most replies 2558 (KDC-REP), the padata field will be left out. 2560 This field may also contain information needed by certain extensions to 2561 the Kerberos protocol. For example, it might be used to initially 2562 verify the identity of a client before any response is returned. This 2563 is accomplished with a padata field with padata-type equal to 2564 PA-ENC-TIMESTAMP and padata-value defined as follows: 2566 padata-type ::= PA-ENC-TIMESTAMP 2567 padata-value ::= EncryptedData -- PA-ENC-TS-ENC 2569 PA-ENC-TS-ENC ::= SEQUENCE { 2570 patimestamp[0] KerberosTime, -- client's time 2571 pausec[1] INTEGER OPTIONAL 2572 } 2574 with patimestamp containing the client's time and pausec containing the 2575 microseconds which may be omitted if a client will not generate more 2576 than one request per second. The ciphertext (padata-value) consists of 2577 the PA-ENC-TS-ENC sequence, encrypted using the client's secret key. 2579 [use-specified-kvno item is here for discussion and may be removed] It 2580 may also be used by the client to specify the version of a key that is 2581 being used for accompanying preauthentication, and/or which should be 2582 used to encrypt the reply from the KDC. 2584 PA-USE-SPECIFIED-KVNO ::= Integer 2586 The KDC should only accept and abide by the value of the 2587 use-specified-kvno preauthentication data field when the specified key 2588 is still valid and until use of a new key is confirmed. This situation 2589 is likely to occur primarily during the period during which an updated 2590 key is propagating to other KDC's in a realm. 2592 The padata field can also contain information needed to help the KDC or 2593 the client select the key needed for generating or decrypting the 2594 response. This form of the padata is useful for supporting the use of 2595 certain token cards with Kerberos. The details of such extensions are 2596 specified in separate documents. See [Pat92] for additional uses of 2597 this field. 2598 the authentication protocol. These extensions provide for authentication of 2600 Neuman, Ts'o, Kohl Expires: 25 December, 2601 1999 2603 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 2604 1999 2606 padata-type 2607 The padata-type element of the padata field indicates the way that the 2608 padata-value element is to be interpreted. Negative values of 2609 padata-type are reserved for unregistered use; non-negative values are 2610 used for a registered interpretation of the element type. 2611 req-body 2612 This field is a placeholder delimiting the extent of the remaining 2613 fields. If a checksum is to be calculated over the request, it is 2614 calculated over an encoding of the KDC-REQ-BODY sequence which is 2615 enclosed within the req-body field. 2616 kdc-options 2617 This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the 2618 KDC and indicates the flags that the client wants set on the tickets as 2619 well as other information that is to modify the behavior of the KDC. 2620 Where appropriate, the name of an option may be the same as the flag 2621 that is set by that option. Although in most case, the bit in the 2622 options field will be the same as that in the flags field, this is not 2623 guaranteed, so it is not acceptable to simply copy the options field to 2624 the flags field. There are various checks that must be made before 2625 honoring an option anyway. 2627 The kdc_options field is a bit-field, where the selected options are 2628 indicated by the bit being set (1), and the unselected options and 2629 reserved fields being reset (0). The encoding of the bits is specified 2630 in section 5.2. The options are described in more detail above in 2631 section 2. The meanings of the options are: 2633 Bit(s) Name Description 2634 0 RESERVED 2635 Reserved for future expansion of 2636 this 2637 field. 2639 1 FORWARDABLE 2640 The FORWARDABLE option indicates 2641 that 2642 the ticket to be issued is to have 2643 its 2644 forwardable flag set. It may only 2645 be 2646 set on the initial request, or in a 2647 sub- 2648 sequent request if the 2649 ticket-granting 2650 ticket on which it is based is also 2651 for- 2652 wardable. 2654 2 FORWARDED 2655 The FORWARDED option is only 2656 specified 2657 in a request to the 2658 ticket-granting 2659 server and will only be honored if 2660 the 2661 ticket-granting ticket in the 2662 request 2663 has its FORWARDABLE bit set. 2664 This 2665 option indicates that this is a 2666 request 2667 for forwarding. The address(es) of 2668 the 2669 host from which the resulting ticket 2670 is 2671 to be valid are included in 2672 the 2673 addresses field of the request. 2675 the authentication protocol. These extensions provide for authentication of 2677 Neuman, Ts'o, Kohl Expires: 25 December, 2678 1999 2680 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 2681 1999 2683 3 PROXIABLE 2684 The PROXIABLE option indicates that 2685 the 2686 ticket to be issued is to have its 2687 prox- 2688 iable flag set. It may only be set 2689 on 2690 the initial request, or in a 2691 subsequent 2692 request if the ticket-granting ticket 2693 on 2694 which it is based is also proxiable. 2696 4 PROXY 2697 The PROXY option indicates that this 2698 is 2699 a request for a proxy. This option 2700 will 2701 only be honored if the 2702 ticket-granting 2703 ticket in the request has its 2704 PROXIABLE 2705 bit set. The address(es) of the 2706 host 2707 from which the resulting ticket is to 2708 be 2709 valid are included in the 2710 addresses 2711 field of the request. 2713 5 ALLOW-POSTDATE 2714 The ALLOW-POSTDATE option indicates 2715 that 2716 the ticket to be issued is to have 2717 its 2718 MAY-POSTDATE flag set. It may only 2719 be 2720 set on the initial request, or in a 2721 sub- 2722 sequent request if the 2723 ticket-granting 2724 ticket on which it is based also has 2725 its 2726 MAY-POSTDATE flag set. 2728 6 POSTDATED 2729 The POSTDATED option indicates that 2730 this 2731 is a request for a postdated 2732 ticket. 2733 This option will only be honored if 2734 the 2735 ticket-granting ticket on which it 2736 is 2737 based has its MAY-POSTDATE flag 2738 set. 2739 The resulting ticket will also have 2740 its 2741 INVALID flag set, and that flag may 2742 be 2743 reset by a subsequent request to the 2744 KDC 2745 after the starttime in the ticket 2746 has 2747 been reached. 2749 7 UNUSED 2750 This option is presently unused. 2752 8 RENEWABLE 2753 The RENEWABLE option indicates that 2754 the 2755 ticket to be issued is to have 2756 its 2757 RENEWABLE flag set. It may only be 2758 set 2759 on the initial request, or when 2760 the 2761 ticket-granting ticket on which 2762 the 2763 request is based is also renewable. 2764 If 2765 this option is requested, then the 2766 rtime 2767 field in the request contains 2768 the 2769 desired absolute expiration time for 2770 the 2771 ticket. 2773 9-13 UNUSED 2774 These options are presently unused. 2776 the authentication protocol. These extensions provide for authentication of 2778 Neuman, Ts'o, Kohl Expires: 25 December, 2779 1999 2781 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 2782 1999 2784 14 REQUEST-ANONYMOUS 2785 The REQUEST-ANONYMOUS option 2786 indicates 2787 that the ticket to be issued is not 2788 to 2789 identify the user to which it 2790 was 2791 issued. Instead, the principal 2792 identif- 2793 ier is to be generic, as specified 2794 by 2795 the policy of the realm (e.g. 2796 usually 2797 anonymous@realm). The purpose of 2798 the 2799 ticket is only to securely distribute 2800 a 2801 session key, and not to identify 2802 the 2803 user. The ANONYMOUS flag on the 2804 ticket 2805 to be returned should be set. If 2806 the 2807 local realms policy does not 2808 permit 2809 anonymous credentials, the request is 2810 to 2811 be rejected. 2813 15-25 RESERVED 2814 Reserved for future use. 2816 26 DISABLE-TRANSITED-CHECK 2817 By default the KDC will check the 2818 transited field of a ticket-granting- 2819 ticket against the policy of the local 2820 realm before it will issue derivative 2821 tickets based on the ticket granting 2822 ticket. If this flag is set in the 2823 request, checking of the transited 2824 field 2825 is disabled. Tickets issued without 2826 the 2827 performance of this check will be 2828 noted 2829 by the reset (0) value of the 2830 TRANSITED-POLICY-CHECKED flag, 2831 indicating to the application server 2832 that the tranisted field must be 2833 checked 2834 locally. KDC's are encouraged but not 2835 required to honor the 2836 DISABLE-TRANSITED-CHECK option. 2838 27 RENEWABLE-OK 2839 The RENEWABLE-OK option indicates that 2840 a 2841 renewable ticket will be acceptable if 2842 a 2843 ticket with the requested life 2844 cannot 2845 otherwise be provided. If a ticket 2846 with 2847 the requested life cannot be 2848 provided, 2849 then a renewable ticket may be 2850 issued 2851 with a renew-till equal to the 2852 the 2853 requested endtime. The value of 2854 the 2855 renew-till field may still be limited 2856 by 2857 local limits, or limits selected by 2858 the 2859 individual principal or server. 2861 28 ENC-TKT-IN-SKEY 2862 This option is used only by the 2863 ticket- 2864 granting service. The 2865 ENC-TKT-IN-SKEY 2866 option indicates that the ticket for 2867 the 2868 end server is to be encrypted in 2869 the 2870 session key from the additional 2871 ticket- 2872 granting ticket provided. 2874 the authentication protocol. These extensions provide for authentication of 2876 Neuman, Ts'o, Kohl Expires: 25 December, 2877 1999 2879 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 2880 1999 2882 29 RESERVED 2883 Reserved for future use. 2885 30 RENEW 2886 This option is used only by the 2887 ticket- 2888 granting service. The RENEW 2889 option 2890 indicates that the present request 2891 is 2892 for a renewal. The ticket provided 2893 is 2894 encrypted in the secret key for 2895 the 2896 server on which it is valid. 2897 This 2898 option will only be honored if 2899 the 2900 ticket to be renewed has its 2901 RENEWABLE 2902 flag set and if the time in its 2903 renew- 2904 till field has not passed. The 2905 ticket 2906 to be renewed is passed in the 2907 padata 2908 field as part of the 2909 authentication 2910 header. 2912 31 VALIDATE 2913 This option is used only by the 2914 ticket- 2915 granting service. The VALIDATE 2916 option 2917 indicates that the request is to 2918 vali- 2919 date a postdated ticket. It will 2920 only 2921 be honored if the ticket presented 2922 is 2923 postdated, presently has its 2924 INVALID 2925 flag set, and would be otherwise 2926 usable 2927 at this time. A ticket cannot be 2928 vali- 2929 dated before its starttime. The 2930 ticket 2931 presented for validation is encrypted 2932 in 2933 the key of the server for which it 2934 is 2935 valid and is passed in the padata 2936 field 2937 as part of the authentication header. 2939 cname and sname 2940 These fields are the same as those described for the ticket in section 2941 5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY option is 2942 specified. If absent, the name of the server is taken from the name of 2943 the client in the ticket passed as additional-tickets. 2944 enc-authorization-data 2945 The enc-authorization-data, if present (and it can only be present in 2946 the TGS_REQ form), is an encoding of the desired authorization-data 2947 encrypted under the sub-session key if present in the Authenticator, or 2948 alternatively from the session key in the ticket-granting ticket, both 2949 from the padata field in the KRB_AP_REQ. 2950 realm 2951 This field specifies the realm part of the server's principal 2952 identifier. In the AS exchange, this is also the realm part of the 2953 client's principal identifier. 2954 from 2955 This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket 2956 requests when the requested ticket is to be postdated. It specifies the 2957 desired start time for the requested ticket. If this field is omitted 2958 then the KDC should use the current time instead. 2959 till 2960 This field contains the expiration date requested by the client in a 2961 ticket request. It is optional and if omitted the requested ticket is 2962 to have the maximum endtime permitted according to KDC policy for the 2963 parties to the authentication exchange as limited by expiration date of 2964 the ticket granting ticket or other preauthentication credentials. 2965 the authentication protocol. These extensions provide for authentication of 2967 Neuman, Ts'o, Kohl Expires: 25 December, 2968 1999 2970 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 2971 1999 2973 rtime 2974 This field is the requested renew-till time sent from a client to the 2975 KDC in a ticket request. It is optional. 2976 nonce 2977 This field is part of the KDC request and response. It it intended to 2978 hold a random number generated by the client. If the same number is 2979 included in the encrypted response from the KDC, it provides evidence 2980 that the response is fresh and has not been replayed by an attacker. 2981 Nonces must never be re-used. Ideally, it should be generated randomly, 2982 but if the correct time is known, it may suffice[25]. 2983 etype 2984 This field specifies the desired encryption algorithm to be used in the 2985 response. 2986 addresses 2987 This field is included in the initial request for tickets, and 2988 optionally included in requests for additional tickets from the 2989 ticket-granting server. It specifies the addresses from which the 2990 requested ticket is to be valid. Normally it includes the addresses for 2991 the client's host. If a proxy is requested, this field will contain 2992 other addresses. The contents of this field are usually copied by the 2993 KDC into the caddr field of the resulting ticket. 2994 additional-tickets 2995 Additional tickets may be optionally included in a request to the 2996 ticket-granting server. If the ENC-TKT-IN-SKEY option has been 2997 specified, then the session key from the additional ticket will be used 2998 in place of the server's key to encrypt the new ticket. If more than 2999 one option which requires additional tickets has been specified, then 3000 the additional tickets are used in the order specified by the ordering 3001 of the options bits (see kdc-options, above). 3003 The application code will be either ten (10) or twelve (12) depending on 3004 whether the request is for an initial ticket (AS-REQ) or for an additional 3005 ticket (TGS-REQ). 3007 The optional fields (addresses, authorization-data and additional-tickets) 3008 are only included if necessary to perform the operation specified in the 3009 kdc-options field. 3011 It should be noted that in KRB_TGS_REQ, the protocol version number appears 3012 twice and two different message types appear: the KRB_TGS_REQ message 3013 contains these fields as does the authentication header (KRB_AP_REQ) that is 3014 passed in the padata field. 3016 5.4.2. KRB_KDC_REP definition 3018 The KRB_KDC_REP message format is used for the reply from the KDC for either 3019 an initial (AS) request or a subsequent (TGS) request. There is no message 3020 type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or 3021 KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply 3022 depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in 3023 the client's secret key, and the client's key version number is included in 3024 the key version number for the encrypted data. For KRB_TGS_REP, the 3025 ciphertext is encrypted in the sub-session key from the Authenticator, or if 3026 absent, the session key from the ticket-granting ticket used in the request. 3027 In that case, no version number will be present in the EncryptedData 3028 sequence. 3030 the authentication protocol. These extensions provide for authentication of 3032 Neuman, Ts'o, Kohl Expires: 25 December, 3033 1999 3035 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 3036 1999 3038 The KRB_KDC_REP message contains the following fields: 3040 AS-REP ::= [APPLICATION 11] KDC-REP 3041 TGS-REP ::= [APPLICATION 13] KDC-REP 3043 KDC-REP ::= SEQUENCE { 3044 pvno[0] INTEGER, 3045 msg-type[1] INTEGER, 3046 padata[2] SEQUENCE OF PA-DATA OPTIONAL, 3047 crealm[3] Realm, 3048 cname[4] PrincipalName, 3049 ticket[5] Ticket, 3050 enc-part[6] EncryptedData 3051 } 3053 EncASRepPart ::= [APPLICATION 25[27]] EncKDCRepPart 3054 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 3056 EncKDCRepPart ::= SEQUENCE { 3057 key[0] EncryptionKey, 3058 last-req[1] LastReq, 3059 nonce[2] INTEGER, 3060 key-expiration[3] KerberosTime OPTIONAL, 3061 flags[4] TicketFlags, 3062 authtime[5] KerberosTime, 3063 starttime[6] KerberosTime OPTIONAL, 3064 endtime[7] KerberosTime, 3065 renew-till[8] KerberosTime OPTIONAL, 3066 srealm[9] Realm, 3067 sname[10] PrincipalName, 3068 caddr[11] HostAddresses OPTIONAL 3069 } 3071 pvno and msg-type 3072 These fields are described above in section 5.4.1. msg-type is either 3073 KRB_AS_REP or KRB_TGS_REP. 3074 padata 3075 This field is described in detail in section 5.4.1. One possible use 3076 for this field is to encode an alternate "mix-in" string to be used 3077 with a string-to-key algorithm (such as is described in section 6.3.2). 3078 This ability is useful to ease transitions if a realm name needs to 3079 change (e.g. when a company is acquired); in such a case all existing 3080 password-derived entries in the KDC database would be flagged as 3081 needing a special mix-in string until the next password change. 3082 crealm, cname, srealm and sname 3083 These fields are the same as those described for the ticket in section 3084 5.3.1. 3085 ticket 3086 The newly-issued ticket, from section 5.3.1. 3087 enc-part 3088 This field is a place holder for the ciphertext and related information 3089 that forms the encrypted part of a message. The description of the 3090 encrypted part of the message follows each appearance of this field. 3091 The encrypted part is encoded as described in section 6.1. 3092 key 3093 This field is the same as described for the ticket in section 5.3.1. 3094 the authentication protocol. These extensions provide for authentication of 3096 Neuman, Ts'o, Kohl Expires: 25 December, 3097 1999 3099 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 3100 1999 3102 last-req 3103 This field is returned by the KDC and specifies the time(s) of the last 3104 request by a principal. Depending on what information is available, 3105 this might be the last time that a request for a ticket-granting ticket 3106 was made, or the last time that a request based on a ticket-granting 3107 ticket was successful. It also might cover all servers for a realm, or 3108 just the particular server. Some implementations may display this 3109 information to the user to aid in discovering unauthorized use of one's 3110 identity. It is similar in spirit to the last login time displayed when 3111 logging into timesharing systems. 3112 nonce 3113 This field is described above in section 5.4.1. 3114 key-expiration 3115 The key-expiration field is part of the response from the KDC and 3116 specifies the time that the client's secret key is due to expire. The 3117 expiration might be the result of password aging or an account 3118 expiration. This field will usually be left out of the TGS reply since 3119 the response to the TGS request is encrypted in a session key and no 3120 client information need be retrieved from the KDC database. It is up to 3121 the application client (usually the login program) to take appropriate 3122 action (such as notifying the user) if the expiration time is imminent. 3123 flags, authtime, starttime, endtime, renew-till and caddr 3124 These fields are duplicates of those found in the encrypted portion of 3125 the attached ticket (see section 5.3.1), provided so the client may 3126 verify they match the intended request and to assist in proper ticket 3127 caching. If the message is of type KRB_TGS_REP, the caddr field will 3128 only be filled in if the request was for a proxy or forwarded ticket, 3129 or if the user is substituting a subset of the addresses from the 3130 ticket granting ticket. If the client-requested addresses are not 3131 present or not used, then the addresses contained in the ticket will be 3132 the same as those included in the ticket-granting ticket. 3134 5.5. Client/Server (CS) message specifications 3136 This section specifies the format of the messages used for the 3137 authentication of the client to the application server. 3139 5.5.1. KRB_AP_REQ definition 3141 The KRB_AP_REQ message contains the Kerberos protocol version number, the 3142 message type KRB_AP_REQ, an options field to indicate any options in use, 3143 and the ticket and authenticator themselves. The KRB_AP_REQ message is often 3144 referred to as the 'authentication header'. 3146 AP-REQ ::= [APPLICATION 14] SEQUENCE { 3147 pvno[0] INTEGER, 3148 msg-type[1] INTEGER, 3149 ap-options[2] APOptions, 3150 ticket[3] Ticket, 3151 authenticator[4] EncryptedData 3152 } 3154 APOptions ::= BIT STRING { 3155 reserved(0), 3156 use-session-key(1), 3157 mutual-required(2) 3158 } 3160 the authentication protocol. These extensions provide for authentication of 3162 Neuman, Ts'o, Kohl Expires: 25 December, 3163 1999 3165 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 3166 1999 3168 pvno and msg-type 3169 These fields are described above in section 5.4.1. msg-type is 3170 KRB_AP_REQ. 3171 ap-options 3172 This field appears in the application request (KRB_AP_REQ) and affects 3173 the way the request is processed. It is a bit-field, where the selected 3174 options are indicated by the bit being set (1), and the unselected 3175 options and reserved fields being reset (0). The encoding of the bits 3176 is specified in section 5.2. The meanings of the options are: 3178 Bit(s) Name Description 3180 0 RESERVED 3181 Reserved for future expansion of this 3182 field. 3184 1 USE-SESSION-KEY 3185 The USE-SESSION-KEY option indicates 3186 that the ticket the client is presenting 3187 to a server is encrypted in the session 3188 key from the server's ticket-granting 3189 ticket. When this option is not speci- 3190 fied, the ticket is encrypted in the 3191 server's secret key. 3193 2 MUTUAL-REQUIRED 3194 The MUTUAL-REQUIRED option tells the 3195 server that the client requires mutual 3196 authentication, and that it must respond 3197 with a KRB_AP_REP message. 3199 3-31 RESERVED 3200 Reserved for future use. 3202 ticket 3203 This field is a ticket authenticating the client to the server. 3204 authenticator 3205 This contains the authenticator, which includes the client's choice of 3206 a subkey. Its encoding is described in section 5.3.2. 3208 5.5.2. KRB_AP_REP definition 3210 The KRB_AP_REP message contains the Kerberos protocol version number, the 3211 message type, and an encrypted time- stamp. The message is sent in in 3212 response to an application request (KRB_AP_REQ) where the mutual 3213 authentication option has been selected in the ap-options field. 3215 AP-REP ::= [APPLICATION 15] SEQUENCE { 3216 pvno[0] INTEGER, 3217 msg-type[1] INTEGER, 3218 enc-part[2] EncryptedData 3219 } 3221 EncAPRepPart ::= [APPLICATION 27[29]] SEQUENCE { 3222 ctime[0] KerberosTime, 3223 cusec[1] INTEGER, 3224 subkey[2] EncryptionKey OPTIONAL, 3225 seq-number[3] INTEGER OPTIONAL 3226 } 3227 the authentication protocol. These extensions provide for authentication of 3229 Neuman, Ts'o, Kohl Expires: 25 December, 3230 1999 3232 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 3233 1999 3235 The encoded EncAPRepPart is encrypted in the shared session key of the 3236 ticket. The optional subkey field can be used in an application-arranged 3237 negotiation to choose a per association session key. 3239 pvno and msg-type 3240 These fields are described above in section 5.4.1. msg-type is 3241 KRB_AP_REP. 3242 enc-part 3243 This field is described above in section 5.4.2. 3244 ctime 3245 This field contains the current time on the client's host. 3246 cusec 3247 This field contains the microsecond part of the client's timestamp. 3248 subkey 3249 This field contains an encryption key which is to be used to protect 3250 this specific application session. See section 3.2.6 for specifics on 3251 how this field is used to negotiate a key. Unless an application 3252 specifies otherwise, if this field is left out, the sub-session key 3253 from the authenticator, or if also left out, the session key from the 3254 ticket will be used. 3256 5.5.3. Error message reply 3258 If an error occurs while processing the application request, the KRB_ERROR 3259 message will be sent in response. See section 5.9.1 for the format of the 3260 error message. The cname and crealm fields may be left out if the server 3261 cannot determine their appropriate values from the corresponding KRB_AP_REQ 3262 message. If the authenticator was decipherable, the ctime and cusec fields 3263 will contain the values from it. 3265 5.6. KRB_SAFE message specification 3267 This section specifies the format of a message that can be used by either 3268 side (client or server) of an application to send a tamper-proof message to 3269 its peer. It presumes that a session key has previously been exchanged (for 3270 example, by using the KRB_AP_REQ/KRB_AP_REP messages). 3272 5.6.1. KRB_SAFE definition 3274 The KRB_SAFE message contains user data along with a collision-proof 3275 checksum keyed with the last encryption key negotiated via subkeys, or the 3276 session key if no negotiation has occured. The message fields are: 3278 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 3279 pvno[0] INTEGER, 3280 msg-type[1] INTEGER, 3281 safe-body[2] KRB-SAFE-BODY, 3282 cksum[3] Checksum 3283 } 3285 KRB-SAFE-BODY ::= SEQUENCE { 3286 user-data[0] OCTET STRING, 3287 timestamp[1] KerberosTime OPTIONAL, 3288 usec[2] INTEGER OPTIONAL, 3289 seq-number[3] INTEGER OPTIONAL, 3290 s-address[4] HostAddress OPTIONAL, 3291 r-address[5] HostAddress OPTIONAL 3292 } 3294 the authentication protocol. These extensions provide for authentication of 3296 Neuman, Ts'o, Kohl Expires: 25 December, 3297 1999 3299 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 3300 1999 3302 pvno and msg-type 3303 These fields are described above in section 5.4.1. msg-type is 3304 KRB_SAFE. 3305 safe-body 3306 This field is a placeholder for the body of the KRB-SAFE message. 3307 cksum 3308 This field contains the checksum of the application data. Checksum 3309 details are described in section 6.4. The checksum is computed over the 3310 encoding of the KRB-SAFE sequence. First, the cksum is zeroed and the 3311 checksum is computed over the encoding of the KRB-SAFE sequence, then 3312 the checksum is set to the result of that computation, and finally the 3313 KRB-SAFE sequence is encoded again. 3314 user-data 3315 This field is part of the KRB_SAFE and KRB_PRIV messages and contain 3316 the application specific data that is being passed from the sender to 3317 the recipient. 3318 timestamp 3319 This field is part of the KRB_SAFE and KRB_PRIV messages. Its contents 3320 are the current time as known by the sender of the message. By checking 3321 the timestamp, the recipient of the message is able to make sure that 3322 it was recently generated, and is not a replay. 3323 usec 3324 This field is part of the KRB_SAFE and KRB_PRIV headers. It contains 3325 the microsecond part of the timestamp. 3326 seq-number 3327 This field is described above in section 5.3.2. 3328 s-address 3329 This field specifies the address in use by the sender of the message. 3330 It may be omitted if not required by the application protocol. The 3331 application designer considering omission of this field is warned, that 3332 the inclusion of this address prevents some kinds of replay attacks 3333 (e.g., reflection attacks) and that it is only acceptable to omit this 3334 address if there is sufficient information in the integrity protected 3335 part of the application message for the recipient to unambiguously 3336 determine if it was the intended recipient. 3337 r-address 3338 This field specifies the address in use by the recipient of the 3339 message. It may be omitted for some uses (such as broadcast protocols), 3340 but the recipient may arbitrarily reject such messages. This field 3341 along with s-address can be used to help detect messages which have 3342 been incorrectly or maliciously delivered to the wrong recipient. 3344 5.7. KRB_PRIV message specification 3346 This section specifies the format of a message that can be used by either 3347 side (client or server) of an application to securely and privately send a 3348 message to its peer. It presumes that a session key has previously been 3349 exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages). 3351 5.7.1. KRB_PRIV definition 3353 The KRB_PRIV message contains user data encrypted in the Session Key. The 3354 message fields are: 3356 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 3357 pvno[0] INTEGER, 3358 msg-type[1] INTEGER, 3359 enc-part[3] EncryptedData 3360 } 3362 the authentication protocol. These extensions provide for authentication of 3364 Neuman, Ts'o, Kohl Expires: 25 December, 3365 1999 3367 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 3368 1999 3370 EncKrbPrivPart ::= [APPLICATION 28[31]] SEQUENCE { 3371 user-data[0] OCTET STRING, 3372 timestamp[1] KerberosTime OPTIONAL, 3373 usec[2] INTEGER OPTIONAL, 3374 seq-number[3] INTEGER OPTIONAL, 3375 s-address[4] HostAddress OPTIONAL, -- sender's 3376 addr 3377 r-address[5] HostAddress OPTIONAL -- recip's 3378 addr 3379 } 3381 pvno and msg-type 3382 These fields are described above in section 5.4.1. msg-type is 3383 KRB_PRIV. 3384 enc-part 3385 This field holds an encoding of the EncKrbPrivPart sequence encrypted 3386 under the session key[32]. This encrypted encoding is used for the 3387 enc-part field of the KRB-PRIV message. See section 6 for the format of 3388 the ciphertext. 3389 user-data, timestamp, usec, s-address and r-address 3390 These fields are described above in section 5.6.1. 3391 seq-number 3392 This field is described above in section 5.3.2. 3394 5.8. KRB_CRED message specification 3396 This section specifies the format of a message that can be used to send 3397 Kerberos credentials from one principal to another. It is presented here to 3398 encourage a common mechanism to be used by applications when forwarding 3399 tickets or providing proxies to subordinate servers. It presumes that a 3400 session key has already been exchanged perhaps by using the 3401 KRB_AP_REQ/KRB_AP_REP messages. 3403 5.8.1. KRB_CRED definition 3405 The KRB_CRED message contains a sequence of tickets to be sent and 3406 information needed to use the tickets, including the session key from each. 3407 The information needed to use the tickets is encrypted under an encryption 3408 key previously exchanged or transferred alongside the KRB_CRED message. The 3409 message fields are: 3411 KRB-CRED ::= [APPLICATION 22] SEQUENCE { 3412 pvno[0] INTEGER, 3413 msg-type[1] INTEGER, -- KRB_CRED 3414 tickets[2] SEQUENCE OF Ticket, 3415 enc-part[3] EncryptedData 3416 } 3418 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 3419 ticket-info[0] SEQUENCE OF KrbCredInfo, 3420 nonce[1] INTEGER OPTIONAL, 3421 timestamp[2] KerberosTime OPTIONAL, 3422 usec[3] INTEGER OPTIONAL, 3423 s-address[4] HostAddress OPTIONAL, 3424 r-address[5] HostAddress OPTIONAL 3425 } 3427 KrbCredInfo ::= SEQUENCE { 3428 key[0] EncryptionKey, 3429 prealm[1] Realm OPTIONAL, 3430 the authentication protocol. These extensions provide for authentication of 3432 Neuman, Ts'o, Kohl Expires: 25 December, 3433 1999 3435 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 3436 1999 3438 pname[2] PrincipalName OPTIONAL, 3439 flags[3] TicketFlags OPTIONAL, 3440 authtime[4] KerberosTime OPTIONAL, 3441 starttime[5] KerberosTime OPTIONAL, 3442 endtime[6] KerberosTime OPTIONAL 3443 renew-till[7] KerberosTime OPTIONAL, 3444 srealm[8] Realm OPTIONAL, 3445 sname[9] PrincipalName OPTIONAL, 3446 caddr[10] HostAddresses OPTIONAL 3447 } 3449 pvno and msg-type 3450 These fields are described above in section 5.4.1. msg-type is 3451 KRB_CRED. 3452 tickets 3453 These are the tickets obtained from the KDC specifically for use by the 3454 intended recipient. Successive tickets are paired with the 3455 corresponding KrbCredInfo sequence from the enc-part of the KRB-CRED 3456 message. 3457 enc-part 3458 This field holds an encoding of the EncKrbCredPart sequence encrypted 3459 under the session key shared between the sender and the intended 3460 recipient. This encrypted encoding is used for the enc-part field of 3461 the KRB-CRED message. See section 6 for the format of the ciphertext. 3462 nonce 3463 If practical, an application may require the inclusion of a nonce 3464 generated by the recipient of the message. If the same value is 3465 included as the nonce in the message, it provides evidence that the 3466 message is fresh and has not been replayed by an attacker. A nonce must 3467 never be re-used; it should be generated randomly by the recipient of 3468 the message and provided to the sender of the message in an application 3469 specific manner. 3470 timestamp and usec 3471 These fields specify the time that the KRB-CRED message was generated. 3472 The time is used to provide assurance that the message is fresh. 3473 s-address and r-address 3474 These fields are described above in section 5.6.1. They are used 3475 optionally to provide additional assurance of the integrity of the 3476 KRB-CRED message. 3477 key 3478 This field exists in the corresponding ticket passed by the KRB-CRED 3479 message and is used to pass the session key from the sender to the 3480 intended recipient. The field's encoding is described in section 6.2. 3482 The following fields are optional. If present, they can be associated with 3483 the credentials in the remote ticket file. If left out, then it is assumed 3484 that the recipient of the credentials already knows their value. 3486 prealm and pname 3487 The name and realm of the delegated principal identity. 3488 flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr 3489 These fields contain the values of the correspond- ing fields from the 3490 ticket found in the ticket field. Descriptions of the fields are 3491 identical to the descriptions in the KDC-REP message. 3493 the authentication protocol. These extensions provide for authentication of 3495 Neuman, Ts'o, Kohl Expires: 25 December, 3496 1999 3498 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 3499 1999 3501 5.9. Error message specification 3503 This section specifies the format for the KRB_ERROR message. The fields 3504 included in the message are intended to return as much information as 3505 possible about an error. It is not expected that all the information 3506 required by the fields will be available for all types of errors. If the 3507 appropriate information is not available when the message is composed, the 3508 corresponding field will be left out of the message. 3510 Note that since the KRB_ERROR message is only optionally integrity 3511 protected, it is quite possible for an intruder to synthesize or modify such 3512 a message. In particular, this means that unless appropriate integrity 3513 protection mechanisms have been applied to the KRB_ERROR message, the client 3514 should not use any fields in this message for security-critical purposes, 3515 such as setting a system clock or generating a fresh authenticator. The 3516 message can be useful, however, for advising a user on the reason for some 3517 failure. 3519 5.9.1. KRB_ERROR definition 3521 The KRB_ERROR message consists of the following fields: 3523 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 3524 pvno[0] INTEGER, 3525 msg-type[1] INTEGER, 3526 ctime[2] KerberosTime OPTIONAL, 3527 cusec[3] INTEGER OPTIONAL, 3528 stime[4] KerberosTime, 3529 susec[5] INTEGER, 3530 error-code[6] INTEGER, 3531 crealm[7] Realm OPTIONAL, 3532 cname[8] PrincipalName OPTIONAL, 3533 realm[9] Realm, -- Correct realm 3534 sname[10] PrincipalName, -- Correct name 3535 e-text[11] GeneralString OPTIONAL, 3536 e-data[12] OCTET STRING OPTIONAL, 3537 e-cksum[13] Checksum OPTIONAL, 3538 (*REMOVE7/14*) e-typed-data[14] SEQUENCE of ETypedData 3539 OPTIONAL 3540 } 3542 pvno and msg-type 3543 These fields are described above in section 5.4.1. msg-type is 3544 KRB_ERROR. 3545 ctime 3546 This field is described above in section 5.4.1. 3547 cusec 3548 This field is described above in section 5.5.2. 3549 stime 3550 This field contains the current time on the server. It is of type 3551 KerberosTime. 3552 susec 3553 This field contains the microsecond part of the server's timestamp. Its 3554 value ranges from 0 to 999999. It appears along with stime. The two 3555 fields are used in conjunction to specify a reasonably accurate 3556 timestamp. 3557 the authentication protocol. These extensions provide for authentication of 3559 Neuman, Ts'o, Kohl Expires: 25 December, 3560 1999 3562 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 3563 1999 3565 error-code 3566 This field contains the error code returned by Kerberos or the server 3567 when a request fails. To interpret the value of this field see the list 3568 of error codes in section 8. Implementations are encouraged to provide 3569 for national language support in the display of error messages. 3570 crealm, cname, srealm and sname 3571 These fields are described above in section 5.3.1. 3572 e-text 3573 This field contains additional text to help explain the error code 3574 associated with the failed request (for example, it might include a 3575 principal name which was unknown). 3576 e-data 3577 This field contains additional data about the error for use by the 3578 application to help it recover from or handle the error. If present, 3579 this field will contain the encoding of a sequence of TypedData 3580 (TYPED-DATA below), unless the errorcode is KDC_ERR_PREAUTH_REQUIRED, 3581 in which case it will contain the encoding of a sequence of of padata 3582 fields (METHOD-DATA below), each corresponding to an acceptable 3583 pre-authentication method and optionally containing data for the 3584 method: 3586 TYPED-DATA ::= SEQUENCE of TypeData 3587 METHOD-DATA ::= SEQUENCE of PA-DATA 3589 TypedData ::= SEQUENCE { 3590 data-type[0] INTEGER, 3591 data-value[1] OCTET STRING OPTIONAL 3592 } 3594 Note that e-data-types have been reserved for all PA data types defined 3595 prior to July 1999. For the KDC_ERR_PREAUTH_REQUIRED message, when 3596 using new PA data types defined in July 1999 or later, the METHOD-DATA 3597 sequence must itself be encapsulated in an TypedData element of type 3598 TD-PADATA. All new implementations interpreting the METHOD-DATA field 3599 for the KDC_ERR_PREAUTH_REQUIRED message must accept a type of 3600 TD-PADATA, extract the typed data field and interpret the use any 3601 elements encapsulated in the TD-PADATA elements as if they were present 3602 in the METHOD-DATA sequence. 3603 e-cksum 3604 This field contains an optional checksum for the KRB-ERROR message. The 3605 checksum is calculated over the Kerberos ASN.1 encoding of the 3606 KRB-ERROR message with the checksum absent. The checksum is then added 3607 to the KRB-ERROR structure and the message is re-encoded. The Checksum 3608 should be calculated using the session key from the ticket granting 3609 ticket or service ticket, where available. If the error is in response 3610 to a TGS or AP request, the checksum should be calculated uing the the 3611 session key from the client's ticket. If the error is in response to an 3612 AS request, then the checksum should be calulated using the client's 3613 secret key ONLY if there has been suitable preauthentication to prove 3614 knowledge of the secret key by the client[33]. If a checksum can not be 3615 computed because the key to be used is not available, no checksum will 3616 be included. 3617 e-typed-data 3618 [***Will be deleted 7/14***] This field contains optional data that may 3619 be used to help the client recover from the indicated error. [This 3620 could contain the METHOD-DATA specified since I don't think anyone 3621 actually uses it yet. It could also contain the PA-DATA sequence for 3622 the preauth required error if we had a clear way to transition to the 3623 the authentication protocol. These extensions provide for authentication of 3625 Neuman, Ts'o, Kohl Expires: 25 December, 3626 1999 3628 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 3629 1999 3631 use of this field from the use of the untyped e-data field.] For 3632 example, this field may specify the key version of the key used to 3633 verify preauthentication: 3635 e-data-type := 20 -- Key version number 3636 e-data-value := Integer -- Key version number used to 3637 verify preauthentication 3639 6. Encryption and Checksum Specifications 3641 The Kerberos protocols described in this document are designed to use stream 3642 encryption ciphers, which can be simulated using commonly available block 3643 encryption ciphers, such as the Data Encryption Standard, [DES77] in 3644 conjunction with block chaining and checksum methods [DESM80]. Encryption is 3645 used to prove the identities of the network entities participating in 3646 message exchanges. The Key Distribution Center for each realm is trusted by 3647 all principals registered in that realm to store a secret key in confidence. 3648 Proof of knowledge of this secret key is used to verify the authenticity of 3649 a principal. [*** Discussion above will change to use 3DES as example 3650 7/14/99 ***] 3652 The KDC uses the principal's secret key (in the AS exchange) or a shared 3653 session key (in the TGS exchange) to encrypt responses to ticket requests; 3654 the ability to obtain the secret key or session key implies the knowledge of 3655 the appropriate keys and the identity of the KDC. The ability of a principal 3656 to decrypt the KDC response and present a Ticket and a properly formed 3657 Authenticator (generated with the session key from the KDC response) to a 3658 service verifies the identity of the principal; likewise the ability of the 3659 service to extract the session key from the Ticket and prove its knowledge 3660 thereof in a response verifies the identity of the service. 3662 The Kerberos protocols generally assume that the encryption used is secure 3663 from cryptanalysis; however, in some cases, the order of fields in the 3664 encrypted portions of messages are arranged to minimize the effects of 3665 poorly chosen keys. It is still important to choose good keys. If keys are 3666 derived from user-typed passwords, those passwords need to be well chosen to 3667 make brute force attacks more difficult. Poorly chosen keys still make easy 3668 targets for intruders. 3670 The following sections specify the encryption and checksum mechanisms 3671 currently defined for Kerberos. The encodings, chaining, and padding 3672 requirements for each are described. For encryption methods, it is often 3673 desirable to place random information (often referred to as a confounder) at 3674 the start of the message. The requirements for a confounder are specified 3675 with each encryption mechanism. 3677 Some encryption systems use a block-chaining method to improve the the 3678 security characteristics of the ciphertext. However, these chaining methods 3679 often don't provide an integrity check upon decryption. Such systems (such 3680 as DES in CBC mode) must be augmented with a checksum of the plain-text 3681 which can be verified at decryption and used to detect any tampering or 3682 damage. Such checksums should be good at detecting burst errors in the 3683 input. If any damage is detected, the decryption routine is expected to 3684 return an error indicating the failure of an integrity check. Each 3685 encryption type is expected to provide and verify an appropriate checksum. 3686 The specification of each encryption method sets out its checksum 3687 requirements. 3689 the authentication protocol. These extensions provide for authentication of 3691 Neuman, Ts'o, Kohl Expires: 25 December, 3692 1999 3694 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 3695 1999 3697 Finally, where a key is to be derived from a user's password, an algorithm 3698 for converting the password to a key of the appropriate type is included. It 3699 is desirable for the string to key function to be one-way, and for the 3700 mapping to be different in different realms. This is important because users 3701 who are registered in more than one realm will often use the same password 3702 in each, and it is desirable that an attacker compromising the Kerberos 3703 server in one realm not obtain or derive the user's key in another. 3705 For an discussion of the integrity characteristics of the candidate 3706 encryption and checksum methods considered for Kerberos, the reader is 3707 referred to [SG92]. 3709 6.1. Encryption Specifications 3711 The following ASN.1 definition describes all encrypted messages. The 3712 enc-part field which appears in the unencrypted part of messages in section 3713 5 is a sequence consisting of an encryption type, an optional key version 3714 number, and the ciphertext. 3716 EncryptedData ::= SEQUENCE { 3717 etype[0] INTEGER, -- EncryptionType 3718 kvno[1] INTEGER OPTIONAL, 3719 cipher[2] OCTET STRING -- ciphertext 3720 } 3722 etype 3723 This field identifies which encryption algorithm was used to encipher 3724 the cipher. Detailed specifications for selected encryption types 3725 appear later in this section. 3726 kvno 3727 This field contains the version number of the key under which data is 3728 encrypted. It is only present in messages encrypted under long lasting 3729 keys, such as principals' secret keys. 3730 cipher 3731 This field contains the enciphered text, encoded as an OCTET STRING. 3733 The cipher field is generated by applying the specified encryption algorithm 3734 to data composed of the message and algorithm-specific inputs. Encryption 3735 mechanisms defined for use with Kerberos must take sufficient measures to 3736 guarantee the integrity of the plaintext, and we recommend they also take 3737 measures to protect against precomputed dictionary attacks. If the 3738 encryption algorithm is not itself capable of doing so, the protections can 3739 often be enhanced by adding a checksum and a confounder. 3741 The suggested format for the data to be encrypted includes a confounder, a 3742 checksum, the encoded plaintext, and any necessary padding. The msg-seq 3743 field contains the part of the protocol message described in section 5 which 3744 is to be encrypted. The confounder, checksum, and padding are all untagged 3745 and untyped, and their length is exactly sufficient to hold the appropriate 3746 item. The type and length is implicit and specified by the particular 3747 encryption type being used (etype). The format for the data to be encrypted 3748 is described in the following diagram: 3750 the authentication protocol. These extensions provide for authentication of 3752 Neuman, Ts'o, Kohl Expires: 25 December, 3753 1999 3755 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 3756 1999 3758 +-----------+----------+-------------+-----+ 3759 |confounder | check | msg-seq | pad | 3760 +-----------+----------+-------------+-----+ 3762 The format cannot be described in ASN.1, but for those who prefer an 3763 ASN.1-like notation: 3765 CipherText ::= ENCRYPTED SEQUENCE { 3766 confounder[0] UNTAGGED[35] OCTET STRING(conf_length) OPTIONAL, 3767 check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL, 3768 msg-seq[2] MsgSequence, 3769 pad UNTAGGED OCTET STRING(pad_length) OPTIONAL 3770 } 3772 One generates a random confounder of the appropriate length, placing it in 3773 confounder; zeroes out check; calculates the appropriate checksum over 3774 confounder, check, and msg-seq, placing the result in check; adds the 3775 necessary padding; then encrypts using the specified encryption type and the 3776 appropriate key. 3778 Unless otherwise specified, a definition of an encryption algorithm that 3779 specifies a checksum, a length for the confounder field, or an octet 3780 boundary for padding uses this ciphertext format[36]. Those fields which are 3781 not specified will be omitted. 3783 In the interest of allowing all implementations using a particular 3784 encryption type to communicate with all others using that type, the 3785 specification of an encryption type defines any checksum that is needed as 3786 part of the encryption process. If an alternative checksum is to be used, a 3787 new encryption type must be defined. 3789 Some cryptosystems require additional information beyond the key and the 3790 data to be encrypted. For example, DES, when used in cipher-block-chaining 3791 mode, requires an initialization vector. If required, the description for 3792 each encryption type must specify the source of such additional information. 3793 6.2. Encryption Keys 3795 The sequence below shows the encoding of an encryption key: 3797 EncryptionKey ::= SEQUENCE { 3798 keytype[0] INTEGER, 3799 keyvalue[1] OCTET STRING 3800 } 3802 keytype 3803 This field specifies the type of encryption that is to be performed 3804 using the key that follows in the keyvalue field. It will always 3805 correspond to the etype to be used to generate or decode the 3806 EncryptedData. In cases when multiple algorithms use a common kind of 3807 key (e.g., if the encryption algorithm uses an alternate checksum 3808 algorithm for an integrity check, or a different chaining mechanism), 3809 the keytype provides information needed to determine which algorithm is 3810 to be used. 3811 keyvalue 3812 This field contains the key itself, encoded as an octet string. 3814 All negative values for the encryption key type are reserved for local use. 3815 All non-negative values are reserved for officially assigned type fields and 3816 interpreta- tions. 3818 the authentication protocol. These extensions provide for authentication of 3820 Neuman, Ts'o, Kohl Expires: 25 December, 3821 1999 3823 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 3824 1999 3826 6.3. Encryption Systems 3828 6.3.1. The NULL Encryption System (null) 3830 If no encryption is in use, the encryption system is said to be the NULL 3831 encryption system. In the NULL encryption system there is no checksum, 3832 confounder or padding. The ciphertext is simply the plaintext. The NULL Key 3833 is used by the null encryption system and is zero octets in length, with 3834 keytype zero (0). 3836 6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc) 3838 The des-cbc-crc encryption mode encrypts information under the Data 3839 Encryption Standard [DES77] using the cipher block chaining mode [DESM80]. A 3840 CRC-32 checksum (described in ISO 3309 [ISO3309]) is applied to the 3841 confounder and message sequence (msg-seq) and placed in the cksum field. DES 3842 blocks are 8 bytes. As a result, the data to be encrypted (the concatenation 3843 of confounder, checksum, and message) must be padded to an 8 byte boundary 3844 before encryption. The details of the encryption of this data are identical 3845 to those for the des-cbc-md5 encryption mode. 3847 Note that, since the CRC-32 checksum is not collision-proof, an attacker 3848 could use a probabilistic chosen-plaintext attack to generate a valid 3849 message even if a confounder is used [SG92]. The use of collision-proof 3850 checksums is recommended for environments where such attacks represent a 3851 significant threat. The use of the CRC-32 as the checksum for ticket or 3852 authenticator is no longer mandated as an interoperability requirement for 3853 Kerberos Version 5 Specification 1 (See section 9.1 for specific details). 3855 6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4) 3857 The des-cbc-md4 encryption mode encrypts information under the Data 3858 Encryption Standard [DES77] using the cipher block chaining mode [DESM80]. 3859 An MD4 checksum (described in [MD492]) is applied to the confounder and 3860 message sequence (msg-seq) and placed in the cksum field. DES blocks are 8 3861 bytes. As a result, the data to be encrypted (the concatenation of 3862 confounder, checksum, and message) must be padded to an 8 byte boundary 3863 before encryption. The details of the encryption of this data are identical 3864 to those for the des-cbc-md5 encryption mode. 3866 6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5) 3868 The des-cbc-md5 encryption mode encrypts information under the Data 3869 Encryption Standard [DES77] using the cipher block chaining mode [DESM80]. 3870 An MD5 checksum (described in [MD5-92].) is applied to the confounder and 3871 message sequence (msg-seq) and placed in the cksum field. DES blocks are 8 3872 bytes. As a result, the data to be encrypted (the concatenation of 3873 confounder, checksum, and message) must be padded to an 8 byte boundary 3874 before encryption. 3876 Plaintext and DES ciphtertext are encoded as blocks of 8 octets which are 3877 concatenated to make the 64-bit inputs for the DES algorithms. The first 3878 octet supplies the 8 most significant bits (with the octet's MSbit used as 3879 the DES input block's MSbit, etc.), the second octet the next 8 bits, ..., 3880 and the eighth octet supplies the 8 least significant bits. 3882 the authentication protocol. These extensions provide for authentication of 3884 Neuman, Ts'o, Kohl Expires: 25 December, 3885 1999 3887 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 3888 1999 3890 Encryption under DES using cipher block chaining requires an additional 3891 input in the form of an initialization vector. Unless otherwise specified, 3892 zero should be used as the initialization vector. Kerberos' use of DES 3893 requires an 8 octet confounder. 3895 The DES specifications identify some 'weak' and 'semi-weak' keys; those keys 3896 shall not be used for encrypting messages for use in Kerberos. Additionally, 3897 because of the way that keys are derived for the encryption of checksums, 3898 keys shall not be used that yield 'weak' or 'semi-weak' keys when 3899 eXclusive-ORed with the hexadecimal constant F0F0F0F0F0F0F0F0. 3901 A DES key is 8 octets of data, with keytype one (1). This consists of 56 3902 bits of key, and 8 parity bits (one per octet). The key is encoded as a 3903 series of 8 octets written in MSB-first order. The bits within the key are 3904 also encoded in MSB order. For example, if the encryption key is 3905 (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where 3906 B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the parity 3907 bits, the first octet of the key would be B1,B2,...,B7,P1 (with B1 as the 3908 MSbit). [See the FIPS 81 introduction for reference.] 3910 String to key transformation 3912 To generate a DES key from a text string (password), a "salt" is 3913 concatenated to the text string, and then padded with ASCII nulls to an 8 3914 byte boundary. This "salt" is normally the realm and each component of the 3915 principal's name appended. However, sometimes different salts are used --- 3916 for example, when a realm is renamed, or if a user changes her username, or 3917 for compatibility with Kerberos V4 (whose string-to-key algorithm uses a 3918 null string for the salt). This string is then fan-folded and eXclusive-ORed 3919 with itself to form an 8 byte DES key. Before eXclusive-ORing a block, every 3920 byte is shifted one bit to the left to leave the lowest bit zero. The key is 3921 the "corrected" by correcting the parity on the key, and if the key matches 3922 a 'weak' or 'semi-weak' key as described in the DES specification, it is 3923 eXclusive-ORed with the constant 00000000000000F0. This key is then used to 3924 generate a DES CBC checksum on the initial string (with the salt appended). 3925 The result of the CBC checksum is the "corrected" as described above to form 3926 the result which is return as the key. Pseudocode follows: 3928 name_to_default_salt(realm, name) { 3929 s = realm 3930 for(each component in name) { 3931 s = s + component; 3932 } 3933 return s; 3934 } 3936 key_correction(key) { 3937 fixparity(key); 3938 if (is_weak_key_key(key)) 3939 key = key XOR 0xF0; 3940 return(key); 3941 } 3943 string_to_key(string,salt) { 3945 odd = 1; 3946 s = string + salt; 3947 tempkey = NULL; 3948 the authentication protocol. These extensions provide for authentication of 3950 Neuman, Ts'o, Kohl Expires: 25 December, 3951 1999 3953 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 3954 1999 3956 pad(s); /* with nulls to 8 byte boundary */ 3957 for(8byteblock in s) { 3958 if(odd == 0) { 3959 odd = 1; 3960 reverse(8byteblock) 3961 } 3962 else odd = 0; 3963 left shift every byte in 8byteblock one bit; 3964 tempkey = tempkey XOR 8byteblock; 3965 } 3966 tempkey = key_correction(tempkey); 3967 key = key_correction(DES-CBC-check(s,tempkey)); 3968 return(key); 3969 } 3971 6.3.5. Triple DES with HMAC-SHA1 Kerberos Encryption Type with Key 3972 Derivation [Horowitz] 3974 [*** Note that there are several 3DES varients in use in different Kerberos 3975 implemenations, updates to this section will be sent to the cat list and 3976 krb-protocol list prior to the Oslo IETF, including the key derivation and 3977 non-key derivation varients ***] NOTE: This description currently refers to 3978 documents, the contents of which might be bettered included by value in this 3979 spec. The description below was provided by Marc Horowitz, and the form in 3980 which it will finally appear is yet to be determined. This description is 3981 included in this version of the draft because it does describe the 3982 implemenation ready for use with the MIT implementation. Note also that the 3983 encryption identifier has been left unspecified here because the value from 3984 Marc Horowitz's spec conflicted with some other impmenentations implemented 3985 based on perevious versions of the specification. 3987 This encryption type is based on the Triple DES cryptosystem, the HMAC-SHA1 3988 [Krawczyk96] message authentication algorithm, and key derivation for 3989 Kerberos V5 [HorowitzB96]. 3991 The des3-cbc-hmac-sha1 encryption type has been assigned the value ??. The 3992 hmac-sha1-des3 checksum type has been assigned the value 12. 3994 Encryption Type des3-cbc-hmac-sha1 3996 EncryptedData using this type must be generated as described in 3997 [Horowitz96]. The encryption algorithm is Triple DES in Outer-CBC mode. The 3998 keyed hash algorithm is HMAC-SHA1. Unless otherwise specified, a zero IV 3999 must be used. If the length of the input data is not a multiple of the block 4000 size, zero octets must be used to pad the plaintext to the next eight-octet 4001 boundary. The counfounder must be eight random octets (one block). 4003 Checksum Type hmac-sha1-des3 4005 Checksums using this type must be generated as described in [Horowitz96]. 4006 The keyed hash algorithm is HMAC-SHA1. 4008 Common Requirements 4010 The EncryptionKey value is 24 octets long. The 7 most significant bits of 4011 each octet contain key bits, and the least significant bit is the inverse of 4012 the xor of the key bits. 4014 the authentication protocol. These extensions provide for authentication of 4016 Neuman, Ts'o, Kohl Expires: 25 December, 4017 1999 4019 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 4020 1999 4022 For the purposes of key derivation, the block size is 64 bits, and the key 4023 size is 168 bits. The 168 bits output by key derivation are converted to an 4024 EncryptionKey value as follows. First, the 168 bits are divided into three 4025 groups of 56 bits, which are expanded individually into 64 bits as follows: 4027 1 2 3 4 5 6 7 p 4028 9 10 11 12 13 14 15 p 4029 17 18 19 20 21 22 23 p 4030 25 26 27 28 29 30 31 p 4031 33 34 35 36 37 38 39 p 4032 41 42 43 44 45 46 47 p 4033 49 50 51 52 53 54 55 p 4034 56 48 40 32 24 16 8 p 4036 The "p" bits are parity bits computed over the data bits. The output of the 4037 three expansions are concatenated to form the EncryptionKey value. 4039 When the HMAC-SHA1 of a string is computed, the key is used in the 4040 EncryptedKey form. 4042 Key Derivation 4044 In the Kerberos protocol, cryptographic keys are used in a number of places. 4045 In order to minimize the effect of compromising a key, it is desirable to 4046 use a different key for each of these places. Key derivation [Horowitz96] 4047 can be used to construct different keys for each operation from the keys 4048 transported on the network. For this to be possible, a small change to the 4049 specification is necessary. 4051 This section specifies a profile for the use of key derivation [Horowitz96] 4052 with Kerberos. For each place where a key is used, a ``key usage'' must is 4053 specified for that purpose. The key, key usage, and encryption/checksum type 4054 together describe the transformation from plaintext to ciphertext, or 4055 plaintext to checksum. 4057 Key Usage Values 4059 This is a complete list of places keys are used in the kerberos protocol, 4060 with key usage values and RFC 1510 section numbers: 4062 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the 4063 client key (section 5.4.1) 4064 2. AS-REP Ticket and TGS-REP Ticket (includes tgs session key or 4065 application session key), encrypted with the service key 4066 (section 5.4.2) 4067 3. AS-REP encrypted part (includes tgs session key or application 4068 session key), encrypted with the client key (section 5.4.2) 4069 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs 4070 session key (section 5.4.1) 4071 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs 4072 authenticator subkey (section 5.4.1) 4073 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed 4074 with the tgs session key (sections 5.3.2, 5.4.1) 4075 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs 4076 authenticator subkey), encrypted with the tgs session key 4077 (section 5.3.2) 4078 8. TGS-REP encrypted part (includes application session key), 4079 encrypted with the tgs session key (section 5.4.2) 4080 the authentication protocol. These extensions provide for authentication of 4082 Neuman, Ts'o, Kohl Expires: 25 December, 4083 1999 4085 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 4086 1999 4088 9. TGS-REP encrypted part (includes application session key), 4089 encrypted with the tgs authenticator subkey (section 5.4.2) 4090 10. AP-REQ Authenticator cksum, keyed with the application session 4091 key (section 5.3.2) 4092 11. AP-REQ Authenticator (includes application authenticator 4093 subkey), encrypted with the application session key (section 4094 5.3.2) 4095 12. AP-REP encrypted part (includes application session subkey), 4096 encrypted with the application session key (section 5.5.2) 4097 13. KRB-PRIV encrypted part, encrypted with a key chosen by the 4098 application (section 5.7.1) 4099 14. KRB-CRED encrypted part, encrypted with a key chosen by the 4100 application (section 5.6.1) 4101 15. KRB-SAVE cksum, keyed with a key chosen by the application 4102 (section 5.8.1) 4103 18. KRB-ERROR checksum (e-cksum in section 5.9.1) 4104 19. AD-KDCIssued checksum (ad-checksum in appendix B.1) 4105 20. Checksum for Mandatory Ticket Extensions (appendix B.6) 4106 21. Checksum in Authorization Data in Ticket Extensions (appendix B.7) 4108 Key usage values between 1024 and 2047 (inclusive) are reserved for 4109 application use. Applications should use even values for encryption and odd 4110 values for checksums within this range. 4112 A few of these key usages need a little clarification. A service which 4113 receives an AP-REQ has no way to know if the enclosed Ticket was part of an 4114 AS-REP or TGS-REP. Therefore, key usage 2 must always be used for generating 4115 a Ticket, whether it is in response to an AS- REQ or TGS-REQ. 4117 There might exist other documents which define protocols in terms of the 4118 RFC1510 encryption types or checksum types. Such documents would not know 4119 about key usages. In order that these documents continue to be meaningful 4120 until they are updated, key usages 1024 and 1025 must be used to derive keys 4121 for encryption and checksums, respectively. New protocols defined in terms 4122 of the Kerberos encryption and checksum types should use their own key 4123 usages. Key usages may be registered with IANA to avoid conflicts. Key 4124 usages must be unsigned 32 bit integers. Zero is not permitted. 4126 Defining Cryptosystems Using Key Derivation 4128 Kerberos requires that the ciphertext component of EncryptedData be 4129 tamper-resistant as well as confidential. This implies encryption and 4130 integrity functions, which must each use their own separate keys. So, for 4131 each key usage, two keys must be generated, one for encryption (Ke), and one 4132 for integrity (Ki): 4134 Ke = DK(protocol key, key usage | 0xAA) 4135 Ki = DK(protocol key, key usage | 0x55) 4137 where the protocol key is from the EncryptionKey from the wire protocol, and 4138 the key usage is represented as a 32 bit integer in network byte order. The 4139 ciphertest must be generated from the plaintext as follows: 4141 ciphertext = E(Ke, confounder | plaintext | padding) | 4142 H(Ki, confounder | plaintext | padding) 4144 The confounder and padding are specific to the encryption algorithm E. 4146 the authentication protocol. These extensions provide for authentication of 4148 Neuman, Ts'o, Kohl Expires: 25 December, 4149 1999 4151 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 4152 1999 4154 When generating a checksum only, there is no need for a confounder or 4155 padding. Again, a new key (Kc) must be used. Checksums must be generated 4156 from the plaintext as follows: 4158 Kc = DK(protocol key, key usage | 0x99) 4160 MAC = H(Kc, plaintext) 4162 Note that each enctype is described by an encryption algorithm E and a keyed 4163 hash algorithm H, and each checksum type is described by a keyed hash 4164 algorithm H. HMAC, with an appropriate hash, is recommended for use as H. 4166 Key Derivation from Passwords 4168 The well-known constant for password key derivation must be the byte string 4169 {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values correspond to the 4170 ASCII encoding for the string "kerberos". 4172 6.4. Checksums 4174 The following is the ASN.1 definition used for a checksum: 4176 Checksum ::= SEQUENCE { 4177 cksumtype[0] INTEGER, 4178 checksum[1] OCTET STRING 4179 } 4181 cksumtype 4182 This field indicates the algorithm used to generate the accompanying 4183 checksum. 4184 checksum 4185 This field contains the checksum itself, encoded as an octet string. 4187 Detailed specification of selected checksum types appear later in this 4188 section. Negative values for the checksum type are reserved for local use. 4189 All non-negative values are reserved for officially assigned type fields and 4190 interpretations. 4192 Checksums used by Kerberos can be classified by two properties: whether they 4193 are collision-proof, and whether they are keyed. It is infeasible to find 4194 two plaintexts which generate the same checksum value for a collision-proof 4195 checksum. A key is required to perturb or initialize the algorithm in a 4196 keyed checksum. To prevent message-stream modification by an active 4197 attacker, unkeyed checksums should only be used when the checksum and 4198 message will be subsequently encrypted (e.g. the checksums defined as part 4199 of the encryption algorithms covered earlier in this section). 4201 Collision-proof checksums can be made tamper-proof if the checksum value is 4202 encrypted before inclusion in a message. In such cases, the composition of 4203 the checksum and the encryption algorithm must be considered a separate 4204 checksum algorithm (e.g. RSA-MD5 encrypted using DES is a new checksum 4205 algorithm of type RSA-MD5-DES). For most keyed checksums, as well as for the 4206 encrypted forms of unkeyed collision-proof checksums, Kerberos prepends a 4207 confounder before the checksum is calculated. 4209 the authentication protocol. These extensions provide for authentication of 4211 Neuman, Ts'o, Kohl Expires: 25 December, 4212 1999 4214 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 4215 1999 4217 6.4.1. The CRC-32 Checksum (crc32) 4219 The CRC-32 checksum calculates a checksum based on a cyclic redundancy check 4220 as described in ISO 3309 [ISO3309]. The resulting checksum is four (4) 4221 octets in length. The CRC-32 is neither keyed nor collision-proof. The use 4222 of this checksum is not recommended. An attacker using a probabilistic 4223 chosen-plaintext attack as described in [SG92] might be able to generate an 4224 alternative message that satisfies the checksum. The use of collision-proof 4225 checksums is recommended for environments where such attacks represent a 4226 significant threat. 4228 6.4.2. The RSA MD4 Checksum (rsa-md4) 4230 The RSA-MD4 checksum calculates a checksum using the RSA MD4 algorithm 4231 [MD4-92]. The algorithm takes as input an input message of arbitrary length 4232 and produces as output a 128-bit (16 octet) checksum. RSA-MD4 is believed to 4233 be collision-proof. 4235 6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4-des) 4237 The RSA-MD4-DES checksum calculates a keyed collision-proof checksum by 4238 prepending an 8 octet confounder before the text, applying the RSA MD4 4239 checksum algorithm, and encrypting the confounder and the checksum using DES 4240 in cipher-block-chaining (CBC) mode using a variant of the key, where the 4241 variant is computed by eXclusive-ORing the key with the constant 4242 F0F0F0F0F0F0F0F0[39]. The initialization vector should be zero. The 4243 resulting checksum is 24 octets long (8 octets of which are redundant). This 4244 checksum is tamper-proof and believed to be collision-proof. 4246 The DES specifications identify some weak keys' and 'semi-weak keys'; those 4247 keys shall not be used for generating RSA-MD4 checksums for use in Kerberos. 4249 The format for the checksum is described in the follow- ing diagram: 4251 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4252 | des-cbc(confounder + rsa-md4(confounder+msg),key=var(key),iv=0) | 4253 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4255 The format cannot be described in ASN.1, but for those who prefer an 4256 ASN.1-like notation: 4258 rsa-md4-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { 4259 confounder[0] UNTAGGED OCTET STRING(8), 4260 check[1] UNTAGGED OCTET STRING(16) 4261 } 4263 6.4.4. The RSA MD5 Checksum (rsa-md5) 4265 The RSA-MD5 checksum calculates a checksum using the RSA MD5 algorithm. 4266 [MD5-92]. The algorithm takes as input an input message of arbitrary length 4267 and produces as output a 128-bit (16 octet) checksum. RSA-MD5 is believed to 4268 be collision-proof. 4270 6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5-des) 4272 The RSA-MD5-DES checksum calculates a keyed collision-proof checksum by 4273 prepending an 8 octet confounder before the text, applying the RSA MD5 4274 checksum algorithm, and encrypting the confounder and the checksum using DES 4275 the authentication protocol. These extensions provide for authentication of 4277 Neuman, Ts'o, Kohl Expires: 25 December, 4278 1999 4280 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 4281 1999 4283 in cipher-block-chaining (CBC) mode using a variant of the key, where the 4284 variant is computed by eXclusive-ORing the key with the hexadecimal constant 4285 F0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting 4286 checksum is 24 octets long (8 octets of which are redundant). This checksum 4287 is tamper-proof and believed to be collision-proof. 4289 The DES specifications identify some 'weak keys' and 'semi-weak keys'; those 4290 keys shall not be used for encrypting RSA-MD5 checksums for use in Kerberos. 4292 The format for the checksum is described in the following diagram: 4294 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4295 | des-cbc(confounder + rsa-md5(confounder+msg),key=var(key),iv=0) | 4296 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4298 The format cannot be described in ASN.1, but for those who prefer an 4299 ASN.1-like notation: 4301 rsa-md5-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { 4302 confounder[0] UNTAGGED OCTET STRING(8), 4303 check[1] UNTAGGED OCTET STRING(16) 4304 } 4306 6.4.6. DES cipher-block chained checksum (des-mac) 4308 The DES-MAC checksum is computed by prepending an 8 octet confounder to the 4309 plaintext, performing a DES CBC-mode encryption on the result using the key 4310 and an initialization vector of zero, taking the last block of the 4311 ciphertext, prepending the same confounder and encrypting the pair using DES 4312 in cipher-block-chaining (CBC) mode using a a variant of the key, where the 4313 variant is computed by eXclusive-ORing the key with the hexadecimal constant 4314 F0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting 4315 checksum is 128 bits (16 octets) long, 64 bits of which are redundant. This 4316 checksum is tamper-proof and collision-proof. 4318 The format for the checksum is described in the following diagram: 4320 +--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ 4321 | des-cbc(confounder + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) | 4322 +--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+ 4324 The format cannot be described in ASN.1, but for those who prefer an 4325 ASN.1-like notation: 4327 des-mac-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { 4328 confounder[0] UNTAGGED OCTET STRING(8), 4329 check[1] UNTAGGED OCTET STRING(8) 4330 } 4332 The DES specifications identify some 'weak' and 'semi-weak' keys; those keys 4333 shall not be used for generating DES-MAC checksums for use in Kerberos, nor 4334 shall a key be used whose variant is 'weak' or 'semi-weak'. 4336 6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative (rsa-md4-des-k) 4338 The RSA-MD4-DES-K checksum calculates a keyed collision-proof checksum by 4339 applying the RSA MD4 checksum algorithm and encrypting the results using DES 4340 in cipher-block-chaining (CBC) mode using a DES key as both key and 4341 the authentication protocol. These extensions provide for authentication of 4343 Neuman, Ts'o, Kohl Expires: 25 December, 4344 1999 4346 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 4347 1999 4349 initialization vector. The resulting checksum is 16 octets long. This 4350 checksum is tamper-proof and believed to be collision-proof. Note that this 4351 checksum type is the old method for encoding the RSA-MD4-DES checksum and it 4352 is no longer recommended. 4354 6.4.8. DES cipher-block chained checksum alternative (des-mac-k) 4356 The DES-MAC-K checksum is computed by performing a DES CBC-mode encryption 4357 of the plaintext, and using the last block of the ciphertext as the checksum 4358 value. It is keyed with an encryption key and an initialization vector; any 4359 uses which do not specify an additional initialization vector will use the 4360 key as both key and initialization vector. The resulting checksum is 64 bits 4361 (8 octets) long. This checksum is tamper-proof and collision-proof. Note 4362 that this checksum type is the old method for encoding the DES-MAC checksum 4363 and it is no longer recommended. The DES specifications identify some 'weak 4364 keys' and 'semi-weak keys'; those keys shall not be used for generating 4365 DES-MAC checksums for use in Kerberos. 4367 7. Naming Constraints 4369 7.1. Realm Names 4371 Although realm names are encoded as GeneralStrings and although a realm can 4372 technically select any name it chooses, interoperability across realm 4373 boundaries requires agreement on how realm names are to be assigned, and 4374 what information they imply. 4376 To enforce these conventions, each realm must conform to the conventions 4377 itself, and it must require that any realms with which inter-realm keys are 4378 shared also conform to the conventions and require the same from its 4379 neighbors. 4381 Kerberos realm names are case sensitive. Realm names that differ only in the 4382 case of the characters are not equivalent. There are presently four styles 4383 of realm names: domain, X500, other, and reserved. Examples of each style 4384 follow: 4386 domain: ATHENA.MIT.EDU (example) 4387 X500: C=US/O=OSF (example) 4388 other: NAMETYPE:rest/of.name=without-restrictions (example) 4389 reserved: reserved, but will not conflict with above 4391 Domain names must look like domain names: they consist of components 4392 separated by periods (.) and they contain neither colons (:) nor slashes 4393 (/). Domain names must be converted to upper case when used as realm names. 4395 X.500 names contain an equal (=) and cannot contain a colon (:) before the 4396 equal. The realm names for X.500 names will be string representations of the 4397 names with components separated by slashes. Leading and trailing slashes 4398 will not be included. 4400 Names that fall into the other category must begin with a prefix that 4401 contains no equal (=) or period (.) and the prefix must be followed by a 4402 colon (:) and the rest of the name. All prefixes must be assigned before 4403 they may be used. Presently none are assigned. 4405 the authentication protocol. These extensions provide for authentication of 4407 Neuman, Ts'o, Kohl Expires: 25 December, 4408 1999 4410 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 4411 1999 4413 The reserved category includes strings which do not fall into the first 4414 three categories. All names in this category are reserved. It is unlikely 4415 that names will be assigned to this category unless there is a very strong 4416 argument for not using the 'other' category. 4418 These rules guarantee that there will be no conflicts between the various 4419 name styles. The following additional constraints apply to the assignment of 4420 realm names in the domain and X.500 categories: the name of a realm for the 4421 domain or X.500 formats must either be used by the organization owning (to 4422 whom it was assigned) an Internet domain name or X.500 name, or in the case 4423 that no such names are registered, authority to use a realm name may be 4424 derived from the authority of the parent realm. For example, if there is no 4425 domain name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can 4426 authorize the creation of a realm with that name. 4428 This is acceptable because the organization to which the parent is assigned 4429 is presumably the organization authorized to assign names to its children in 4430 the X.500 and domain name systems as well. If the parent assigns a realm 4431 name without also registering it in the domain name or X.500 hierarchy, it 4432 is the parent's responsibility to make sure that there will not in the 4433 future exists a name identical to the realm name of the child unless it is 4434 assigned to the same entity as the realm name. 4436 7.2. Principal Names 4438 As was the case for realm names, conventions are needed to ensure that all 4439 agree on what information is implied by a principal name. The name-type 4440 field that is part of the principal name indicates the kind of information 4441 implied by the name. The name-type should be treated as a hint. Ignoring the 4442 name type, no two names can be the same (i.e. at least one of the 4443 components, or the realm, must be different). The following name types are 4444 defined: 4446 name-type value meaning 4448 NT-UNKNOWN 0 Name type not known 4449 NT-PRINCIPAL 1 General principal name (e.g. username, or DCE 4450 principal) 4451 NT-SRV-INST 2 Service and other unique instance (krbtgt) 4452 NT-SRV-HST 3 Service with host name as instance (telnet, 4453 rcommands) 4454 NT-SRV-XHST 4 Service with slash-separated host name components 4455 NT-UID 5 Unique ID 4456 NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 1779] 4458 When a name implies no information other than its uniqueness at a particular 4459 time the name type PRINCIPAL should be used. The principal name type should 4460 be used for users, and it might also be used for a unique server. If the 4461 name is a unique machine generated ID that is guaranteed never to be 4462 reassigned then the name type of UID should be used (note that it is 4463 generally a bad idea to reassign names of any type since stale entries might 4464 remain in access control lists). 4466 If the first component of a name identifies a service and the remaining 4467 components identify an instance of the service in a server specified manner, 4468 then the name type of SRV-INST should be used. An example of this name type 4469 is the Kerberos ticket-granting service whose name has a first component of 4470 krbtgt and a second component identifying the realm for which the ticket is 4471 valid. 4473 the authentication protocol. These extensions provide for authentication of 4475 Neuman, Ts'o, Kohl Expires: 25 December, 4476 1999 4478 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 4479 1999 4481 If instance is a single component following the service name and the 4482 instance identifies the host on which the server is running, then the name 4483 type SRV-HST should be used. This type is typically used for Internet 4484 services such as telnet and the Berkeley R commands. If the separate 4485 components of the host name appear as successive components following the 4486 name of the service, then the name type SRV-XHST should be used. This type 4487 might be used to identify servers on hosts with X.500 names where the slash 4488 (/) might otherwise be ambiguous. 4490 A name type of NT-X500-PRINCIPAL should be used when a name from an X.509 4491 certificiate is translated into a Kerberos name. The encoding of the X.509 4492 name as a Kerberos principal shall conform to the encoding rules specified 4493 in RFC 2253. 4495 A name type of UNKNOWN should be used when the form of the name is not 4496 known. When comparing names, a name of type UNKNOWN will match principals 4497 authenticated with names of any type. A principal authenticated with a name 4498 of type UNKNOWN, however, will only match other names of type UNKNOWN. 4500 Names of any type with an initial component of 'krbtgt' are reserved for the 4501 Kerberos ticket granting service. See section 8.2.3 for the form of such 4502 names. 4504 7.2.1. Name of server principals 4506 The principal identifier for a server on a host will generally be composed 4507 of two parts: (1) the realm of the KDC with which the server is registered, 4508 and (2) a two-component name of type NT-SRV-HST if the host name is an 4509 Internet domain name or a multi-component name of type NT-SRV-XHST if the 4510 name of the host is of a form such as X.500 that allows slash (/) 4511 separators. The first component of the two- or multi-component name will 4512 identify the service and the latter components will identify the host. Where 4513 the name of the host is not case sensitive (for example, with Internet 4514 domain names) the name of the host must be lower case. If specified by the 4515 application protocol for services such as telnet and the Berkeley R commands 4516 which run with system privileges, the first component may be the string 4517 'host' instead of a service specific identifier. When a host has an official 4518 name and one or more aliases, the official name of the host must be used 4519 when constructing the name of the server principal. 4521 8. Constants and other defined values 4523 8.1. Host address types 4525 All negative values for the host address type are reserved for local use. 4526 All non-negative values are reserved for officially assigned type fields and 4527 interpretations. 4529 The values of the types for the following addresses are chosen to match the 4530 defined address family constants in the Berkeley Standard Distributions of 4531 Unix. They can be found in with symbolic names AF_xxx (where xxx is an 4532 abbreviation of the address family name). 4534 Internet (IPv4) Addresses 4536 Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in MSB 4537 order. The type of IPv4 addresses is two (2). 4539 the authentication protocol. These extensions provide for authentication of 4541 Neuman, Ts'o, Kohl Expires: 25 December, 4542 1999 4544 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 4545 1999 4547 Internet (IPv6) Addresses [Westerlund] 4549 IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. The 4550 type of IPv6 addresses is twenty-four (24). [RFC1883] [RFC1884]. The 4551 following addresses (see [RFC1884]) MUST not appear in any Kerberos packet: 4553 * the Unspecified Address 4554 * the Loopback Address 4555 * Link-Local addresses 4557 IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2. 4559 CHAOSnet addresses 4561 CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB order. 4562 The type of CHAOSnet addresses is five (5). 4564 ISO addresses 4566 ISO addresses are variable-length. The type of ISO addresses is seven (7). 4568 Xerox Network Services (XNS) addresses 4570 XNS addresses are 48-bit (6-octet) quantities, encoded in MSB order. The 4571 type of XNS addresses is six (6). 4573 AppleTalk Datagram Delivery Protocol (DDP) addresses 4575 AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit network 4576 number. The first octet of the address is the node number; the remaining two 4577 octets encode the network number in MSB order. The type of AppleTalk DDP 4578 addresses is sixteen (16). 4580 DECnet Phase IV addresses 4582 DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. The 4583 type of DECnet Phase IV addresses is twelve (12). 4585 Netbios addresses 4587 Netbios addresses are 16-octet addresses typically composed of 1 to 15 4588 characters, trailing blank (ascii char 20) filled, with a 16th octet of 0x0. 4589 The type of Netbios addresses is 20 (0x14). 4591 8.2. KDC messages 4593 8.2.1. UDP/IP transport 4595 When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request using UDP 4596 IP transport, the client shall send a UDP datagram containing only an 4597 encoding of the request to port 88 (decimal) at the KDC's IP address; the 4598 KDC will respond with a reply datagram containing only an encoding of the 4599 reply message (either a KRB_ERROR or a KRB_KDC_REP) to the sending port at 4600 the sender's IP address. Kerberos servers supporting IP transport must 4601 accept UDP requests on port 88 (decimal). The response to a request made 4602 through UDP/IP transport must also use UDP/IP transport. 4604 the authentication protocol. These extensions provide for authentication of 4606 Neuman, Ts'o, Kohl Expires: 25 December, 4607 1999 4609 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 4610 1999 4612 8.2.2. TCP/IP transport [Westerlund,Danielsson] 4614 Kerberos servers (KDC's) should accept TCP requests on port 88 (decimal) and 4615 clients should support the sending of TCP requests on port 88 (decimal). 4616 When the KRB_KDC_REQ message is sent to the KDC over a TCP stream, a new 4617 connection will be established for each authentication exchange (request and 4618 response). The KRB_KDC_REP or KRB_ERROR message will be returned to the 4619 client on the same TCP stream that was established for the request. The 4620 response to a request made through TCP/IP transport must also use TCP/IP 4621 transport. Implementors should note that some extentions to the Kerberos 4622 protocol will not work if any implementation not supporting the TCP 4623 transport is involved (client or KDC). Implementors are strongly urged to 4624 support the TCP transport on both the client and server and are advised that 4625 the current notation of "should" support will likely change in the future to 4626 must support. The KDC may close the TCP stream after sending a response, but 4627 may leave the stream open if it expects a followup - in which case it may 4628 close the stream at any time if resource constratints or other factors make 4629 it desirable to do so. Care must be taken in managing TCP/IP connections 4630 with the KDC to prevent denial of service attacks based on the number of 4631 TCP/IP connections with the KDC that remain open. If multiple exchanges with 4632 the KDC are needed for certain forms of preauthentication, multiple TCP 4633 connections may be required. A client may close the stream after receiving 4634 response, and should close the stream if it does not expect to send followup 4635 messages. The client must be prepared to have the stream closed by the KDC 4636 at anytime, in which case it must simply connect again when it is ready to 4637 send subsequent messages. 4639 The first four octets of the TCP stream used to transmit the request request 4640 will encode in network byte order the length of the request (KRB_KDC_REQ), 4641 and the length will be followed by the request itself. The response will 4642 similarly be preceeded by a 4 octet encoding in network byte order of the 4643 length of the KRB_KDC_REP or the KRB_ERROR message and will be followed by 4644 the KRB_KDC_REP or the KRB_ERROR response. If the sign bit is set on the 4645 integer represented by the first 4 octets, then the next 4 octets will be 4646 read, extending the length of the field by another 4 octets (less the sign 4647 bit which is reserved for future expansion). 4649 8.2.3. OSI transport 4651 During authentication of an OSI client to an OSI server, the mutual 4652 authentication of an OSI server to an OSI client, the transfer of 4653 credentials from an OSI client to an OSI server, or during exchange of 4654 private or integrity checked messages, Kerberos protocol messages may be 4655 treated as opaque objects and the type of the authentication mechanism will 4656 be: 4658 OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), 4659 security(5),kerberosv5(2)} 4661 Depending on the situation, the opaque object will be an authentication 4662 header (KRB_AP_REQ), an authentication reply (KRB_AP_REP), a safe message 4663 (KRB_SAFE), a private message (KRB_PRIV), or a credentials message 4664 (KRB_CRED). The opaque data contains an application code as specified in the 4665 ASN.1 description for each message. The application code may be used by 4666 Kerberos to determine the message type. 4668 the authentication protocol. These extensions provide for authentication of 4670 Neuman, Ts'o, Kohl Expires: 25 December, 4671 1999 4673 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 4674 1999 4676 8.2.3. Name of the TGS 4678 The principal identifier of the ticket-granting service shall be composed of 4679 three parts: (1) the realm of the KDC issuing the TGS ticket (2) a two-part 4680 name of type NT-SRV-INST, with the first part "krbtgt" and the second part 4681 the name of the realm which will accept the ticket-granting ticket. For 4682 example, a ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be 4683 used to get tickets from the ATHENA.MIT.EDU KDC has a principal identifier 4684 of "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A 4685 ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be used to get 4686 tickets from the MIT.EDU realm has a principal identifier of 4687 "ATHENA.MIT.EDU" (realm), ("krbtgt", "MIT.EDU") (name). 4689 8.3. Protocol constants and associated values 4691 The following tables list constants used in the protocol and defines their 4692 meanings. Ranges are specified in the "specification" section that limit the 4693 values of constants for which values are defined here. This allows 4694 implementations to make assumptions about the maximum values that will be 4695 received for these constants. Implementation receiving values outside the 4696 range specified in the "specification" section may reject the request, but 4697 they must recover cleanly. 4699 Encryption type etype value block size minimum pad size confounder 4700 size 4701 NULL 0 1 0 0 4702 des-cbc-crc 1 8 4 8 4703 des-cbc-md4 2 8 0 8 4704 des-cbc-md5 3 8 0 8 4705 4 4706 des3-cbc-md5 5 8 0 8 4707 6 4708 des3-cbc-sha1 7 8 0 8 4709 sign-dsa-generate 8 4710 (old-pkinit-will-remove) 4711 dsaWithSHA1-CmsOID 9 (pkinit) 4712 md5WithRSAEncryption-CmsOID 10 (pkinit) 4713 sha1WithRSAEncryption-CmsOID 11 (pkinit) 4714 rc2CBC-EnvOID 12 (pkinit) 4715 rsaEncryption-EnvOID 13 (pkinit from PKCS#1 4716 v1.5) 4717 rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 4718 v2.0) 4719 des-ede3-cbc-Env-OID 15 (pkinit) 4720 des3kd-cbc-sha1 ?? 8 0 8 4721 ENCTYPE_PK_CROSS 48 (reserved for pkcross) 4722 0x8003 4724 Checksum type sumtype value checksum size 4725 CRC32 1 4 4726 rsa-md4 2 16 4727 rsa-md4-des 3 24 4728 des-mac 4 16 4729 des-mac-k 5 8 4730 rsa-md4-des-k 6 16 4731 rsa-md5 7 16 4732 rsa-md5-des 8 24 4733 rsa-md5-des3 9 24 4734 hmac-sha1-des3 12 20 (I had this as 10, is it 4735 12) 4737 the authentication protocol. These extensions provide for authentication of 4739 Neuman, Ts'o, Kohl Expires: 25 December, 4740 1999 4742 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 4743 1999 4745 padata type padata-type value 4747 PA-TGS-REQ 1 4748 PA-ENC-TIMESTAMP 2 4749 PA-PW-SALT 3 4750 4 4751 PA-ENC-UNIX-TIME 5 4752 PA-SANDIA-SECUREID 6 4753 PA-SESAME 7 4754 PA-OSF-DCE 8 4755 PA-CYBERSAFE-SECUREID 9 4756 PA-AFS3-SALT 10 4757 PA-ETYPE-INFO 11 4758 SAM-CHALLENGE 12 (sam/otp) 4759 SAM-RESPONSE 13 (sam/otp) 4760 PA-PK-AS-REQ 14 (pkinit) 4761 PA-PK-AS-REP 15 (pkinit) 4762 PA-PK-AS-SIGN 16 (***remove on 7/14***) 4763 PA-PK-KEY-REQ 17 (***remove on 7/14***) 4764 PA-PK-KEY-REP 18 (***remove on 7/14***) 4765 PA-USE-SPECIFIED-KVNO 20 4766 SAM-REDIRECT 21 (sam/otp) 4767 PA-GET-FROM-TYPED-DATA 22 4769 data-type value form of typed-data 4771 1-21 4772 TD-PADATA 22 4773 TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS 4774 TD-KRB-PRINCIPAL 102 4775 TD-KRB-REALM 103 4776 TD-TRUSTED-CERTIFIERS 104 4777 TD-CERTIFICATE-INDEX 105 4779 authorization data type ad-type value 4780 AD-IF-RELEVANT 1 4781 AD-INTENDED-FOR-SERVER 2 4782 AD-INTENDED-FOR-APPLICATION-CLASS 3 4783 AD-KDC-ISSUED 4 4784 AD-OR 5 4785 AD-MANDATORY-TICKET-EXTENSIONS 6 4786 AD-IN-TICKET-EXTENSIONS 7 4787 reserved values 8-63 4788 OSF-DCE 64 4789 SESAME 65 4791 Ticket Extension Types 4793 TE-TYPE-NULL 0 Null ticket extension 4794 TE-TYPE-EXTERNAL-ADATA 1 Integrity protected authorization data 4795 2 TE-TYPE-PKCROSS-KDC (I have reservations) 4796 TE-TYPE-PKCROSS-CLIENT 3 PKCROSS cross realm key ticket 4797 TE-TYPE-CYBERSAFE-EXT 4 Assigned to CyberSafe Corp 4798 5 TE-TYPE-DEST-HOST (I have reservations) 4800 the authentication protocol. These extensions provide for authentication of 4802 Neuman, Ts'o, Kohl Expires: 25 December, 4803 1999 4805 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 4806 1999 4808 alternate authentication type method-type value 4809 reserved values 0-63 4810 ATT-CHALLENGE-RESPONSE 64 4812 transited encoding type tr-type value 4813 DOMAIN-X500-COMPRESS 1 4814 reserved values all others 4816 Label Value Meaning or MIT code 4818 pvno 5 current Kerberos protocol version number 4820 message types 4822 KRB_AS_REQ 10 Request for initial authentication 4823 KRB_AS_REP 11 Response to KRB_AS_REQ request 4824 KRB_TGS_REQ 12 Request for authentication based on TGT 4825 KRB_TGS_REP 13 Response to KRB_TGS_REQ request 4826 KRB_AP_REQ 14 application request to server 4827 KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL 4828 KRB_SAFE 20 Safe (checksummed) application message 4829 KRB_PRIV 21 Private (encrypted) application message 4830 KRB_CRED 22 Private (encrypted) message to forward 4831 credentials 4832 KRB_ERROR 30 Error response 4834 name types 4836 KRB_NT_UNKNOWN 0 Name type not known 4837 KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for 4838 users 4839 KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) 4840 KRB_NT_SRV_HST 3 Service with host name as instance (telnet, 4841 rcommands) 4842 KRB_NT_SRV_XHST 4 Service with host as remaining components 4843 KRB_NT_UID 5 Unique ID 4844 KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] 4846 error codes 4848 KDC_ERR_NONE 0 No error 4849 KDC_ERR_NAME_EXP 1 Client's entry in database has expired 4850 KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired 4851 KDC_ERR_BAD_PVNO 3 Requested protocol version # not 4852 supported 4853 KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key 4854 KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key 4855 KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database 4856 KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database 4857 KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database 4858 KDC_ERR_NULL_KEY 9 The client or server has a null key 4859 KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating 4860 KDC_ERR_NEVER_VALID 11 Requested start time is later than end 4861 time 4862 KDC_ERR_POLICY 12 KDC policy rejects request 4863 KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option 4864 KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type 4865 KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type 4866 KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type 4867 KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type 4868 KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked 4869 KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked 4870 KDC_ERR_TGT_REVOKED 20 TGT has been revoked 4871 the authentication protocol. These extensions provide for authentication of 4873 Neuman, Ts'o, Kohl Expires: 25 December, 4874 1999 4876 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 4877 1999 4879 KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later 4880 KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later 4881 KDC_ERR_KEY_EXPIRED 23 Password has expired - change password 4882 KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was 4883 invalid 4884 KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired 4885 [40] 4886 KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match 4887 KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user 4888 only 4889 KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path 4890 KDC_ERR_SVC_UNAVAILABLE 29 A service is not available 4891 KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field 4892 failed 4893 KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired 4894 KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid 4895 KRB_AP_ERR_REPEAT 34 Request is a replay 4896 KRB_AP_ERR_NOT_US 35 The ticket isn't for us 4897 KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match 4898 KRB_AP_ERR_SKEW 37 Clock skew too great 4899 KRB_AP_ERR_BADADDR 38 Incorrect net address 4900 KRB_AP_ERR_BADVERSION 39 Protocol version mismatch 4901 KRB_AP_ERR_MSG_TYPE 40 Invalid msg type 4902 KRB_AP_ERR_MODIFIED 41 Message stream modified 4903 KRB_AP_ERR_BADORDER 42 Message out of order 4904 KRB_AP_ERR_BADKEYVER 44 Specified version of key is not 4905 available 4906 KRB_AP_ERR_NOKEY 45 Service key not available 4907 KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed 4908 KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction 4909 KRB_AP_ERR_METHOD 48 Alternative authentication method 4910 required 4911 KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message 4912 KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in 4913 message 4914 KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path 4915 KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP, retry with TCP 4916 KRB_ERR_GENERIC 60 Generic error (description in e-text) 4917 KRB_ERR_FIELD_TOOLONG 61 Field is too long for this 4918 implementation 4919 KDC_ERROR_CLIENT_NOT_TRUSTED 62 (pkinit) 4920 KDC_ERROR_KDC_NOT_TRUSTED 63 (pkinit) 4921 KDC_ERROR_INVALID_SIG 64 (pkinit) 4922 KDC_ERR_KEY_TOO_WEAK 65 (pkinit) 4923 KDC_ERR_CERTIFICATE_MISMATCH 66 (pkinit) 4924 KRB_AP_ERR_NO_TGT 67 (user-to-user) 4925 KDC_ERR_WRONG_REALM 68 (user-to-user) 4926 KRB_AP_ERR_USER_TO_USER_REQUIRED 69 (user-to-user) 4927 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 (pkinit) 4928 KDC_ERR_INVALID_CERTIFICATE 71 (pkinit) 4929 KDC_ERR_REVOKED_CERTIFICATE 72 (pkinit) 4930 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 (pkinit) 4931 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 (pkinit) 4932 KDC_ERR_CLIENT_NAME_MISMATCH 75 (pkinit) 4933 KDC_ERR_KDC_NAME_MISMATCH 76 (pkinit) 4935 9. Interoperability requirements 4937 Version 5 of the Kerberos protocol supports a myriad of options. Among these 4938 are multiple encryption and checksum types, alternative encoding schemes for 4939 the transited field, optional mechanisms for pre-authentication, the 4940 handling of tickets with no addresses, options for mutual authentication, 4941 user to user authentication, support for proxies, forwarding, postdating, 4942 and renewing tickets, the format of realm names, and the handling of 4943 authorization data. 4945 the authentication protocol. These extensions provide for authentication of 4947 Neuman, Ts'o, Kohl Expires: 25 December, 4948 1999 4950 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 4951 1999 4953 In order to ensure the interoperability of realms, it is necessary to define 4954 a minimal configuration which must be supported by all implementations. This 4955 minimal configuration is subject to change as technology does. For example, 4956 if at some later date it is discovered that one of the required encryption 4957 or checksum algorithms is not secure, it will be replaced. 4959 9.1. Specification 2 4961 This section defines the second specification of these options. 4962 Implementations which are configured in this way can be said to support 4963 Kerberos Version 5 Specification 2 (5.1). Specification 1 (depricated) may 4964 be found in RFC1510. 4966 Transport 4968 TCP/IP and UDP/IP transport must be supported by KDCs claiming conformance 4969 to specification 2. Kerberos clients claiming conformance to specification 2 4970 must support UDP/IP transport for messages with the KDC and should support 4971 TCP/IP transport. 4973 Encryption and checksum methods 4975 The following encryption and checksum mechanisms must be supported. 4976 Implementations may support other mechanisms as well, but the additional 4977 mechanisms may only be used when communicating with principals known to also 4978 support them: This list is to be determined. [***This section will change, 4979 and alternatives will be sent to the cat and krb-protocol list prior to the 4980 Oslo IETF - change will be made 7/14/99 ***] 4982 Encryption: DES-CBC-MD5 4983 Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5 4985 Realm Names 4987 All implementations must understand hierarchical realms in both the Internet 4988 Domain and the X.500 style. When a ticket granting ticket for an unknown 4989 realm is requested, the KDC must be able to determine the names of the 4990 intermediate realms between the KDCs realm and the requested realm. 4992 Transited field encoding 4994 DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported. 4995 Alternative encodings may be supported, but they may be used only when that 4996 encoding is supported by ALL intermediate realms. 4998 Pre-authentication methods 5000 The TGS-REQ method must be supported. The TGS-REQ method is not used on the 5001 initial request. The PA-ENC-TIMESTAMP method must be supported by clients 5002 but whether it is enabled by default may be determined on a realm by realm 5003 basis. If not used in the initial request and the error 5004 KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an 5005 acceptable method, the client should retry the initial request using the 5006 PA-ENC-TIMESTAMP preauthentication method. Servers need not support the 5007 PA-ENC-TIMESTAMP method, but if not supported the server should ignore the 5008 presence of PA-ENC-TIMESTAMP pre-authentication in a request. 5010 the authentication protocol. These extensions provide for authentication of 5012 Neuman, Ts'o, Kohl Expires: 25 December, 5013 1999 5015 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 5016 1999 5018 Mutual authentication 5020 Mutual authentication (via the KRB_AP_REP message) must be supported. 5022 Ticket addresses and flags 5024 All KDC's must pass on tickets that carry no addresses (i.e. if a TGT 5025 contains no addresses, the KDC will return derivative tickets), but each 5026 realm may set its own policy for issuing such tickets, and each application 5027 server will set its own policy with respect to accepting them. 5029 Proxies and forwarded tickets must be supported. Individual realms and 5030 application servers can set their own policy on when such tickets will be 5031 accepted. 5033 All implementations must recognize renewable and postdated tickets, but need 5034 not actually implement them. If these options are not supported, the 5035 starttime and endtime in the ticket shall specify a ticket's entire useful 5036 life. When a postdated ticket is decoded by a server, all implementations 5037 shall make the presence of the postdated flag visible to the calling server. 5039 User-to-user authentication 5041 Support for user to user authentication (via the ENC-TKT-IN-SKEY KDC option) 5042 must be provided by implementations, but individual realms may decide as a 5043 matter of policy to reject such requests on a per-principal or realm-wide 5044 basis. 5046 Authorization data 5048 Implementations must pass all authorization data subfields from 5049 ticket-granting tickets to any derivative tickets unless directed to 5050 suppress a subfield as part of the definition of that registered subfield 5051 type (it is never incorrect to pass on a subfield, and no registered 5052 subfield types presently specify suppression at the KDC). 5054 Implementations must make the contents of any authorization data subfields 5055 available to the server when a ticket is used. Implementations are not 5056 required to allow clients to specify the contents of the authorization data 5057 fields. 5059 Constant ranges 5061 All protocol constants are constrained to 32 bit (signed) values unless 5062 further constrained by the protocol definition. This limit is provided to 5063 allow implementations to make assumptions about the maximum values that will 5064 be received for these constants. Implementation receiving values outside 5065 this range may reject the request, but they must recover cleanly. 5067 9.2. Recommended KDC values 5069 Following is a list of recommended values for a KDC implementation, based on 5070 the list of suggested configuration constants (see section 4.4). 5072 minimum lifetime 5 minutes 5073 maximum renewable lifetime 1 week 5074 maximum ticket lifetime 1 day 5075 empty addresses only when suitable restrictions appear 5076 in authorization data 5077 proxiable, etc. Allowed. 5079 the authentication protocol. These extensions provide for authentication of 5081 Neuman, Ts'o, Kohl Expires: 25 December, 5082 1999 5084 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 5085 1999 5087 10. REFERENCES 5089 [NT94] B. Clifford Neuman and Theodore Y. Ts'o, "An Authenti- 5090 cation Service for Computer Networks," IEEE Communica- 5091 tions Magazine, Vol. 32(9), pp. 33-38 (September 1994). 5093 [MNSS87] S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. 5094 Saltzer, Section E.2.1: Kerberos Authentication and 5095 Authorization System, M.I.T. Project Athena, Cambridge, 5096 Massachusetts (December 21, 1987). 5098 [SNS88] J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Ker- 5099 beros: An Authentication Service for Open Network Sys- 5100 tems," pp. 191-202 in Usenix Conference Proceedings, 5101 Dallas, Texas (February, 1988). 5103 [NS78] Roger M. Needham and Michael D. Schroeder, "Using 5104 Encryption for Authentication in Large Networks of Com- 5105 puters," Communications of the ACM, Vol. 21(12), 5106 pp. 993-999 (December, 1978). 5108 [DS81] Dorothy E. Denning and Giovanni Maria Sacco, "Time- 5109 stamps in Key Distribution Protocols," Communications 5110 of the ACM, Vol. 24(8), pp. 533-536 (August 1981). 5112 [KNT92] John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, 5113 "The Evolution of the Kerberos Authentication Service," 5114 in an IEEE Computer Society Text soon to be published 5115 (June 1992). 5117 [Neu93] B. Clifford Neuman, "Proxy-Based Authorization and 5118 Accounting for Distributed Systems," in Proceedings of 5119 the 13th International Conference on Distributed Com- 5120 puting Systems, Pittsburgh, PA (May, 1993). 5122 [DS90] Don Davis and Ralph Swick, "Workstation Services and 5123 Kerberos Authentication at Project Athena," Technical 5124 Memorandum TM-424, MIT Laboratory for Computer Science 5125 (February 1990). 5127 [LGDSR87] P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E. Som- 5128 merfeld, and K. Raeburn, Section E.1: Service Manage- 5129 ment System, M.I.T. Project Athena, Cambridge, Mas- 5130 sachusetts (1987). 5132 [X509-88] CCITT, Recommendation X.509: The Directory Authentica- 5133 tion Framework, December 1988. 5135 [Pat92]. J. Pato, Using Pre-Authentication to Avoid Password 5136 Guessing Attacks, Open Software Foundation DCE Request 5137 for Comments 26 (December 1992). 5139 [DES77] National Bureau of Standards, U.S. Department of Com- 5140 merce, "Data Encryption Standard," Federal Information 5141 Processing Standards Publication 46, Washington, DC 5142 (1977). 5144 the authentication protocol. These extensions provide for authentication of 5146 Neuman, Ts'o, Kohl Expires: 25 December, 5147 1999 5149 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 5150 1999 5152 [DESM80] National Bureau of Standards, U.S. Department of Com- 5153 merce, "DES Modes of Operation," Federal Information 5154 Processing Standards Publication 81, Springfield, VA 5155 (December 1980). 5157 [SG92] Stuart G. Stubblebine and Virgil D. Gligor, "On Message 5158 Integrity in Cryptographic Protocols," in Proceedings 5159 of the IEEE Symposium on Research in Security and 5160 Privacy, Oakland, California (May 1992). 5162 [IS3309] International Organization for Standardization, "ISO 5163 Information Processing Systems - Data Communication - 5164 High-Level Data Link Control Procedure - Frame Struc- 5165 ture," IS 3309 (October 1984). 3rd Edition. 5167 [MD4-92] R. Rivest, "The MD4 Message Digest Algorithm," RFC 5168 1320, MIT Laboratory for Computer Science (April 5169 1992). 5171 [MD5-92] R. Rivest, "The MD5 Message Digest Algorithm," RFC 5172 1321, MIT Laboratory for Computer Science (April 5173 1992). 5175 [KBC96] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed- 5176 Hashing for Message Authentication," Working Draft 5177 draft-ietf-ipsec-hmac-md5-01.txt, (August 1996). 5179 [Horowitz96] Horowitz, M., "Key Derivation for Authentication, 5180 Integrity, and Privacy", draft-horowitz-key-derivation-02.txt, 5181 August 1998. 5183 [HorowitzB96] Horowitz, M., "Key Derivation for Kerberos V5", draft- 5184 horowitz-kerb-key-derivation-01.txt, September 1998. 5186 [Krawczyk96] Krawczyk, H., Bellare, and M., Canetti, R., "HMAC: 5187 Keyed-Hashing for Message Authentication", draft-ietf-ipsec-hmac- 5188 md5-01.txt, August, 1996. 5190 the authentication protocol. These extensions provide for authentication of 5192 Neuman, Ts'o, Kohl Expires: 25 December, 5193 1999 5195 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 5196 1999 5198 A. Pseudo-code for protocol processing 5200 This appendix provides pseudo-code describing how the messages are to be 5201 constructed and interpreted by clients and servers. 5203 A.1. KRB_AS_REQ generation 5205 request.pvno := protocol version; /* pvno = 5 */ 5206 request.msg-type := message type; /* type = KRB_AS_REQ */ 5208 if(pa_enc_timestamp_required) then 5209 request.padata.padata-type = PA-ENC-TIMESTAMP; 5210 get system_time; 5211 padata-body.patimestamp,pausec = system_time; 5212 encrypt padata-body into request.padata.padata-value 5213 using client.key; /* derived from password */ 5214 endif 5216 body.kdc-options := users's preferences; 5217 body.cname := user's name; 5218 body.realm := user's realm; 5219 body.sname := service's name; /* usually "krbtgt", "localrealm" */ 5220 if (body.kdc-options.POSTDATED is set) then 5221 body.from := requested starting time; 5222 else 5223 omit body.from; 5224 endif 5225 body.till := requested end time; 5226 if (body.kdc-options.RENEWABLE is set) then 5227 body.rtime := requested final renewal time; 5228 endif 5229 body.nonce := random_nonce(); 5230 body.etype := requested etypes; 5231 if (user supplied addresses) then 5232 body.addresses := user's addresses; 5233 else 5234 omit body.addresses; 5235 endif 5236 omit body.enc-authorization-data; 5237 request.req-body := body; 5239 kerberos := lookup(name of local kerberos server (or servers)); 5240 send(packet,kerberos); 5242 wait(for response); 5243 if (timed_out) then 5244 retry or use alternate server; 5245 endif 5247 the authentication protocol. These extensions provide for authentication of 5249 Neuman, Ts'o, Kohl Expires: 25 December, 5250 1999 5252 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 5253 1999 5255 A.2. KRB_AS_REQ verification and KRB_AS_REP generation 5257 decode message into req; 5259 client := lookup(req.cname,req.realm); 5260 server := lookup(req.sname,req.realm); 5262 get system_time; 5263 kdc_time := system_time.seconds; 5265 if (!client) then 5266 /* no client in Database */ 5267 error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN); 5268 endif 5269 if (!server) then 5270 /* no server in Database */ 5271 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); 5272 endif 5274 if(client.pa_enc_timestamp_required and 5275 pa_enc_timestamp not present) then 5276 error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)); 5277 endif 5279 if(pa_enc_timestamp present) then 5280 decrypt req.padata-value into decrypted_enc_timestamp 5281 using client.key; 5282 using auth_hdr.authenticator.subkey; 5283 if (decrypt_error()) then 5284 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5285 if(decrypted_enc_timestamp is not within allowable skew) 5286 then 5287 error_out(KDC_ERR_PREAUTH_FAILED); 5288 endif 5289 if(decrypted_enc_timestamp and usec is replay) 5290 error_out(KDC_ERR_PREAUTH_FAILED); 5291 endif 5292 add decrypted_enc_timestamp and usec to replay cache; 5293 endif 5295 use_etype := first supported etype in req.etypes; 5297 if (no support for req.etypes) then 5298 error_out(KDC_ERR_ETYPE_NOSUPP); 5299 endif 5301 new_tkt.vno := ticket version; /* = 5 */ 5302 new_tkt.sname := req.sname; 5303 new_tkt.srealm := req.srealm; 5304 reset all flags in new_tkt.flags; 5306 /* It should be noted that local policy may affect the */ 5307 /* processing of any of these flags. For example, some */ 5308 /* realms may refuse to issue renewable tickets */ 5310 if (req.kdc-options.FORWARDABLE is set) then 5311 set new_tkt.flags.FORWARDABLE; 5312 endif 5313 if (req.kdc-options.PROXIABLE is set) then 5314 the authentication protocol. These extensions provide for authentication of 5316 Neuman, Ts'o, Kohl Expires: 25 December, 5317 1999 5319 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 5320 1999 5322 set new_tkt.flags.PROXIABLE; 5323 endif 5325 if (req.kdc-options.ALLOW-POSTDATE is set) then 5326 set new_tkt.flags.MAY-POSTDATE; 5327 endif 5328 if ((req.kdc-options.RENEW is set) or 5329 (req.kdc-options.VALIDATE is set) or 5330 (req.kdc-options.PROXY is set) or 5331 (req.kdc-options.FORWARDED is set) or 5332 (req.kdc-options.ENC-TKT-IN-SKEY is set)) then 5333 error_out(KDC_ERR_BADOPTION); 5334 endif 5336 new_tkt.session := random_session_key(); 5337 new_tkt.cname := req.cname; 5338 new_tkt.crealm := req.crealm; 5339 new_tkt.transited := empty_transited_field(); 5341 new_tkt.authtime := kdc_time; 5343 if (req.kdc-options.POSTDATED is set) then 5344 if (against_postdate_policy(req.from)) then 5345 error_out(KDC_ERR_POLICY); 5346 endif 5347 set new_tkt.flags.POSTDATED; 5348 set new_tkt.flags.INVALID; 5349 new_tkt.starttime := req.from; 5350 else 5351 omit new_tkt.starttime; /* treated as authtime when omitted */ 5352 endif 5353 if (req.till = 0) then 5354 till := infinity; 5355 else 5356 till := req.till; 5357 endif 5359 new_tkt.endtime := min(till, 5360 new_tkt.starttime+client.max_life, 5361 new_tkt.starttime+server.max_life, 5362 new_tkt.starttime+max_life_for_realm); 5364 if ((req.kdc-options.RENEWABLE-OK is set) and 5365 (new_tkt.endtime < req.till)) then 5366 /* we set the RENEWABLE option for later processing */ 5367 set req.kdc-options.RENEWABLE; 5368 req.rtime := req.till; 5369 endif 5371 if (req.rtime = 0) then 5372 rtime := infinity; 5373 else 5374 rtime := req.rtime; 5375 endif 5377 if (req.kdc-options.RENEWABLE is set) then 5378 set new_tkt.flags.RENEWABLE; 5379 new_tkt.renew-till := min(rtime, 5380 the authentication protocol. These extensions provide for authentication of 5382 Neuman, Ts'o, Kohl Expires: 25 December, 5383 1999 5385 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 5386 1999 5388 new_tkt.starttime+client.max_rlife, 5389 new_tkt.starttime+server.max_rlife, 5390 new_tkt.starttime+max_rlife_for_realm); 5391 else 5392 omit new_tkt.renew-till; /* only present if RENEWABLE */ 5393 endif 5395 if (req.addresses) then 5396 new_tkt.caddr := req.addresses; 5397 else 5398 omit new_tkt.caddr; 5399 endif 5401 new_tkt.authorization_data := empty_authorization_data(); 5403 encode to-be-encrypted part of ticket into OCTET STRING; 5404 new_tkt.enc-part := encrypt OCTET STRING 5405 using etype_for_key(server.key), server.key, server.p_kvno; 5407 /* Start processing the response */ 5409 resp.pvno := 5; 5410 resp.msg-type := KRB_AS_REP; 5411 resp.cname := req.cname; 5412 resp.crealm := req.realm; 5413 resp.ticket := new_tkt; 5415 resp.key := new_tkt.session; 5416 resp.last-req := fetch_last_request_info(client); 5417 resp.nonce := req.nonce; 5418 resp.key-expiration := client.expiration; 5419 resp.flags := new_tkt.flags; 5421 resp.authtime := new_tkt.authtime; 5422 resp.starttime := new_tkt.starttime; 5423 resp.endtime := new_tkt.endtime; 5425 if (new_tkt.flags.RENEWABLE) then 5426 resp.renew-till := new_tkt.renew-till; 5427 endif 5429 resp.realm := new_tkt.realm; 5430 resp.sname := new_tkt.sname; 5432 resp.caddr := new_tkt.caddr; 5434 encode body of reply into OCTET STRING; 5436 resp.enc-part := encrypt OCTET STRING 5437 using use_etype, client.key, client.p_kvno; 5438 send(resp); 5440 the authentication protocol. These extensions provide for authentication of 5442 Neuman, Ts'o, Kohl Expires: 25 December, 5443 1999 5445 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 5446 1999 5448 A.3. KRB_AS_REP verification 5450 decode response into resp; 5452 if (resp.msg-type = KRB_ERROR) then 5453 if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) then 5454 set pa_enc_timestamp_required; 5455 goto KRB_AS_REQ; 5456 endif 5457 process_error(resp); 5458 return; 5459 endif 5461 /* On error, discard the response, and zero the session key */ 5462 /* from the response immediately */ 5464 key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype, 5465 resp.padata); 5466 unencrypted part of resp := decode of decrypt of resp.enc-part 5467 using resp.enc-part.etype and key; 5468 zero(key); 5470 if (common_as_rep_tgs_rep_checks fail) then 5471 destroy resp.key; 5472 return error; 5473 endif 5475 if near(resp.princ_exp) then 5476 print(warning message); 5477 endif 5478 save_for_later(ticket,session,client,server,times,flags); 5480 A.4. KRB_AS_REP and KRB_TGS_REP common checks 5482 if (decryption_error() or 5483 (req.cname != resp.cname) or 5484 (req.realm != resp.crealm) or 5485 (req.sname != resp.sname) or 5486 (req.realm != resp.realm) or 5487 (req.nonce != resp.nonce) or 5488 (req.addresses != resp.caddr)) then 5489 destroy resp.key; 5490 return KRB_AP_ERR_MODIFIED; 5491 endif 5493 /* make sure no flags are set that shouldn't be, and that all that 5494 */ 5495 /* should be are set 5496 */ 5497 if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then 5498 destroy resp.key; 5499 return KRB_AP_ERR_MODIFIED; 5500 endif 5502 if ((req.from = 0) and 5503 (resp.starttime is not within allowable skew)) then 5504 destroy resp.key; 5505 return KRB_AP_ERR_SKEW; 5506 endif 5507 if ((req.from != 0) and (req.from != resp.starttime)) then 5508 the authentication protocol. These extensions provide for authentication of 5510 Neuman, Ts'o, Kohl Expires: 25 December, 5511 1999 5513 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 5514 1999 5516 destroy resp.key; 5517 return KRB_AP_ERR_MODIFIED; 5518 endif 5519 if ((req.till != 0) and (resp.endtime > req.till)) then 5520 destroy resp.key; 5521 return KRB_AP_ERR_MODIFIED; 5522 endif 5524 if ((req.kdc-options.RENEWABLE is set) and 5525 (req.rtime != 0) and (resp.renew-till > req.rtime)) then 5526 destroy resp.key; 5527 return KRB_AP_ERR_MODIFIED; 5528 endif 5529 if ((req.kdc-options.RENEWABLE-OK is set) and 5530 (resp.flags.RENEWABLE) and 5531 (req.till != 0) and 5532 (resp.renew-till > req.till)) then 5533 destroy resp.key; 5534 return KRB_AP_ERR_MODIFIED; 5535 endif 5537 A.5. KRB_TGS_REQ generation 5539 /* Note that make_application_request might have to recursivly 5540 */ 5541 /* call this routine to get the appropriate ticket-granting ticket 5542 */ 5544 request.pvno := protocol version; /* pvno = 5 */ 5545 request.msg-type := message type; /* type = KRB_TGS_REQ */ 5547 body.kdc-options := users's preferences; 5548 /* If the TGT is not for the realm of the end-server */ 5549 /* then the sname will be for a TGT for the end-realm */ 5550 /* and the realm of the requested ticket (body.realm) */ 5551 /* will be that of the TGS to which the TGT we are */ 5552 /* sending applies */ 5553 body.sname := service's name; 5554 body.realm := service's realm; 5556 if (body.kdc-options.POSTDATED is set) then 5557 body.from := requested starting time; 5558 else 5559 omit body.from; 5560 endif 5561 body.till := requested end time; 5562 if (body.kdc-options.RENEWABLE is set) then 5563 body.rtime := requested final renewal time; 5564 endif 5565 body.nonce := random_nonce(); 5566 body.etype := requested etypes; 5567 if (user supplied addresses) then 5568 body.addresses := user's addresses; 5569 else 5570 omit body.addresses; 5571 endif 5573 body.enc-authorization-data := user-supplied data; 5574 if (body.kdc-options.ENC-TKT-IN-SKEY) then 5575 body.additional-tickets_ticket := second TGT; 5576 the authentication protocol. These extensions provide for authentication of 5578 Neuman, Ts'o, Kohl Expires: 25 December, 5579 1999 5581 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 5582 1999 5584 endif 5586 request.req-body := body; 5587 check := generate_checksum (req.body,checksumtype); 5589 request.padata[0].padata-type := PA-TGS-REQ; 5590 request.padata[0].padata-value := create a KRB_AP_REQ using 5591 the TGT and checksum 5593 /* add in any other padata as required/supplied */ 5595 kerberos := lookup(name of local kerberose server (or servers)); 5596 send(packet,kerberos); 5598 wait(for response); 5599 if (timed_out) then 5600 retry or use alternate server; 5601 endif 5603 A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation 5605 /* note that reading the application request requires first 5606 determining the server for which a ticket was issued, and choosing 5607 the 5608 correct key for decryption. The name of the server appears in the 5609 plaintext part of the ticket. */ 5611 if (no KRB_AP_REQ in req.padata) then 5612 error_out(KDC_ERR_PADATA_TYPE_NOSUPP); 5613 endif 5614 verify KRB_AP_REQ in req.padata; 5616 /* Note that the realm in which the Kerberos server is operating is 5617 determined by the instance from the ticket-granting ticket. The 5618 realm 5619 in the ticket-granting ticket is the realm under which the ticket 5620 granting ticket was issued. It is possible for a single Kerberos 5621 server to support more than one realm. */ 5623 auth_hdr := KRB_AP_REQ; 5624 tgt := auth_hdr.ticket; 5626 if (tgt.sname is not a TGT for local realm and is not req.sname) 5627 then 5628 error_out(KRB_AP_ERR_NOT_US); 5630 realm := realm_tgt_is_for(tgt); 5632 decode remainder of request; 5634 if (auth_hdr.authenticator.cksum is missing) then 5635 error_out(KRB_AP_ERR_INAPP_CKSUM); 5636 endif 5638 if (auth_hdr.authenticator.cksum type is not supported) then 5639 error_out(KDC_ERR_SUMTYPE_NOSUPP); 5640 endif 5641 if (auth_hdr.authenticator.cksum is not both collision-proof and 5642 keyed) then 5643 error_out(KRB_AP_ERR_INAPP_CKSUM); 5644 endif 5645 the authentication protocol. These extensions provide for authentication of 5647 Neuman, Ts'o, Kohl Expires: 25 December, 5648 1999 5650 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 5651 1999 5653 set computed_checksum := checksum(req); 5654 if (computed_checksum != auth_hdr.authenticatory.cksum) then 5655 error_out(KRB_AP_ERR_MODIFIED); 5656 endif 5658 server := lookup(req.sname,realm); 5660 if (!server) then 5661 if (is_foreign_tgt_name(req.sname)) then 5662 server := best_intermediate_tgs(req.sname); 5663 else 5664 /* no server in Database */ 5665 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); 5666 endif 5667 endif 5669 session := generate_random_session_key(); 5671 use_etype := first supported etype in req.etypes; 5673 if (no support for req.etypes) then 5674 error_out(KDC_ERR_ETYPE_NOSUPP); 5675 endif 5677 new_tkt.vno := ticket version; /* = 5 */ 5678 new_tkt.sname := req.sname; 5679 new_tkt.srealm := realm; 5680 reset all flags in new_tkt.flags; 5682 /* It should be noted that local policy may affect the */ 5683 /* processing of any of these flags. For example, some */ 5684 /* realms may refuse to issue renewable tickets */ 5686 new_tkt.caddr := tgt.caddr; 5687 resp.caddr := NULL; /* We only include this if they change */ 5688 if (req.kdc-options.FORWARDABLE is set) then 5689 if (tgt.flags.FORWARDABLE is reset) then 5690 error_out(KDC_ERR_BADOPTION); 5691 endif 5692 set new_tkt.flags.FORWARDABLE; 5693 endif 5694 if (req.kdc-options.FORWARDED is set) then 5695 if (tgt.flags.FORWARDABLE is reset) then 5696 error_out(KDC_ERR_BADOPTION); 5697 endif 5698 set new_tkt.flags.FORWARDED; 5699 new_tkt.caddr := req.addresses; 5700 resp.caddr := req.addresses; 5701 endif 5702 if (tgt.flags.FORWARDED is set) then 5703 set new_tkt.flags.FORWARDED; 5704 endif 5706 if (req.kdc-options.PROXIABLE is set) then 5707 if (tgt.flags.PROXIABLE is reset) 5708 error_out(KDC_ERR_BADOPTION); 5709 endif 5710 the authentication protocol. These extensions provide for authentication of 5712 Neuman, Ts'o, Kohl Expires: 25 December, 5713 1999 5715 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 5716 1999 5718 set new_tkt.flags.PROXIABLE; 5719 endif 5720 if (req.kdc-options.PROXY is set) then 5721 if (tgt.flags.PROXIABLE is reset) then 5722 error_out(KDC_ERR_BADOPTION); 5723 endif 5724 set new_tkt.flags.PROXY; 5725 new_tkt.caddr := req.addresses; 5726 resp.caddr := req.addresses; 5727 endif 5729 if (req.kdc-options.ALLOW-POSTDATE is set) then 5730 if (tgt.flags.MAY-POSTDATE is reset) 5731 error_out(KDC_ERR_BADOPTION); 5732 endif 5733 set new_tkt.flags.MAY-POSTDATE; 5734 endif 5735 if (req.kdc-options.POSTDATED is set) then 5736 if (tgt.flags.MAY-POSTDATE is reset) then 5737 error_out(KDC_ERR_BADOPTION); 5738 endif 5739 set new_tkt.flags.POSTDATED; 5740 set new_tkt.flags.INVALID; 5741 if (against_postdate_policy(req.from)) then 5742 error_out(KDC_ERR_POLICY); 5743 endif 5744 new_tkt.starttime := req.from; 5745 endif 5747 if (req.kdc-options.VALIDATE is set) then 5748 if (tgt.flags.INVALID is reset) then 5749 error_out(KDC_ERR_POLICY); 5750 endif 5751 if (tgt.starttime > kdc_time) then 5752 error_out(KRB_AP_ERR_NYV); 5753 endif 5754 if (check_hot_list(tgt)) then 5755 error_out(KRB_AP_ERR_REPEAT); 5756 endif 5757 tkt := tgt; 5758 reset new_tkt.flags.INVALID; 5759 endif 5761 if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW, 5762 and those already processed) is set) then 5763 error_out(KDC_ERR_BADOPTION); 5764 endif 5766 new_tkt.authtime := tgt.authtime; 5768 if (req.kdc-options.RENEW is set) then 5769 /* Note that if the endtime has already passed, the ticket would 5770 */ 5771 /* have been rejected in the initial authentication stage, so 5772 */ 5773 /* there is no need to check again here 5774 */ 5775 if (tgt.flags.RENEWABLE is reset) then 5776 error_out(KDC_ERR_BADOPTION); 5777 endif 5778 if (tgt.renew-till < kdc_time) then 5779 the authentication protocol. These extensions provide for authentication of 5781 Neuman, Ts'o, Kohl Expires: 25 December, 5782 1999 5784 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 5785 1999 5787 error_out(KRB_AP_ERR_TKT_EXPIRED); 5788 endif 5789 tkt := tgt; 5790 new_tkt.starttime := kdc_time; 5791 old_life := tgt.endttime - tgt.starttime; 5792 new_tkt.endtime := min(tgt.renew-till, 5793 new_tkt.starttime + old_life); 5794 else 5795 new_tkt.starttime := kdc_time; 5796 if (req.till = 0) then 5797 till := infinity; 5798 else 5799 till := req.till; 5800 endif 5801 new_tkt.endtime := min(till, 5802 new_tkt.starttime+client.max_life, 5803 new_tkt.starttime+server.max_life, 5804 new_tkt.starttime+max_life_for_realm, 5805 tgt.endtime); 5807 if ((req.kdc-options.RENEWABLE-OK is set) and 5808 (new_tkt.endtime < req.till) and 5809 (tgt.flags.RENEWABLE is set) then 5810 /* we set the RENEWABLE option for later processing 5811 */ 5812 set req.kdc-options.RENEWABLE; 5813 req.rtime := min(req.till, tgt.renew-till); 5814 endif 5815 endif 5817 if (req.rtime = 0) then 5818 rtime := infinity; 5819 else 5820 rtime := req.rtime; 5821 endif 5823 if ((req.kdc-options.RENEWABLE is set) and 5824 (tgt.flags.RENEWABLE is set)) then 5825 set new_tkt.flags.RENEWABLE; 5826 new_tkt.renew-till := min(rtime, 5827 new_tkt.starttime+client.max_rlife, 5828 new_tkt.starttime+server.max_rlife, 5829 new_tkt.starttime+max_rlife_for_realm, 5830 tgt.renew-till); 5831 else 5832 new_tkt.renew-till := OMIT; /* leave the renew-till field out 5833 */ 5834 endif 5835 if (req.enc-authorization-data is present) then 5836 decrypt req.enc-authorization-data into 5837 decrypted_authorization_data 5838 using auth_hdr.authenticator.subkey; 5839 if (decrypt_error()) then 5840 error_out(KRB_AP_ERR_BAD_INTEGRITY); 5841 endif 5842 endif 5843 new_tkt.authorization_data := req.auth_hdr.ticket.authorization_data 5844 + 5845 decrypted_authorization_data; 5847 new_tkt.key := session; 5848 new_tkt.crealm := tgt.crealm; 5849 the authentication protocol. These extensions provide for authentication of 5851 Neuman, Ts'o, Kohl Expires: 25 December, 5852 1999 5854 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 5855 1999 5857 new_tkt.cname := req.auth_hdr.ticket.cname; 5859 if (realm_tgt_is_for(tgt) := tgt.realm) then 5860 /* tgt issued by local realm */ 5861 new_tkt.transited := tgt.transited; 5862 else 5863 /* was issued for this realm by some other realm */ 5864 if (tgt.transited.tr-type not supported) then 5865 error_out(KDC_ERR_TRTYPE_NOSUPP); 5866 endif 5867 new_tkt.transited := compress_transited(tgt.transited + 5868 tgt.realm) 5869 /* Don't check tranited field if TGT for foreign realm, 5870 * or requested not to check */ 5871 if (is_not_foreign_tgt_name(new_tkt.server) 5872 && req.kdc-options.DISABLE-TRANSITED-CHECK not set) then 5873 /* Check it, so end-server does not have to 5874 * but don't fail, end-server may still accept it */ 5875 if (check_transited_field(new_tkt.transited) == OK) 5876 set new_tkt.flags.TRANSITED-POLICY-CHECKED; 5877 endif 5878 endif 5879 endif 5881 encode encrypted part of new_tkt into OCTET STRING; 5882 if (req.kdc-options.ENC-TKT-IN-SKEY is set) then 5883 if (server not specified) then 5884 server = req.second_ticket.client; 5885 endif 5886 if ((req.second_ticket is not a TGT) or 5887 (req.second_ticket.client != server)) then 5888 error_out(KDC_ERR_POLICY); 5889 endif 5891 new_tkt.enc-part := encrypt OCTET STRING using 5892 using etype_for_key(second-ticket.key), second-ticket.key; 5893 else 5894 new_tkt.enc-part := encrypt OCTET STRING 5895 using etype_for_key(server.key), server.key, server.p_kvno; 5896 endif 5898 resp.pvno := 5; 5899 resp.msg-type := KRB_TGS_REP; 5900 resp.crealm := tgt.crealm; 5901 resp.cname := tgt.cname; 5902 resp.ticket := new_tkt; 5904 resp.key := session; 5905 resp.nonce := req.nonce; 5906 resp.last-req := fetch_last_request_info(client); 5907 resp.flags := new_tkt.flags; 5909 resp.authtime := new_tkt.authtime; 5910 resp.starttime := new_tkt.starttime; 5911 resp.endtime := new_tkt.endtime; 5913 omit resp.key-expiration; 5915 resp.sname := new_tkt.sname; 5916 the authentication protocol. These extensions provide for authentication of 5918 Neuman, Ts'o, Kohl Expires: 25 December, 5919 1999 5921 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 5922 1999 5924 resp.realm := new_tkt.realm; 5926 if (new_tkt.flags.RENEWABLE) then 5927 resp.renew-till := new_tkt.renew-till; 5928 endif 5930 encode body of reply into OCTET STRING; 5932 if (req.padata.authenticator.subkey) 5933 resp.enc-part := encrypt OCTET STRING using use_etype, 5934 req.padata.authenticator.subkey; 5935 else resp.enc-part := encrypt OCTET STRING using use_etype, tgt.key; 5937 send(resp); 5939 A.7. KRB_TGS_REP verification 5941 decode response into resp; 5943 if (resp.msg-type = KRB_ERROR) then 5944 process_error(resp); 5945 return; 5946 endif 5948 /* On error, discard the response, and zero the session key from 5949 the response immediately */ 5951 if (req.padata.authenticator.subkey) 5952 unencrypted part of resp := decode of decrypt of 5953 resp.enc-part 5954 using resp.enc-part.etype and subkey; 5955 else unencrypted part of resp := decode of decrypt of resp.enc-part 5956 using resp.enc-part.etype and tgt's session key; 5957 if (common_as_rep_tgs_rep_checks fail) then 5958 destroy resp.key; 5959 return error; 5960 endif 5962 check authorization_data as necessary; 5963 save_for_later(ticket,session,client,server,times,flags); 5965 A.8. Authenticator generation 5967 body.authenticator-vno := authenticator vno; /* = 5 */ 5968 body.cname, body.crealm := client name; 5969 if (supplying checksum) then 5970 body.cksum := checksum; 5971 endif 5972 get system_time; 5973 body.ctime, body.cusec := system_time; 5974 if (selecting sub-session key) then 5975 select sub-session key; 5976 body.subkey := sub-session key; 5977 endif 5978 if (using sequence numbers) then 5979 select initial sequence number; 5980 body.seq-number := initial sequence; 5981 endif 5983 the authentication protocol. These extensions provide for authentication of 5985 Neuman, Ts'o, Kohl Expires: 25 December, 5986 1999 5988 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 5989 1999 5991 A.9. KRB_AP_REQ generation 5993 obtain ticket and session_key from cache; 5995 packet.pvno := protocol version; /* 5 */ 5996 packet.msg-type := message type; /* KRB_AP_REQ */ 5998 if (desired(MUTUAL_AUTHENTICATION)) then 5999 set packet.ap-options.MUTUAL-REQUIRED; 6000 else 6001 reset packet.ap-options.MUTUAL-REQUIRED; 6002 endif 6003 if (using session key for ticket) then 6004 set packet.ap-options.USE-SESSION-KEY; 6005 else 6006 reset packet.ap-options.USE-SESSION-KEY; 6007 endif 6008 packet.ticket := ticket; /* ticket */ 6009 generate authenticator; 6010 encode authenticator into OCTET STRING; 6011 encrypt OCTET STRING into packet.authenticator using session_key; 6013 A.10. KRB_AP_REQ verification 6015 receive packet; 6016 if (packet.pvno != 5) then 6017 either process using other protocol spec 6018 or error_out(KRB_AP_ERR_BADVERSION); 6019 endif 6020 if (packet.msg-type != KRB_AP_REQ) then 6021 error_out(KRB_AP_ERR_MSG_TYPE); 6022 endif 6023 if (packet.ticket.tkt_vno != 5) then 6024 either process using other protocol spec 6025 or error_out(KRB_AP_ERR_BADVERSION); 6026 endif 6027 if (packet.ap_options.USE-SESSION-KEY is set) then 6028 retrieve session key from ticket-granting ticket for 6029 packet.ticket.{sname,srealm,enc-part.etype}; 6030 else 6031 retrieve service key for 6032 packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno}; 6033 endif 6034 if (no_key_available) then 6035 if (cannot_find_specified_skvno) then 6036 error_out(KRB_AP_ERR_BADKEYVER); 6037 else 6038 error_out(KRB_AP_ERR_NOKEY); 6039 endif 6040 endif 6041 decrypt packet.ticket.enc-part into decr_ticket using retrieved key; 6042 if (decryption_error()) then 6043 error_out(KRB_AP_ERR_BAD_INTEGRITY); 6044 endif 6045 decrypt packet.authenticator into decr_authenticator 6046 using decr_ticket.key; 6047 if (decryption_error()) then 6048 error_out(KRB_AP_ERR_BAD_INTEGRITY); 6049 the authentication protocol. These extensions provide for authentication of 6051 Neuman, Ts'o, Kohl Expires: 25 December, 6052 1999 6054 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 6055 1999 6057 endif 6058 if (decr_authenticator.{cname,crealm} != 6059 decr_ticket.{cname,crealm}) then 6060 error_out(KRB_AP_ERR_BADMATCH); 6061 endif 6062 if (decr_ticket.caddr is present) then 6063 if (sender_address(packet) is not in decr_ticket.caddr) then 6064 error_out(KRB_AP_ERR_BADADDR); 6065 endif 6066 elseif (application requires addresses) then 6067 error_out(KRB_AP_ERR_BADADDR); 6068 endif 6069 if (not in_clock_skew(decr_authenticator.ctime, 6070 decr_authenticator.cusec)) then 6071 error_out(KRB_AP_ERR_SKEW); 6072 endif 6073 if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then 6074 error_out(KRB_AP_ERR_REPEAT); 6075 endif 6076 save_identifier(decr_authenticator.{ctime,cusec,cname,crealm}); 6077 get system_time; 6078 if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or 6079 (decr_ticket.flags.INVALID is set)) then 6080 /* it hasn't yet become valid */ 6081 error_out(KRB_AP_ERR_TKT_NYV); 6082 endif 6083 if (system_time-decr_ticket.endtime > CLOCK_SKEW) then 6084 error_out(KRB_AP_ERR_TKT_EXPIRED); 6085 endif 6086 if (decr_ticket.transited) then 6087 /* caller may ignore the TRANSITED-POLICY-CHECKED and do 6088 * check anyway */ 6089 if (decr_ticket.flags.TRANSITED-POLICY-CHECKED not set) then 6090 if (check_transited_field(decr_ticket.transited) then 6091 error_out(KDC_AP_PATH_NOT_ACCPETED); 6092 endif 6093 endif 6094 endif 6095 /* caller must check decr_ticket.flags for any pertinent details */ 6096 return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED); 6098 the authentication protocol. These extensions provide for authentication of 6100 Neuman, Ts'o, Kohl Expires: 25 December, 6101 1999 6103 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 6104 1999 6106 A.11. KRB_AP_REP generation 6108 packet.pvno := protocol version; /* 5 */ 6109 packet.msg-type := message type; /* KRB_AP_REP */ 6111 body.ctime := packet.ctime; 6112 body.cusec := packet.cusec; 6113 if (selecting sub-session key) then 6114 select sub-session key; 6115 body.subkey := sub-session key; 6116 endif 6117 if (using sequence numbers) then 6118 select initial sequence number; 6119 body.seq-number := initial sequence; 6120 endif 6122 encode body into OCTET STRING; 6124 select encryption type; 6125 encrypt OCTET STRING into packet.enc-part; 6127 A.12. KRB_AP_REP verification 6129 receive packet; 6130 if (packet.pvno != 5) then 6131 either process using other protocol spec 6132 or error_out(KRB_AP_ERR_BADVERSION); 6133 endif 6134 if (packet.msg-type != KRB_AP_REP) then 6135 error_out(KRB_AP_ERR_MSG_TYPE); 6136 endif 6137 cleartext := decrypt(packet.enc-part) using ticket's session key; 6138 if (decryption_error()) then 6139 error_out(KRB_AP_ERR_BAD_INTEGRITY); 6140 endif 6141 if (cleartext.ctime != authenticator.ctime) then 6142 error_out(KRB_AP_ERR_MUT_FAIL); 6143 endif 6144 if (cleartext.cusec != authenticator.cusec) then 6145 error_out(KRB_AP_ERR_MUT_FAIL); 6146 endif 6147 if (cleartext.subkey is present) then 6148 save cleartext.subkey for future use; 6149 endif 6150 if (cleartext.seq-number is present) then 6151 save cleartext.seq-number for future verifications; 6152 endif 6153 return(AUTHENTICATION_SUCCEEDED); 6155 the authentication protocol. These extensions provide for authentication of 6157 Neuman, Ts'o, Kohl Expires: 25 December, 6158 1999 6160 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 6161 1999 6163 A.13. KRB_SAFE generation 6165 collect user data in buffer; 6167 /* assemble packet: */ 6168 packet.pvno := protocol version; /* 5 */ 6169 packet.msg-type := message type; /* KRB_SAFE */ 6171 body.user-data := buffer; /* DATA */ 6172 if (using timestamp) then 6173 get system_time; 6174 body.timestamp, body.usec := system_time; 6175 endif 6176 if (using sequence numbers) then 6177 body.seq-number := sequence number; 6178 endif 6179 body.s-address := sender host addresses; 6180 if (only one recipient) then 6181 body.r-address := recipient host address; 6182 endif 6183 checksum.cksumtype := checksum type; 6184 compute checksum over body; 6185 checksum.checksum := checksum value; /* checksum.checksum */ 6186 packet.cksum := checksum; 6187 packet.safe-body := body; 6189 A.14. KRB_SAFE verification 6191 receive packet; 6192 if (packet.pvno != 5) then 6193 either process using other protocol spec 6194 or error_out(KRB_AP_ERR_BADVERSION); 6195 endif 6196 if (packet.msg-type != KRB_SAFE) then 6197 error_out(KRB_AP_ERR_MSG_TYPE); 6198 endif 6199 if (packet.checksum.cksumtype is not both collision-proof 6200 and keyed) then 6201 error_out(KRB_AP_ERR_INAPP_CKSUM); 6202 endif 6203 if (safe_priv_common_checks_ok(packet)) then 6204 set computed_checksum := checksum(packet.body); 6205 if (computed_checksum != packet.checksum) then 6206 error_out(KRB_AP_ERR_MODIFIED); 6207 endif 6208 return (packet, PACKET_IS_GENUINE); 6209 else 6210 return common_checks_error; 6211 endif 6213 A.15. KRB_SAFE and KRB_PRIV common checks 6215 if (packet.s-address != O/S_sender(packet)) then 6216 /* O/S report of sender not who claims to have sent it */ 6217 error_out(KRB_AP_ERR_BADADDR); 6218 endif 6219 if ((packet.r-address is present) and 6220 (packet.r-address != local_host_address)) then 6221 the authentication protocol. These extensions provide for authentication of 6223 Neuman, Ts'o, Kohl Expires: 25 December, 6224 1999 6226 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 6227 1999 6229 /* was not sent to proper place */ 6230 error_out(KRB_AP_ERR_BADADDR); 6231 endif 6232 if (((packet.timestamp is present) and 6233 (not in_clock_skew(packet.timestamp,packet.usec))) or 6234 (packet.timestamp is not present and timestamp expected)) then 6235 error_out(KRB_AP_ERR_SKEW); 6236 endif 6237 if (repeated(packet.timestamp,packet.usec,packet.s-address)) then 6238 error_out(KRB_AP_ERR_REPEAT); 6239 endif 6241 if (((packet.seq-number is present) and 6242 ((not in_sequence(packet.seq-number)))) or 6243 (packet.seq-number is not present and sequence expected)) then 6244 error_out(KRB_AP_ERR_BADORDER); 6245 endif 6246 if (packet.timestamp not present and packet.seq-number 6247 not present) then 6248 error_out(KRB_AP_ERR_MODIFIED); 6249 endif 6251 save_identifier(packet.{timestamp,usec,s-address}, 6252 sender_principal(packet)); 6254 return PACKET_IS_OK; 6256 A.16. KRB_PRIV generation 6258 collect user data in buffer; 6260 /* assemble packet: */ 6261 packet.pvno := protocol version; /* 5 */ 6262 packet.msg-type := message type; /* KRB_PRIV */ 6264 packet.enc-part.etype := encryption type; 6266 body.user-data := buffer; 6267 if (using timestamp) then 6268 get system_time; 6269 body.timestamp, body.usec := system_time; 6270 endif 6271 if (using sequence numbers) then 6272 body.seq-number := sequence number; 6273 endif 6274 body.s-address := sender host addresses; 6275 if (only one recipient) then 6276 body.r-address := recipient host address; 6277 endif 6279 encode body into OCTET STRING; 6281 select encryption type; 6282 encrypt OCTET STRING into packet.enc-part.cipher; 6284 the authentication protocol. These extensions provide for authentication of 6286 Neuman, Ts'o, Kohl Expires: 25 December, 6287 1999 6289 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 6290 1999 6292 A.17. KRB_PRIV verification 6294 receive packet; 6295 if (packet.pvno != 5) then 6296 either process using other protocol spec 6297 or error_out(KRB_AP_ERR_BADVERSION); 6298 endif 6299 if (packet.msg-type != KRB_PRIV) then 6300 error_out(KRB_AP_ERR_MSG_TYPE); 6301 endif 6303 cleartext := decrypt(packet.enc-part) using negotiated key; 6304 if (decryption_error()) then 6305 error_out(KRB_AP_ERR_BAD_INTEGRITY); 6306 endif 6308 if (safe_priv_common_checks_ok(cleartext)) then 6309 return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED); 6310 else 6311 return common_checks_error; 6312 endif 6314 A.18. KRB_CRED generation 6316 invoke KRB_TGS; /* obtain tickets to be provided to peer */ 6318 /* assemble packet: */ 6319 packet.pvno := protocol version; /* 5 */ 6320 packet.msg-type := message type; /* KRB_CRED */ 6322 for (tickets[n] in tickets to be forwarded) do 6323 packet.tickets[n] = tickets[n].ticket; 6324 done 6326 packet.enc-part.etype := encryption type; 6328 for (ticket[n] in tickets to be forwarded) do 6329 body.ticket-info[n].key = tickets[n].session; 6330 body.ticket-info[n].prealm = tickets[n].crealm; 6331 body.ticket-info[n].pname = tickets[n].cname; 6332 body.ticket-info[n].flags = tickets[n].flags; 6333 body.ticket-info[n].authtime = tickets[n].authtime; 6334 body.ticket-info[n].starttime = tickets[n].starttime; 6335 body.ticket-info[n].endtime = tickets[n].endtime; 6336 body.ticket-info[n].renew-till = tickets[n].renew-till; 6337 body.ticket-info[n].srealm = tickets[n].srealm; 6338 body.ticket-info[n].sname = tickets[n].sname; 6339 body.ticket-info[n].caddr = tickets[n].caddr; 6340 done 6342 get system_time; 6343 body.timestamp, body.usec := system_time; 6345 if (using nonce) then 6346 body.nonce := nonce; 6347 endif 6349 if (using s-address) then 6350 the authentication protocol. These extensions provide for authentication of 6352 Neuman, Ts'o, Kohl Expires: 25 December, 6353 1999 6355 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 6356 1999 6358 body.s-address := sender host addresses; 6359 endif 6360 if (limited recipients) then 6361 body.r-address := recipient host address; 6362 endif 6364 encode body into OCTET STRING; 6366 select encryption type; 6367 encrypt OCTET STRING into packet.enc-part.cipher 6368 using negotiated encryption key; 6370 A.19. KRB_CRED verification 6372 receive packet; 6373 if (packet.pvno != 5) then 6374 either process using other protocol spec 6375 or error_out(KRB_AP_ERR_BADVERSION); 6376 endif 6377 if (packet.msg-type != KRB_CRED) then 6378 error_out(KRB_AP_ERR_MSG_TYPE); 6379 endif 6381 cleartext := decrypt(packet.enc-part) using negotiated key; 6382 if (decryption_error()) then 6383 error_out(KRB_AP_ERR_BAD_INTEGRITY); 6384 endif 6385 if ((packet.r-address is present or required) and 6386 (packet.s-address != O/S_sender(packet)) then 6387 /* O/S report of sender not who claims to have sent it */ 6388 error_out(KRB_AP_ERR_BADADDR); 6389 endif 6390 if ((packet.r-address is present) and 6391 (packet.r-address != local_host_address)) then 6392 /* was not sent to proper place */ 6393 error_out(KRB_AP_ERR_BADADDR); 6394 endif 6395 if (not in_clock_skew(packet.timestamp,packet.usec)) then 6396 error_out(KRB_AP_ERR_SKEW); 6397 endif 6398 if (repeated(packet.timestamp,packet.usec,packet.s-address)) then 6399 error_out(KRB_AP_ERR_REPEAT); 6400 endif 6401 if (packet.nonce is required or present) and 6402 (packet.nonce != expected-nonce) then 6403 error_out(KRB_AP_ERR_MODIFIED); 6404 endif 6406 for (ticket[n] in tickets that were forwarded) do 6407 save_for_later(ticket[n],key[n],principal[n], 6408 server[n],times[n],flags[n]); 6409 return 6411 the authentication protocol. These extensions provide for authentication of 6413 Neuman, Ts'o, Kohl Expires: 25 December, 6414 1999 6416 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 6417 1999 6419 A.20. KRB_ERROR generation 6421 /* assemble packet: */ 6422 packet.pvno := protocol version; /* 5 */ 6423 packet.msg-type := message type; /* KRB_ERROR */ 6425 get system_time; 6426 packet.stime, packet.susec := system_time; 6427 packet.realm, packet.sname := server name; 6429 if (client time available) then 6430 packet.ctime, packet.cusec := client_time; 6431 endif 6432 packet.error-code := error code; 6433 if (client name available) then 6434 packet.cname, packet.crealm := client name; 6435 endif 6436 if (error text available) then 6437 packet.e-text := error text; 6438 endif 6439 if (error data available) then 6440 packet.e-data := error data; 6441 endif 6443 the authentication protocol. These extensions provide for authentication of 6445 Neuman, Ts'o, Kohl Expires: 25 December, 6446 1999 6448 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 6449 1999 6451 B. Definition of common authorization data elements 6453 This appendix contains the definitions of common authorization data 6454 elements. These common authorization data elements are recursivly defined, 6455 meaning the ad-data for these types will itself contain a sequence of 6456 authorization data whose interpretation is affected by the encapsulating 6457 element. Depending on the meaning of the encapsulating element, the 6458 encapsulated elements may be ignored, might be interpreted as issued 6459 directly by the KDC, or they might be stored in a separate plaintext part of 6460 the ticket. The types of the encapsulating elements are specified as part of 6461 the Kerberos specification because the behavior based on these values should 6462 be understood across implementations whereas other elements need only be 6463 understood by the applications which they affect. 6465 In the definitions that follow, the value of the ad-type for the element 6466 will be specified in the subsection number, and the value of the ad-data 6467 will be as shown in the ASN.1 structure that follows the subsection heading. 6469 B.1. If relevant 6471 AD-IF-RELEVANT AuthorizationData 6473 AD elements encapsulated within the if-relevant element are intended for 6474 interpretation only by application servers that understand the particular 6475 ad-type of the embedded element. Application servers that do not understand 6476 the type of an element embedded within the if-relevant element may ignore 6477 the uninterpretable element. This element promotes interoperability across 6478 implementations which may have local extensions for authorization. 6480 B.2. Intended for server 6482 AD-INTENDED-FOR-SERVER SEQUENCE { 6483 intended-server[0] SEQUENCE OF PrincipalName 6484 elements[1] AuthorizationData 6485 } 6487 AD elements encapsulated within the intended-for-server element may be 6488 ignored if the application server is not in the list of principal names of 6489 intended servers. Further, a KDC issuing a ticket for an application server 6490 can remove this element if the application server is not in the list of 6491 intended servers. 6493 Application servers should check for their principal name in the 6494 intended-server field of this element. If their principal name is not found, 6495 this element should be ignored. If found, then the encapsulated elements 6496 should be evaluated in the same manner as if they were present in the top 6497 level authorization data field. Applications and application servers that do 6498 not implement this element should reject tickets that contain authorization 6499 data elements of this type. 6501 the authentication protocol. These extensions provide for authentication of 6503 Neuman, Ts'o, Kohl Expires: 25 December, 6504 1999 6506 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 6507 1999 6509 B.3. Intended for application class 6511 AD-INTENDED-FOR-APPLICATION-CLASS SEQUENCE { intended-application-class[0] 6512 SEQUENCE OF GeneralString elements[1] AuthorizationData } AD elements 6513 encapsulated within the intended-for-application-class element may be 6514 ignored if the application server is not in one of the named classes of 6515 application servers. Examples of application server classes include 6516 "FILESYSTEM", and other kinds of servers. 6518 This element and the elements it encapulates may be safely ignored by 6519 applications, application servers, and KDCs that do not implement this 6520 element. 6522 B.4. KDC Issued 6524 AD-KDCIssued SEQUENCE { 6525 ad-checksum[0] Checksum, 6526 i-realm[1] Realm OPTIONAL, 6527 i-sname[2] PrincipalName OPTIONAL, 6528 elements[3] AuthorizationData. 6529 } 6531 ad-checksum 6532 A checksum over the elements field using a cryptographic checksum 6533 method that is identical to the checksum used to protect the ticket 6534 itself (i.e. using the same hash function and the same encryption 6535 algorithm used to encrypt the ticket) and using a key derived from the 6536 same key used to protect the ticket. 6537 i-realm, i-sname 6538 The name of the issuing principal if different from the KDC itself. 6539 This field would be used when the KDC can verify the authenticity of 6540 elements signed by the issuing principal and it allows this KDC to 6541 notify the application server of the validity of those elements. 6542 elements 6543 A sequence of authorization data elements issued by the KDC. 6545 The KDC-issued ad-data field is intended to provide a means for Kerberos 6546 principal credentials to embed within themselves privilege attributes and 6547 other mechanisms for positive authorization, amplifying the priveleges of 6548 the principal beyond what can be done using a credentials without such an 6549 a-data element. 6551 This can not be provided without this element because the definition of the 6552 authorization-data field allows elements to be added at will by the bearer 6553 of a TGT at the time that they request service tickets and elements may also 6554 be added to a delegated ticket by inclusion in the authenticator. 6556 For KDC-issued elements this is prevented because the elements are signed by 6557 the KDC by including a checksum encrypted using the server's key (the same 6558 key used to encrypt the ticket - or a key derived from that key). Elements 6559 encapsulated with in the KDC-issued element will be ignored by the 6560 application server if this "signature" is not present. Further, elements 6561 encapsulated within this element from a ticket granting ticket may be 6562 interpreted by the KDC, and used as a basis according to policy for 6563 including new signed elements within derivative tickets, but they will not 6564 be copied to a derivative ticket directly. If they are copied directly to a 6565 derivative ticket by a KDC that is not aware of this element, the signature 6566 will not be correct for the application ticket elements, and the field will 6567 be ignored by the application server. 6569 This element and the elements it encapulates may be safely ignored by 6570 applications, application servers, and KDCs that do not implement this 6571 element. 6573 the authentication protocol. These extensions provide for authentication of 6575 Neuman, Ts'o, Kohl Expires: 25 December, 6576 1999 6578 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 6579 1999 6581 B.5. And-Or 6583 AD-AND-OR SEQUENCE { 6584 condition-count[0] INTEGER, 6585 elements[1] AuthorizationData 6586 } 6588 When restrictive AD elements encapsulated within the and-or element are 6589 encountered, only the number specified in condition-count of the 6590 encapsulated conditions must be met in order to satisfy this element. This 6591 element may be used to implement an "or" operation by setting the 6592 condition-count field to 1, and it may specify an "and" operation by setting 6593 the condition count to the number of embedded elements. Application servers 6594 that do not implement this element must reject tickets that contain 6595 authorization data elements of this type. 6597 B.6. Mandatory ticket extensions 6599 AD-Mandatory-Ticket-Extensions Checksum 6601 An authorization data element of type mandatory-ticket-extensions specifies 6602 a collision-proof checksum using the same hash algorithm used to protect the 6603 integrity of the ticket itself. This checksum will be calculated over an 6604 individual extension field. If there are more than one extension, multiple 6605 Mandatory-Ticket-Extensions authorization data elements may be present, each 6606 with a checksum for a different extension field. This restriction indicates 6607 that the ticket should not be accepted if a ticket extension is not present 6608 in the ticket for which the checksum does not match that checksum specified 6609 in the authorization data element. Application servers that do not implement 6610 this element must reject tickets that contain authorization data elements of 6611 this type. 6613 B.7. Authorization Data in ticket extensions 6615 AD-IN-Ticket-Extensions Checksum 6617 An authorization data element of type in-ticket-extensions specifies a 6618 collision-proof checksum using the same hash algorithm used to protect the 6619 integrity of the ticket itself. This checksum is calculated over a separate 6620 external AuthorizationData field carried in the ticket extensions. 6621 Application servers that do not implement this element must reject tickets 6622 that contain authorization data elements of this type. Application servers 6623 that do implement this element will search the ticket extensions for 6624 authorization data fields, calculate the specified checksum over each 6625 authorization data field and look for one matching the checksum in this 6626 in-ticket-extensions element. If not found, then the ticket must be 6627 rejected. If found, the corresponding authorization data elements will be 6628 interpreted in the same manner as if they were contained in the top level 6629 authorization data field. 6631 Note that if multiple external authorization data fields are present in a 6632 ticket, each will have a corresponding element of type in-ticket-extensions 6633 in the top level authorization data field, and the external entries will be 6634 linked to the corresponding element by their checksums. 6636 the authentication protocol. These extensions provide for authentication of 6638 Neuman, Ts'o, Kohl Expires: 25 December, 6639 1999 6641 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 6642 1999 6644 C. Definition of common ticket extensions 6646 This appendix contains the definitions of common ticket extensions. Support 6647 for these extensions is optional. However, certain extensions have 6648 associated authorization data elements that may require rejection of a 6649 ticket containing an extension by application servers that do not implement 6650 the particular extension. Other extensions have been defined beyond those 6651 described in this specification. Such extensions are described elswhere and 6652 for some of those extensions the reserved number may be found in the list of 6653 constants. 6655 It is known that older versions of Kerberos did not support this field, and 6656 that some clients will strip this field from a ticket when they parse and 6657 then reassemble a ticket as it is passed to the application servers. The 6658 presence of the extension will not break such clients, but any functionaly 6659 dependent on the extensions will not work when such tickets are handled by 6660 old clients. In such situations, some implementation may use alternate 6661 methods to transmit the information in the extensions field. 6663 C.1. Null ticket extension 6665 TE-NullExtension OctetString -- The empty Octet String 6667 The te-data field in the null ticket extension is an octet string of lenght 6668 zero. This extension may be included in a ticket granting ticket so that the 6669 KDC can determine on presentation of the ticket granting ticket whether the 6670 client software will strip the extensions field. 6672 C.2. External Authorization Data 6674 TE-ExternalAuthorizationData AuthorizationData 6676 The te-data field in the external authorization data ticket extension is 6677 field of type AuthorizationData containing one or more authorization data 6678 elements. If present, a corresponding authorization data element will be 6679 present in the primary authorization data for the ticket and that element 6680 will contain a checksum of the external authorization data ticket extension. 6681 ------------------------------------------------------------------------ 6682 [TM] Project Athena, Athena, and Kerberos are trademarks of the 6683 Massachusetts Institute of Technology (MIT). No commercial use of these 6684 trademarks may be made without prior written permission of MIT. 6686 [1] Note, however, that many applications use Kerberos' functions only upon 6687 the initiation of a stream-based network connection. Unless an application 6688 subsequently provides integrity protection for the data stream, the identity 6689 verification applies only to the initiation of the connection, and does not 6690 guarantee that subsequent messages on the connection originate from the same 6691 principal. 6693 [2] Secret and private are often used interchangeably in the literature. In 6694 our usage, it takes two (or more) to share a secret, thus a shared DES key 6695 is a secret key. Something is only private when no one but its owner knows 6696 it. Thus, in public key cryptosystems, one has a public and a private key. 6698 [3] Of course, with appropriate permission the client could arrange 6699 registration of a separately-named prin- cipal in a remote realm, and engage 6700 in normal exchanges with that realm's services. However, for even small 6701 numbers of clients this becomes cumbersome, and more automatic methods as 6702 described here are necessary. 6704 the authentication protocol. These extensions provide for authentication of 6706 Neuman, Ts'o, Kohl Expires: 25 December, 6707 1999 6709 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 6710 1999 6712 [4] Though it is permissible to request or issue tick- ets with no network 6713 addresses specified. 6715 [5] The password-changing request must not be honored unless the requester 6716 can provide the old password (the user's current secret key). Otherwise, it 6717 would be possible for someone to walk up to an unattended ses- sion and 6718 change another user's password. 6720 [6] To authenticate a user logging on to a local system, the credentials 6721 obtained in the AS exchange may first be used in a TGS exchange to obtain 6722 credentials for a local server. Those credentials must then be verified by a 6723 local server through successful completion of the Client/Server exchange. 6725 [7] "Random" means that, among other things, it should be impossible to 6726 guess the next session key based on knowledge of past session keys. This can 6727 only be achieved in a pseudo-random number generator if it is based on 6728 cryptographic principles. It is more desirable to use a truly random number 6729 generator, such as one based on measurements of random physical phenomena. 6731 [8] Tickets contain both an encrypted and unencrypted portion, so cleartext 6732 here refers to the entire unit, which can be copied from one message and 6733 replayed in another without any cryptographic skill. 6735 [9] Note that this can make applications based on unreliable transports 6736 difficult to code correctly. If the transport might deliver duplicated 6737 messages, either a new authenticator must be generated for each retry, or 6738 the application server must match requests and replies and replay the first 6739 reply in response to a detected duplicate. 6741 [10] This is used for user-to-user authentication as described in [8]. 6743 [11] Note that the rejection here is restricted to authenticators from the 6744 same principal to the same server. Other client principals communicating 6745 with the same server principal should not be have their authenticators 6746 rejected if the time and microsecond fields happen to match some other 6747 client's authenticator. 6749 [12] In the Kerberos version 4 protocol, the timestamp in the reply was the 6750 client's timestamp plus one. This is not necessary in version 5 because 6751 version 5 messages are formatted in such a way that it is not possible to 6752 create the reply by judicious message surgery (even in encrypted form) 6753 without knowledge of the appropriate encryption keys. 6755 [13] Note that for encrypting the KRB_AP_REP message, the sub-session key is 6756 not used, even if present in the Authenticator. 6758 [14] Implementations of the protocol may wish to provide routines to choose 6759 subkeys based on session keys and random numbers and to generate a 6760 negotiated key to be returned in the KRB_AP_REP message. 6762 [15]This can be accomplished in several ways. It might be known beforehand 6763 (since the realm is part of the principal identifier), it might be stored in 6764 a nameserver, or it might be obtained from a configura- tion file. If the 6765 realm to be used is obtained from a nameserver, there is a danger of being 6766 spoofed if the nameservice providing the realm name is not authenti- cated. 6767 This might result in the use of a realm which has been compromised, and 6768 would result in an attacker's ability to compromise the authentication of 6769 the application server to the client. 6771 the authentication protocol. These extensions provide for authentication of 6773 Neuman, Ts'o, Kohl Expires: 25 December, 6774 1999 6776 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 6777 1999 6779 [16] If the client selects a sub-session key, care must be taken to ensure 6780 the randomness of the selected sub- session key. One approach would be to 6781 generate a random number and XOR it with the session key from the 6782 ticket-granting ticket. 6784 [17] This allows easy implementation of user-to-user authentication [8], 6785 which uses ticket-granting ticket session keys in lieu of secret server keys 6786 in situa- tions where such secret keys could be easily comprom- ised. 6788 [18] For the purpose of appending, the realm preceding the first listed 6789 realm is considered to be the null realm (""). 6791 [19] For the purpose of interpreting null subfields, the client's realm is 6792 considered to precede those in the transited field, and the server's realm 6793 is considered to follow them. 6795 [20] This means that a client and server running on the same host and 6796 communicating with one another using the KRB_SAFE messages should not share 6797 a common replay cache to detect KRB_SAFE replays. 6799 [21] The implementation of the Kerberos server need not combine the database 6800 and the server on the same machine; it is feasible to store the principal 6801 database in, say, a network name service, as long as the entries stored 6802 therein are protected from disclosure to and modification by unauthorized 6803 parties. However, we recommend against such strategies, as they can make 6804 system management and threat analysis quite complex. 6806 [22] See the discussion of the padata field in section 5.4.2 for details on 6807 why this can be useful. 6809 [23] Warning for implementations that unpack and repack data structures 6810 during the generation and verification of embedded checksums: Because any 6811 checksums applied to data structures must be checked against the original 6812 data the length of bit strings must be preserved within a data structure 6813 between the time that a checksum is generated through transmission to the 6814 time that the checksum is verified. 6816 [24] It is NOT recommended that this time value be used to adjust the 6817 workstation's clock since the workstation cannot reliably determine that 6818 such a KRB_AS_REP actually came from the proper KDC in a timely manner. 6820 [25] Note, however, that if the time is used as the nonce, one must make 6821 sure that the workstation time is monotonically increasing. If the time is 6822 ever reset backwards, there is a small, but finite, probability that a nonce 6823 will be reused. 6825 [27] An application code in the encrypted part of a message provides an 6826 additional check that the message was decrypted properly. 6828 [29] An application code in the encrypted part of a message provides an 6829 additional check that the message was decrypted properly. 6831 [31] An application code in the encrypted part of a message provides an 6832 additional check that the message was decrypted properly. 6834 the authentication protocol. These extensions provide for authentication of 6836 Neuman, Ts'o, Kohl Expires: 25 December, 6837 1999 6839 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25, 6840 1999 6842 [32] If supported by the encryption method in use, an initialization vector 6843 may be passed to the encryption procedure, in order to achieve proper cipher 6844 chaining. The initialization vector might come from the last block of the 6845 ciphertext from the previous KRB_PRIV message, but it is the application's 6846 choice whether or not to use such an initialization vector. If left out, the 6847 default initialization vector for the encryption algorithm will be used. 6849 [33] This prevents an attacker who generates an incorrect AS request from 6850 obtaining verifiable plaintext for use in an off-line password guessing 6851 attack. 6853 [35] In the above specification, UNTAGGED OCTET STRING(length) is the 6854 notation for an octet string with its tag and length removed. It is not a 6855 valid ASN.1 type. The tag bits and length must be removed from the 6856 confounder since the purpose of the confounder is so that the message starts 6857 with random data, but the tag and its length are fixed. For other fields, 6858 the length and tag would be redundant if they were included because they are 6859 specified by the encryption type. [36] The ordering of the fields in the 6860 CipherText is important. Additionally, messages encoded in this format must 6861 include a length as part of the msg-seq field. This allows the recipient to 6862 verify that the message has not been truncated. Without a length, an 6863 attacker could use a chosen plaintext attack to generate a message which 6864 could be truncated, while leaving the checksum intact. Note that if the 6865 msg-seq is an encoding of an ASN.1 SEQUENCE or OCTET STRING, then the length 6866 is part of that encoding. 6868 [37] In some cases, it may be necessary to use a different "mix-in" string 6869 for compatibility reasons; see the discussion of padata in section 5.4.2. 6871 [38] In some cases, it may be necessary to use a different "mix-in" string 6872 for compatibility reasons; see the discussion of padata in section 5.4.2. 6874 [39] A variant of the key is used to limit the use of a key to a particular 6875 function, separating the functions of generating a checksum from other 6876 encryption performed using the session key. The constant F0F0F0F0F0F0F0F0 6877 was chosen because it maintains key parity. The properties of DES precluded 6878 the use of the complement. The same constant is used for similar purpose in 6879 the Message Integrity Check in the Privacy Enhanced Mail standard. 6881 [40] This error carries additional information in the e- data field. The 6882 contents of the e-data field for this message is described in section 5.9.1.