idnits 2.17.00 (12 Aug 2021) /tmp/idnits62363/draft-ietf-krb-wg-kerberos-clarifications-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 6177. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 6184. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 6190. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** Missing revision: the document name given in the document, 'draft-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-', but the file name used is 'draft-ietf-krb-wg-kerberos-clarifications-05' ** 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 135 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 286 instances of too long lines in the document, the longest one being 13 characters in excess of 72. ** The abstract seems to contain references ([DS81], [MNSS87], [NT94], [NS78], [SNS88], [KNT94]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC1510, but the abstract doesn't seem to directly say this. It does mention RFC1510 though, so this could be OK. -- The abstract seems to indicate that this document updates RFC1510, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 4789 has weird spacing: '...ticator non-P...' == Line 4791 has weird spacing: '...ketPart non-P...' == Line 4822 has weird spacing: '...RepPart non-...' == Line 4824 has weird spacing: '...RepPart non-P...' == Line 4826 has weird spacing: '...RepPart non-...' == (2 more instances...) -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: When a client wishes to initiate authentication to a server, it obtains (either through a credentials cache, the AS exchange, or the TGS exchange) a ticket and session key for the desired service. The client MAY re-use any tickets it holds until they expire. To use a ticket the client constructs a new Authenticator from the system time, its name, and optionally an application specific checksum, an initial sequence number to be used in KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in negotiations for a session key unique to this particular session. Authenticators MAY NOT be re-used and SHOULD be rejected if replayed to a server[9]. If a sequence number is to be included, it SHOULD be randomly chosen so that even after many messages have been exchanged it is not likely to collide with other sequence numbers in use. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (February 15, 2004) is 6670 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 6749 -- Looks like a reference, but probably isn't: '2' on line 6757 -- Looks like a reference, but probably isn't: '3' on line 6763 -- Looks like a reference, but probably isn't: '4' on line 6772 -- Looks like a reference, but probably isn't: '5' on line 6775 -- Looks like a reference, but probably isn't: '6' on line 6780 -- Looks like a reference, but probably isn't: '7' on line 6786 -- Looks like a reference, but probably isn't: '8' on line 6794 -- Looks like a reference, but probably isn't: '9' on line 6799 -- Looks like a reference, but probably isn't: '10' on line 6806 -- Looks like a reference, but probably isn't: '11' on line 6813 -- Looks like a reference, but probably isn't: '12' on line 6820 -- Looks like a reference, but probably isn't: '13' on line 6827 -- Looks like a reference, but probably isn't: '14' on line 6830 -- Looks like a reference, but probably isn't: '15' on line 1720 -- Looks like a reference, but probably isn't: '16' on line 6845 == Missing Reference: 'RFC1964' is mentioned on line 2509, but not defined == Missing Reference: 'ISO-646' is mentioned on line 2621, but not defined == Missing Reference: 'ECMA-6' is mentioned on line 2621, but not defined == Missing Reference: 'ISO-8859' is mentioned on line 2628, but not defined -- Looks like a reference, but probably isn't: '0' on line 6591 == Missing Reference: 'APPLICATION 1' is mentioned on line 6278, but not defined == Missing Reference: 'APPLICATION 3' is mentioned on line 6286, but not defined == Missing Reference: 'APPLICATION 10' is mentioned on line 6325, but not defined == Missing Reference: 'APPLICATION 12' is mentioned on line 6327, but not defined == Missing Reference: 'APPLICATION 11' is mentioned on line 6385, but not defined == Missing Reference: 'APPLICATION 13' is mentioned on line 6387, but not defined == Missing Reference: 'APPLICATION 25' is mentioned on line 6402, but not defined == Missing Reference: 'APPLICATION 26' is mentioned on line 6404, but not defined == Missing Reference: 'APPLICATION 14' is mentioned on line 6428, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 6442, but not defined == Missing Reference: 'APPLICATION 15' is mentioned on line 6454, but not defined == Missing Reference: 'APPLICATION 27' is mentioned on line 6460, but not defined == Missing Reference: 'APPLICATION 20' is mentioned on line 6469, but not defined == Missing Reference: 'APPLICATION 21' is mentioned on line 6485, but not defined == Missing Reference: 'APPLICATION 28' is mentioned on line 6492, but not defined == Missing Reference: 'APPLICATION 22' is mentioned on line 6501, but not defined == Missing Reference: 'APPLICATION 29' is mentioned on line 6508, but not defined == Missing Reference: 'APPLICATION 30' is mentioned on line 6533, but not defined == Missing Reference: 'RFC 2253' is mentioned on line 5451, but not defined ** Obsolete undefined reference: RFC 2253 (Obsoleted by RFC 4510, RFC 4514) == Missing Reference: 'RFC 1035' is mentioned on line 5176, but not defined == Missing Reference: 'RFC 2434' is mentioned on line 5711, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Missing Reference: 'TM' is mentioned on line 6744, but not defined == Unused Reference: 'RFC1035' is defined on line 6041, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 6048, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 6053, but no explicit reference was found in the text == Unused Reference: 'RFC2782' is defined on line 6057, but no explicit reference was found in the text == Unused Reference: 'RFC2253' is defined on line 6061, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 6140, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: draft-ietf-krb-wg-kerberos-clarifications has been published as RFC 4120 ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' == Outdated reference: draft-ietf-krb-wg-kerberos-clarifications has been published as RFC 4120 -- Duplicate reference: draft-ietf-krb-wg-kerberos-clarifications, mentioned in 'Neu93', was also mentioned in 'RFC2253'. -- Obsolete informational reference (is this intentional?): RFC 1510 (Obsoleted by RFC 4120, RFC 6649) -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 1602 (ref. 'RFC2026') (Obsoleted by RFC 2026) Summary: 15 errors (**), 1 flaw (~~), 48 warnings (==), 30 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Clifford Neuman 2 Obsoletes: 1510 USC-ISI 3 Tom Yu 4 Sam Hartman 5 Ken Raeburn 6 MIT 7 February 15, 2004 8 Expires 15 August, 2004 10 The Kerberos Network Authentication Service (V5) 12 STATUS OF THIS MEMO 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC 2026. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 To learn the current status of any Internet-Draft, please check the 32 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 33 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 34 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 36 The distribution of this memo is unlimited. It is filed as draft- 37 ietf-krb-wg-kerberos-clarifications-05.txt, and expires 15 August 38 2004. Please send comments to: ietf-krb-wg@anl.gov 40 ABSTRACT 42 This document provides an overview and specification of Version 5 of 43 the Kerberos protocol, and updates RFC1510 to clarify aspects of the 44 protocol and its intended use that require more detailed or clearer 45 explanation than was provided in RFC1510. This document is intended 46 to provide a detailed description of the protocol, suitable for 47 implementation, together with descriptions of the appropriate use of 48 protocol messages and fields within those messages. 50 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 52 OVERVIEW 54 This document describes the concepts and model upon which the 55 Kerberos network authentication system is based. It also specifies 56 Version 5 of the Kerberos protocol. The motivations, goals, 57 assumptions, and rationale behind most design decisions are treated 58 cursorily; they are more fully described in a paper available in IEEE 59 communications [NT94] and earlier in the Kerberos portion of the 60 Athena Technical Plan [MNSS87]. 62 This document is not intended to describe Kerberos to the end user, 63 system administrator, or application developer. Higher level papers 64 describing Version 5 of the Kerberos system [NT94] and documenting 65 version 4 [SNS88], are available elsewhere. 67 BACKGROUND 69 The Kerberos model is based in part on Needham and Schroeder's 70 trusted third-party authentication protocol [NS78] and on 71 modifications suggested by Denning and Sacco [DS81]. The original 72 design and implementation of Kerberos Versions 1 through 4 was the 73 work of two former Project Athena staff members, Steve Miller of 74 Digital Equipment Corporation and Clifford Neuman (now at the 75 Information Sciences Institute of the University of Southern 76 California), along with Jerome Saltzer, Technical Director of Project 77 Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other 78 members of Project Athena have also contributed to the work on 79 Kerberos. 81 Version 5 of the Kerberos protocol (described in this document) has 82 evolved from Version 4 based on new requirements and desires for 83 features not available in Version 4. The design of Version 5 of the 84 Kerberos protocol was led by Clifford Neuman and John Kohl with much 85 input from the community. The development of the MIT reference 86 implementation was led at MIT by John Kohl and Theodore Ts'o, with 87 help and contributed code from many others. Since RFC1510 was issued, 88 extensions and revisions to the protocol have been proposed by many 89 individuals. Some of these proposals are reflected in this document. 90 Where such changes involved significant effort, the document cites 91 the contribution of the proposer. 93 Reference implementations of both version 4 and version 5 of Kerberos 94 are publicly available and commercial implementations have been 95 developed and are widely used. Details on the differences between 96 Kerberos Versions 4 and 5 can be found in [KNT94]. 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119. 102 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 104 Table of Contents 106 1. Introduction ................................................... 7 107 1.1. Cross-realm operation ........................................ 9 108 1.2. Choosing a principal with which to communicate ............... 10 109 1.3. Authorization ................................................ 11 110 1.4. Extending Kerberos Without Breaking Interoperability ......... 12 111 1.4.1. Compatibility with RFC 1510 ................................ 12 112 1.4.2. Sending Extensible Messages ................................ 13 113 1.5. Environmental assumptions .................................... 14 114 1.6. Glossary of terms ............................................ 14 115 2. Ticket flag uses and requests .................................. 17 116 2.1. Initial, pre-authenticated, and hardware authenticated 117 tickets ..................................................... 18 118 2.2. Invalid tickets .............................................. 18 119 2.3. Renewable tickets ............................................ 18 120 2.4. Postdated tickets ............................................ 19 121 2.5. Proxiable and proxy tickets .................................. 20 122 2.6. Forwardable tickets .......................................... 21 123 2.7. Transited Policy Checking .................................... 21 124 2.8. OK as Delegate ............................................... 22 125 2.9. Other KDC options ............................................ 23 126 2.9.1. Renewable-OK ............................................... 23 127 2.9.2. ENC-TKT-IN-SKEY ............................................ 23 128 2.9.3. Passwordless Hardware Authentication ....................... 23 129 3. Message Exchanges .............................................. 23 130 3.1. The Authentication Service Exchange .......................... 23 131 3.1.1. Generation of KRB_AS_REQ message ........................... 25 132 3.1.2. Receipt of KRB_AS_REQ message .............................. 25 133 3.1.3. Generation of KRB_AS_REP message ........................... 25 134 3.1.4. Generation of KRB_ERROR message ............................ 28 135 3.1.5. Receipt of KRB_AS_REP message .............................. 28 136 3.1.6. Receipt of KRB_ERROR message ............................... 29 137 3.2. The Client/Server Authentication Exchange .................... 30 138 3.2.1. The KRB_AP_REQ message ..................................... 30 139 3.2.2. Generation of a KRB_AP_REQ message ......................... 30 140 3.2.3. Receipt of KRB_AP_REQ message .............................. 31 141 3.2.4. Generation of a KRB_AP_REP message ......................... 33 142 3.2.5. Receipt of KRB_AP_REP message .............................. 33 143 3.2.6. Using the encryption key ................................... 34 144 3.3. The Ticket-Granting Service (TGS) Exchange ................... 34 145 3.3.1. Generation of KRB_TGS_REQ message .......................... 36 146 3.3.2. Receipt of KRB_TGS_REQ message ............................. 37 147 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 149 3.3.3. Generation of KRB_TGS_REP message .......................... 38 150 3.3.3.1. Checking for revoked tickets ............................. 40 151 3.3.3.2. Encoding the transited field ............................. 41 152 3.3.4. Receipt of KRB_TGS_REP message ............................. 42 153 3.4. The KRB_SAFE Exchange ........................................ 43 154 3.4.1. Generation of a KRB_SAFE message ........................... 43 155 3.4.2. Receipt of KRB_SAFE message ................................ 43 156 3.5. The KRB_PRIV Exchange ........................................ 44 157 3.5.1. Generation of a KRB_PRIV message ........................... 45 158 3.5.2. Receipt of KRB_PRIV message ................................ 45 159 3.6. The KRB_CRED Exchange ........................................ 46 160 3.6.1. Generation of a KRB_CRED message ........................... 46 161 3.6.2. Receipt of KRB_CRED message ................................ 47 162 3.7. User-to-User Authentication Exchanges ........................ 47 163 4. Encryption and Checksum Specifications ......................... 49 164 5. Message Specifications ......................................... 50 165 5.1. Specific Compatibility Notes on ASN.1 ........................ 52 166 5.1.1. ASN.1 Distinguished Encoding Rules ......................... 52 167 5.1.2. Optional Integer Fields .................................... 52 168 5.1.3. Empty SEQUENCE OF Types .................................... 52 169 5.1.4. Unrecognized Tag Numbers ................................... 53 170 5.1.5. Tag Numbers Greater Than 30 ................................ 53 171 5.2. Basic Kerberos Types ......................................... 53 172 5.2.1. KerberosString ............................................. 53 173 5.2.2. Realm and PrincipalName .................................... 55 174 5.2.3. KerberosTime ............................................... 56 175 5.2.4. Constrained Integer types .................................. 56 176 5.2.5. HostAddress and HostAddresses .............................. 57 177 5.2.6. AuthorizationData .......................................... 57 178 5.2.6.1. IF-RELEVANT .............................................. 59 179 5.2.6.2. KDCIssued ................................................ 59 180 5.2.6.3. AND-OR ................................................... 60 181 5.2.6.4. MANDATORY-FOR-KDC ........................................ 60 182 5.2.7. PA-DATA .................................................... 61 183 5.2.7.1. PA-TGS-REQ ............................................... 62 184 5.2.7.2. Encrypted Timestamp Pre-authentication ................... 62 185 5.2.7.3. PA-PW-SALT ............................................... 62 186 5.2.7.4. PA-ETYPE-INFO ............................................ 63 187 5.2.7.5. PA-ETYPE-INFO2 ........................................... 63 188 5.2.8. KerberosFlags .............................................. 64 189 5.2.9. Cryptosystem-related Types ................................. 65 190 5.3. Tickets ...................................................... 67 191 5.4. Specifications for the AS and TGS exchanges .................. 74 192 5.4.1. KRB_KDC_REQ definition ..................................... 74 193 5.4.2. KRB_KDC_REP definition ..................................... 82 194 5.5. Client/Server (CS) message specifications .................... 85 195 5.5.1. KRB_AP_REQ definition ...................................... 85 196 5.5.2. KRB_AP_REP definition ...................................... 89 197 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 199 5.5.3. Error message reply ........................................ 90 200 5.6. KRB_SAFE message specification ............................... 90 201 5.6.1. KRB_SAFE definition ........................................ 90 202 5.7. KRB_PRIV message specification ............................... 92 203 5.7.1. KRB_PRIV definition ........................................ 92 204 5.8. KRB_CRED message specification ............................... 92 205 5.8.1. KRB_CRED definition ........................................ 93 206 5.9. Error message specification .................................. 95 207 5.9.1. KRB_ERROR definition ....................................... 95 208 5.10. Application Tag Numbers ..................................... 97 209 6. Naming Constraints ............................................. 98 210 6.1. Realm Names .................................................. 98 211 6.2. Principal Names .............................................. 99 212 6.2.1. Name of server principals .................................. 101 213 7. Constants and other defined values ............................. 101 214 7.1. Host address types ........................................... 101 215 7.2. KDC messaging - IP Transports ................................ 103 216 7.2.1. UDP/IP transport ........................................... 103 217 7.2.2. TCP/IP transport ........................................... 103 218 7.2.3. KDC Discovery on IP Networks ............................... 104 219 7.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names ....... 105 220 7.2.3.2. Specifying KDC Location information with DNS SRV 221 records ..................................................... 105 222 7.2.3.3. KDC Discovery for Domain Style Realm Names on IP 223 Networks .................................................... 106 224 7.3. Name of the TGS .............................................. 106 225 7.4. OID arc for KerberosV5 ....................................... 106 226 7.5. Protocol constants and associated values ..................... 106 227 7.5.1. Key usage numbers .......................................... 107 228 7.5.2. PreAuthentication Data Types 229 ............................................................. 108 230 7.5.3. Address Types 231 ............................................................. 109 232 7.5.4. Authorization Data Types 233 ............................................................. 109 234 7.5.5. Transited Encoding Types 235 ............................................................. 109 236 7.5.6. Protocol Version Number 237 ............................................................. 110 238 7.5.7. Kerberos Message Types 239 ............................................................. 110 240 7.5.8. Name Types 241 ............................................................. 110 242 7.5.9. Error Codes 243 ............................................................. 110 244 8. Interoperability requirements .................................. 112 245 8.1. Specification 2 .............................................. 112 246 8.2. Recommended KDC values ....................................... 115 247 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 249 9. IANA considerations ............................................ 115 250 10. Security Considerations ....................................... 116 251 11. Author's Addresses ............................................ 120 252 12. Acknowledgements .............................................. 121 253 13. REFERENCES .................................................... 122 254 13.1 NORMATIVE REFERENCES ......................................... 122 255 13.2 INFORMATIVE REFERENCES ....................................... 123 256 14. Copyright Statement ........................................... 124 257 15. Intellectual Property ......................................... 125 258 A. ASN.1 module ................................................... 125 259 B. Changes since RFC-1510 ......................................... 133 260 END NOTES ......................................................... 136 261 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 263 1. Introduction 265 Kerberos provides a means of verifying the identities of 266 principals, (e.g. a workstation user or a network server) on an 267 open (unprotected) network. This is accomplished without relying 268 on assertions by the host operating system, without basing trust 269 on host addresses, without requiring physical security of all the 270 hosts on the network, and under the assumption that packets 271 traveling along the network can be read, modified, and inserted at 272 will[1]. Kerberos performs authentication under these conditions 273 as a trusted third-party authentication service by using 274 conventional (shared secret key [2]) cryptography. Kerberos 275 extensions (outside the scope of this document) can provide for 276 the use of public key cryptography during certain phases of the 277 authentication protocol [@RFCE: if PKINIT advances concurrently 278 include reference to the RFC here]. Such extensions support 279 Kerberos authentication for users registered with public key 280 certification authorities and provide certain benefits of public 281 key cryptography in situations where they are needed. 283 The basic Kerberos authentication process proceeds as follows: A 284 client sends a request to the authentication server (AS) 285 requesting "credentials" for a given server. The AS responds with 286 these credentials, encrypted in the client's key. The credentials 287 consist of a "ticket" for the server and a temporary encryption 288 key (often called a "session key"). The client transmits the 289 ticket (which contains the client's identity and a copy of the 290 session key, all encrypted in the server's key) to the server. The 291 session key (now shared by the client and server) is used to 292 authenticate the client, and may optionally be used to 293 authenticate the server. It may also be used to encrypt further 294 communication between the two parties or to exchange a separate 295 sub-session key to be used to encrypt further communication. 297 Implementation of the basic protocol consists of one or more 298 authentication servers running on physically secure hosts. The 299 authentication servers maintain a database of principals (i.e., 300 users and servers) and their secret keys. Code libraries provide 301 encryption and implement the Kerberos protocol. In order to add 302 authentication to its transactions, a typical network application 303 adds calls to the Kerberos library directly or through the Generic 304 Security Services Application Programming Interface, GSSAPI, 305 described in separate document [ref to GSSAPI RFC]. These calls 306 result in the transmission of the necessary messages to achieve 307 authentication. 309 The Kerberos protocol consists of several sub-protocols (or 310 exchanges). There are two basic methods by which a client can ask 311 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 313 a Kerberos server for credentials. In the first approach, the 314 client sends a cleartext request for a ticket for the desired 315 server to the AS. The reply is sent encrypted in the client's 316 secret key. Usually this request is for a ticket-granting ticket 317 (TGT) which can later be used with the ticket-granting server 318 (TGS). In the second method, the client sends a request to the 319 TGS. The client uses the TGT to authenticate itself to the TGS in 320 the same manner as if it were contacting any other application 321 server that requires Kerberos authentication. The reply is 322 encrypted in the session key from the TGT. Though the protocol 323 specification describes the AS and the TGS as separate servers, 324 they are implemented in practice as different protocol entry 325 points within a single Kerberos server. 327 Once obtained, credentials may be used to verify the identity of 328 the principals in a transaction, to ensure the integrity of 329 messages exchanged between them, or to preserve privacy of the 330 messages. The application is free to choose whatever protection 331 may be necessary. 333 To verify the identities of the principals in a transaction, the 334 client transmits the ticket to the application server. Since the 335 ticket is sent "in the clear" (parts of it are encrypted, but this 336 encryption doesn't thwart replay) and might be intercepted and 337 reused by an attacker, additional information is sent to prove 338 that the message originated with the principal to whom the ticket 339 was issued. This information (called the authenticator) is 340 encrypted in the session key, and includes a timestamp. The 341 timestamp proves that the message was recently generated and is 342 not a replay. Encrypting the authenticator in the session key 343 proves that it was generated by a party possessing the session 344 key. Since no one except the requesting principal and the server 345 know the session key (it is never sent over the network in the 346 clear) this guarantees the identity of the client. 348 The integrity of the messages exchanged between principals can 349 also be guaranteed using the session key (passed in the ticket and 350 contained in the credentials). This approach provides detection of 351 both replay attacks and message stream modification attacks. It is 352 accomplished by generating and transmitting a collision-proof 353 checksum (elsewhere called a hash or digest function) of the 354 client's message, keyed with the session key. Privacy and 355 integrity of the messages exchanged between principals can be 356 secured by encrypting the data to be passed using the session key 357 contained in the ticket or the sub-session key found in the 358 authenticator. 360 The authentication exchanges mentioned above require read-only 361 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 363 access to the Kerberos database. Sometimes, however, the entries 364 in the database must be modified, such as when adding new 365 principals or changing a principal's key. This is done using a 366 protocol between a client and a third Kerberos server, the 367 Kerberos Administration Server (KADM). There is also a protocol 368 for maintaining multiple copies of the Kerberos database. Neither 369 of these protocols are described in this document. 371 1.1. Cross-realm operation 373 The Kerberos protocol is designed to operate across organizational 374 boundaries. A client in one organization can be authenticated to a 375 server in another. Each organization wishing to run a Kerberos 376 server establishes its own "realm". The name of the realm in which 377 a client is registered is part of the client's name, and can be 378 used by the end-service to decide whether to honor a request. 380 By establishing "inter-realm" keys, the administrators of two 381 realms can allow a client authenticated in the local realm to 382 prove its identity to servers in other realms[3]. The exchange of 383 inter-realm keys (a separate key may be used for each direction) 384 registers the ticket-granting service of each realm as a principal 385 in the other realm. A client is then able to obtain a ticket- 386 granting ticket for the remote realm's ticket-granting service 387 from its local realm. When that ticket-granting ticket is used, 388 the remote ticket-granting service uses the inter-realm key (which 389 usually differs from its own normal TGS key) to decrypt the 390 ticket-granting ticket, and is thus certain that it was issued by 391 the client's own TGS. Tickets issued by the remote ticket-granting 392 service will indicate to the end-service that the client was 393 authenticated from another realm. 395 A realm is said to communicate with another realm if the two 396 realms share an inter-realm key, or if the local realm shares an 397 inter-realm key with an intermediate realm that communicates with 398 the remote realm. An authentication path is the sequence of 399 intermediate realms that are transited in communicating from one 400 realm to another. 402 Realms may be organized hierarchically. Each realm shares a key 403 with its parent and a different key with each child. If an inter- 404 realm key is not directly shared by two realms, the hierarchical 405 organization allows an authentication path to be easily 406 constructed. If a hierarchical organization is not used, it may be 407 necessary to consult a database in order to construct an 408 authentication path between realms. 410 Although realms are typically hierarchical, intermediate realms 411 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 413 may be bypassed to achieve cross-realm authentication through 414 alternate authentication paths (these might be established to make 415 communication between two realms more efficient). It is important 416 for the end-service to know which realms were transited when 417 deciding how much faith to place in the authentication process. To 418 facilitate this decision, a field in each ticket contains the 419 names of the realms that were involved in authenticating the 420 client. 422 The application server is ultimately responsible for accepting or 423 rejecting authentication and SHOULD check the transited field. The 424 application server may choose to rely on the KDC for the 425 application server's realm to check the transited field. The 426 application server's KDC will set the TRANSITED-POLICY-CHECKED 427 flag in this case. The KDCs for intermediate realms may also check 428 the transited field as they issue ticket-granting tickets for 429 other realms, but they are encouraged not to do so. A client may 430 request that the KDCs not check the transited field by setting the 431 DISABLE-TRANSITED-CHECK flag. KDCs SHOULD honor this flag. 433 1.2. Choosing a principal with which to communicate 435 The Kerberos protocol provides the means for verifying (subject to 436 the assumptions in 1.5) that the entity with which one 437 communicates is the same entity that was registered with the KDC 438 using the claimed identity (principal name). It is still necessary 439 to determine whether that identity corresponds to the entity with 440 which one intends to communicate. 442 When appropriate data has been exchanged in advance, this 443 determination may be performed syntactically by the application 444 based on the application protocol specification, information 445 provided by the user, and configuration files. For example, the 446 server principal name (including realm) for a telnet server might 447 be derived from the user specified host name (from the telnet 448 command line), the "host/" prefix specified in the application 449 protocol specification, and a mapping to a Kerberos realm derived 450 syntactically from the domain part of the specified hostname and 451 information from the local Kerberos realms database. 453 One can also rely on trusted third parties to make this 454 determination, but only when the data obtained from the third 455 party is suitably integrity protected while resident on the third 456 party server and when transmitted. Thus, for example, one should 457 not rely on an unprotected domain name system record to map a host 458 alias to the primary name of a server, accepting the primary name 459 as the party one intends to contact, since an attacker can modify 460 the mapping and impersonate the party with which one intended to 461 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 463 communicate. 465 Implementations of Kerberos and protocols based on Kerberos MUST 466 NOT use insecure DNS queries to canonicalize the hostname 467 components of the service principal names (i.e. MUST NOT use 468 insecure DNS queries to map one name to another to determine the 469 host part of the principal name with which one is to communicate). 470 In an environment without secure name service, application authors 471 MAY append a statically configured domain name to unqualified 472 hostnames before passing the name to the security mechanisms, but 473 should do no more than that. Secure name service facilities, if 474 available, might be trusted for hostname canonicalization, but 475 such canonicalization by the client SHOULD NOT be required by KDC 476 implementations. 478 Implementation note: Many current implementations do some degree 479 of canonicalization of the provided service name, often using DNS 480 even though it creates security problems. However there is no 481 consistency among implementations about whether the service name 482 is case folded to lower case or whether reverse resolution is 483 used. To maximize interoperability and security, applications 484 SHOULD provide security mechanisms with names which result from 485 folding the user-entered name to lower case, without performing 486 any other modifications or canonicalization. 488 1.3. Authorization 490 As an authentication service, Kerberos provides a means of 491 verifying the identity of principals on a network. Authentication 492 is usually useful primarily as a first step in the process of 493 authorization, determining whether a client may use a service, 494 which objects the client is allowed to access, and the type of 495 access allowed for each. Kerberos does not, by itself, provide 496 authorization. Possession of a client ticket for a service 497 provides only for authentication of the client to that service, 498 and in the absence of a separate authorization procedure, it 499 should not be considered by an application as authorizing the use 500 of that service. 502 Such separate authorization methods MAY be implemented as 503 application specific access control functions and may utilize 504 files on the application server, or on separately issued 505 authorization credentials such as those based on proxies [Neu93], 506 or on other authorization services. Separately authenticated 507 authorization credentials MAY be embedded in a ticket's 508 authorization data when encapsulated by the KDC-issued 509 authorization data element. 511 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 513 Applications should not accept the mere issuance of a service 514 ticket by the Kerberos server (even by a modified Kerberos server) 515 as granting authority to use the service, since such applications 516 may become vulnerable to the bypass of this authorization check in 517 an environment if they interoperate with other KDCs or where other 518 options for application authentication are provided. 520 1.4. Extending Kerberos Without Breaking Interoperability 522 As the deployed base of Kerberos implementations grows, extending 523 Kerberos becomes more important. Unfortunately some extensions to 524 the existing Kerberos protocol create interoperability issues 525 because of uncertainty regarding the treatment of certain 526 extensibility options by some implementations. This section 527 includes guidelines that will enable future implementations to 528 maintain interoperability. 530 Kerberos provides a general mechanism for protocol extensibility. 531 Some protocol messages contain typed holes -- sub-messages that 532 contain an octet-string along with an integer that defines how to 533 interpret the octet-string. The integer types are registered 534 centrally, but can be used both for vendor extensions and for 535 extensions standardized through the IETF. 537 In this document, the word "extension" means an extension by 538 defining a new type to insert into an existing typed hole in a 539 protocol message. It does not mean extension by addition of new 540 fields to ASN.1 types, unless explicitly indicated otherwise in 541 the text. 543 1.4.1. Compatibility with RFC 1510 545 It is important to note that existing Kerberos message formats can 546 not be readily extended by adding fields to the ASN.1 types. 547 Sending additional fields often results in the entire message 548 being discarded without an error indication. Future versions of 549 this specification will provide guidelines to ensure that ASN.1 550 fields can be added without creating an interoperability problem. 552 In the meantime, all new or modified implementations of Kerberos 553 that receive an unknown message extension SHOULD preserve the 554 encoding of the extension but otherwise ignore the presence of the 555 extension. Recipients MUST NOT decline a request simply because an 556 extension is present. 558 There is one exception to this rule. If an unknown authorization 559 data element type is received by a server other than the ticket 560 granting service either in an AP-REQ or in a ticket contained in 561 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 563 an AP-REQ, then authentication MUST fail. One of the primary uses 564 of authorization data is to restrict the use of the ticket. If the 565 service cannot determine whether the restriction applies to that 566 service then a security weakness may result if the ticket can be 567 used for that service. Authorization elements that are optional 568 SHOULD be enclosed in the AD-IF-RELEVANT element. 570 The ticket granting service MUST ignore but propagate to 571 derivative tickets any unknown authorization data types, unless 572 those data types are embedded in a MANDATORY-FOR-KDC element, in 573 which case the request will be rejected. This behavior is 574 appropriate because requiring that the ticket granting service 575 understand unknown authorization data types would require that KDC 576 software be upgraded to understand new application-level 577 restrictions before applications used these restrictions, 578 decreasing the utility of authorization data as a mechanism for 579 restricting the use of tickets. No security problem is created 580 because services to which the tickets are issued will verify the 581 authorization data. 583 Implementation note: Many RFC 1510 implementations ignore unknown 584 authorization data elements. Depending on these implementations to 585 honor authorization data restrictions may create a security 586 weakness. 588 1.4.2. Sending Extensible Messages 590 Care must be taken to ensure that old implementations can 591 understand messages sent to them even if they do not understand an 592 extension that is used. Unless the sender knows an extension is 593 supported, the extension cannot change the semantics of the core 594 message or previously defined extensions. 596 For example, an extension including key information necessary to 597 decrypt the encrypted part of a KDC-REP could only be used in 598 situations where the recipient was known to support the extension. 599 Thus when designing such extensions it is important to provide a 600 way for the recipient to notify the sender of support for the 601 extension. For example in the case of an extension that changes 602 the KDC-REP reply key, the client could indicate support for the 603 extension by including a padata element in the AS-REQ sequence. 604 The KDC should only use the extension if this padata element is 605 present in the AS-REQ. Even if policy requires the use of the 606 extension, it is better to return an error indicating that the 607 extension is required than to use the extension when the recipient 608 may not support it; debugging why implementations do not 609 interoperate is easier when errors are returned. 611 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 613 1.5. Environmental assumptions 615 Kerberos imposes a few assumptions on the environment in which it 616 can properly function: 618 * "Denial of service" attacks are not solved with Kerberos. There 619 are places in the protocols where an intruder can prevent an 620 application from participating in the proper authentication steps. 621 Detection and solution of such attacks (some of which can appear 622 to be not-uncommon "normal" failure modes for the system) is 623 usually best left to the human administrators and users. 625 * Principals MUST keep their secret keys secret. If an intruder 626 somehow steals a principal's key, it will be able to masquerade as 627 that principal or impersonate any server to the legitimate 628 principal. 630 * "Password guessing" attacks are not solved by Kerberos. If a user 631 chooses a poor password, it is possible for an attacker to 632 successfully mount an offline dictionary attack by repeatedly 633 attempting to decrypt, with successive entries from a dictionary, 634 messages obtained which are encrypted under a key derived from the 635 user's password. 637 * Each host on the network MUST have a clock which is "loosely 638 synchronized" to the time of the other hosts; this synchronization 639 is used to reduce the bookkeeping needs of application servers 640 when they do replay detection. The degree of "looseness" can be 641 configured on a per-server basis, but is typically on the order of 642 5 minutes. If the clocks are synchronized over the network, the 643 clock synchronization protocol MUST itself be secured from network 644 attackers. 646 * Principal identifiers are not recycled on a short-term basis. A 647 typical mode of access control will use access control lists 648 (ACLs) to grant permissions to particular principals. If a stale 649 ACL entry remains for a deleted principal and the principal 650 identifier is reused, the new principal will inherit rights 651 specified in the stale ACL entry. By not re-using principal 652 identifiers, the danger of inadvertent access is removed. 654 1.6. Glossary of terms 656 Below is a list of terms used throughout this document. 658 Authentication 659 Verifying the claimed identity of a principal. 661 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 663 Authentication header 664 A record containing a Ticket and an Authenticator to be presented 665 to a server as part of the authentication process. 667 Authentication path 668 A sequence of intermediate realms transited in the authentication 669 process when communicating from one realm to another. 671 Authenticator 672 A record containing information that can be shown to have been 673 recently generated using the session key known only by the client 674 and server. 676 Authorization 677 The process of determining whether a client may use a service, 678 which objects the client is allowed to access, and the type of 679 access allowed for each. 681 Capability 682 A token that grants the bearer permission to access an object or 683 service. In Kerberos, this might be a ticket whose use is 684 restricted by the contents of the authorization data field, but 685 which lists no network addresses, together with the session key 686 necessary to use the ticket. 688 Ciphertext 689 The output of an encryption function. Encryption transforms 690 plaintext into ciphertext. 692 Client 693 A process that makes use of a network service on behalf of a user. 694 Note that in some cases a Server may itself be a client of some 695 other server (e.g. a print server may be a client of a file 696 server). 698 Credentials 699 A ticket plus the secret session key necessary to successfully use 700 that ticket in an authentication exchange. 702 Encryption Type (etype) 703 When associated with encrypted data, an encryption type identifies 704 the algorithm used to encrypt the data and is used to select the 705 appropriate algorithm for decrypting the data. Encryption type 706 tags are communicated in other messages to enumerate algorithms 707 that are desired, supported, preferred, or allowed to be used for 708 encryption of data between parties. This preference is combined 709 with local information and policy to select an algorithm to be 710 used. 712 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 714 KDC 715 Key Distribution Center, a network service that supplies tickets 716 and temporary session keys; or an instance of that service or the 717 host on which it runs. The KDC services both initial ticket and 718 ticket-granting ticket requests. The initial ticket portion is 719 sometimes referred to as the Authentication Server (or service). 720 The ticket-granting ticket portion is sometimes referred to as the 721 ticket-granting server (or service). 723 Kerberos 724 The name given to the Project Athena's authentication service, the 725 protocol used by that service, or the code used to implement the 726 authentication service. The name is adopted from the three-headed 727 dog which guards Hades. 729 Key Version Number (kvno) 730 A tag associated with encrypted data identifies which key was used 731 for encryption when a long lived key associated with a principal 732 changes over time. It is used during the transition to a new key 733 so that the party decrypting a message can tell whether the data 734 was encrypted using the old or the new key. 736 Plaintext 737 The input to an encryption function or the output of a decryption 738 function. Decryption transforms ciphertext into plaintext. 740 Principal 741 A named client or server entity that participates in a network 742 communication, with one name that is considered canonical. 744 Principal identifier 745 The canonical name used to uniquely identify each different 746 principal. 748 Seal 749 To encipher a record containing several fields in such a way that 750 the fields cannot be individually replaced without either 751 knowledge of the encryption key or leaving evidence of tampering. 753 Secret key 754 An encryption key shared by a principal and the KDC, distributed 755 outside the bounds of the system, with a long lifetime. In the 756 case of a human user's principal, the secret key MAY be derived 757 from a password. 759 Server 760 A particular Principal which provides a resource to network 761 clients. The server is sometimes referred to as the Application 762 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 764 Server. 766 Service 767 A resource provided to network clients; often provided by more 768 than one server (for example, remote file service). 770 Session key 771 A temporary encryption key used between two principals, with a 772 lifetime limited to the duration of a single login "session". In 773 the Kerberos system, a session key is generated by the KDC. The 774 session key is distinct from the sub-session key, described next.. 776 Sub-session key 777 A temporary encryption key used between two principals, selected 778 and exchanged by the principals using the session key, and with a 779 lifetime limited to the duration of a single association. The sub- 780 session key is also referred to as the subkey. 782 Ticket 783 A record that helps a client authenticate itself to a server; it 784 contains the client's identity, a session key, a timestamp, and 785 other information, all sealed using the server's secret key. It 786 only serves to authenticate a client when presented along with a 787 fresh Authenticator. 789 2. Ticket flag uses and requests 791 Each Kerberos ticket contains a set of flags which are used to 792 indicate attributes of that ticket. Most flags may be requested by 793 a client when the ticket is obtained; some are automatically 794 turned on and off by a Kerberos server as required. The following 795 sections explain what the various flags mean and give examples of 796 reasons to use them. With the exception of the INVALID flag 797 clients MUST ignore ticket flags that are not recognized. KDCs 798 MUST ignore KDC options that are not recognized. Some 799 implementations of RFC 1510 are known to reject unknown KDC 800 options, so clients may need to resend a request without new KDC 801 options if the request was rejected when sent with options added 802 since RFC 1510. Since new KDCs will ignore unknown options, 803 clients MUST confirm that the ticket returned by the KDC meets 804 their needs. 806 Note that it is not, in general, possible to determine whether an 807 option was not honored because it was not understood or because it 808 was rejected either through configuration or policy. When adding a 809 new option to the Kerberos protocol, designers should consider 810 whether the distinction is important for their option. In cases 811 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 813 where it is, a mechanism for the KDC to return an indication that 814 the option was understood but rejected needs to be provided in the 815 specification of the option. Often in such cases, the mechanism 816 needs to be broad enough to permit an error or reason to be 817 returned. 819 2.1. Initial, pre-authenticated, and hardware authenticated tickets 821 The INITIAL flag indicates that a ticket was issued using the AS 822 protocol, rather than issued based on a ticket-granting ticket. 823 Application servers that want to require the demonstrated 824 knowledge of a client's secret key (e.g. a password-changing 825 program) can insist that this flag be set in any tickets they 826 accept, and thus be assured that the client's key was recently 827 presented to the application client. 829 The PRE-AUTHENT and HW-AUTHENT flags provide additional 830 information about the initial authentication, regardless of 831 whether the current ticket was issued directly (in which case 832 INITIAL will also be set) or issued on the basis of a ticket- 833 granting ticket (in which case the INITIAL flag is clear, but the 834 PRE-AUTHENT and HW-AUTHENT flags are carried forward from the 835 ticket-granting ticket). 837 2.2. Invalid tickets 839 The INVALID flag indicates that a ticket is invalid. Application 840 servers MUST reject tickets which have this flag set. A postdated 841 ticket will be issued in this form. Invalid tickets MUST be 842 validated by the KDC before use, by presenting them to the KDC in 843 a TGS request with the VALIDATE option specified. The KDC will 844 only validate tickets after their starttime has passed. The 845 validation is required so that postdated tickets which have been 846 stolen before their starttime can be rendered permanently invalid 847 (through a hot-list mechanism) (see section 3.3.3.1). 849 2.3. Renewable tickets 851 Applications may desire to hold tickets which can be valid for 852 long periods of time. However, this can expose their credentials 853 to potential theft for equally long periods, and those stolen 854 credentials would be valid until the expiration time of the 855 ticket(s). Simply using short-lived tickets and obtaining new ones 856 periodically would require the client to have long-term access to 857 its secret key, an even greater risk. Renewable tickets can be 858 used to mitigate the consequences of theft. Renewable tickets have 859 two "expiration times": the first is when the current instance of 860 the ticket expires, and the second is the latest permissible value 861 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 863 for an individual expiration time. An application client must 864 periodically (i.e. before it expires) present a renewable ticket 865 to the KDC, with the RENEW option set in the KDC request. The KDC 866 will issue a new ticket with a new session key and a later 867 expiration time. All other fields of the ticket are left 868 unmodified by the renewal process. When the latest permissible 869 expiration time arrives, the ticket expires permanently. At each 870 renewal, the KDC MAY consult a hot-list to determine if the ticket 871 had been reported stolen since its last renewal; it will refuse to 872 renew such stolen tickets, and thus the usable lifetime of stolen 873 tickets is reduced. 875 The RENEWABLE flag in a ticket is normally only interpreted by the 876 ticket-granting service (discussed below in section 3.3). It can 877 usually be ignored by application servers. However, some 878 particularly careful application servers MAY disallow renewable 879 tickets. 881 If a renewable ticket is not renewed by its expiration time, the 882 KDC will not renew the ticket. The RENEWABLE flag is reset by 883 default, but a client MAY request it be set by setting the 884 RENEWABLE option in the KRB_AS_REQ message. If it is set, then the 885 renew-till field in the ticket contains the time after which the 886 ticket may not be renewed. 888 2.4. Postdated tickets 890 Applications may occasionally need to obtain tickets for use much 891 later, e.g. a batch submission system would need tickets to be 892 valid at the time the batch job is serviced. However, it is 893 dangerous to hold valid tickets in a batch queue, since they will 894 be on-line longer and more prone to theft. Postdated tickets 895 provide a way to obtain these tickets from the KDC at job 896 submission time, but to leave them "dormant" until they are 897 activated and validated by a further request of the KDC. If a 898 ticket theft were reported in the interim, the KDC would refuse to 899 validate the ticket, and the thief would be foiled. 901 The MAY-POSTDATE flag in a ticket is normally only interpreted by 902 the ticket-granting service. It can be ignored by application 903 servers. This flag MUST be set in a ticket-granting ticket in 904 order to issue a postdated ticket based on the presented ticket. 905 It is reset by default; it MAY be requested by a client by setting 906 the ALLOW-POSTDATE option in the KRB_AS_REQ message. This flag 907 does not allow a client to obtain a postdated ticket-granting 908 ticket; postdated ticket-granting tickets can only by obtained by 909 requesting the postdating in the KRB_AS_REQ message. The life 910 (endtime-starttime) of a postdated ticket will be the remaining 911 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 913 life of the ticket-granting ticket at the time of the request, 914 unless the RENEWABLE option is also set, in which case it can be 915 the full life (endtime-starttime) of the ticket-granting ticket. 916 The KDC MAY limit how far in the future a ticket may be postdated. 918 The POSTDATED flag indicates that a ticket has been postdated. The 919 application server can check the authtime field in the ticket to 920 see when the original authentication occurred. Some services MAY 921 choose to reject postdated tickets, or they may only accept them 922 within a certain period after the original authentication. When 923 the KDC issues a POSTDATED ticket, it will also be marked as 924 INVALID, so that the application client MUST present the ticket to 925 the KDC to be validated before use. 927 2.5. Proxiable and proxy tickets 929 At times it may be necessary for a principal to allow a service to 930 perform an operation on its behalf. The service must be able to 931 take on the identity of the client, but only for a particular 932 purpose. A principal can allow a service to take on the 933 principal's identity for a particular purpose by granting it a 934 proxy. 936 The process of granting a proxy using the proxy and proxiable 937 flags is used to provide credentials for use with specific 938 services. Though conceptually also a proxy, users wishing to 939 delegate their identity in a form usable for all purpose MUST use 940 the ticket forwarding mechanism described in the next section to 941 forward a ticket-granting ticket. 943 The PROXIABLE flag in a ticket is normally only interpreted by the 944 ticket-granting service. It can be ignored by application servers. 945 When set, this flag tells the ticket-granting server that it is OK 946 to issue a new ticket (but not a ticket-granting ticket) with a 947 different network address based on this ticket. This flag is set 948 if requested by the client on initial authentication. By default, 949 the client will request that it be set when requesting a ticket- 950 granting ticket, and reset when requesting any other ticket. 952 This flag allows a client to pass a proxy to a server to perform a 953 remote request on its behalf (e.g. a print service client can give 954 the print server a proxy to access the client's files on a 955 particular file server in order to satisfy a print request). 957 In order to complicate the use of stolen credentials, Kerberos 958 tickets are usually valid from only those network addresses 959 specifically included in the ticket[4]. When granting a proxy, the 960 client MUST specify the new network address from which the proxy 961 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 963 is to be used, or indicate that the proxy is to be issued for use 964 from any address. 966 The PROXY flag is set in a ticket by the TGS when it issues a 967 proxy ticket. Application servers MAY check this flag and at 968 their option they MAY require additional authentication from the 969 agent presenting the proxy in order to provide an audit trail. 971 2.6. Forwardable tickets 973 Authentication forwarding is an instance of a proxy where the 974 service that is granted is complete use of the client's identity. 975 An example where it might be used is when a user logs in to a 976 remote system and wants authentication to work from that system as 977 if the login were local. 979 The FORWARDABLE flag in a ticket is normally only interpreted by 980 the ticket-granting service. It can be ignored by application 981 servers. The FORWARDABLE flag has an interpretation similar to 982 that of the PROXIABLE flag, except ticket-granting tickets may 983 also be issued with different network addresses. This flag is 984 reset by default, but users MAY request that it be set by setting 985 the FORWARDABLE option in the AS request when they request their 986 initial ticket-granting ticket. 988 This flag allows for authentication forwarding without requiring 989 the user to enter a password again. If the flag is not set, then 990 authentication forwarding is not permitted, but the same result 991 can still be achieved if the user engages in the AS exchange 992 specifying the requested network addresses and supplies a 993 password. 995 The FORWARDED flag is set by the TGS when a client presents a 996 ticket with the FORWARDABLE flag set and requests a forwarded 997 ticket by specifying the FORWARDED KDC option and supplying a set 998 of addresses for the new ticket. It is also set in all tickets 999 issued based on tickets with the FORWARDED flag set. Application 1000 servers may choose to process FORWARDED tickets differently than 1001 non-FORWARDED tickets. 1003 If addressless tickets are forwarded from one system to another, 1004 clients SHOULD still use this option to obtain a new TGT in order 1005 to have different session keys on the different systems. 1007 2.7. Transited Policy Checking 1009 In Kerberos, the application server is ultimately responsible for 1010 accepting or rejecting authentication and SHOULD check that only 1011 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1013 suitably trusted KDCs are relied upon to authenticate a principal. 1014 The transited field in the ticket identifies which realms (and 1015 thus which KDCs) were involved in the authentication process and 1016 an application server would normally check this field. If any of 1017 these are untrusted to authenticate the indicated client principal 1018 (probably determined by a realm-based policy), the authentication 1019 attempt MUST be rejected. The presence of trusted KDCs in this 1020 list does not provide any guarantee; an untrusted KDC may have 1021 fabricated the list. 1023 While the end server ultimately decides whether authentication is 1024 valid, the KDC for the end server's realm MAY apply a realm 1025 specific policy for validating the transited field and accepting 1026 credentials for cross-realm authentication. When the KDC applies 1027 such checks and accepts such cross-realm authentication it will 1028 set the TRANSITED-POLICY-CHECKED flag in the service tickets it 1029 issues based on the cross-realm TGT. A client MAY request that the 1030 KDCs not check the transited field by setting the DISABLE- 1031 TRANSITED-CHECK flag. KDCs are encouraged but not required to 1032 honor this flag. 1034 Application servers MUST either do the transited-realm checks 1035 themselves, or reject cross-realm tickets without TRANSITED- 1036 POLICY-CHECKED set. 1038 2.8. OK as Delegate 1040 For some applications a client may need to delegate authority to a 1041 server to act on its behalf in contacting other services. This 1042 requires that the client forward credentials to an intermediate 1043 server. The ability for a client to obtain a service ticket to a 1044 server conveys no information to the client about whether the 1045 server should be trusted to accept delegated credentials. The OK- 1046 AS-DELEGATE provides a way for a KDC to communicate local realm 1047 policy to a client regarding whether an intermediate server is 1048 trusted to accept such credentials. 1050 The copy of the ticket flags in the encrypted part of the KDC 1051 reply may have the OK-AS-DELEGATE flag set to indicates to the 1052 client that the server specified in the ticket has been determined 1053 by policy of the realm to be a suitable recipient of delegation. 1054 A client can use the presence of this flag to help it make a 1055 decision whether to delegate credentials (either grant a proxy or 1056 a forwarded ticket-granting ticket) to this server. It is 1057 acceptable to ignore the value of this flag. When setting this 1058 flag, an administrator should consider the security and placement 1059 of the server on which the service will run, as well as whether 1060 the service requires the use of delegated credentials. 1062 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1064 2.9. Other KDC options 1066 There are three additional options which MAY be set in a client's 1067 request of the KDC. 1069 2.9.1. Renewable-OK 1071 The RENEWABLE-OK option indicates that the client will accept a 1072 renewable ticket if a ticket with the requested life cannot 1073 otherwise be provided. If a ticket with the requested life cannot 1074 be provided, then the KDC MAY issue a renewable ticket with a 1075 renew-till equal to the requested endtime. The value of the renew- 1076 till field MAY still be adjusted by site-determined limits or 1077 limits imposed by the individual principal or server. 1079 2.9.2. ENC-TKT-IN-SKEY 1081 In its basic form the Kerberos protocol supports authentication in 1082 a client-server 1083 setting and is not well suited to authentication in a peer-to- 1084 peer environment because the long term key of the user does not 1085 remain on the workstation after initial login. Authentication of 1086 such peers may be supported by Kerberos in its user-to-user 1087 variant. The ENC-TKT-IN-SKEY option supports user-to-user 1088 authentication by allowing the KDC to issue a service ticket 1089 encrypted using the session key from another ticket-granting 1090 ticket issued to another user. The ENC-TKT-IN-SKEY option is 1091 honored only by the ticket-granting service. It indicates that the 1092 ticket to be issued for the end server is to be encrypted in the 1093 session key from the additional second ticket-granting ticket 1094 provided with the request. See section 3.3.3 for specific details. 1096 2.9.3. Passwordless Hardware Authentication 1098 The OPT-HARDWARE-AUTH option indicates that the client wishes to 1099 use some form of hardware authentication instead of or in addition 1100 to the client's password or other long-lived encryption key. OPT- 1101 HARDWARE-AUTH is honored only by the authentication service. If 1102 supported and allowed by policy, the KDC will return an errorcode 1103 KDC_ERR_PREAUTH_REQUIRED and include the required METHOD-DATA to 1104 perform such authentication. 1106 3. Message Exchanges 1108 The following sections describe the interactions between network 1109 clients and servers and the messages involved in those exchanges. 1111 3.1. The Authentication Service Exchange 1112 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1114 Summary 1116 Message direction Message type Section 1117 1. Client to Kerberos KRB_AS_REQ 5.4.1 1118 2. Kerberos to client KRB_AS_REP or 5.4.2 1119 KRB_ERROR 5.9.1 1121 The Authentication Service (AS) Exchange between the client and 1122 the Kerberos Authentication Server is initiated by a client when 1123 it wishes to obtain authentication credentials for a given server 1124 but currently holds no credentials. In its basic form, the 1125 client's secret key is used for encryption and decryption. This 1126 exchange is typically used at the initiation of a login session to 1127 obtain credentials for a Ticket-Granting Server which will 1128 subsequently be used to obtain credentials for other servers (see 1129 section 3.3) without requiring further use of the client's secret 1130 key. This exchange is also used to request credentials for 1131 services which must not be mediated through the Ticket-Granting 1132 Service, but rather require a principal's secret key, such as the 1133 password-changing service[5]. This exchange does not by itself 1134 provide any assurance of the identity of the user[6]. 1136 The exchange consists of two messages: KRB_AS_REQ from the client 1137 to Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for 1138 these messages are described in sections 5.4.1, 5.4.2, and 5.9.1. 1140 In the request, the client sends (in cleartext) its own identity 1141 and the identity of the server for which it is requesting 1142 credentials, other information about the credentials it is 1143 requesting, and a randomly generated nonce which can be used to 1144 detect replays, and to associate replies with the matching 1145 requests. This nonce MUST be generated randomly by the client and 1146 remembered for checking against the nonce in the expected reply. 1147 The response, KRB_AS_REP, contains a ticket for the client to 1148 present to the server, and a session key that will be shared by 1149 the client and the server. The session key and additional 1150 information are encrypted in the client's secret key. The 1151 encrypted part of the KRB_AS_REP message also contains the nonce 1152 which MUST be matched with the nonce from the KRB_AS_REQ message. 1154 Without pre-authentication, the authentication server does not 1155 know whether the client is actually the principal named in the 1156 request. It simply sends a reply without knowing or caring whether 1157 they are the same. This is acceptable because nobody but the 1158 principal whose identity was given in the request will be able to 1159 use the reply. Its critical information is encrypted in that 1160 principal's key. However, an attacker can send a KRB_AS_REQ 1161 message to get known plaintext in order to attack the principal's 1162 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1164 key. Especially if the key is based on a password, this may create 1165 a security exposure. So, the initial request supports an optional 1166 field that can be used to pass additional information that might 1167 be needed for the initial exchange. This field SHOULD be used for 1168 pre-authentication as described in sections 3.1.1 and 5.2.7. 1170 Various errors can occur; these are indicated by an error response 1171 (KRB_ERROR) instead of the KRB_AS_REP response. The error message 1172 is not encrypted. The KRB_ERROR message contains information which 1173 can be used to associate it with the message to which it replies. 1174 The contents of the KRB_ERROR message are not integrity-protected. 1175 As such, the client cannot detect replays, fabrications or 1176 modifications. A solution to this problem will be included in a 1177 future version of the protocol. 1179 3.1.1. Generation of KRB_AS_REQ message 1181 The client may specify a number of options in the initial request. 1182 Among these options are whether pre-authentication is to be 1183 performed; whether the requested ticket is to be renewable, 1184 proxiable, or forwardable; whether it should be postdated or allow 1185 postdating of derivative tickets; and whether a renewable ticket 1186 will be accepted in lieu of a non-renewable ticket if the 1187 requested ticket expiration date cannot be satisfied by a non- 1188 renewable ticket (due to configuration constraints). 1190 The client prepares the KRB_AS_REQ message and sends it to the 1191 KDC. 1193 3.1.2. Receipt of KRB_AS_REQ message 1195 If all goes well, processing the KRB_AS_REQ message will result in 1196 the creation of a ticket for the client to present to the server. 1197 The format for the ticket is described in section 5.3. 1199 Because Kerberos can run over unreliable transports such as UDP, 1200 the KDC MUST be prepared to retransmit responses in case they are 1201 lost. If a KDC receives a request identical to one it has recently 1202 successfully processed, the KDC MUST respond with a KRB_AS_REP 1203 message rather than a replay error. In order to reduce ciphertext 1204 given to a potential attacker, KDCs MAY send the same response 1205 generated when the request was first handled. KDCs MUST obey this 1206 replay behavior even if the actual transport in use is reliable. 1208 3.1.3. Generation of KRB_AS_REP message 1210 The authentication server looks up the client and server 1211 principals named in the KRB_AS_REQ in its database, extracting 1212 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1214 their respective keys. If the requested client principal named in 1215 the request is not known because it doesn't exist in the KDC's 1216 principal database, then an error message with a 1217 KDC_ERR_C_PRINCIPAL_UNKNOWN is returned. 1219 If required, the server pre-authenticates the request, and if the 1220 pre-authentication check fails, an error message with the code 1221 KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is 1222 required, but was not present in the request, an error message 1223 with the code KDC_ERR_PREAUTH_REQUIRED is returned and a METHOD- 1224 DATA object will be stored in the e-data field of the KRB-ERROR 1225 message to specify which pre-authentication mechanisms are 1226 acceptable. Usually this will include PA-ETYPE-INFO and/or PA- 1227 ETYPE-INFO2 elements as described below. If the server cannot 1228 accommodate any encryption type requested by the client, an error 1229 message with code KDC_ERR_ETYPE_NOSUPP is returned. Otherwise the 1230 KDC generates a 'random' session key[7]. 1232 When responding to an AS request, if there are multiple encryption 1233 keys registered for a client in the Kerberos database, then the 1234 etype field from the AS request is used by the KDC to select the 1235 encryption method to be used to protect the encrypted part of the 1236 KRB_AS_REP message which is sent to the client. If there is more 1237 than one supported strong encryption type in the etype list, the 1238 KDC SHOULD use the first valid strong etype for which an 1239 encryption key is available. 1241 When the user's key is generated from a password or pass phrase, 1242 the string-to-key function for the particular encryption key type 1243 is used, as specified in [@KCRYPTO]. The salt value and additional 1244 parameters for the string-to-key function have default values 1245 (specified by section 4 and by the encryption mechanism 1246 specification, respectively) that may be overridden by pre- 1247 authentication data (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA- 1248 ETYPE-INFO2, etc). Since the KDC is presumed to store a copy of 1249 the resulting key only, these values should not be changed for 1250 password-based keys except when changing the principal's key. 1252 When the AS server is to include pre-authentication data in a KRB- 1253 ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE- 1254 INFO, if the etype field of the client's AS-REQ lists at least one 1255 "newer" encryption type. Otherwise (when the etype field of the 1256 client's AS-REQ does not list any "newer" encryption types) it 1257 MUST send both, PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an 1258 entry for each enctype). A "newer" enctype is any enctype first 1259 officially specified concurrently with or subsequent to the issue 1260 of this RFC. The enctypes DES, 3DES or RC4 and any defined in 1261 [RFC1510] are not "newer" enctypes. 1263 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1265 It is not possible to reliably generate a user's key given a pass 1266 phrase without contacting the KDC, since it will not be known 1267 whether alternate salt or parameter values are required. 1269 The KDC will attempt to assign the type of the random session key 1270 from the list of methods in the etype field. The KDC will select 1271 the appropriate type using the list of methods provided together 1272 with information from the Kerberos database indicating acceptable 1273 encryption methods for the application server. The KDC will not 1274 issue tickets with a weak session key encryption type. 1276 If the requested start time is absent, indicates a time in the 1277 past, or is within the window of acceptable clock skew for the KDC 1278 and the POSTDATE option has not been specified, then the start 1279 time of the ticket is set to the authentication server's current 1280 time. If it indicates a time in the future beyond the acceptable 1281 clock skew, but the POSTDATED option has not been specified then 1282 the error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the 1283 requested start time is checked against the policy of the local 1284 realm (the administrator might decide to prohibit certain types or 1285 ranges of postdated tickets), and if acceptable, the ticket's 1286 start time is set as requested and the INVALID flag is set in the 1287 new ticket. The postdated ticket MUST be validated before use by 1288 presenting it to the KDC after the start time has been reached. 1290 The expiration time of the ticket will be set to the earlier of 1291 the requested endtime and a time determined by local policy, 1292 possibly determined using realm or principal specific factors. For 1293 example, the expiration time MAY be set to the earliest of the 1294 following: 1296 * The expiration time (endtime) requested in the KRB_AS_REQ 1297 message. 1299 * The ticket's start time plus the maximum allowable lifetime 1300 associated with the client principal from the authentication 1301 server's database. 1303 * The ticket's start time plus the maximum allowable lifetime 1304 associated with the server principal. 1306 * The ticket's start time plus the maximum lifetime set by the 1307 policy of the local realm. 1309 If the requested expiration time minus the start time (as determined 1310 above) is less than a site-determined minimum lifetime, an error 1311 message with code KDC_ERR_NEVER_VALID is returned. If the requested 1312 expiration time for the ticket exceeds what was determined as above, 1313 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1315 and if the 'RENEWABLE-OK' option was requested, then the 'RENEWABLE' 1316 flag is set in the new ticket, and the renew-till value is set as if 1317 the 'RENEWABLE' option were requested (the field and option names are 1318 described fully in section 5.4.1). 1320 If the RENEWABLE option has been requested or if the RENEWABLE-OK 1321 option has been set and a renewable ticket is to be issued, then the 1322 renew-till field MAY be set to the earliest of: 1324 * Its requested value. 1326 * The start time of the ticket plus the minimum of the two 1327 maximum renewable lifetimes associated with the principals' 1328 database entries. 1330 * The start time of the ticket plus the maximum renewable 1331 lifetime set by the policy of the local realm. 1333 The flags field of the new ticket will have the following options set 1334 if they have been requested and if the policy of the local realm 1335 allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. 1336 If the new ticket is postdated (the start time is in the future), its 1337 INVALID flag will also be set. 1339 If all of the above succeed, the server will encrypt the ciphertext 1340 part of the ticket using the encryption key extracted from the server 1341 principal's record in the Kerberos database using the encryption type 1342 associated with the server principal's key (this choice is NOT 1343 affected by the etype field in the request). It then formats a 1344 KRB_AS_REP message (see section 5.4.2), copying the addresses in the 1345 request into the caddr of the response, placing any required pre- 1346 authentication data into the padata of the response, and encrypts the 1347 ciphertext part in the client's key using an acceptable encryption 1348 method requested in the etype field of the request, or in some key 1349 specified by pre-authentication mechanisms being used. 1351 3.1.4. Generation of KRB_ERROR message 1353 Several errors can occur, and the Authentication Server responds 1354 by returning an error message, KRB_ERROR, to the client, with the 1355 error-code and e-text fields set to appropriate values. The error 1356 message contents and details are described in Section 5.9.1. 1358 3.1.5. Receipt of KRB_AS_REP message 1360 If the reply message type is KRB_AS_REP, then the client verifies 1361 that the cname and crealm fields in the cleartext portion of the 1362 reply match what it requested. If any padata fields are present, 1363 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1365 they may be used to derive the proper secret key to decrypt the 1366 message. The client decrypts the encrypted part of the response 1367 using its secret key, verifies that the nonce in the encrypted 1368 part matches the nonce it supplied in its request (to detect 1369 replays). It also verifies that the sname and srealm in the 1370 response match those in the request (or are otherwise expected 1371 values), and that the host address field is also correct. It then 1372 stores the ticket, session key, start and expiration times, and 1373 other information for later use. The last-req field (and the 1374 deprecated key-expiration field) from the encrypted part of the 1375 response MAY be checked to notify the user of impending key 1376 expiration. This enables the client program to suggest remedial 1377 action, such as a password change. 1379 Upon validation of the KRB_AS_REP message (by checking the 1380 returned nonce against that sent in the KRB_AS_REQ message) the 1381 client knows that the current time on the KDC is that read from 1382 the authtime field of the encrypted part of the reply. The client 1383 can optionally use this value for clock synchronization in 1384 subsequent messages by recording with the ticket the difference 1385 (offset) between the authtime value and the local clock. This 1386 offset can then be used by the same user to adjust the time read 1387 from the system clock when generating messages [DGT96]. 1389 This technique MUST be used when adjusting for clock skew instead 1390 of directly changing the system clock because the KDC reply is 1391 only authenticated to the user whose secret key was used, but not 1392 to the system or workstation. If the clock were adjusted, an 1393 attacker colluding with a user logging into a workstation could 1394 agree on a password, resulting in a KDC reply that would be 1395 correctly validated even though it did not originate from a KDC 1396 trusted by the workstation. 1398 Proper decryption of the KRB_AS_REP message is not sufficient for 1399 the host to verify the identity of the user; the user and an 1400 attacker could cooperate to generate a KRB_AS_REP format message 1401 which decrypts properly but is not from the proper KDC. If the 1402 host wishes to verify the identity of the user, it MUST require 1403 the user to present application credentials which can be verified 1404 using a securely-stored secret key for the host. If those 1405 credentials can be verified, then the identity of the user can be 1406 assured. 1408 3.1.6. Receipt of KRB_ERROR message 1410 If the reply message type is KRB_ERROR, then the client interprets 1411 it as an error and performs whatever application-specific tasks 1412 are necessary to recover. 1414 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1416 3.2. The Client/Server Authentication Exchange 1418 Summary 1419 Message direction Message type Section 1420 Client to Application server KRB_AP_REQ 5.5.1 1421 [optional] Application server to client KRB_AP_REP or 5.5.2 1422 KRB_ERROR 5.9.1 1424 The client/server authentication (CS) exchange is used by network 1425 applications to authenticate the client to the server and vice 1426 versa. The client MUST have already acquired credentials for the 1427 server using the AS or TGS exchange. 1429 3.2.1. The KRB_AP_REQ message 1431 The KRB_AP_REQ contains authentication information which SHOULD be 1432 part of the first message in an authenticated transaction. It 1433 contains a ticket, an authenticator, and some additional 1434 bookkeeping information (see section 5.5.1 for the exact format). 1435 The ticket by itself is insufficient to authenticate a client, 1436 since tickets are passed across the network in cleartext[8], so 1437 the authenticator is used to prevent invalid replay of tickets by 1438 proving to the server that the client knows the session key of the 1439 ticket and thus is entitled to use the ticket. The KRB_AP_REQ 1440 message is referred to elsewhere as the 'authentication header.' 1442 3.2.2. Generation of a KRB_AP_REQ message 1444 When a client wishes to initiate authentication to a server, it 1445 obtains (either through a credentials cache, the AS exchange, or 1446 the TGS exchange) a ticket and session key for the desired 1447 service. The client MAY re-use any tickets it holds until they 1448 expire. To use a ticket the client constructs a new Authenticator 1449 from the system time, its name, and optionally an application 1450 specific checksum, an initial sequence number to be used in 1451 KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used 1452 in negotiations for a session key unique to this particular 1453 session. Authenticators MAY NOT be re-used and SHOULD be rejected 1454 if replayed to a server[9]. If a sequence number is to be 1455 included, it SHOULD be randomly chosen so that even after many 1456 messages have been exchanged it is not likely to collide with 1457 other sequence numbers in use. 1459 The client MAY indicate a requirement of mutual authentication or 1460 the use of a session-key based ticket (for user-to-user 1461 authentication - see section 3.7) by setting the appropriate 1462 flag(s) in the ap-options field of the message. 1464 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1466 The Authenticator is encrypted in the session key and combined 1467 with the ticket to form the KRB_AP_REQ message which is then sent 1468 to the end server along with any additional application-specific 1469 information. 1471 3.2.3. Receipt of KRB_AP_REQ message 1473 Authentication is based on the server's current time of day 1474 (clocks MUST be loosely synchronized), the authenticator, and the 1475 ticket. Several errors are possible. If an error occurs, the 1476 server is expected to reply to the client with a KRB_ERROR 1477 message. This message MAY be encapsulated in the application 1478 protocol if its raw form is not acceptable to the protocol. The 1479 format of error messages is described in section 5.9.1. 1481 The algorithm for verifying authentication information is as 1482 follows. If the message type is not KRB_AP_REQ, the server returns 1483 the KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the 1484 Ticket in the KRB_AP_REQ is not one the server can use (e.g., it 1485 indicates an old key, and the server no longer possesses a copy of 1486 the old key), the KRB_AP_ERR_BADKEYVER error is returned. If the 1487 USE-SESSION-KEY flag is set in the ap-options field, it indicates 1488 to the server that user-to-user authentication is in use, and that 1489 the ticket is encrypted in the session key from the server's 1490 ticket-granting ticket rather than in the server's secret key. See 1491 section 3.7 for a more complete description of the effect of user- 1492 to-user authentication on all messages in the Kerberos protocol. 1494 Since it is possible for the server to be registered in multiple 1495 realms, with different keys in each, the srealm field in the 1496 unencrypted portion of the ticket in the KRB_AP_REQ is used to 1497 specify which secret key the server should use to decrypt that 1498 ticket. The KRB_AP_ERR_NOKEY error code is returned if the server 1499 doesn't have the proper key to decipher the ticket. 1501 The ticket is decrypted using the version of the server's key 1502 specified by the ticket. If the decryption routines detect a 1503 modification of the ticket (each encryption system MUST provide 1504 safeguards to detect modified ciphertext), the 1505 KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that 1506 different keys were used to encrypt and decrypt). 1508 The authenticator is decrypted using the session key extracted 1509 from the decrypted ticket. If decryption shows it to have been 1510 modified, the KRB_AP_ERR_BAD_INTEGRITY error is returned. The name 1511 and realm of the client from the ticket are compared against the 1512 same fields in the authenticator. If they don't match, the 1513 KRB_AP_ERR_BADMATCH error is returned; this normally is caused by 1514 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1516 a client error or attempted attack. The addresses in the ticket 1517 (if any) are then searched for an address matching the operating- 1518 system reported address of the client. If no match is found or the 1519 server insists on ticket addresses but none are present in the 1520 ticket, the KRB_AP_ERR_BADADDR error is returned. If the local 1521 (server) time and the client time in the authenticator differ by 1522 more than the allowable clock skew (e.g., 5 minutes), the 1523 KRB_AP_ERR_SKEW error is returned. 1525 Unless the application server provides its own suitable means to 1526 protect against replay (for example, a challenge-response sequence 1527 initiated by the server after authentication, or use of a server- 1528 generated encryption subkey), the server MUST utilize a replay 1529 cache to remember any authenticator presented within the allowable 1530 clock skew. Careful analysis of the application protocol and 1531 implementation is recommended before eliminating this cache. The 1532 replay cache will store at least the server name, along with the 1533 client name, time and microsecond fields from the recently-seen 1534 authenticators and if a matching tuple is found, the 1535 KRB_AP_ERR_REPEAT error is returned [10]. If a server loses track 1536 of authenticators presented within the allowable clock skew, it 1537 MUST reject all requests until the clock skew interval has passed, 1538 providing assurance that any lost or replayed authenticators will 1539 fall outside the allowable clock skew and can no longer be 1540 successfully replayed [11]. 1542 Implementation note: If a client generates multiple requests to 1543 the KDC with the same timestamp, including the microsecond field, 1544 all but the first of the requests received will be rejected as 1545 replays. This might happen, for example, if the resolution of the 1546 client's clock is too coarse. Client implementations SHOULD 1547 ensure that the timestamps are not reused, possibly by 1548 incrementing the microseconds field in the time stamp when the 1549 clock returns the same time for multiple requests. 1551 If multiple servers (for example, different services on one 1552 machine, or a single service implemented on multiple machines) 1553 share a service principal (a practice we do not recommend in 1554 general, but acknowledge will be used in some cases), they MUST 1555 either share this replay cache, or the application protocol MUST 1556 be designed so as to eliminate the need for it. Note that this 1557 applies to all of the services, if any of the application 1558 protocols does not have replay protection built in; an 1559 authenticator used with such a service could later be replayed to 1560 a different service with the same service principal but no replay 1561 protection, if the former doesn't record the authenticator 1562 information in the common replay cache. 1564 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1566 If a sequence number is provided in the authenticator, the server 1567 saves it for later use in processing KRB_SAFE and/or KRB_PRIV 1568 messages. If a subkey is present, the server either saves it for 1569 later use or uses it to help generate its own choice for a subkey 1570 to be returned in a KRB_AP_REP message. 1572 The server computes the age of the ticket: local (server) time 1573 minus the start time inside the Ticket. If the start time is later 1574 than the current time by more than the allowable clock skew or if 1575 the INVALID flag is set in the ticket, the KRB_AP_ERR_TKT_NYV 1576 error is returned. Otherwise, if the current time is later than 1577 end time by more than the allowable clock skew, the 1578 KRB_AP_ERR_TKT_EXPIRED error is returned. 1580 If all these checks succeed without an error, the server is 1581 assured that the client possesses the credentials of the principal 1582 named in the ticket and thus, the client has been authenticated to 1583 the server. 1585 Passing these checks provides only authentication of the named 1586 principal; it does not imply authorization to use the named 1587 service. Applications MUST make a separate authorization decision 1588 based upon the authenticated name of the user, the requested 1589 operation, local access control information such as that contained 1590 in a .k5login or .k5users file, and possibly a separate 1591 distributed authorization service. 1593 3.2.4. Generation of a KRB_AP_REP message 1595 Typically, a client's request will include both the authentication 1596 information and its initial request in the same message, and the 1597 server need not explicitly reply to the KRB_AP_REQ. However, if 1598 mutual authentication (not only authenticating the client to the 1599 server, but also the server to the client) is being performed, the 1600 KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options 1601 field, and a KRB_AP_REP message is required in response. As with 1602 the error message, this message MAY be encapsulated in the 1603 application protocol if its "raw" form is not acceptable to the 1604 application's protocol. The timestamp and microsecond field used 1605 in the reply MUST be the client's timestamp and microsecond field 1606 (as provided in the authenticator) [12]. If a sequence number is 1607 to be included, it SHOULD be randomly chosen as described above 1608 for the authenticator. A subkey MAY be included if the server 1609 desires to negotiate a different subkey. The KRB_AP_REP message is 1610 encrypted in the session key extracted from the ticket. 1612 3.2.5. Receipt of KRB_AP_REP message 1613 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1615 If a KRB_AP_REP message is returned, the client uses the session 1616 key from the credentials obtained for the server [13] to decrypt 1617 the message, and verifies that the timestamp and microsecond 1618 fields match those in the Authenticator it sent to the server. If 1619 they match, then the client is assured that the server is genuine. 1620 The sequence number and subkey (if present) are retained for later 1621 use. 1623 3.2.6. Using the encryption key 1625 After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client 1626 and server share an encryption key which can be used by the 1627 application. In some cases, the use of this session key will be 1628 implicit in the protocol; in others the method of use must be 1629 chosen from several alternatives. The actual encryption key to be 1630 used for KRB_PRIV, KRB_SAFE, or other application-specific uses 1631 MAY be chosen by the application based on the session key from the 1632 ticket and subkeys in the KRB_AP_REP message and the authenticator 1633 [14]. To mitigate the effect of failures in random number 1634 generation on the client it is strongly encouraged that any key 1635 derived by an application for subsequent use include the full key 1636 entropy derived from the KDC generated session key carried in the 1637 ticket. We leave the protocol negotiations of how to use the key 1638 (e.g. selecting an encryption or checksum type) to the application 1639 programmer; the Kerberos protocol does not constrain the 1640 implementation options, but an example of how this might be done 1641 follows. 1643 One way that an application may choose to negotiate a key to be 1644 used for subsequent integrity and privacy protection is for the 1645 client to propose a key in the subkey field of the authenticator. 1646 The server can then choose a key using the proposed key from the 1647 client as input, returning the new subkey in the subkey field of 1648 the application reply. This key could then be used for subsequent 1649 communication. 1651 With both the one-way and mutual authentication exchanges, the 1652 peers should take care not to send sensitive information to each 1653 other without proper assurances. In particular, applications that 1654 require privacy or integrity SHOULD use the KRB_AP_REP response 1655 from the server to client to assure both client and server of 1656 their peer's identity. If an application protocol requires privacy 1657 of its messages, it can use the KRB_PRIV message (section 3.5). 1658 The KRB_SAFE message (section 3.4) can be used to assure 1659 integrity. 1661 3.3. The Ticket-Granting Service (TGS) Exchange 1662 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1664 Summary 1665 Message direction Message type Section 1666 1. Client to Kerberos KRB_TGS_REQ 5.4.1 1667 2. Kerberos to client KRB_TGS_REP or 5.4.2 1668 KRB_ERROR 5.9.1 1670 The TGS exchange between a client and the Kerberos Ticket-Granting 1671 Server is initiated by a client when it wishes to obtain 1672 authentication credentials for a given server (which might be 1673 registered in a remote realm), when it wishes to renew or validate 1674 an existing ticket, or when it wishes to obtain a proxy ticket. In 1675 the first case, the client must already have acquired a ticket for 1676 the Ticket-Granting Service using the AS exchange (the ticket- 1677 granting ticket is usually obtained when a client initially 1678 authenticates to the system, such as when a user logs in). The 1679 message format for the TGS exchange is almost identical to that 1680 for the AS exchange. The primary difference is that encryption 1681 and decryption in the TGS exchange does not take place under the 1682 client's key. Instead, the session key from the ticket-granting 1683 ticket or renewable ticket, or sub-session key from an 1684 Authenticator is used. As is the case for all application servers, 1685 expired tickets are not accepted by the TGS, so once a renewable 1686 or ticket-granting ticket expires, the client must use a separate 1687 exchange to obtain valid tickets. 1689 The TGS exchange consists of two messages: A request (KRB_TGS_REQ) 1690 from the client to the Kerberos Ticket-Granting Server, and a 1691 reply (KRB_TGS_REP or KRB_ERROR). The KRB_TGS_REQ message includes 1692 information authenticating the client plus a request for 1693 credentials. The authentication information consists of the 1694 authentication header (KRB_AP_REQ) which includes the client's 1695 previously obtained ticket-granting, renewable, or invalid ticket. 1696 In the ticket-granting ticket and proxy cases, the request MAY 1697 include one or more of: a list of network addresses, a collection 1698 of typed authorization data to be sealed in the ticket for 1699 authorization use by the application server, or additional tickets 1700 (the use of which are described later). The TGS reply 1701 (KRB_TGS_REP) contains the requested credentials, encrypted in the 1702 session key from the ticket-granting ticket or renewable ticket, 1703 or if present, in the sub-session key from the Authenticator (part 1704 of the authentication header). The KRB_ERROR message contains an 1705 error code and text explaining what went wrong. The KRB_ERROR 1706 message is not encrypted. The KRB_TGS_REP message contains 1707 information which can be used to detect replays, and to associate 1708 it with the message to which it replies. The KRB_ERROR message 1709 also contains information which can be used to associate it with 1710 the message to which it replies. The same comments about integrity 1711 protection of KRB_ERROR messages mentioned in section 3.1 apply to 1712 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1714 the TGS exchange. 1716 3.3.1. Generation of KRB_TGS_REQ message 1718 Before sending a request to the ticket-granting service, the 1719 client MUST determine in which realm the application server is 1720 believed to be registered [15]. If the client knows the service 1721 principal name and realm and it does not already possess a ticket- 1722 granting ticket for the appropriate realm, then one must be 1723 obtained. This is first attempted by requesting a ticket-granting 1724 ticket for the destination realm from a Kerberos server for which 1725 the client possesses a ticket-granting ticket (using the 1726 KRB_TGS_REQ message recursively). The Kerberos server MAY return a 1727 TGT for the desired realm in which case one can proceed. 1728 Alternatively, the Kerberos server MAY return a TGT for a realm 1729 which is 'closer' to the desired realm (further along the standard 1730 hierarchical path between the client's realm and the requested 1731 realm server's realm). It should be noted in this case that 1732 misconfiguration of the Kerberos servers may cause loops in the 1733 resulting authentication path, which the client should be careful 1734 to detect and avoid. 1736 If the Kerberos server returns a TGT for a 'closer' realm other 1737 than the desired realm, the client MAY use local policy 1738 configuration to verify that the authentication path used is an 1739 acceptable one. Alternatively, a client MAY choose its own 1740 authentication path, rather than relying on the Kerberos server to 1741 select one. In either case, any policy or configuration 1742 information used to choose or validate authentication paths, 1743 whether by the Kerberos server or client, MUST be obtained from a 1744 trusted source. 1746 When a client obtains a ticket-granting ticket that is 'closer' to 1747 the destination realm, the client MAY cache this ticket and reuse 1748 it in future KRB-TGS exchanges with services in the 'closer' 1749 realm. However, if the client were to obtain a ticket-granting 1750 ticket for the 'closer' realm by starting at the initial KDC 1751 rather than as part of obtaining another ticket, then a shorter 1752 path to the 'closer' realm might be used. This shorter path may be 1753 desirable because fewer intermediate KDCs would know the session 1754 key of the ticket involved. For this reason, clients SHOULD 1755 evaluate whether they trust the realms transited in obtaining the 1756 'closer' ticket when making a decision to use the ticket in 1757 future. 1759 Once the client obtains a ticket-granting ticket for the 1760 appropriate realm, it determines which Kerberos servers serve that 1761 realm, and contacts one. The list might be obtained through a 1762 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1764 configuration file or network service or it MAY be generated from 1765 the name of the realm; as long as the secret keys exchanged by 1766 realms are kept secret, only denial of service results from using 1767 a false Kerberos server. 1769 As in the AS exchange, the client MAY specify a number of options 1770 in the KRB_TGS_REQ message. One of these options is the ENC-TKT- 1771 IN-SKEY option used for user-to-user authentication. An overview 1772 of user-to-user authentication can be found in section 3.7. When 1773 generating the KRB_TGS_REQ message, this option indicates that the 1774 client is including a ticket-granting ticket obtained from the 1775 application server in the additional tickets field of the request 1776 and that the KDC SHOULD encrypt the ticket for the application 1777 server using the session key from this additional ticket, instead 1778 of using a server key from the principal database. 1780 The client prepares the KRB_TGS_REQ message, providing an 1781 authentication header as an element of the padata field, and 1782 including the same fields as used in the KRB_AS_REQ message along 1783 with several optional fields: the enc-authorizatfion-data field 1784 for application server use and additional tickets required by some 1785 options. 1787 In preparing the authentication header, the client can select a 1788 sub-session key under which the response from the Kerberos server 1789 will be encrypted [16]. If the sub-session key is not specified, 1790 the session key from the ticket-granting ticket will be used. If 1791 the enc-authorization-data is present, it MUST be encrypted in the 1792 sub-session key, if present, from the authenticator portion of the 1793 authentication header, or if not present, using the session key 1794 from the ticket-granting ticket. 1796 Once prepared, the message is sent to a Kerberos server for the 1797 destination realm. 1799 3.3.2. Receipt of KRB_TGS_REQ message 1801 The KRB_TGS_REQ message is processed in a manner similar to the 1802 KRB_AS_REQ message, but there are many additional checks to be 1803 performed. First, the Kerberos server MUST determine which server 1804 the accompanying ticket is for and it MUST select the appropriate 1805 key to decrypt it. For a normal KRB_TGS_REQ message, it will be 1806 for the ticket granting service, and the TGS's key will be used. 1807 If the TGT was issued by another realm, then the appropriate 1808 inter-realm key MUST be used. If the accompanying ticket is not a 1809 ticket-granting ticket for the current realm, but is for an 1810 application server in the current realm, the RENEW, VALIDATE, or 1811 PROXY options are specified in the request, and the server for 1812 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1814 which a ticket is requested is the server named in the 1815 accompanying ticket, then the KDC will decrypt the ticket in the 1816 authentication header using the key of the server for which it was 1817 issued. If no ticket can be found in the padata field, the 1818 KDC_ERR_PADATA_TYPE_NOSUPP error is returned. 1820 Once the accompanying ticket has been decrypted, the user-supplied 1821 checksum in the Authenticator MUST be verified against the 1822 contents of the request, and the message rejected if the checksums 1823 do not match (with an error code of KRB_AP_ERR_MODIFIED) or if the 1824 checksum is not collision-proof (with an error code of 1825 KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported, 1826 the KDC_ERR_SUMTYPE_NOSUPP error is returned. If the 1827 authorization-data are present, they are decrypted using the sub- 1828 session key from the Authenticator. 1830 If any of the decryptions indicate failed integrity checks, the 1831 KRB_AP_ERR_BAD_INTEGRITY error is returned. 1833 As discussed in section 3.1.2, the KDC MUST send a valid 1834 KRB_TGS_REP message if it receives a KRB_TGS_REQ message identical 1835 to one it has recently processed. However, if the authenticator is 1836 a replay, but the rest of the request is not identical, then the 1837 KDC SHOULD return KRB_AP_ERR_REPEAT. 1839 3.3.3. Generation of KRB_TGS_REP message 1841 The KRB_TGS_REP message shares its format with the KRB_AS_REP 1842 (KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The 1843 detailed specification is in section 5.4.2. 1845 The response will include a ticket for the requested server or for 1846 a ticket granting server of an intermediate KDC to be contacted to 1847 obtain the requested ticket. The Kerberos database is queried to 1848 retrieve the record for the appropriate server (including the key 1849 with which the ticket will be encrypted). If the request is for a 1850 ticket-granting ticket for a remote realm, and if no key is shared 1851 with the requested realm, then the Kerberos server will select the 1852 realm 'closest' to the requested realm with which it does share a 1853 key, and use that realm instead. This is the only case where the 1854 response for the KDC will be for a different server than that 1855 requested by the client. 1857 By default, the address field, the client's name and realm, the 1858 list of transited realms, the time of initial authentication, the 1859 expiration time, and the authorization data of the newly-issued 1860 ticket will be copied from the ticket-granting ticket (TGT) or 1861 renewable ticket. If the transited field needs to be updated, but 1862 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1864 the transited type is not supported, the KDC_ERR_TRTYPE_NOSUPP 1865 error is returned. 1867 If the request specifies an endtime, then the endtime of the new 1868 ticket is set to the minimum of (a) that request, (b) the endtime 1869 from the TGT, and (c) the starttime of the TGT plus the minimum of 1870 the maximum life for the application server and the maximum life 1871 for the local realm (the maximum life for the requesting principal 1872 was already applied when the TGT was issued). If the new ticket is 1873 to be a renewal, then the endtime above is replaced by the minimum 1874 of (a) the value of the renew_till field of the ticket and (b) the 1875 starttime for the new ticket plus the life (endtime-starttime) of 1876 the old ticket. 1878 If the FORWARDED option has been requested, then the resulting 1879 ticket will contain the addresses specified by the client. This 1880 option will only be honored if the FORWARDABLE flag is set in the 1881 TGT. The PROXY option is similar; the resulting ticket will 1882 contain the addresses specified by the client. It will be honored 1883 only if the PROXIABLE flag in the TGT is set. The PROXY option 1884 will not be honored on requests for additional ticket-granting 1885 tickets. 1887 If the requested start time is absent, indicates a time in the 1888 past, or is within the window of acceptable clock skew for the KDC 1889 and the POSTDATE option has not been specified, then the start 1890 time of the ticket is set to the authentication server's current 1891 time. If it indicates a time in the future beyond the acceptable 1892 clock skew, but the POSTDATED option has not been specified or the 1893 MAY-POSTDATE flag is not set in the TGT, then the error 1894 KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the ticket- 1895 granting ticket has the MAY-POSTDATE flag set, then the resulting 1896 ticket will be postdated and the requested starttime is checked 1897 against the policy of the local realm. If acceptable, the ticket's 1898 start time is set as requested, and the INVALID flag is set. The 1899 postdated ticket MUST be validated before use by presenting it to 1900 the KDC after the starttime has been reached. However, in no case 1901 may the starttime, endtime, or renew-till time of a newly-issued 1902 postdated ticket extend beyond the renew-till time of the ticket- 1903 granting ticket. 1905 If the ENC-TKT-IN-SKEY option has been specified and an additional 1906 ticket has been included in the request, it indicates that the 1907 client is using user- to-user authentication to prove its identity 1908 to a server that does not have access to a persistent key. Section 1909 3.7 describes the affect of this option on the entire Kerberos 1910 protocol. When generating the KRB_TGS_REP message, this option in 1911 the KRB_TGS_REQ message tells the KDC to decrypt the additional 1912 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1914 ticket using the key for the server to which the additional ticket 1915 was issued and verify that it is a ticket-granting ticket. If the 1916 name of the requested server is missing from the request, the name 1917 of the client in the additional ticket will be used. Otherwise the 1918 name of the requested server will be compared to the name of the 1919 client in the additional ticket and if different, the request will 1920 be rejected. If the request succeeds, the session key from the 1921 additional ticket will be used to encrypt the new ticket that is 1922 issued instead of using the key of the server for which the new 1923 ticket will be used. 1925 If the name of the server in the ticket that is presented to the 1926 KDC as part of the authentication header is not that of the 1927 ticket-granting server itself, the server is registered in the 1928 realm of the KDC, and the RENEW option is requested, then the KDC 1929 will verify that the RENEWABLE flag is set in the ticket, that the 1930 INVALID flag is not set in the ticket, and that the renew_till 1931 time is still in the future. If the VALIDATE option is requested, 1932 the KDC will check that the starttime has passed and the INVALID 1933 flag is set. If the PROXY option is requested, then the KDC will 1934 check that the PROXIABLE flag is set in the ticket. If the tests 1935 succeed, and the ticket passes the hotlist check described in the 1936 next section, the KDC will issue the appropriate new ticket. 1938 The ciphertext part of the response in the KRB_TGS_REP message is 1939 encrypted in the sub-session key from the Authenticator, if 1940 present, or the session key from the ticket-granting ticket. It is 1941 not encrypted using the client's secret key. Furthermore, the 1942 client's key's expiration date and the key version number fields 1943 are left out since these values are stored along with the client's 1944 database record, and that record is not needed to satisfy a 1945 request based on a ticket-granting ticket. 1947 3.3.3.1. Checking for revoked tickets 1949 Whenever a request is made to the ticket-granting server, the 1950 presented ticket(s) is(are) checked against a hot-list of tickets 1951 which have been canceled. This hot-list might be implemented by 1952 storing a range of issue timestamps for 'suspect tickets'; if a 1953 presented ticket had an authtime in that range, it would be 1954 rejected. In this way, a stolen ticket-granting ticket or 1955 renewable ticket cannot be used to gain additional tickets 1956 (renewals or otherwise) once the theft has been reported to the 1957 KDC for the realm in which the server resides. Any normal ticket 1958 obtained before it was reported stolen will still be valid 1959 (because they require no interaction with the KDC), but only until 1960 their normal expiration time. If TGT's have been issued for cross- 1961 realm authentication, use of the cross-realm TGT will not be 1962 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 1964 affected unless the hot-list is propagated to the KDCs for the 1965 realms for which such cross-realm tickets were issued. 1967 3.3.3.2. Encoding the transited field 1969 If the identity of the server in the TGT that is presented to the 1970 KDC as part of the authentication header is that of the ticket- 1971 granting service, but the TGT was issued from another realm, the 1972 KDC will look up the inter-realm key shared with that realm and 1973 use that key to decrypt the ticket. If the ticket is valid, then 1974 the KDC will honor the request, subject to the constraints 1975 outlined above in the section describing the AS exchange. The 1976 realm part of the client's identity will be taken from the ticket- 1977 granting ticket. The name of the realm that issued the ticket- 1978 granting ticket, if it is not the realm of the client principal, 1979 will be added to the transited field of the ticket to be issued. 1980 This is accomplished by reading the transited field from the 1981 ticket-granting ticket (which is treated as an unordered set of 1982 realm names), adding the new realm to the set, then constructing 1983 and writing out its encoded (shorthand) form (this may involve a 1984 rearrangement of the existing encoding). 1986 Note that the ticket-granting service does not add the name of its 1987 own realm. Instead, its responsibility is to add the name of the 1988 previous realm. This prevents a malicious Kerberos server from 1989 intentionally leaving out its own name (it could, however, omit 1990 other realms' names). 1992 The names of neither the local realm nor the principal's realm are 1993 to be included in the transited field. They appear elsewhere in 1994 the ticket and both are known to have taken part in authenticating 1995 the principal. Since the endpoints are not included, both local 1996 and single-hop inter-realm authentication result in a transited 1997 field that is empty. 1999 Because the name of each realm transited is added to this field, 2000 it might potentially be very long. To decrease the length of this 2001 field, its contents are encoded. The initially supported encoding 2002 is optimized for the normal case of inter-realm communication: a 2003 hierarchical arrangement of realms using either domain or X.500 2004 style realm names. This encoding (called DOMAIN-X500-COMPRESS) is 2005 now described. 2007 Realm names in the transited field are separated by a ",". The 2008 ",", "\", trailing "."s, and leading spaces (" ") are special 2009 characters, and if they are part of a realm name, they MUST be 2010 quoted in the transited field by preceding them with a "\". 2012 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2014 A realm name ending with a "." is interpreted as being prepended 2015 to the previous realm. For example, we can encode traversal of 2016 EDU, MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, and 2017 CS.WASHINGTON.EDU as: 2019 "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". 2021 Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, 2022 that they would not be included in this field, and we would have: 2024 "EDU,MIT.,WASHINGTON.EDU" 2026 A realm name beginning with a "/" is interpreted as being appended 2027 to the previous realm. For the purpose of appending, the realm 2028 preceding the first listed realm is considered to be the null 2029 realm (""). If a realm name beginning with a "/" is to stand by 2030 itself, then it SHOULD be preceded by a space (" "). For example, 2031 we can encode traversal of /COM/HP/APOLLO, /COM/HP, /COM, and 2032 /COM/DEC as: 2034 "/COM,/HP,/APOLLO, /COM/DEC". 2036 Like the example above, if /COM/HP/APOLLO and /COM/DEC are 2037 endpoints, they would not be included in this field, and we would 2038 have: 2040 "/COM,/HP" 2042 A null subfield preceding or following a "," indicates that all 2043 realms between the previous realm and the next realm have been 2044 traversed. For the purpose of interpreting null subfields, the 2045 client's realm is considered to precede those in the transited 2046 field, and the server's realm is considered to follow them. Thus, 2047 "," means that all realms along the path between the client and 2048 the server have been traversed. ",EDU, /COM," means that all 2049 realms from the client's realm up to EDU (in a domain style 2050 hierarchy) have been traversed, and that everything from /COM down 2051 to the server's realm in an X.500 style has also been traversed. 2052 This could occur if the EDU realm in one hierarchy shares an 2053 inter-realm key directly with the /COM realm in another hierarchy. 2055 3.3.4. Receipt of KRB_TGS_REP message 2057 When the KRB_TGS_REP is received by the client, it is processed in 2058 the same manner as the KRB_AS_REP processing described above. The 2059 primary difference is that the ciphertext part of the response 2060 must be decrypted using the sub-session key from the 2061 Authenticator, if it was specified in the request, or the session 2062 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2064 key from the ticket-granting ticket, rather than the client's 2065 secret key. The server name returned in the reply is the true 2066 principal name of the service. 2068 3.4. The KRB_SAFE Exchange 2070 The KRB_SAFE message MAY be used by clients requiring the ability 2071 to detect modifications of messages they exchange. It achieves 2072 this by including a keyed collision-proof checksum of the user 2073 data and some control information. The checksum is keyed with an 2074 encryption key (usually the last key negotiated via subkeys, or 2075 the session key if no negotiation has occurred). 2077 3.4.1. Generation of a KRB_SAFE message 2079 When an application wishes to send a KRB_SAFE message, it collects 2080 its data and the appropriate control information and computes a 2081 checksum over them. The checksum algorithm should be the keyed 2082 checksum mandated to be implemented along with the crypto system 2083 used for the sub-session or session key. The checksum is generated 2084 using the sub-session key if present or the session key. Some 2085 implementations use a different checksum algorithm for the 2086 KRB_SAFE messages but doing so in a interoperable manner is not 2087 always possible. 2089 The control information for the KRB_SAFE message includes both a 2090 timestamp and a sequence number. The designer of an application 2091 using the KRB_SAFE message MUST choose at least one of the two 2092 mechanisms. This choice SHOULD be based on the needs of the 2093 application protocol. 2095 Sequence numbers are useful when all messages sent will be 2096 received by one's peer. Connection state is presently required to 2097 maintain the session key, so maintaining the next sequence number 2098 should not present an additional problem. 2100 If the application protocol is expected to tolerate lost messages 2101 without them being resent, the use of the timestamp is the 2102 appropriate replay detection mechanism. Using timestamps is also 2103 the appropriate mechanism for multi-cast protocols where all of 2104 one's peers share a common sub-session key, but some messages will 2105 be sent to a subset of one's peers. 2107 After computing the checksum, the client then transmits the 2108 information and checksum to the recipient in the message format 2109 specified in section 5.6.1. 2111 3.4.2. Receipt of KRB_SAFE message 2112 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2114 When an application receives a KRB_SAFE message, it verifies it as 2115 follows. If any error occurs, an error code is reported for use 2116 by the application. 2118 The message is first checked by verifying that the protocol 2119 version and type fields match the current version and KRB_SAFE, 2120 respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or 2121 KRB_AP_ERR_MSG_TYPE error. The application verifies that the 2122 checksum used is a collision-proof keyed checksum that uses keys 2123 compatible with the sub-session or session key as appropriate (or 2124 with the application key derived from the session or sub-session 2125 keys), and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is 2126 generated. The sender's address MUST be included in the control 2127 information; the recipient verifies that the operating system's 2128 report of the sender's address matches the sender's address in the 2129 message, and (if a recipient address is specified or the recipient 2130 requires an address) that one of the recipient's addresses appears 2131 as the recipient's address in the message. To work with network 2132 address translation, senders MAY use the directional address type 2133 specified in section 8.1 for the sender address and not include 2134 recipient addresses. A failed match for either case generates a 2135 KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the 2136 sequence number fields are checked. If timestamp and usec are 2137 expected and not present, or they are present but not current, the 2138 KRB_AP_ERR_SKEW error is generated. Timestamps are not required to 2139 be strictly ordered; they are only required to be in the skew 2140 window. If the server name, along with the client name, time and 2141 microsecond fields from the Authenticator match any recently-seen 2142 (sent or received) such tuples, the KRB_AP_ERR_REPEAT error is 2143 generated. If an incorrect sequence number is included, or a 2144 sequence number is expected but not present, the 2145 KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp 2146 and usec or a sequence number is present, a KRB_AP_ERR_MODIFIED 2147 error is generated. Finally, the checksum is computed over the 2148 data and control information, and if it doesn't match the received 2149 checksum, a KRB_AP_ERR_MODIFIED error is generated. 2151 If all the checks succeed, the application is assured that the 2152 message was generated by its peer and was not modified in transit. 2154 Implementations SHOULD accept any checksum algorithm they 2155 implement that both have adequate security and that have keys 2156 compatible with the sub-session or session key. Unkeyed or non- 2157 collision-proof checksums are not suitable for this use. 2159 3.5. The KRB_PRIV Exchange 2161 The KRB_PRIV message MAY be used by clients requiring 2162 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2164 confidentiality and the ability to detect modifications of 2165 exchanged messages. It achieves this by encrypting the messages 2166 and adding control information. 2168 3.5.1. Generation of a KRB_PRIV message 2170 When an application wishes to send a KRB_PRIV message, it collects 2171 its data and the appropriate control information (specified in 2172 section 5.7.1) and encrypts them under an encryption key (usually 2173 the last key negotiated via subkeys, or the session key if no 2174 negotiation has occurred). As part of the control information, the 2175 client MUST choose to use either a timestamp or a sequence number 2176 (or both); see the discussion in section 3.4.1 for guidelines on 2177 which to use. After the user data and control information are 2178 encrypted, the client transmits the ciphertext and some 'envelope' 2179 information to the recipient. 2181 3.5.2. Receipt of KRB_PRIV message 2183 When an application receives a KRB_PRIV message, it verifies it as 2184 follows. If any error occurs, an error code is reported for use 2185 by the application. 2187 The message is first checked by verifying that the protocol 2188 version and type fields match the current version and KRB_PRIV, 2189 respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or 2190 KRB_AP_ERR_MSG_TYPE error. The application then decrypts the 2191 ciphertext and processes the resultant plaintext. If decryption 2192 shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY 2193 error is generated. 2195 The sender's address MUST be included in the control information; 2196 the recipient verifies that the operating system's report of the 2197 sender's address matches the sender's address in the message. If 2198 a recipient address is specified or the recipient requires an 2199 address then one of the recipient's addresses MUST also appear as 2200 the recipient's address in the message. Where a sender's or 2201 receiver's address might not otherwise match the address in a 2202 message because of network address translation, an application MAY 2203 be written to use addresses of the directional address type in 2204 place of the actual network address. 2206 A failed match for either case generates a KRB_AP_ERR_BADADDR 2207 error. To work with network address translation, implementations 2208 MAY use the directional address type defined in section 7.1 for 2209 the sender address and include no recipient address. 2211 Then the timestamp and usec and/or the sequence number fields are 2212 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2214 checked. If timestamp and usec are expected and not present, or 2215 they are present but not current, the KRB_AP_ERR_SKEW error is 2216 generated. If the server name, along with the client name, time 2217 and microsecond fields from the Authenticator match any recently- 2218 seen such tuples, the KRB_AP_ERR_REPEAT error is generated. If an 2219 incorrect sequence number is included, or a sequence number is 2220 expected but not present, the KRB_AP_ERR_BADORDER error is 2221 generated. If neither a time-stamp and usec or a sequence number 2222 is present, a KRB_AP_ERR_MODIFIED error is generated. 2224 If all the checks succeed, the application can assume the message 2225 was generated by its peer, and was securely transmitted (without 2226 intruders able to see the unencrypted contents). 2228 3.6. The KRB_CRED Exchange 2230 The KRB_CRED message MAY be used by clients requiring the ability 2231 to send Kerberos credentials from one host to another. It achieves 2232 this by sending the tickets together with encrypted data 2233 containing the session keys and other information associated with 2234 the tickets. 2236 3.6.1. Generation of a KRB_CRED message 2238 When an application wishes to send a KRB_CRED message it first 2239 (using the KRB_TGS exchange) obtains credentials to be sent to the 2240 remote host. It then constructs a KRB_CRED message using the 2241 ticket or tickets so obtained, placing the session key needed to 2242 use each ticket in the key field of the corresponding KrbCredInfo 2243 sequence of the encrypted part of the KRB_CRED message. 2245 Other information associated with each ticket and obtained during 2246 the KRB_TGS exchange is also placed in the corresponding 2247 KrbCredInfo sequence in the encrypted part of the KRB_CRED 2248 message. The current time and, if specifically required by the 2249 application the nonce, s-address, and r-address fields, are placed 2250 in the encrypted part of the KRB_CRED message which is then 2251 encrypted under an encryption key previously exchanged in the 2252 KRB_AP exchange (usually the last key negotiated via subkeys, or 2253 the session key if no negotiation has occurred). 2255 Implementation note: When constructing a KRB_CRED message for 2256 inclusion in a GSSAPI initial context token, the MIT 2257 implementation of Kerberos will not encrypt the KRB_CRED message 2258 if the session key is a DES or triple DES key. For 2259 interoperability with MIT, the Microsoft implementation will not 2260 encrypt the KRB_CRED in a GSSAPI token if it is using a DES 2261 session key. Starting at version 1.2.5, MIT Kerberos can receive 2262 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2264 and decode either encrypted or unencrypted KRB_CRED tokens in the 2265 GSSAPI exchange. The Heimdal implementation of Kerberos can also 2266 accept either encrypted or unencrypted KRB_CRED messages. Since 2267 the KRB_CRED message in a GSSAPI token is encrypted in the 2268 authenticator, the MIT behavior does not present a security 2269 problem, although it is a violation of the Kerberos specification. 2271 3.6.2. Receipt of KRB_CRED message 2273 When an application receives a KRB_CRED message, it verifies it. 2274 If any error occurs, an error code is reported for use by the 2275 application. The message is verified by checking that the protocol 2276 version and type fields match the current version and KRB_CRED, 2277 respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or 2278 KRB_AP_ERR_MSG_TYPE error. The application then decrypts the 2279 ciphertext and processes the resultant plaintext. If decryption 2280 shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY 2281 error is generated. 2283 If present or required, the recipient MAY verify that the 2284 operating system's report of the sender's address matches the 2285 sender's address in the message, and that one of the recipient's 2286 addresses appears as the recipient's address in the message. The 2287 address check does not provide any added security, since the 2288 address if present has already been checked in the KRB_AP_REQ 2289 message and there is not any benefit to be gained by an attacker 2290 in reflecting a KRB_CRED message back to its originator. Thus, the 2291 recipient MAY ignore the address even if present in order to work 2292 better in NAT environments. A failed match for either case 2293 generates a KRB_AP_ERR_BADADDR error. Recipients MAY skip the 2294 address check as the KRB_CRED message cannot generally be 2295 reflected back to the originator. The timestamp and usec fields 2296 (and the nonce field if required) are checked next. If the 2297 timestamp and usec are not present, or they are present but not 2298 current, the KRB_AP_ERR_SKEW error is generated. 2300 If all the checks succeed, the application stores each of the new 2301 tickets in its credentials cache together with the session key and 2302 other information in the corresponding KrbCredInfo sequence from 2303 the encrypted part of the KRB_CRED message. 2305 3.7. User-to-User Authentication Exchanges 2307 User-to-User authentication provides a method to perform 2308 authentication when the verifier does not have a access to long 2309 term service key. This might be the case when running a server 2310 (for example a window server) as a user on a workstation. In such 2311 cases, the server may have access to the ticket-granting ticket 2312 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2314 obtained when the user logged in to the workstation, but because 2315 the server is running as an unprivileged user it might not have 2316 access to system keys. Similar situations may arise when running 2317 peer-to-peer applications. 2319 Summary 2320 Message direction Message type Sections 2321 0. Message from application server Not Specified 2322 1. Client to Kerberos KRB_TGS_REQ 3.3 + 5.4.1 2323 2. Kerberos to client KRB_TGS_REP or 3.3 + 5.4.2 2324 KRB_ERROR 5.9.1 2325 3. Client to Application server KRB_AP_REQ 3.2 + 5.5.1 2327 To address this problem, the Kerberos protocol allows the client 2328 to request that the ticket issued by the KDC be encrypted using a 2329 session key from a ticket-granting ticket issued to the party that 2330 will verify the authentication. This ticket-granting ticket must 2331 be obtained from the verifier by means of an exchange external to 2332 the Kerberos protocol, usually as part of the application 2333 protocol. This message is shown in the summary above as message 0. 2334 Note that because the ticket-granting ticket is encrypted in the 2335 KDC's secret key, it can not be used for authentication without 2336 possession of the corresponding secret key. Furthermore, because 2337 the verifier does not reveal the corresponding secret key, 2338 providing a copy of the verifier's ticket-granting ticket does not 2339 allow impersonation of the verifier. 2341 Message 0 in the table above represents an application specific 2342 negotiation between the client and server, at the end of which 2343 both have determined that they will use user-to-user 2344 authentication and the client has obtained the server's TGT. 2346 Next, the client includes the server's TGT as an additional ticket 2347 in its KRB_TGS_REQ request to the KDC (message 1 in the table 2348 above) and specifies the ENC-TKT-IN-SKEY option in its request. 2350 If validated according to the instructions in 3.3.3, the 2351 application ticket returned to the client (message 2 in the table 2352 above) will be encrypted using the session key from the additional 2353 ticket and the client will note this when it uses or stores the 2354 application ticket. 2356 When contacting the server using a ticket obtained for user-to- 2357 user authentication (message 3 in the table above), the client 2358 MUST specify the USE-SESSION-KEY flag in the ap-options field. 2359 This tells the application server to use the session key 2360 associated with its ticket-granting ticket to decrypt the server 2361 ticket provided in the application request. 2363 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2365 4. Encryption and Checksum Specifications 2367 The Kerberos protocols described in this document are designed to 2368 encrypt messages of arbitrary sizes, using stream or block 2369 encryption ciphers. Encryption is used to prove the identities of 2370 the network entities participating in message exchanges. The Key 2371 Distribution Center for each realm is trusted by all principals 2372 registered in that realm to store a secret key in confidence. 2373 Proof of knowledge of this secret key is used to verify the 2374 authenticity of a principal. 2376 The KDC uses the principal's secret key (in the AS exchange) or a 2377 shared session key (in the TGS exchange) to encrypt responses to 2378 ticket requests; the ability to obtain the secret key or session 2379 key implies the knowledge of the appropriate keys and the identity 2380 of the KDC. The ability of a principal to decrypt the KDC response 2381 and present a Ticket and a properly formed Authenticator 2382 (generated with the session key from the KDC response) to a 2383 service verifies the identity of the principal; likewise the 2384 ability of the service to extract the session key from the Ticket 2385 and prove its knowledge thereof in a response verifies the 2386 identity of the service. 2388 [@KCRYPTO] defines a framework for defining encryption and 2389 checksum mechanisms for use with Kerberos. It also defines several 2390 such mechanisms, and more may be added in future updates to that 2391 document. 2393 The string-to-key operation provided by [@KCRYPTO] is used to 2394 produce a long-term key for a principal (generally for a user). 2395 The default salt string, if none is provided via pre- 2396 authentication data, is the concatenation of the principal's realm 2397 and name components, in order, with no separators. Unless 2398 otherwise indicated, the default string-to-key opaque parameter 2399 set as defined in [@KCRYPTO] is used. 2401 Encrypted data, keys and checksums are transmitted using the 2402 EncryptedData, EncryptionKey and Checksum data objects defined in 2403 section 5.2.9. The encryption, decryption, and checksum operations 2404 described in this document use the corresponding encryption, 2405 decryption, and get_mic operations described in [@KCRYPTO], with 2406 implicit "specific key" generation using the "key usage" values 2407 specified in the description of each EncryptedData or Checksum 2408 object to vary the key for each operation. Note that in some 2409 cases, the value to be used is dependent on the method of choosing 2410 the key or the context of the message. 2412 Key usages are unsigned 32 bit integers; zero is not permitted. 2414 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2416 The key usage values for encrypting or checksumming Kerberos 2417 messages are indicated in section 5 along with the message 2418 definitions. Key usage values 512-1023 are reserved for uses 2419 internal to a Kerberos implementation. (For example, seeding a 2420 pseudo-random number generator with a value produced by encrypting 2421 something with a session key and a key usage value not used for 2422 any other purpose.) Key usage values between 1024 and 2047 2423 (inclusive) are reserved for application use; applications SHOULD 2424 use even values for encryption and odd values for checksums within 2425 this range. Key usage values are also summarized in a table in 2426 section 7.5.1. 2428 There might exist other documents which define protocols in terms 2429 of the RFC1510 encryption types or checksum types. Such documents 2430 would not know about key usages. In order that these 2431 specifications continue to be meaningful until they are updated, 2432 if no key usage values are specified then key usages 1024 and 1025 2433 must be used to derive keys for encryption and checksums, 2434 respectively (this does not apply to protocols that do their own 2435 encryption independent of this framework, directly using the key 2436 resulting from the Kerberos authentication exchange.) New 2437 protocols defined in terms of the Kerberos encryption and checksum 2438 types SHOULD use their own key usage values. 2440 Unless otherwise indicated, no cipher state chaining is done from 2441 one encryption operation to another. 2443 Implementation note: While not recommended, some application 2444 protocols will continue to use the key data directly, even if only 2445 in currently existing protocol specifications. An implementation 2446 intended to support general Kerberos applications may therefore 2447 need to make key data available, as well as the attributes and 2448 operations described in [@KCRYPTO]. One of the more common 2449 reasons for directly performing encryption is direct control over 2450 negotiation and selection of a "sufficiently strong" encryption 2451 algorithm (in the context of a given application). While Kerberos 2452 does not directly provide a facility for negotiating encryption 2453 types between the application client and server, there are 2454 approaches for using Kerberos to facilitate this negotiation - for 2455 example, a client may request only "sufficiently strong" session 2456 key types from the KDC and expect that any type returned by the 2457 KDC will be understood and supported by the application server. 2459 5. Message Specifications 2461 NOTE: The ASN.1 collected here should be identical to the contents 2462 of Appendix A. In case of conflict, the contents of Appendix A 2463 shall take precedence. 2465 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2467 The Kerberos protocol is defined here in terms of Abstract Syntax 2468 Notation One (ASN.1) [X680], which provides a syntax for 2469 specifying both the abstract layout of protocol messages as well 2470 as their encodings. Implementors not utilizing an existing ASN.1 2471 compiler or support library are cautioned to thoroughly understand 2472 the actual ASN.1 specification to ensure correct implementation 2473 behavior, as there is more complexity in the notation than is 2474 immediately obvious, and some tutorials and guides to ASN.1 are 2475 misleading or erroneous. 2477 Note that in several places, there have been changes here from RFC 2478 1510 that change the abstract types. This is in part to address 2479 widespread assumptions that various implementors have made, in 2480 some cases resulting in unintentional violations of the ASN.1 2481 standard. These are clearly flagged where they occur. The 2482 differences between the abstract types in RFC 1510 and abstract 2483 types in this document can cause incompatible encodings to be 2484 emitted when certain encoding rules, e.g. the Packed Encoding 2485 Rules (PER), are used. This theoretical incompatibility should not 2486 be relevant for Kerberos, since Kerberos explicitly specifies the 2487 use of the Distinguished Encoding Rules (DER). It might be an 2488 issue for protocols wishing to use Kerberos types with other 2489 encoding rules. (This practice is not recommended.) With very few 2490 exceptions (most notably the usages of BIT STRING), the encodings 2491 resulting from using the DER remain identical between the types 2492 defined in RFC 1510 and the types defined in this document. 2494 The type definitions in this section assume an ASN.1 module 2495 definition of the following form: 2497 KerberosV5Spec2 { 2498 iso(1) identified-organization(3) dod(6) internet(1) 2499 security(5) kerberosV5(2) modules(4) krb5spec2(2) 2500 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 2502 -- rest of definitions here 2504 END 2506 This specifies that the tagging context for the module will be 2507 explicit and non-automatic. 2509 Note that in some other publications [RFC1510] [RFC1964], the 2510 "dod" portion of the object identifier is erroneously specified as 2511 having the value "5". In the case of RFC 1964, use of the 2512 "correct" OID value would result in a change in the wire protocol; 2513 therefore, it remains unchanged for now. 2515 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2517 Note that elsewhere in this document, nomenclature for various 2518 message types is inconsistent, but largely follows C language 2519 conventions, including use of underscore (_) characters and all- 2520 caps spelling of names intended to be numeric constants. Also, in 2521 some places, identifiers (especially ones referring to constants) 2522 are written in all-caps in order to distinguish them from 2523 surrounding explanatory text. 2525 The ASN.1 notation does not permit underscores in identifiers, so 2526 in actual ASN.1 definitions, underscores are replaced with hyphens 2527 (-). Additionally, structure member names and defined values in 2528 ASN.1 MUST begin with a lowercase letter, while type names MUST 2529 begin with an uppercase letter. 2531 5.1. Specific Compatibility Notes on ASN.1 2533 For compatibility purposes, implementors should heed the following 2534 specific notes regarding the use of ASN.1 in Kerberos. These notes 2535 do not describe deviations from standard usage of ASN.1. The 2536 purpose of these notes is to instead describe some historical 2537 quirks and non-compliance of various implementations, as well as 2538 historical ambiguities, which, while being valid ASN.1, can lead 2539 to confusion during implementation. 2541 5.1.1. ASN.1 Distinguished Encoding Rules 2543 The encoding of Kerberos protocol messages shall obey the 2544 Distinguished Encoding Rules (DER) of ASN.1 as described in 2545 [X690]. Some implementations (believed to be primarily ones 2546 derived from DCE 1.1 and earlier) are known to use the more 2547 general Basic Encoding Rules (BER); in particular, these 2548 implementations send indefinite encodings of lengths. 2549 Implementations MAY accept such encodings in the interests of 2550 backwards compatibility, though implementors are warned that 2551 decoding fully-general BER is fraught with peril. 2553 5.1.2. Optional Integer Fields 2555 Some implementations do not internally distinguish between an 2556 omitted optional integer value and a transmitted value of zero. 2557 The places in the protocol where this is relevant include various 2558 microseconds fields, nonces, and sequence numbers. Implementations 2559 SHOULD treat omitted optional integer values as having been 2560 transmitted with a value of zero, if the application is expecting 2561 this. 2563 5.1.3. Empty SEQUENCE OF Types 2564 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2566 There are places in the protocol where a message contains a 2567 SEQUENCE OF type as an optional member. This can result in an 2568 encoding that contains an empty SEQUENCE OF encoding. The Kerberos 2569 protocol does not semantically distinguish between an absent 2570 optional SEQUENCE OF type and a present optional but empty 2571 SEQUENCE OF type. Implementations SHOULD NOT send empty SEQUENCE 2572 OF encodings that are marked OPTIONAL, but SHOULD accept them as 2573 being equivalent to an omitted OPTIONAL type. In the ASN.1 syntax 2574 describing Kerberos messages, instances of these problematic 2575 optional SEQUENCE OF types are indicated with a comment. 2577 5.1.4. Unrecognized Tag Numbers 2579 Future revisions to this protocol may include new message types 2580 with different APPLICATION class tag numbers. Such revisions 2581 should protect older implementations by only sending the message 2582 types to parties that are known to understand them, e.g. by means 2583 of a flag bit set by the receiver in a preceding request. In the 2584 interest of robust error handling, implementations SHOULD 2585 gracefully handle receiving a message with an unrecognized tag 2586 anyway, and return an error message if appropriate. 2588 In particular, KDCs SHOULD return KRB_AP_ERR_MSG_TYPE if the 2589 incorrect tag is sent over a TCP transport. The KDCs SHOULD NOT 2590 respond to messages received with an unknown tag over UDP 2591 transport in order to avoid denial of service attacks. For non- 2592 KDC applications, the Kerberos implementation typically indicates 2593 an error to the application which takes appropriate steps based on 2594 the application protocol. 2596 5.1.5. Tag Numbers Greater Than 30 2598 A naive implementation of a DER ASN.1 decoder may experience 2599 problems with ASN.1 tag numbers greater than 30, due to such tag 2600 numbers being encoded using more than one byte. Future revisions 2601 of this protocol may utilize tag numbers greater than 30, and 2602 implementations SHOULD be prepared to gracefully return an error, 2603 if appropriate, if they do not recognize the tag. 2605 5.2. Basic Kerberos Types 2607 This section defines a number of basic types that are potentially 2608 used in multiple Kerberos protocol messages. 2610 5.2.1. KerberosString 2612 The original specification of the Kerberos protocol in RFC 1510 2613 uses GeneralString in numerous places for human-readable string 2614 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2616 data. Historical implementations of Kerberos cannot utilize the 2617 full power of GeneralString. This ASN.1 type requires the use of 2618 designation and invocation escape sequences as specified in 2619 ISO-2022/ECMA-35 [ISO-2022/ECMA-35] to switch character sets, and 2620 the default character set that is designated as G0 is the 2621 ISO-646/ECMA-6 [ISO-646,ECMA-6] International Reference Version 2622 (IRV) (aka U.S. ASCII), which mostly works. 2624 ISO-2022/ECMA-35 defines four character-set code elements (G0..G3) 2625 and two Control-function code elements (C0..C1). DER prohibits the 2626 designation of character sets as any but the G0 and C0 sets. 2627 Unfortunately, this seems to have the side effect of prohibiting 2628 the use of ISO-8859 (ISO Latin) [ISO-8859] character-sets or any 2629 other character-sets that utilize a 96-character set, since it is 2630 prohibited by ISO-2022/ECMA-35 to designate them as the G0 code 2631 element. This side effect is being investigated in the ASN.1 2632 standards community. 2634 In practice, many implementations treat GeneralStrings as if they 2635 were 8-bit strings of whichever character set the implementation 2636 defaults to, without regard for correct usage of character-set 2637 designation escape sequences. The default character set is often 2638 determined by the current user's operating system dependent 2639 locale. At least one major implementation places unescaped UTF-8 2640 encoded Unicode characters in the GeneralString. This failure to 2641 adhere to the GeneralString specifications results in 2642 interoperability issues when conflicting character encodings are 2643 utilized by the Kerberos clients, services, and KDC. 2645 This unfortunate situation is the result of improper documentation 2646 of the restrictions of the ASN.1 GeneralString type in prior 2647 Kerberos specifications. 2649 The new (post-RFC 1510) type KerberosString, defined below, is a 2650 GeneralString that is constrained to only contain characters in 2651 IA5String 2653 KerberosString ::= GeneralString (IA5String) 2655 In general, US-ASCII control characters should not be used in 2656 KerberosString. Control characters SHOULD NOT be used in principal 2657 names or realm names. 2659 For compatibility, implementations MAY choose to accept 2660 GeneralString values that contain characters other than those 2661 permitted by IA5String, but they should be aware that character 2662 set designation codes will likely be absent, and that the encoding 2663 should probably be treated as locale-specific in almost every way. 2665 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2667 Implementations MAY also choose to emit GeneralString values that 2668 are beyond those permitted by IA5String, but should be aware that 2669 doing so is extraordinarily risky from an interoperability 2670 perspective. 2672 Some existing implementations use GeneralString to encode 2673 unescaped locale-specific characters. This is a violation of the 2674 ASN.1 standard. Most of these implementations encode US-ASCII in 2675 the left-hand half, so as long the implementation transmits only 2676 US-ASCII, the ASN.1 standard is not violated in this regard. As 2677 soon as such an implementation encodes unescaped locale-specific 2678 characters with the high bit set, it violates the ASN.1 standard. 2680 Other implementations have been known to use GeneralString to 2681 contain a UTF-8 encoding. This also violates the ASN.1 standard, 2682 since UTF-8 is a different encoding, not a 94 or 96 character "G" 2683 set as defined by ISO 2022. It is believed that these 2684 implementations do not even use the ISO 2022 escape sequence to 2685 change the character encoding. Even if implementations were to 2686 announce the change of encoding by using that escape sequence, the 2687 ASN.1 standard prohibits the use of any escape sequences other 2688 than those used to designate/invoke "G" or "C" sets allowed by 2689 GeneralString. 2691 Future revisions to this protocol will almost certainly allow for 2692 a more interoperable representation of principal names, probably 2693 including UTF8String. 2695 Note that applying a new constraint to a previously unconstrained 2696 type constitutes creation of a new ASN.1 type. In this particular 2697 case, the change does not result in a changed encoding under DER. 2699 5.2.2. Realm and PrincipalName 2701 Realm ::= KerberosString 2703 PrincipalName ::= SEQUENCE { 2704 name-type [0] Int32, 2705 name-string [1] SEQUENCE OF KerberosString 2706 } 2708 Kerberos realm names are encoded as KerberosStrings. Realms shall 2709 not contain a character with the code 0 (the US-ASCII NUL). Most 2710 realms will usually consist of several components separated by 2711 periods (.), in the style of Internet Domain Names, or separated 2712 by slashes (/) in the style of X.500 names. Acceptable forms for 2713 realm names are specified in section 6.1.. A PrincipalName is a 2714 typed sequence of components consisting of the following sub- 2715 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2717 fields: 2719 name-type 2720 This field specifies the type of name that follows. Pre-defined 2721 values for this field are specified in section 6.2. The name-type 2722 SHOULD be treated as a hint. Ignoring the name type, no two names 2723 can be the same (i.e. at least one of the components, or the 2724 realm, must be different). 2726 name-string 2727 This field encodes a sequence of components that form a name, each 2728 component encoded as a KerberosString. Taken together, a 2729 PrincipalName and a Realm form a principal identifier. Most 2730 PrincipalNames will have only a few components (typically one or 2731 two). 2733 5.2.3. KerberosTime 2735 KerberosTime ::= GeneralizedTime -- with no fractional seconds 2737 The timestamps used in Kerberos are encoded as GeneralizedTimes. A 2738 KerberosTime value shall not include any fractional portions of 2739 the seconds. As required by the DER, it further shall not include 2740 any separators, and it shall specify the UTC time zone (Z). 2741 Example: The only valid format for UTC time 6 minutes, 27 seconds 2742 after 9 pm on 6 November 1985 is 19851106210627Z. 2744 5.2.4. Constrained Integer types 2746 Some integer members of types SHOULD be constrained to values 2747 representable in 32 bits, for compatibility with reasonable 2748 implementation limits. 2750 Int32 ::= INTEGER (-2147483648..2147483647) 2751 -- signed values representable in 32 bits 2753 UInt32 ::= INTEGER (0..4294967295) 2754 -- unsigned 32 bit values 2756 Microseconds ::= INTEGER (0..999999) 2757 -- microseconds 2759 While this results in changes to the abstract types from the RFC 2760 1510 version, the encoding in DER should be unaltered. Historical 2761 implementations were typically limited to 32-bit integer values 2762 anyway, and assigned numbers SHOULD fall in the space of integer 2763 values representable in 32 bits in order to promote 2764 interoperability anyway. 2766 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2768 There are several integer fields in messages that are constrained 2769 to fixed values. 2771 pvno 2772 also TKT-VNO or AUTHENTICATOR-VNO, this recurring field is always 2773 the constant integer 5. There is no easy way to make this field 2774 into a useful protocol version number, so its value is fixed. 2776 msg-type 2777 this integer field is usually identical to the application tag 2778 number of the containing message type. 2780 5.2.5. HostAddress and HostAddresses 2782 HostAddress ::= SEQUENCE { 2783 addr-type [0] Int32, 2784 address [1] OCTET STRING 2785 } 2787 -- NOTE: HostAddresses is always used as an OPTIONAL field and 2788 -- should not be empty. 2789 HostAddresses -- NOTE: subtly different from rfc1510, 2790 -- but has a value mapping and encodes the same 2791 ::= SEQUENCE OF HostAddress 2793 The host address encodings consists of two fields: 2795 addr-type 2796 This field specifies the type of address that follows. Pre-defined 2797 values for this field are specified in section 7.5.3. 2799 address 2800 This field encodes a single address of type addr-type. 2802 5.2.6. AuthorizationData 2804 -- NOTE: AuthorizationData is always used as an OPTIONAL field and 2805 -- should not be empty. 2806 AuthorizationData ::= SEQUENCE OF SEQUENCE { 2807 ad-type [0] Int32, 2808 ad-data [1] OCTET STRING 2809 } 2811 ad-data 2812 This field contains authorization data to be interpreted according 2813 to the value of the corresponding ad-type field. 2815 ad-type 2816 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2818 This field specifies the format for the ad-data subfield. All 2819 negative values are reserved for local use. Non-negative values 2820 are reserved for registered use. 2822 Each sequence of type and data is referred to as an authorization 2823 element. Elements MAY be application specific, however, there is a 2824 common set of recursive elements that should be understood by all 2825 implementations. These elements contain other elements embedded 2826 within them, and the interpretation of the encapsulating element 2827 determines which of the embedded elements must be interpreted, and 2828 which may be ignored. 2830 These common authorization data elements are recursively defined, 2831 meaning the ad-data for these types will itself contain a sequence of 2832 authorization data whose interpretation is affected by the 2833 encapsulating element. Depending on the meaning of the encapsulating 2834 element, the encapsulated elements may be ignored, might be 2835 interpreted as issued directly by the KDC, or they might be stored in 2836 a separate plaintext part of the ticket. The types of the 2837 encapsulating elements are specified as part of the Kerberos 2838 specification because the behavior based on these values should be 2839 understood across implementations whereas other elements need only be 2840 understood by the applications which they affect. 2842 Authorization data elements are considered critical if present in a 2843 ticket or authenticator. Unless encapsulated in a known authorization 2844 data element amending the criticality of the elements it contains, if 2845 an unknown authorization data element type is received by a server 2846 either in an AP-REQ or in a ticket contained in an AP-REQ, then 2847 authentication MUST fail. Authorization data is intended to restrict 2848 the use of a ticket. If the service cannot determine whether the 2849 restriction applies to that service then a security weakness may 2850 result if the ticket can be used for that service. Authorization 2851 elements that are optional can be enclosed in AD-IF-RELEVANT element. 2853 In the definitions that follow, the value of the ad-type for the 2854 element will be specified as the least significant part of the 2855 subsection number, and the value of the ad-data will be as shown in 2856 the ASN.1 structure that follows the subsection heading. 2858 contents of ad-data ad-type 2860 DER encoding of AD-IF-RELEVANT 1 2862 DER encoding of AD-KDCIssued 4 2864 DER encoding of AD-AND-OR 5 2865 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2867 DER encoding of AD-MANDATORY-FOR-KDC 8 2869 5.2.6.1. IF-RELEVANT 2871 AD-IF-RELEVANT ::= AuthorizationData 2873 AD elements encapsulated within the if-relevant element are 2874 intended for interpretation only by application servers that 2875 understand the particular ad-type of the embedded element. 2876 Application servers that do not understand the type of an element 2877 embedded within the if-relevant element MAY ignore the 2878 uninterpretable element. This element promotes interoperability 2879 across implementations which may have local extensions for 2880 authorization. The ad-type for AD-IF-RELEVANT is (1). 2882 5.2.6.2. KDCIssued 2884 AD-KDCIssued ::= SEQUENCE { 2885 ad-checksum [0] Checksum, 2886 i-realm [1] Realm OPTIONAL, 2887 i-sname [2] PrincipalName OPTIONAL, 2888 elements [3] AuthorizationData 2889 } 2891 ad-checksum 2892 A cryptographic checksum computed over the DER encoding of the 2893 AuthorizationData in the "elements" field, keyed with the session 2894 key. Its checksumtype is the mandatory checksum type for the 2895 encryption type of the session key, and its key usage value is 19. 2897 i-realm, i-sname 2898 The name of the issuing principal if different from the KDC 2899 itself. This field would be used when the KDC can verify the 2900 authenticity of elements signed by the issuing principal and it 2901 allows this KDC to notify the application server of the validity 2902 of those elements. 2904 elements 2905 A sequence of authorization data elements issued by the KDC. 2907 The KDC-issued ad-data field is intended to provide a means for 2908 Kerberos principal credentials to embed within themselves privilege 2909 attributes and other mechanisms for positive authorization, 2910 amplifying the privileges of the principal beyond what can be done 2911 using a credentials without such an a-data element. 2913 This can not be provided without this element because the definition 2914 of the authorization-data field allows elements to be added at will 2915 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2917 by the bearer of a TGT at the time that they request service tickets 2918 and elements may also be added to a delegated ticket by inclusion in 2919 the authenticator. 2921 For KDC-issued elements this is prevented because the elements are 2922 signed by the KDC by including a checksum encrypted using the 2923 server's key (the same key used to encrypt the ticket - or a key 2924 derived from that key). Elements encapsulated with in the KDC-issued 2925 element MUST be ignored by the application server if this 2926 "signature" is not present. Further, elements encapsulated within 2927 this element from a ticket-granting ticket MAY be interpreted by the 2928 KDC, and used as a basis according to policy for including new signed 2929 elements within derivative tickets, but they will not be copied to a 2930 derivative ticket directly. If they are copied directly to a 2931 derivative ticket by a KDC that is not aware of this element, the 2932 signature will not be correct for the application ticket elements, 2933 and the field will be ignored by the application server. 2935 This element and the elements it encapsulates MAY be safely ignored 2936 by applications, application servers, and KDCs that do not implement 2937 this element. 2939 The ad-type for AD-KDC-ISSUED is (4). 2941 5.2.6.3. AND-OR 2943 AD-AND-OR ::= SEQUENCE { 2944 condition-count [0] INTEGER, 2945 elements [1] AuthorizationData 2946 } 2948 When restrictive AD elements are encapsulated within the and-or 2949 element, the and-or element is considered satisfied if and only if 2950 at least the number of encapsulated elements specified in 2951 condition-count are satisfied. Therefore, this element MAY be 2952 used to implement an "or" operation by setting the condition-count 2953 field to 1, and it MAY specify an "and" operation by setting the 2954 condition count to the number of embedded elements. Application 2955 servers that do not implement this element MUST reject tickets 2956 that contain authorization data elements of this type. 2958 The ad-type for AD-AND-OR is (5). 2960 5.2.6.4. MANDATORY-FOR-KDC 2962 AD-MANDATORY-FOR-KDC ::= AuthorizationData 2963 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 2965 AD elements encapsulated within the mandatory-for-kdc element are 2966 to be interpreted by the KDC. KDCs that do not understand the type 2967 of an element embedded within the mandatory-for-kdc element MUST 2968 reject the request. 2970 The ad-type for AD-MANDATORY-FOR-KDC is (8). 2972 5.2.7. PA-DATA 2974 Historically, PA-DATA have been known as "pre-authentication 2975 data", meaning that they were used to augment the initial 2976 authentication with the KDC. Since that time, they have also been 2977 used as a typed hole with which to extend protocol exchanges with 2978 the KDC. 2980 PA-DATA ::= SEQUENCE { 2981 -- NOTE: first tag is [1], not [0] 2982 padata-type [1] Int32, 2983 padata-value [2] OCTET STRING -- might be encoded AP-REQ 2984 } 2986 padata-type 2987 indicates the way that the padata-value element is to be 2988 interpreted. Negative values of padata-type are reserved for 2989 unregistered use; non-negative values are used for a registered 2990 interpretation of the element type. 2992 padata-value 2993 Usually contains the DER encoding of another type; the padata-type 2994 field identifies which type is encoded here. 2996 padata-type name contents of padata-value 2998 1 pa-tgs-req DER encoding of AP-REQ 3000 2 pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP 3002 3 pa-pw-salt salt (not ASN.1 encoded) 3004 11 pa-etype-info DER encoding of ETYPE-INFO 3006 19 pa-etype-info2 DER encoding of ETYPE-INFO2 3008 This field MAY also contain information needed by certain 3009 extensions to the Kerberos protocol. For example, it might be used 3010 to initially verify the identity of a client before any response 3011 is returned. 3013 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3015 The padata field can also contain information needed to help the 3016 KDC or the client select the key needed for generating or 3017 decrypting the response. This form of the padata is useful for 3018 supporting the use of certain token cards with Kerberos. The 3019 details of such extensions are specified in separate documents. 3020 See [Pat92] for additional uses of this field. 3022 5.2.7.1. PA-TGS-REQ 3024 In the case of requests for additional tickets (KRB_TGS_REQ), 3025 padata-value will contain an encoded AP-REQ. The checksum in the 3026 authenticator (which MUST be collision-proof) is to be computed 3027 over the KDC-REQ-BODY encoding. 3029 5.2.7.2. Encrypted Timestamp Pre-authentication 3031 There are pre-authentication types that may be used to pre- 3032 authenticate a client by means of an encrypted timestamp. 3034 PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC 3036 PA-ENC-TS-ENC ::= SEQUENCE { 3037 patimestamp [0] KerberosTime -- client's time --, 3038 pausec [1] Microseconds OPTIONAL 3039 } 3041 Patimestamp contains the client's time, and pausec contains the 3042 microseconds, which MAY be omitted if a client will not generate 3043 more than one request per second. The ciphertext (padata-value) 3044 consists of the PA-ENC-TS-ENC encoding, encrypted using the 3045 client's secret key and a key usage value of 1. 3047 This pre-authentication type was not present in RFC 1510, but many 3048 implementations support it. 3050 5.2.7.3. PA-PW-SALT 3052 The padata-value for this pre-authentication type contains the 3053 salt for the string-to-key to be used by the client to obtain the 3054 key for decrypting the encrypted part of an AS-REP message. 3055 Unfortunately, for historical reasons, the character set to be 3056 used is unspecified and probably locale-specific. 3058 This pre-authentication type was not present in RFC 1510, but many 3059 implementations support it. It is necessary in any case where the 3060 salt for the string-to-key algorithm is not the default. 3062 In the trivial example, a zero-length salt string is very 3063 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3065 commonplace for realms that have converted their principal 3066 databases from Kerberos 4. 3068 A KDC SHOULD NOT send PA-PW-SALT when issuing a KRB-ERROR message 3069 that requests additional pre-authentication. Implementation note: 3070 some KDC implementations issue an erroneous PA-PW-SALT when 3071 issuing a KRB-ERROR message that requests additional pre- 3072 authentication. Therefore, clients SHOULD ignore a PA-PW-SALT 3073 accompanying a KRB-ERROR message that requests additional pre- 3074 authentication. As noted in section 3.1.3, a KDC MUST NOT send 3075 PA-PW-SALT when the client's AS-REQ includes at least one "newer" 3076 etype. 3078 5.2.7.4. PA-ETYPE-INFO 3080 The ETYPE-INFO pre-authentication type is sent by the KDC in a 3081 KRB-ERROR indicating a requirement for additional pre- 3082 authentication. It is usually used to notify a client of which key 3083 to use for the encryption of an encrypted timestamp for the 3084 purposes of sending a PA-ENC-TIMESTAMP pre-authentication value. 3085 It MAY also be sent in an AS-REP to provide information to the 3086 client about which key salt to use for the string-to-key to be 3087 used by the client to obtain the key for decrypting the encrypted 3088 part the AS-REP. 3090 ETYPE-INFO-ENTRY ::= SEQUENCE { 3091 etype [0] Int32, 3092 salt [1] OCTET STRING OPTIONAL 3093 } 3095 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY 3097 The salt, like that of PA-PW-SALT, is also completely unspecified 3098 with respect to character set and is probably locale-specific. 3100 If ETYPE-INFO is sent in an AS-REP, there shall be exactly one 3101 ETYPE-INFO-ENTRY, and its etype shall match that of the enc-part 3102 in the AS-REP. 3104 This pre-authentication type was not present in RFC 1510, but many 3105 implementations that support encrypted timestamps for pre- 3106 authentication need to support ETYPE-INFO as well. As noted in 3107 section 3.1.3, a KDC MUST NOT send PA-ETYPE-INFO when the client's 3108 AS-REQ includes at least one "newer" etype. 3110 5.2.7.5. PA-ETYPE-INFO2 3112 The ETYPE-INFO2 pre-authentication type is sent by the KDC in a 3113 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3115 KRB-ERROR indicating a requirement for additional pre- 3116 authentication. It is usually used to notify a client of which key 3117 to use for the encryption of an encrypted timestamp for the 3118 purposes of sending a PA-ENC-TIMESTAMP pre-authentication value. 3119 It MAY also be sent in an AS-REP to provide information to the 3120 client about which key salt to use for the string-to-key to be 3121 used by the client to obtain the key for decrypting the encrypted 3122 part the AS-REP. 3124 ETYPE-INFO2-ENTRY ::= SEQUENCE { 3125 etype [0] Int32, 3126 salt [1] KerberosString OPTIONAL, 3127 s2kparams [2] OCTET STRING OPTIONAL 3128 } 3130 ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY 3132 The type of the salt is KerberosString, but existing installations 3133 might have locale-specific characters stored in salt strings, and 3134 implementors MAY choose to handle them. 3136 The interpretation of s2kparams is specified in the cryptosystem 3137 description associated with the etype. Each cryptosystem has a 3138 default interpretation of s2kparams that will hold if that element 3139 is omitted from the encoding of ETYPE-INFO2-ENTRY. 3141 If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one 3142 ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part 3143 in the AS-REP. 3145 The preferred ordering of the "hint" pre-authentication data that 3146 affect client key selection is: ETYPE-INFO2, followed by ETYPE- 3147 INFO, followed by PW-SALT. As noted in section 3.1.3, a KDC MUST 3148 NOT send ETYPE-INFO or PW-SALT when the client's AS-REQ includes 3149 at least one "newer" etype. 3151 The ETYPE-INFO2 pre-authentication type was not present in RFC 3152 1510. 3154 5.2.8. KerberosFlags 3156 For several message types, a specific constrained bit string type, 3157 KerberosFlags, is used. 3159 KerberosFlags ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits 3160 -- shall be sent, but no fewer than 32 3162 Compatibility note: the following paragraphs describe a change 3163 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3165 from the RFC1510 description of bit strings that would result in 3166 incompatility in the case of an implementation that strictly 3167 conformed to ASN.1 DER and RFC1510. 3169 ASN.1 bit strings have multiple uses. The simplest use of a bit 3170 string is to contain a vector of bits, with no particular meaning 3171 attached to individual bits. This vector of bits is not 3172 necessarily a multiple of eight bits long. The use in Kerberos of 3173 a bit string as a compact boolean vector wherein each element has 3174 a distinct meaning poses some problems. The natural notation for a 3175 compact boolean vector is the ASN.1 "NamedBit" notation, and the 3176 DER require that encodings of a bit string using "NamedBit" 3177 notation exclude any trailing zero bits. This truncation is easy 3178 to neglect, especially given C language implementations that 3179 naturally choose to store boolean vectors as 32 bit integers. 3181 For example, if the notation for KDCOptions were to include the 3182 "NamedBit" notation, as in RFC 1510, and a KDCOptions value to be 3183 encoded had only the "forwardable" (bit number one) bit set, the 3184 DER encoding MUST include only two bits: the first reserved bit 3185 ("reserved", bit number zero, value zero) and the one-valued bit 3186 (bit number one) for "forwardable". 3188 Most existing implementations of Kerberos unconditionally send 32 3189 bits on the wire when encoding bit strings used as boolean 3190 vectors. This behavior violates the ASN.1 syntax used for flag 3191 values in RFC 1510, but occurs on such a widely installed base 3192 that the protocol description is being modified to accommodate it. 3194 Consequently, this document removes the "NamedBit" notations for 3195 individual bits, relegating them to comments. The size constraint 3196 on the KerberosFlags type requires that at least 32 bits be 3197 encoded at all times, though a lenient implementation MAY choose 3198 to accept fewer than 32 bits and to treat the missing bits as set 3199 to zero. 3201 Currently, no uses of KerberosFlags specify more than 32 bits 3202 worth of flags, although future revisions of this document may do 3203 so. When more than 32 bits are to be transmitted in a 3204 KerberosFlags value, future revisions to this document will likely 3205 specify that the smallest number of bits needed to encode the 3206 highest-numbered one-valued bit should be sent. This is somewhat 3207 similar to the DER encoding of a bit string that is declared with 3208 the "NamedBit" notation. 3210 5.2.9. Cryptosystem-related Types 3212 Many Kerberos protocol messages contain an EncryptedData as a 3213 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3215 container for arbitrary encrypted data, which is often the 3216 encrypted encoding of another data type. Fields within 3217 EncryptedData assist the recipient in selecting a key with which 3218 to decrypt the enclosed data. 3220 EncryptedData ::= SEQUENCE { 3221 etype [0] Int32 -- EncryptionType --, 3222 kvno [1] UInt32 OPTIONAL, 3223 cipher [2] OCTET STRING -- ciphertext 3224 } 3226 etype 3227 This field identifies which encryption algorithm was used to 3228 encipher the cipher. 3230 kvno 3231 This field contains the version number of the key under which data 3232 is encrypted. It is only present in messages encrypted under long 3233 lasting keys, such as principals' secret keys. 3235 cipher 3236 This field contains the enciphered text, encoded as an OCTET 3237 STRING. (Note that the encryption mechanisms defined in 3238 [@KCRYPTO] MUST incorporate integrity protection as well, so no 3239 additional checksum is required.) 3241 The EncryptionKey type is the means by which cryptographic keys used 3242 for encryption are transferred. 3244 EncryptionKey ::= SEQUENCE { 3245 keytype [0] Int32 -- actually encryption type --, 3246 keyvalue [1] OCTET STRING 3247 } 3249 keytype 3250 This field specifies the encryption type of the encryption key 3251 that follows in the keyvalue field. While its name is "keytype", 3252 it actually specifies an encryption type. Previously, multiple 3253 cryptosystems that performed encryption differently but were 3254 capable of using keys with the same characteristics were permitted 3255 to share an assigned number to designate the type of key; this 3256 usage is now deprecated. 3258 keyvalue 3259 This field contains the key itself, encoded as an octet string. 3261 Messages containing cleartext data to be authenticated will usually 3262 do so by using a member of type Checksum. Most instances of Checksum 3263 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3265 use a keyed hash, though exceptions will be noted. 3267 Checksum ::= SEQUENCE { 3268 cksumtype [0] Int32, 3269 checksum [1] OCTET STRING 3270 } 3272 cksumtype 3273 This field indicates the algorithm used to generate the 3274 accompanying checksum. 3276 checksum 3277 This field contains the checksum itself, encoded as an octet 3278 string. 3280 See section 4 for a brief description of the use of encryption and 3281 checksums in Kerberos. 3283 5.3. Tickets 3285 This section describes the format and encryption parameters for 3286 tickets and authenticators. When a ticket or authenticator is 3287 included in a protocol message it is treated as an opaque object. 3288 A ticket is a record that helps a client authenticate to a 3289 service. A Ticket contains the following information: 3291 Ticket ::= [APPLICATION 1] SEQUENCE { 3292 tkt-vno [0] INTEGER (5), 3293 realm [1] Realm, 3294 sname [2] PrincipalName, 3295 enc-part [3] EncryptedData -- EncTicketPart 3296 } 3298 -- Encrypted part of ticket 3299 EncTicketPart ::= [APPLICATION 3] SEQUENCE { 3300 flags [0] TicketFlags, 3301 key [1] EncryptionKey, 3302 crealm [2] Realm, 3303 cname [3] PrincipalName, 3304 transited [4] TransitedEncoding, 3305 authtime [5] KerberosTime, 3306 starttime [6] KerberosTime OPTIONAL, 3307 endtime [7] KerberosTime, 3308 renew-till [8] KerberosTime OPTIONAL, 3309 caddr [9] HostAddresses OPTIONAL, 3310 authorization-data [10] AuthorizationData OPTIONAL 3311 } 3312 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3314 -- encoded Transited field 3315 TransitedEncoding ::= SEQUENCE { 3316 tr-type [0] Int32 -- must be registered --, 3317 contents [1] OCTET STRING 3318 } 3320 TicketFlags ::= KerberosFlags 3321 -- reserved(0), 3322 -- forwardable(1), 3323 -- forwarded(2), 3324 -- proxiable(3), 3325 -- proxy(4), 3326 -- may-postdate(5), 3327 -- postdated(6), 3328 -- invalid(7), 3329 -- renewable(8), 3330 -- initial(9), 3331 -- pre-authent(10), 3332 -- hw-authent(11), 3333 -- the following are new since 1510 3334 -- transited-policy-checked(12), 3335 -- ok-as-delegate(13) 3337 tkt-vno 3338 This field specifies the version number for the ticket format. 3339 This document describes version number 5. 3341 realm 3342 This field specifies the realm that issued a ticket. It also 3343 serves to identify the realm part of the server's principal 3344 identifier. Since a Kerberos server can only issue tickets for 3345 servers within its realm, the two will always be identical. 3347 sname 3348 This field specifies all components of the name part of the 3349 server's identity, including those parts that identify a specific 3350 instance of a service. 3352 enc-part 3353 This field holds the encrypted encoding of the EncTicketPart 3354 sequence. It is encrypted in the key shared by Kerberos and the 3355 end server (the server's secret key), using a key usage value of 3356 2. 3358 flags 3359 This field indicates which of various options were used or 3360 requested when the ticket was issued. The meanings of the flags 3361 are: 3363 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3365 Bit(s) Name Description 3367 0 reserved Reserved for future expansion of this 3368 field. 3370 The FORWARDABLE flag is normally only 3371 interpreted by the TGS, and can be 3372 ignored by end servers. When set, this 3373 1 forwardable flag tells the ticket-granting server 3374 that it is OK to issue a new 3375 ticket-granting ticket with a 3376 different network address based on the 3377 presented ticket. 3379 When set, this flag indicates that the 3380 ticket has either been forwarded or 3381 2 forwarded was issued based on authentication 3382 involving a forwarded ticket-granting 3383 ticket. 3385 The PROXIABLE flag is normally only 3386 interpreted by the TGS, and can be 3387 ignored by end servers. The PROXIABLE 3388 flag has an interpretation identical 3389 3 proxiable to that of the FORWARDABLE flag, 3390 except that the PROXIABLE flag tells 3391 the ticket-granting server that only 3392 non-ticket-granting tickets may be 3393 issued with different network 3394 addresses. 3396 4 proxy When set, this flag indicates that a 3397 ticket is a proxy. 3399 The MAY-POSTDATE flag is normally only 3400 interpreted by the TGS, and can be 3401 5 may-postdate ignored by end servers. This flag 3402 tells the ticket-granting server that 3403 a post-dated ticket MAY be issued 3404 based on this ticket-granting ticket. 3406 This flag indicates that this ticket 3407 has been postdated. The end-service 3408 6 postdated can check the authtime field to see 3409 when the original authentication 3410 occurred. 3412 This flag indicates that a ticket is 3413 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3415 invalid, and it must be validated by 3416 7 invalid the KDC before use. Application 3417 servers must reject tickets which have 3418 this flag set. 3420 The RENEWABLE flag is normally only 3421 interpreted by the TGS, and can 3422 usually be ignored by end servers 3423 8 renewable (some particularly careful servers MAY 3424 disallow renewable tickets). A 3425 renewable ticket can be used to obtain 3426 a replacement ticket that expires at a 3427 later date. 3429 This flag indicates that this ticket 3430 9 initial was issued using the AS protocol, and 3431 not issued based on a ticket-granting 3432 ticket. 3434 This flag indicates that during 3435 initial authentication, the client was 3436 authenticated by the KDC before a 3437 10 pre-authent ticket was issued. The strength of the 3438 pre-authentication method is not 3439 indicated, but is acceptable to the 3440 KDC. 3442 This flag indicates that the protocol 3443 employed for initial authentication 3444 required the use of hardware expected 3445 11 hw-authent to be possessed solely by the named 3446 client. The hardware authentication 3447 method is selected by the KDC and the 3448 strength of the method is not 3449 indicated. 3451 This flag indicates that the KDC for 3452 the realm has checked the transited 3453 field against a realm defined policy 3454 for trusted certifiers. If this flag 3455 is reset (0), then the application 3456 server must check the transited field 3457 itself, and if unable to do so it must 3458 reject the authentication. If the flag 3459 12 transited- is set (1) then the application server 3460 policy-checked MAY skip its own validation of the 3461 transited field, relying on the 3462 validation performed by the KDC. At 3463 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3465 its option the application server MAY 3466 still apply its own validation based 3467 on a separate policy for acceptance. 3469 This flag is new since RFC 1510. 3471 This flag indicates that the server 3472 (not the client) specified in the 3473 ticket has been determined by policy 3474 of the realm to be a suitable 3475 recipient of delegation. A client can 3476 use the presence of this flag to help 3477 it make a decision whether to delegate 3478 credentials (either grant a proxy or a 3479 forwarded ticket-granting ticket) to 3480 13 ok-as-delegate this server. The client is free to 3481 ignore the value of this flag. When 3482 setting this flag, an administrator 3483 should consider the Security and 3484 placement of the server on which the 3485 service will run, as well as whether 3486 the service requires the use of 3487 delegated credentials. 3489 This flag is new since RFC 1510. 3491 14-31 reserved Reserved for future use. 3493 key 3494 This field exists in the ticket and the KDC response and is used 3495 to pass the session key from Kerberos to the application server 3496 and the client. 3498 crealm 3499 This field contains the name of the realm in which the client is 3500 registered and in which initial authentication took place. 3502 cname 3503 This field contains the name part of the client's principal 3504 identifier. 3506 transited 3507 This field lists the names of the Kerberos realms that took part 3508 in authenticating the user to whom this ticket was issued. It does 3509 not specify the order in which the realms were transited. See 3510 section 3.3.3.2 for details on how this field encodes the 3511 traversed realms. When the names of CA's are to be embedded in 3512 the transited field (as specified for some extensions to the 3513 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3515 protocol), the X.500 names of the CA's SHOULD be mapped into items 3516 in the transited field using the mapping defined by RFC2253. 3518 authtime 3519 This field indicates the time of initial authentication for the 3520 named principal. It is the time of issue for the original ticket 3521 on which this ticket is based. It is included in the ticket to 3522 provide additional information to the end service, and to provide 3523 the necessary information for implementation of a `hot list' 3524 service at the KDC. An end service that is particularly paranoid 3525 could refuse to accept tickets for which the initial 3526 authentication occurred "too far" in the past. This field is also 3527 returned as part of the response from the KDC. When returned as 3528 part of the response to initial authentication (KRB_AS_REP), this 3529 is the current time on the Kerberos server. It is NOT recommended 3530 that this time value be used to adjust the workstation's clock 3531 since the workstation cannot reliably determine that such a 3532 KRB_AS_REP actually came from the proper KDC in a timely manner. 3534 starttime 3536 This field in the ticket specifies the time after which the ticket 3537 is valid. Together with endtime, this field specifies the life of 3538 the ticket. If the starttime field is absent from the ticket, then 3539 the authtime field SHOULD be used in its place to determine the 3540 life of the ticket. 3542 endtime 3543 This field contains the time after which the ticket will not be 3544 honored (its expiration time). Note that individual services MAY 3545 place their own limits on the life of a ticket and MAY reject 3546 tickets which have not yet expired. As such, this is really an 3547 upper bound on the expiration time for the ticket. 3549 renew-till 3550 This field is only present in tickets that have the RENEWABLE flag 3551 set in the flags field. It indicates the maximum endtime that may 3552 be included in a renewal. It can be thought of as the absolute 3553 expiration time for the ticket, including all renewals. 3555 caddr 3556 This field in a ticket contains zero (if omitted) or more (if 3557 present) host addresses. These are the addresses from which the 3558 ticket can be used. If there are no addresses, the ticket can be 3559 used from any location. The decision by the KDC to issue or by the 3560 end server to accept addressless tickets is a policy decision and 3561 is left to the Kerberos and end-service administrators; they MAY 3562 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3564 refuse to issue or accept such tickets. Because of the wide 3565 deployment of network address translation, it is recommended that 3566 policy allow the issue and acceptance of such tickets. 3568 Network addresses are included in the ticket to make it harder for 3569 an attacker to use stolen credentials. Because the session key is 3570 not sent over the network in cleartext, credentials can't be 3571 stolen simply by listening to the network; an attacker has to gain 3572 access to the session key (perhaps through operating system 3573 security breaches or a careless user's unattended session) to make 3574 use of stolen tickets. 3576 It is important to note that the network address from which a 3577 connection is received cannot be reliably determined. Even if it 3578 could be, an attacker who has compromised the client's workstation 3579 could use the credentials from there. Including the network 3580 addresses only makes it more difficult, not impossible, for an 3581 attacker to walk off with stolen credentials and then use them 3582 from a "safe" location. 3584 authorization-data 3585 The authorization-data field is used to pass authorization data 3586 from the principal on whose behalf a ticket was issued to the 3587 application service. If no authorization data is included, this 3588 field will be left out. Experience has shown that the name of this 3589 field is confusing, and that a better name for this field would be 3590 restrictions. Unfortunately, it is not possible to change the name 3591 of this field at this time. 3593 This field contains restrictions on any authority obtained on the 3594 basis of authentication using the ticket. It is possible for any 3595 principal in possession of credentials to add entries to the 3596 authorization data field since these entries further restrict what 3597 can be done with the ticket. Such additions can be made by 3598 specifying the additional entries when a new ticket is obtained 3599 during the TGS exchange, or they MAY be added during chained 3600 delegation using the authorization data field of the 3601 authenticator. 3603 Because entries may be added to this field by the holder of 3604 credentials, except when an entry is separately authenticated by 3605 encapsulation in the KDC-issued element, it is not allowable for 3606 the presence of an entry in the authorization data field of a 3607 ticket to amplify the privileges one would obtain from using a 3608 ticket. 3610 The data in this field may be specific to the end service; the 3611 field will contain the names of service specific objects, and the 3612 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3614 rights to those objects. The format for this field is described in 3615 section 5.2.6. Although Kerberos is not concerned with the format 3616 of the contents of the sub-fields, it does carry type information 3617 (ad-type). 3619 By using the authorization_data field, a principal is able to 3620 issue a proxy that is valid for a specific purpose. For example, a 3621 client wishing to print a file can obtain a file server proxy to 3622 be passed to the print server. By specifying the name of the file 3623 in the authorization_data field, the file server knows that the 3624 print server can only use the client's rights when accessing the 3625 particular file to be printed. 3627 A separate service providing authorization or certifying group 3628 membership may be built using the authorization-data field. In 3629 this case, the entity granting authorization (not the authorized 3630 entity), may obtain a ticket in its own name (e.g. the ticket is 3631 issued in the name of a privilege server), and this entity adds 3632 restrictions on its own authority and delegates the restricted 3633 authority through a proxy to the client. The client would then 3634 present this authorization credential to the application server 3635 separately from the authentication exchange. Alternatively, such 3636 authorization credentials MAY be embedded in the ticket 3637 authenticating the authorized entity, when the authorization is 3638 separately authenticated using the KDC-issued authorization data 3639 element (see 5.2.6.2). 3641 Similarly, if one specifies the authorization-data field of a 3642 proxy and leaves the host addresses blank, the resulting ticket 3643 and session key can be treated as a capability. See [Neu93] for 3644 some suggested uses of this field. 3646 The authorization-data field is optional and does not have to be 3647 included in a ticket. 3649 5.4. Specifications for the AS and TGS exchanges 3651 This section specifies the format of the messages used in the 3652 exchange between the client and the Kerberos server. The format of 3653 possible error messages appears in section 5.9.1. 3655 5.4.1. KRB_KDC_REQ definition 3657 The KRB_KDC_REQ message has no application tag number of its own. 3658 Instead, it is incorporated into one of KRB_AS_REQ or KRB_TGS_REQ, 3659 which each have an application tag, depending on whether the 3660 request is for an initial ticket or an additional ticket. In 3661 either case, the message is sent from the client to the KDC to 3662 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3664 request credentials for a service. 3666 The message fields are: 3668 AS-REQ ::= [APPLICATION 10] KDC-REQ 3670 TGS-REQ ::= [APPLICATION 12] KDC-REQ 3672 KDC-REQ ::= SEQUENCE { 3673 -- NOTE: first tag is [1], not [0] 3674 pvno [1] INTEGER (5) , 3675 msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --), 3676 padata [3] SEQUENCE OF PA-DATA OPTIONAL 3677 -- NOTE: not empty --, 3678 req-body [4] KDC-REQ-BODY 3679 } 3681 KDC-REQ-BODY ::= SEQUENCE { 3682 kdc-options [0] KDCOptions, 3683 cname [1] PrincipalName OPTIONAL 3684 -- Used only in AS-REQ --, 3685 realm [2] Realm 3686 -- Server's realm 3687 -- Also client's in AS-REQ --, 3688 sname [3] PrincipalName OPTIONAL, 3689 from [4] KerberosTime OPTIONAL, 3690 till [5] KerberosTime, 3691 rtime [6] KerberosTime OPTIONAL, 3692 nonce [7] UInt32, 3693 etype [8] SEQUENCE OF Int32 -- EncryptionType 3694 -- in preference order --, 3695 addresses [9] HostAddresses OPTIONAL, 3696 enc-authorization-data [10] EncryptedData -- AuthorizationData --, 3697 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 3698 -- NOTE: not empty 3699 } 3701 KDCOptions ::= KerberosFlags 3702 -- reserved(0), 3703 -- forwardable(1), 3704 -- forwarded(2), 3705 -- proxiable(3), 3706 -- proxy(4), 3707 -- allow-postdate(5), 3708 -- postdated(6), 3709 -- unused7(7), 3710 -- renewable(8), 3711 -- unused9(9), 3712 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3714 -- unused10(10), 3715 -- opt-hardware-auth(11), 3716 -- unused12(12), 3717 -- unused13(13), 3718 -- 15 is reserved for canonicalize 3719 -- unused15(15), 3720 -- 26 was unused in 1510 3721 -- disable-transited-check(26), 3722 -- 3723 -- renewable-ok(27), 3724 -- enc-tkt-in-skey(28), 3725 -- renew(30), 3726 -- validate(31) 3728 The fields in this message are: 3730 pvno 3731 This field is included in each message, and specifies the protocol 3732 version number. This document specifies protocol version 5. 3734 msg-type 3735 This field indicates the type of a protocol message. It will 3736 almost always be the same as the application identifier associated 3737 with a message. It is included to make the identifier more readily 3738 accessible to the application. For the KDC-REQ message, this type 3739 will be KRB_AS_REQ or KRB_TGS_REQ. 3741 padata 3742 Contains pre-authentication data. Requests for additional tickets 3743 (KRB_TGS_REQ) MUST contain a padata of PA-TGS-REQ. 3745 The padata (pre-authentication data) field contains a sequence of 3746 authentication information which may be needed before credentials 3747 can be issued or decrypted. 3749 req-body 3750 This field is a placeholder delimiting the extent of the remaining 3751 fields. If a checksum is to be calculated over the request, it is 3752 calculated over an encoding of the KDC-REQ-BODY sequence which is 3753 enclosed within the req-body field. 3755 kdc-options 3756 This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to 3757 the KDC and indicates the flags that the client wants set on the 3758 tickets as well as other information that is to modify the 3759 behavior of the KDC. Where appropriate, the name of an option may 3760 be the same as the flag that is set by that option. Although in 3761 most case, the bit in the options field will be the same as that 3762 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3764 in the flags field, this is not guaranteed, so it is not 3765 acceptable to simply copy the options field to the flags field. 3766 There are various checks that must be made before honoring an 3767 option anyway. 3769 The kdc_options field is a bit-field, where the selected options 3770 are indicated by the bit being set (1), and the unselected options 3771 and reserved fields being reset (0). The encoding of the bits is 3772 specified in section 5.2. The options are described in more detail 3773 above in section 2. The meanings of the options are: 3775 Bits Name Description 3777 0 RESERVED Reserved for future expansion of 3778 this field. 3780 The FORWARDABLE option indicates 3781 that the ticket to be issued is to 3782 have its forwardable flag set. It 3783 1 FORWARDABLE may only be set on the initial 3784 request, or in a subsequent request 3785 if the ticket-granting ticket on 3786 which it is based is also 3787 forwardable. 3789 The FORWARDED option is only 3790 specified in a request to the 3791 ticket-granting server and will only 3792 be honored if the ticket-granting 3793 ticket in the request has its 3794 2 FORWARDED FORWARDABLE bit set. This option 3795 indicates that this is a request for 3796 forwarding. The address(es) of the 3797 host from which the resulting ticket 3798 is to be valid are included in the 3799 addresses field of the request. 3801 The PROXIABLE option indicates that 3802 the ticket to be issued is to have 3803 its proxiable flag set. It may only 3804 3 PROXIABLE be set on the initial request, or in 3805 a subsequent request if the 3806 ticket-granting ticket on which it 3807 is based is also proxiable. 3809 The PROXY option indicates that this 3810 is a request for a proxy. This 3811 option will only be honored if the 3812 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3814 ticket-granting ticket in the 3815 4 PROXY request has its PROXIABLE bit set. 3816 The address(es) of the host from 3817 which the resulting ticket is to be 3818 valid are included in the addresses 3819 field of the request. 3821 The ALLOW-POSTDATE option indicates 3822 that the ticket to be issued is to 3823 have its MAY-POSTDATE flag set. It 3824 5 ALLOW-POSTDATE may only be set on the initial 3825 request, or in a subsequent request 3826 if the ticket-granting ticket on 3827 which it is based also has its 3828 MAY-POSTDATE flag set. 3830 The POSTDATED option indicates that 3831 this is a request for a postdated 3832 ticket. This option will only be 3833 honored if the ticket-granting 3834 ticket on which it is based has its 3835 6 POSTDATED MAY-POSTDATE flag set. The resulting 3836 ticket will also have its INVALID 3837 flag set, and that flag may be reset 3838 by a subsequent request to the KDC 3839 after the starttime in the ticket 3840 has been reached. 3842 7 RESERVED This option is presently unused. 3844 The RENEWABLE option indicates that 3845 the ticket to be issued is to have 3846 its RENEWABLE flag set. It may only 3847 be set on the initial request, or 3848 when the ticket-granting ticket on 3849 8 RENEWABLE which the request is based is also 3850 renewable. If this option is 3851 requested, then the rtime field in 3852 the request contains the desired 3853 absolute expiration time for the 3854 ticket. 3856 9 RESERVED Reserved for PK-Cross 3858 10 RESERVED Reserved for future use. 3860 11 RESERVED Reserved for opt-hardware-auth. 3862 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3864 12-25 RESERVED Reserved for future use. 3866 By default the KDC will check the 3867 transited field of a 3868 ticket-granting-ticket against the 3869 policy of the local realm before it 3870 will issue derivative tickets based 3871 on the ticket-granting ticket. If 3872 this flag is set in the request, 3873 checking of the transited field is 3874 disabled. Tickets issued without the 3875 26 DISABLE-TRANSITED-CHECK performance of this check will be 3876 noted by the reset (0) value of the 3877 TRANSITED-POLICY-CHECKED flag, 3878 indicating to the application server 3879 that the tranisted field must be 3880 checked locally. KDCs are 3881 encouraged but not required to honor 3882 the DISABLE-TRANSITED-CHECK option. 3884 This flag is new since RFC 1510 3886 The RENEWABLE-OK option indicates 3887 that a renewable ticket will be 3888 acceptable if a ticket with the 3889 requested life cannot otherwise be 3890 provided. If a ticket with the 3891 requested life cannot be provided, 3892 27 RENEWABLE-OK then a renewable ticket may be 3893 issued with a renew-till equal to 3894 the requested endtime. The value 3895 of the renew-till field may still be 3896 limited by local limits, or limits 3897 selected by the individual principal 3898 or server. 3900 This option is used only by the 3901 ticket-granting service. The 3902 ENC-TKT-IN-SKEY option indicates 3903 28 ENC-TKT-IN-SKEY that the ticket for the end server 3904 is to be encrypted in the session 3905 key from the additional 3906 ticket-granting ticket provided. 3908 29 RESERVED Reserved for future use. 3910 This option is used only by the 3911 ticket-granting service. The RENEW 3912 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3914 option indicates that the present 3915 request is for a renewal. The ticket 3916 provided is encrypted in the secret 3917 key for the server on which it is 3918 30 RENEW valid. This option will only be 3919 honored if the ticket to be renewed 3920 has its RENEWABLE flag set and if 3921 the time in its renew-till field has 3922 not passed. The ticket to be renewed 3923 is passed in the padata field as 3924 part of the authentication header. 3926 This option is used only by the 3927 ticket-granting service. The 3928 VALIDATE option indicates that the 3929 request is to validate a postdated 3930 ticket. It will only be honored if 3931 the ticket presented is postdated, 3932 presently has its INVALID flag set, 3933 31 VALIDATE and would be otherwise usable at 3934 this time. A ticket cannot be 3935 validated before its starttime. The 3936 ticket presented for validation is 3937 encrypted in the key of the server 3938 for which it is valid and is passed 3939 in the padata field as part of the 3940 authentication header. 3941 cname and sname 3942 These fields are the same as those described for the ticket in 3943 section 5.3. The sname may only be absent when the ENC-TKT-IN-SKEY 3944 option is specified. If absent, the name of the server is taken 3945 from the name of the client in the ticket passed as additional- 3946 tickets. 3948 enc-authorization-data 3949 The enc-authorization-data, if present (and it can only be present 3950 in the TGS_REQ form), is an encoding of the desired authorization- 3951 data encrypted under the sub-session key if present in the 3952 Authenticator, or alternatively from the session key in the 3953 ticket-granting ticket (both the Authenticator and ticket-granting 3954 ticket come from the padata field in the KRB_TGS_REQ). The key 3955 usage value used when encrypting is 5 if a sub-session key is 3956 used, or 4 if the session key is used. 3958 realm 3959 This field specifies the realm part of the server's principal 3960 identifier. In the AS exchange, this is also the realm part of the 3961 client's principal identifier. 3963 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 3965 from 3966 This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket 3967 requests when the requested ticket is to be postdated. It 3968 specifies the desired start time for the requested ticket. If this 3969 field is omitted then the KDC SHOULD use the current time instead. 3971 till 3972 This field contains the expiration date requested by the client in 3973 a ticket request. It is not optional, but if the requested endtime 3974 is "19700101000000Z", the requested ticket is to have the maximum 3975 endtime permitted according to KDC policy. Implementation note: 3976 This special timestamp corresponds to a UNIX time_t value of zero 3977 on most systems. 3979 rtime 3980 This field is the requested renew-till time sent from a client to 3981 the KDC in a ticket request. It is optional. 3983 nonce 3984 This field is part of the KDC request and response. It is intended 3985 to hold a random number generated by the client. If the same 3986 number is included in the encrypted response from the KDC, it 3987 provides evidence that the response is fresh and has not been 3988 replayed by an attacker. Nonces MUST NEVER be reused. 3990 etype 3991 This field specifies the desired encryption algorithm to be used 3992 in the response. 3994 addresses 3995 This field is included in the initial request for tickets, and 3996 optionally included in requests for additional tickets from the 3997 ticket-granting server. It specifies the addresses from which the 3998 requested ticket is to be valid. Normally it includes the 3999 addresses for the client's host. If a proxy is requested, this 4000 field will contain other addresses. The contents of this field are 4001 usually copied by the KDC into the caddr field of the resulting 4002 ticket. 4004 additional-tickets 4005 Additional tickets MAY be optionally included in a request to the 4006 ticket-granting server. If the ENC-TKT-IN-SKEY option has been 4007 specified, then the session key from the additional ticket will be 4008 used in place of the server's key to encrypt the new ticket. When 4009 the ENC-TKT-IN-SKEY option is used for user-to-user 4010 authentication, this additional ticket MAY be a TGT issued by the 4011 local realm or an inter-realm TGT issued for the current KDC's 4012 realm by a remote KDC. If more than one option which requires 4013 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4015 additional tickets has been specified, then the additional tickets 4016 are used in the order specified by the ordering of the options 4017 bits (see kdc-options, above). 4019 The application tag number will be either ten (10) or twelve (12) 4020 depending on whether the request is for an initial ticket (AS-REQ) or 4021 for an additional ticket (TGS-REQ). 4023 The optional fields (addresses, authorization-data and additional- 4024 tickets) are only included if necessary to perform the operation 4025 specified in the kdc-options field. 4027 It should be noted that in KRB_TGS_REQ, the protocol version number 4028 appears twice and two different message types appear: the KRB_TGS_REQ 4029 message contains these fields as does the authentication header 4030 (KRB_AP_REQ) that is passed in the padata field. 4032 5.4.2. KRB_KDC_REP definition 4034 The KRB_KDC_REP message format is used for the reply from the KDC 4035 for either an initial (AS) request or a subsequent (TGS) request. 4036 There is no message type for KRB_KDC_REP. Instead, the type will 4037 be either KRB_AS_REP or KRB_TGS_REP. The key used to encrypt the 4038 ciphertext part of the reply depends on the message type. For 4039 KRB_AS_REP, the ciphertext is encrypted in the client's secret 4040 key, and the client's key version number is included in the key 4041 version number for the encrypted data. For KRB_TGS_REP, the 4042 ciphertext is encrypted in the sub-session key from the 4043 Authenticator, or if absent, the session key from the ticket- 4044 granting ticket used in the request. In that case, no version 4045 number will be present in the EncryptedData sequence. 4047 The KRB_KDC_REP message contains the following fields: 4049 AS-REP ::= [APPLICATION 11] KDC-REP 4051 TGS-REP ::= [APPLICATION 13] KDC-REP 4053 KDC-REP ::= SEQUENCE { 4054 pvno [0] INTEGER (5), 4055 msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --), 4056 padata [2] SEQUENCE OF PA-DATA OPTIONAL 4057 -- NOTE: not empty --, 4058 crealm [3] Realm, 4059 cname [4] PrincipalName, 4060 ticket [5] Ticket, 4061 enc-part [6] EncryptedData 4062 -- EncASRepPart or EncTGSRepPart, 4063 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4065 -- as appropriate 4066 } 4068 EncASRepPart ::= [APPLICATION 25] EncKDCRepPart 4070 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 4072 EncKDCRepPart ::= SEQUENCE { 4073 key [0] EncryptionKey, 4074 last-req [1] LastReq, 4075 nonce [2] UInt32, 4076 key-expiration [3] KerberosTime OPTIONAL, 4077 flags [4] TicketFlags, 4078 authtime [5] KerberosTime, 4079 starttime [6] KerberosTime OPTIONAL, 4080 endtime [7] KerberosTime, 4081 renew-till [8] KerberosTime OPTIONAL, 4082 srealm [9] Realm, 4083 sname [10] PrincipalName, 4084 caddr [11] HostAddresses OPTIONAL 4085 } 4087 LastReq ::= SEQUENCE OF SEQUENCE { 4088 lr-type [0] Int32, 4089 lr-value [1] KerberosTime 4090 } 4092 pvno and msg-type 4093 These fields are described above in section 5.4.1. msg-type is 4094 either KRB_AS_REP or KRB_TGS_REP. 4096 padata 4097 This field is described in detail in section 5.4.1. One possible 4098 use for this field is to encode an alternate "salt" string to be 4099 used with a string-to-key algorithm. This ability is useful to 4100 ease transitions if a realm name needs to change (e.g. when a 4101 company is acquired); in such a case all existing password-derived 4102 entries in the KDC database would be flagged as needing a special 4103 salt string until the next password change. 4105 crealm, cname, srealm and sname 4106 These fields are the same as those described for the ticket in 4107 section 5.3. 4109 ticket 4110 The newly-issued ticket, from section 5.3. 4112 enc-part 4113 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4115 This field is a place holder for the ciphertext and related 4116 information that forms the encrypted part of a message. The 4117 description of the encrypted part of the message follows each 4118 appearance of this field. 4120 The key usage value for encrypting this field is 3 in an AS-REP 4121 message, using the client's long-term key or another key selected 4122 via pre-authentication mechanisms. In a TGS-REP message, the key 4123 usage value is 8 if the TGS session key is used, or 9 if a TGS 4124 authenticator subkey is used. 4126 Compatibility note: Some implementations unconditionally send an 4127 encrypted EncTGSRepPart (application tag number 26) in this field 4128 regardless of whether the reply is a AS-REP or a TGS-REP. In the 4129 interests of compatibility, implementors MAY relax the check on 4130 the tag number of the decrypted ENC-PART. 4132 key 4133 This field is the same as described for the ticket in section 5.3. 4135 last-req 4136 This field is returned by the KDC and specifies the time(s) of the 4137 last request by a principal. Depending on what information is 4138 available, this might be the last time that a request for a 4139 ticket-granting ticket was made, or the last time that a request 4140 based on a ticket-granting ticket was successful. It also might 4141 cover all servers for a realm, or just the particular server. Some 4142 implementations MAY display this information to the user to aid in 4143 discovering unauthorized use of one's identity. It is similar in 4144 spirit to the last login time displayed when logging into 4145 timesharing systems. 4147 lr-type 4148 This field indicates how the following lr-value field is to be 4149 interpreted. Negative values indicate that the information 4150 pertains only to the responding server. Non-negative values 4151 pertain to all servers for the realm. 4153 If the lr-type field is zero (0), then no information is 4154 conveyed by the lr-value subfield. If the absolute value of the 4155 lr-type field is one (1), then the lr-value subfield is the 4156 time of last initial request for a TGT. If it is two (2), then 4157 the lr-value subfield is the time of last initial request. If 4158 it is three (3), then the lr-value subfield is the time of 4159 issue for the newest ticket-granting ticket used. If it is four 4160 (4), then the lr-value subfield is the time of the last 4161 renewal. If it is five (5), then the lr-value subfield is the 4162 time of last request (of any type). If it is (6), then the lr- 4163 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4165 value subfield is the time when the password will expire. If 4166 it is (7), then the lr-value subfield is the time when the 4167 account will expire. 4169 lr-value 4170 This field contains the time of the last request. The time MUST 4171 be interpreted according to the contents of the accompanying 4172 lr-type subfield. 4174 nonce 4175 This field is described above in section 5.4.1. 4177 key-expiration 4178 The key-expiration field is part of the response from the KDC and 4179 specifies the time that the client's secret key is due to expire. 4180 The expiration might be the result of password aging or an account 4181 expiration. If present, it SHOULD be set to the earliest of the 4182 user's key expiration and account expiration. The use of this 4183 field is deprecated and the last-req field SHOULD be used to 4184 convey this information instead. This field will usually be left 4185 out of the TGS reply since the response to the TGS request is 4186 encrypted in a session key and no client information need be 4187 retrieved from the KDC database. It is up to the application 4188 client (usually the login program) to take appropriate action 4189 (such as notifying the user) if the expiration time is imminent. 4191 flags, authtime, starttime, endtime, renew-till and caddr 4192 These fields are duplicates of those found in the encrypted 4193 portion of the attached ticket (see section 5.3), provided so the 4194 client MAY verify they match the intended request and to assist in 4195 proper ticket caching. If the message is of type KRB_TGS_REP, the 4196 caddr field will only be filled in if the request was for a proxy 4197 or forwarded ticket, or if the user is substituting a subset of 4198 the addresses from the ticket-granting ticket. If the client- 4199 requested addresses are not present or not used, then the 4200 addresses contained in the ticket will be the same as those 4201 included in the ticket-granting ticket. 4203 5.5. Client/Server (CS) message specifications 4205 This section specifies the format of the messages used for the 4206 authentication of the client to the application server. 4208 5.5.1. KRB_AP_REQ definition 4210 The KRB_AP_REQ message contains the Kerberos protocol version 4211 number, the message type KRB_AP_REQ, an options field to indicate 4212 any options in use, and the ticket and authenticator themselves. 4214 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4216 The KRB_AP_REQ message is often referred to as the 'authentication 4217 header'. 4219 AP-REQ ::= [APPLICATION 14] SEQUENCE { 4220 pvno [0] INTEGER (5), 4221 msg-type [1] INTEGER (14), 4222 ap-options [2] APOptions, 4223 ticket [3] Ticket, 4224 authenticator [4] EncryptedData -- Authenticator 4225 } 4227 APOptions ::= KerberosFlags 4228 -- reserved(0), 4229 -- use-session-key(1), 4230 -- mutual-required(2) 4232 pvno and msg-type 4233 These fields are described above in section 5.4.1. msg-type is 4234 KRB_AP_REQ. 4236 ap-options 4237 This field appears in the application request (KRB_AP_REQ) and 4238 affects the way the request is processed. It is a bit-field, where 4239 the selected options are indicated by the bit being set (1), and 4240 the unselected options and reserved fields being reset (0). The 4241 encoding of the bits is specified in section 5.2. The meanings of 4242 the options are: 4244 Bit(s) Name Description 4246 0 reserved Reserved for future expansion of this field. 4248 The USE-SESSION-KEY option indicates that the 4249 ticket the client is presenting to a server 4250 1 use-session-key is encrypted in the session key from the 4251 server's ticket-granting ticket. When this 4252 option is not specified, the ticket is 4253 encrypted in the server's secret key. 4255 The MUTUAL-REQUIRED option tells the server 4256 2 mutual-required that the client requires mutual 4257 authentication, and that it must respond with 4258 a KRB_AP_REP message. 4260 3-31 reserved Reserved for future use. 4262 ticket 4263 This field is a ticket authenticating the client to the server. 4265 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4267 authenticator 4268 This contains the encrypted authenticator, which includes the 4269 client's choice of a subkey. 4271 The encrypted authenticator is included in the AP-REQ; it certifies 4272 to a server that the sender has recent knowledge of the encryption 4273 key in the accompanying ticket, to help the server detect replays. It 4274 also assists in the selection of a "true session key" to use with the 4275 particular session. The DER encoding of the following is encrypted 4276 in the ticket's session key, with a key usage value of 11 in normal 4277 application exchanges, or 7 when used as the PA-TGS-REQ PA-DATA field 4278 of a TGS-REQ exchange (see section 5.4.1): 4280 -- Unencrypted authenticator 4281 Authenticator ::= [APPLICATION 2] SEQUENCE { 4282 authenticator-vno [0] INTEGER (5), 4283 crealm [1] Realm, 4284 cname [2] PrincipalName, 4285 cksum [3] Checksum OPTIONAL, 4286 cusec [4] Microseconds, 4287 ctime [5] KerberosTime, 4288 subkey [6] EncryptionKey OPTIONAL, 4289 seq-number [7] UInt32 OPTIONAL, 4290 authorization-data [8] AuthorizationData OPTIONAL 4291 } 4293 authenticator-vno 4294 This field specifies the version number for the format of the 4295 authenticator. This document specifies version 5. 4297 crealm and cname 4298 These fields are the same as those described for the ticket in 4299 section 5.3. 4301 cksum 4302 This field contains a checksum of the application data that 4303 accompanies the KRB_AP_REQ, computed using a key usage value of 10 4304 in normal application exchanges, or 6 when used in the TGS-REQ PA- 4305 TGS-REQ AP-DATA field. 4307 cusec 4308 This field contains the microsecond part of the client's 4309 timestamp. Its value (before encryption) ranges from 0 to 999999. 4310 It often appears along with ctime. The two fields are used 4311 together to specify a reasonably accurate timestamp. 4313 ctime 4314 This field contains the current time on the client's host. 4316 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4318 subkey 4319 This field contains the client's choice for an encryption key 4320 which is to be used to protect this specific application session. 4321 Unless an application specifies otherwise, if this field is left 4322 out the session key from the ticket will be used. 4324 seq-number 4325 This optional field includes the initial sequence number to be 4326 used by the KRB_PRIV or KRB_SAFE messages when sequence numbers 4327 are used to detect replays (It may also be used by application 4328 specific messages). When included in the authenticator this field 4329 specifies the initial sequence number for messages from the client 4330 to the server. When included in the AP-REP message, the initial 4331 sequence number is that for messages from the server to the 4332 client. When used in KRB_PRIV or KRB_SAFE messages, it is 4333 incremented by one after each message is sent. Sequence numbers 4334 fall in the range of 0 through 2^32 - 1 and wrap to zero following 4335 the value 2^32 - 1. 4337 For sequence numbers to adequately support the detection of 4338 replays they SHOULD be non-repeating, even across connection 4339 boundaries. The initial sequence number SHOULD be random and 4340 uniformly distributed across the full space of possible sequence 4341 numbers, so that it cannot be guessed by an attacker and so that 4342 it and the successive sequence numbers do not repeat other 4343 sequences. In the event that more than 2^32 messages are to be 4344 generated in a series of KRB_PRIV or KRB_SAFE messages, rekeying 4345 SHOULD be performed before sequence numbers are reused with the 4346 same encryption key. 4348 Implmentation note: historically, some implementations transmit 4349 signed twos-complement numbers for sequence numbers. In the 4350 interests of compatibility, implementations MAY accept the 4351 equivalent negative number where a positive number greater than 4352 2^31 - 1 is expected. 4354 Implementation note: as noted before, some implementations omit 4355 the optional sequence number when its value would be zero. 4356 Implementations MAY accept an omitted sequence number when 4357 expecting a value of zero, and SHOULD NOT transmit an 4358 Authenticator with a initial sequence number of zero. 4360 authorization-data 4361 This field is the same as described for the ticket in section 5.3. 4362 It is optional and will only appear when additional restrictions 4363 are to be placed on the use of a ticket, beyond those carried in 4364 the ticket itself. 4366 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4368 5.5.2. KRB_AP_REP definition 4370 The KRB_AP_REP message contains the Kerberos protocol version 4371 number, the message type, and an encrypted time-stamp. The message 4372 is sent in response to an application request (KRB_AP_REQ) where 4373 the mutual authentication option has been selected in the ap- 4374 options field. 4376 AP-REP ::= [APPLICATION 15] SEQUENCE { 4377 pvno [0] INTEGER (5), 4378 msg-type [1] INTEGER (15), 4379 enc-part [2] EncryptedData -- EncAPRepPart 4380 } 4382 EncAPRepPart ::= [APPLICATION 27] SEQUENCE { 4383 ctime [0] KerberosTime, 4384 cusec [1] Microseconds, 4385 subkey [2] EncryptionKey OPTIONAL, 4386 seq-number [3] UInt32 OPTIONAL 4387 } 4389 The encoded EncAPRepPart is encrypted in the shared session key of 4390 the ticket. The optional subkey field can be used in an 4391 application-arranged negotiation to choose a per association 4392 session key. 4394 pvno and msg-type 4395 These fields are described above in section 5.4.1. msg-type is 4396 KRB_AP_REP. 4398 enc-part 4399 This field is described above in section 5.4.2. It is computed 4400 with a key usage value of 12. 4402 ctime 4403 This field contains the current time on the client's host. 4405 cusec 4406 This field contains the microsecond part of the client's 4407 timestamp. 4409 subkey 4410 This field contains an encryption key which is to be used to 4411 protect this specific application session. See section 3.2.6 for 4412 specifics on how this field is used to negotiate a key. Unless an 4413 application specifies otherwise, if this field is left out, the 4414 sub-session key from the authenticator, or if also left out, the 4415 session key from the ticket will be used. 4417 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4419 seq-number 4420 This field is described above in section 5.3.2. 4422 5.5.3. Error message reply 4424 If an error occurs while processing the application request, the 4425 KRB_ERROR message will be sent in response. See section 5.9.1 for 4426 the format of the error message. The cname and crealm fields MAY 4427 be left out if the server cannot determine their appropriate 4428 values from the corresponding KRB_AP_REQ message. If the 4429 authenticator was decipherable, the ctime and cusec fields will 4430 contain the values from it. 4432 5.6. KRB_SAFE message specification 4434 This section specifies the format of a message that can be used by 4435 either side (client or server) of an application to send a tamper- 4436 proof message to its peer. It presumes that a session key has 4437 previously been exchanged (for example, by using the 4438 KRB_AP_REQ/KRB_AP_REP messages). 4440 5.6.1. KRB_SAFE definition 4442 The KRB_SAFE message contains user data along with a collision- 4443 proof checksum keyed with the last encryption key negotiated via 4444 subkeys, or the session key if no negotiation has occurred. The 4445 message fields are: 4447 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 4448 pvno [0] INTEGER (5), 4449 msg-type [1] INTEGER (20), 4450 safe-body [2] KRB-SAFE-BODY, 4451 cksum [3] Checksum 4452 } 4454 KRB-SAFE-BODY ::= SEQUENCE { 4455 user-data [0] OCTET STRING, 4456 timestamp [1] KerberosTime OPTIONAL, 4457 usec [2] Microseconds OPTIONAL, 4458 seq-number [3] UInt32 OPTIONAL, 4459 s-address [4] HostAddress, 4460 r-address [5] HostAddress OPTIONAL 4461 } 4463 pvno and msg-type 4464 These fields are described above in section 5.4.1. msg-type is 4465 KRB_SAFE. 4467 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4469 safe-body 4470 This field is a placeholder for the body of the KRB-SAFE message. 4472 cksum 4473 This field contains the checksum of the application data, computed 4474 with a key usage value of 15. 4476 The checksum is computed over the encoding of the KRB-SAFE 4477 sequence. First, the cksum is set to a type zero, zero-length 4478 value and the checksum is computed over the encoding of the KRB- 4479 SAFE sequence, then the checksum is set to the result of that 4480 computation, and finally the KRB-SAFE sequence is encoded again. 4481 This method, while different than the one specified in RFC 1510, 4482 corresponds to existing practice. 4484 user-data 4485 This field is part of the KRB_SAFE and KRB_PRIV messages and 4486 contain the application specific data that is being passed from 4487 the sender to the recipient. 4489 timestamp 4490 This field is part of the KRB_SAFE and KRB_PRIV messages. Its 4491 contents are the current time as known by the sender of the 4492 message. By checking the timestamp, the recipient of the message 4493 is able to make sure that it was recently generated, and is not a 4494 replay. 4496 usec 4497 This field is part of the KRB_SAFE and KRB_PRIV headers. It 4498 contains the microsecond part of the timestamp. 4500 seq-number 4501 This field is described above in section 5.3.2. 4503 s-address 4504 Sender's address. 4506 This field specifies the address in use by the sender of the 4507 message. 4509 r-address 4510 This field specifies the address in use by the recipient of the 4511 message. It MAY be omitted for some uses (such as broadcast 4512 protocols), but the recipient MAY arbitrarily reject such 4513 messages. This field, along with s-address, can be used to help 4514 detect messages which have been incorrectly or maliciously 4515 delivered to the wrong recipient. 4517 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4519 5.7. KRB_PRIV message specification 4521 This section specifies the format of a message that can be used by 4522 either side (client or server) of an application to securely and 4523 privately send a message to its peer. It presumes that a session 4524 key has previously been exchanged (for example, by using the 4525 KRB_AP_REQ/KRB_AP_REP messages). 4527 5.7.1. KRB_PRIV definition 4529 The KRB_PRIV message contains user data encrypted in the Session 4530 Key. The message fields are: 4532 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 4533 pvno [0] INTEGER (5), 4534 msg-type [1] INTEGER (21), 4535 -- NOTE: there is no [2] tag 4536 enc-part [3] EncryptedData -- EncKrbPrivPart 4537 } 4539 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 4540 user-data [0] OCTET STRING, 4541 timestamp [1] KerberosTime OPTIONAL, 4542 usec [2] Microseconds OPTIONAL, 4543 seq-number [3] UInt32 OPTIONAL, 4544 s-address [4] HostAddress -- sender's addr --, 4545 r-address [5] HostAddress OPTIONAL -- recip's addr 4546 } 4548 pvno and msg-type 4549 These fields are described above in section 5.4.1. msg-type is 4550 KRB_PRIV. 4552 enc-part 4553 This field holds an encoding of the EncKrbPrivPart sequence 4554 encrypted under the session key, with a key usage value of 13. 4555 This encrypted encoding is used for the enc-part field of the KRB- 4556 PRIV message. 4558 user-data, timestamp, usec, s-address and r-address 4559 These fields are described above in section 5.6.1. 4561 seq-number 4562 This field is described above in section 5.3.2. 4564 5.8. KRB_CRED message specification 4566 This section specifies the format of a message that can be used to 4567 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4569 send Kerberos credentials from one principal to another. It is 4570 presented here to encourage a common mechanism to be used by 4571 applications when forwarding tickets or providing proxies to 4572 subordinate servers. It presumes that a session key has already 4573 been exchanged perhaps by using the KRB_AP_REQ/KRB_AP_REP 4574 messages. 4576 5.8.1. KRB_CRED definition 4578 The KRB_CRED message contains a sequence of tickets to be sent and 4579 information needed to use the tickets, including the session key 4580 from each. The information needed to use the tickets is encrypted 4581 under an encryption key previously exchanged or transferred 4582 alongside the KRB_CRED message. The message fields are: 4584 KRB-CRED ::= [APPLICATION 22] SEQUENCE { 4585 pvno [0] INTEGER (5), 4586 msg-type [1] INTEGER (22), 4587 tickets [2] SEQUENCE OF Ticket, 4588 enc-part [3] EncryptedData -- EncKrbCredPart 4589 } 4591 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 4592 ticket-info [0] SEQUENCE OF KrbCredInfo, 4593 nonce [1] UInt32 OPTIONAL, 4594 timestamp [2] KerberosTime OPTIONAL, 4595 usec [3] Microseconds OPTIONAL, 4596 s-address [4] HostAddress OPTIONAL, 4597 r-address [5] HostAddress OPTIONAL 4598 } 4600 KrbCredInfo ::= SEQUENCE { 4601 key [0] EncryptionKey, 4602 prealm [1] Realm OPTIONAL, 4603 pname [2] PrincipalName OPTIONAL, 4604 flags [3] TicketFlags OPTIONAL, 4605 authtime [4] KerberosTime OPTIONAL, 4606 starttime [5] KerberosTime OPTIONAL, 4607 endtime [6] KerberosTime OPTIONAL, 4608 renew-till [7] KerberosTime OPTIONAL, 4609 srealm [8] Realm OPTIONAL, 4610 sname [9] PrincipalName OPTIONAL, 4611 caddr [10] HostAddresses OPTIONAL 4612 } 4614 pvno and msg-type 4615 These fields are described above in section 5.4.1. msg-type is 4616 KRB_CRED. 4618 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4620 tickets 4621 These are the tickets obtained from the KDC specifically for use 4622 by the intended recipient. Successive tickets are paired with the 4623 corresponding KrbCredInfo sequence from the enc-part of the KRB- 4624 CRED message. 4626 enc-part 4627 This field holds an encoding of the EncKrbCredPart sequence 4628 encrypted under the session key shared between the sender and the 4629 intended recipient, with a key usage value of 14. This encrypted 4630 encoding is used for the enc-part field of the KRB-CRED message. 4632 Implementation note: implementations of certain applications, most 4633 notably certain implementations of the Kerberos GSS-API mechanism, 4634 do not separately encrypt the contents of the EncKrbCredPart of 4635 the KRB-CRED message when sending it. In the case of those GSS- 4636 API mechanisms, this is not a security vulnerability, as the 4637 entire KRB-CRED message is itself embedded in an encrypted 4638 message. 4640 nonce 4641 If practical, an application MAY require the inclusion of a nonce 4642 generated by the recipient of the message. If the same value is 4643 included as the nonce in the message, it provides evidence that 4644 the message is fresh and has not been replayed by an attacker. A 4645 nonce MUST NEVER be reused. 4647 timestamp and usec 4648 These fields specify the time that the KRB-CRED message was 4649 generated. The time is used to provide assurance that the message 4650 is fresh. 4652 s-address and r-address 4653 These fields are described above in section 5.6.1. They are used 4654 optionally to provide additional assurance of the integrity of the 4655 KRB-CRED message. 4657 key 4658 This field exists in the corresponding ticket passed by the KRB- 4659 CRED message and is used to pass the session key from the sender 4660 to the intended recipient. The field's encoding is described in 4661 section 5.2.9. 4663 The following fields are optional. If present, they can be associated 4664 with the credentials in the remote ticket file. If left out, then it 4665 is assumed that the recipient of the credentials already knows their 4666 value. 4668 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4670 prealm and pname 4671 The name and realm of the delegated principal identity. 4673 flags, authtime, starttime, endtime, renew-till, srealm, sname, and 4674 caddr 4675 These fields contain the values of the corresponding fields from 4676 the ticket found in the ticket field. Descriptions of the fields 4677 are identical to the descriptions in the KDC-REP message. 4679 5.9. Error message specification 4681 This section specifies the format for the KRB_ERROR message. The 4682 fields included in the message are intended to return as much 4683 information as possible about an error. It is not expected that 4684 all the information required by the fields will be available for 4685 all types of errors. If the appropriate information is not 4686 available when the message is composed, the corresponding field 4687 will be left out of the message. 4689 Note that since the KRB_ERROR message is not integrity protected, 4690 it is quite possible for an intruder to synthesize or modify such 4691 a message. In particular, this means that the client SHOULD NOT 4692 use any fields in this message for security-critical purposes, 4693 such as setting a system clock or generating a fresh 4694 authenticator. The message can be useful, however, for advising a 4695 user on the reason for some failure. 4697 5.9.1. KRB_ERROR definition 4699 The KRB_ERROR message consists of the following fields: 4701 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 4702 pvno [0] INTEGER (5), 4703 msg-type [1] INTEGER (30), 4704 ctime [2] KerberosTime OPTIONAL, 4705 cusec [3] Microseconds OPTIONAL, 4706 stime [4] KerberosTime, 4707 susec [5] Microseconds, 4708 error-code [6] Int32, 4709 crealm [7] Realm OPTIONAL, 4710 cname [8] PrincipalName OPTIONAL, 4711 realm [9] Realm -- service realm --, 4712 sname [10] PrincipalName -- service name --, 4713 e-text [11] KerberosString OPTIONAL, 4714 e-data [12] OCTET STRING OPTIONAL 4715 } 4717 pvno and msg-type 4718 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4720 These fields are described above in section 5.4.1. msg-type is 4721 KRB_ERROR. 4723 ctime 4724 This field is described above in section 5.5.2. 4726 cusec 4727 This field is described above in section 5.5.2. 4729 stime 4730 This field contains the current time on the server. It is of type 4731 KerberosTime. 4733 susec 4734 This field contains the microsecond part of the server's 4735 timestamp. Its value ranges from 0 to 999999. It appears along 4736 with stime. The two fields are used in conjunction to specify a 4737 reasonably accurate timestamp. 4739 error-code 4740 This field contains the error code returned by Kerberos or the 4741 server when a request fails. To interpret the value of this field 4742 see the list of error codes in section 7.5.9. Implementations are 4743 encouraged to provide for national language support in the display 4744 of error messages. 4746 crealm, cname, realm and sname 4747 These fields are described above in section 5.3. 4749 e-text 4750 This field contains additional text to help explain the error code 4751 associated with the failed request (for example, it might include 4752 a principal name which was unknown). 4754 e-data 4755 This field contains additional data about the error for use by the 4756 application to help it recover from or handle the error. If the 4757 errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will 4758 contain an encoding of a sequence of padata fields, each 4759 corresponding to an acceptable pre-authentication method and 4760 optionally containing data for the method: 4762 METHOD-DATA ::= SEQUENCE OF PA-DATA 4764 For error codes defined in this document other than 4765 KDC_ERR_PREAUTH_REQUIRED, the format and contents of the e-data field 4766 are implementation-defined. Similarly, for future error codes, the 4767 format and contents of the e-data field are implementation-defined 4768 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4770 unless specified. Whether defined by the implementation or in a 4771 future document, the e-data field MAY take the form of TYPED-DATA: 4773 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 4774 data-type [0] INTEGER, 4775 data-value [1] OCTET STRING OPTIONAL 4776 } 4778 5.10. Application Tag Numbers 4780 The following table lists the application class tag numbers used 4781 by various data types defined in this section. 4783 Tag Number(s) Type Name Comments 4785 0 unused 4787 1 Ticket PDU 4789 2 Authenticator non-PDU 4791 3 EncTicketPart non-PDU 4793 4-9 unused 4795 10 AS-REQ PDU 4797 11 AS-REP PDU 4799 12 TGS-REQ PDU 4801 13 TGS-REP PDU 4803 14 AP-REQ PDU 4805 15 AP-REP PDU 4807 16 RESERVED16 TGT-REQ (for user-to-user) 4809 17 RESERVED17 TGT-REP (for user-to-user) 4811 18-19 unused 4813 20 KRB-SAFE PDU 4815 21 KRB-PRIV PDU 4817 22 KRB-CRED PDU 4818 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4820 23-24 unused 4822 25 EncASRepPart non-PDU 4824 26 EncTGSRepPart non-PDU 4826 27 EncApRepPart non-PDU 4828 28 EncKrbPrivPart non-PDU 4830 29 EncKrbCredPart non-PDU 4832 30 KRB-ERROR PDU 4834 The ASN.1 types marked as "PDU" (Protocol Data Unit) in the above 4835 are the only ASN.1 types intended as top-level types of the 4836 Kerberos protocol, and are the only types that may be used as 4837 elements in another protocol that makes use of Kerberos. 4839 6. Naming Constraints 4841 6.1. Realm Names 4843 Although realm names are encoded as GeneralStrings and although a 4844 realm can technically select any name it chooses, interoperability 4845 across realm boundaries requires agreement on how realm names are 4846 to be assigned, and what information they imply. 4848 To enforce these conventions, each realm MUST conform to the 4849 conventions itself, and it MUST require that any realms with which 4850 inter-realm keys are shared also conform to the conventions and 4851 require the same from its neighbors. 4853 Kerberos realm names are case sensitive. Realm names that differ 4854 only in the case of the characters are not equivalent. There are 4855 presently three styles of realm names: domain, X500, and other. 4856 Examples of each style follow: 4858 domain: ATHENA.MIT.EDU 4859 X500: C=US/O=OSF 4860 other: NAMETYPE:rest/of.name=without-restrictions 4862 Domain style realm names MUST look like domain names: they consist 4863 of components separated by periods (.) and they contain neither 4864 colons (:) nor slashes (/). Though domain names themselves are 4865 case insensitive, in order for realms to match, the case must 4866 match as well. When establishing a new realm name based on an 4867 internet domain name it is recommended by convention that the 4868 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4870 characters be converted to upper case. 4872 X.500 names contain an equal (=) and cannot contain a colon (:) 4873 before the equal. The realm names for X.500 names will be string 4874 representations of the names with components separated by slashes. 4875 Leading and trailing slashes will not be included. Note that the 4876 slash separator is consistent with Kerberos implementations based 4877 on RFC1510, but it is different from the separator recommended in 4878 RFC2253. 4880 Names that fall into the other category MUST begin with a prefix 4881 that contains no equal (=) or period (.) and the prefix MUST be 4882 followed by a colon (:) and the rest of the name. All prefixes 4883 expect those beginning with used. Presently none are assigned. 4885 The reserved category includes strings which do not fall into the 4886 first three categories. All names in this category are reserved. 4887 It is unlikely that names will be assigned to this category unless 4888 there is a very strong argument for not using the 'other' 4889 category. 4891 These rules guarantee that there will be no conflicts between the 4892 various name styles. The following additional constraints apply to 4893 the assignment of realm names in the domain and X.500 categories: 4894 the name of a realm for the domain or X.500 formats must either be 4895 used by the organization owning (to whom it was assigned) an 4896 Internet domain name or X.500 name, or in the case that no such 4897 names are registered, authority to use a realm name MAY be derived 4898 from the authority of the parent realm. For example, if there is 4899 no domain name for E40.MIT.EDU, then the administrator of the 4900 MIT.EDU realm can authorize the creation of a realm with that 4901 name. 4903 This is acceptable because the organization to which the parent is 4904 assigned is presumably the organization authorized to assign names 4905 to its children in the X.500 and domain name systems as well. If 4906 the parent assigns a realm name without also registering it in the 4907 domain name or X.500 hierarchy, it is the parent's responsibility 4908 to make sure that there will not in the future exist a name 4909 identical to the realm name of the child unless it is assigned to 4910 the same entity as the realm name. 4912 6.2. Principal Names 4914 As was the case for realm names, conventions are needed to ensure 4915 that all agree on what information is implied by a principal name. 4916 The name-type field that is part of the principal name indicates 4917 the kind of information implied by the name. The name-type SHOULD 4918 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4920 be treated only as a hint to interpreting the meaning of a name. 4921 It is not significant when checking for equivalence. Principal 4922 names that differ only in the name-type identify the same 4923 principal. The name type does not partition the name space. 4924 Ignoring the name type, no two names can be the same (i.e. at 4925 least one of the components, or the realm, MUST be different). The 4926 following name types are defined: 4928 name-type value meaning 4930 name types 4932 NT-UNKNOWN 0 Name type not known 4933 NT-PRINCIPAL 1 Just the name of the principal as in DCE, or for users 4934 NT-SRV-INST 2 Service and other unique instance (krbtgt) 4935 NT-SRV-HST 3 Service with host name as instance (telnet, rcommands) 4936 NT-SRV-XHST 4 Service with host as remaining components 4937 NT-UID 5 Unique ID 4938 NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] 4939 NT-SMTP-NAME 7 Name in form of SMTP email name (e.g. user@foo.com) 4940 NT-ENTERPRISE 10 Enterprise name - may be mapped to principal name 4942 When a name implies no information other than its uniqueness at a 4943 particular time the name type PRINCIPAL SHOULD be used. The 4944 principal name type SHOULD be used for users, and it might also be 4945 used for a unique server. If the name is a unique machine 4946 generated ID that is guaranteed never to be reassigned then the 4947 name type of UID SHOULD be used (note that it is generally a bad 4948 idea to reassign names of any type since stale entries might 4949 remain in access control lists). 4951 If the first component of a name identifies a service and the 4952 remaining components identify an instance of the service in a 4953 server specified manner, then the name type of SRV-INST SHOULD be 4954 used. An example of this name type is the Kerberos ticket-granting 4955 service whose name has a first component of krbtgt and a second 4956 component identifying the realm for which the ticket is valid. 4958 If the first component of a name identifies a service and there is 4959 a single component following the service name identifying the 4960 instance as the host on which the server is running, then the name 4961 type SRV-HST SHOULD be used. This type is typically used for 4962 Internet services such as telnet and the Berkeley R commands. If 4963 the separate components of the host name appear as successive 4964 components following the name of the service, then the name type 4965 SRV-XHST SHOULD be used. This type might be used to identify 4966 servers on hosts with X.500 names where the slash (/) might 4967 otherwise be ambiguous. 4969 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 4971 A name type of NT-X500-PRINCIPAL SHOULD be used when a name from 4972 an X.509 certificate is translated into a Kerberos name. The 4973 encoding of the X.509 name as a Kerberos principal shall conform 4974 to the encoding rules specified in RFC 2253. 4976 A name type of SMTP allows a name to be of a form that resembles a 4977 SMTP email name. This name, including an "@" and a domain name, is 4978 used as the one component of the principal name. 4980 A name type of UNKNOWN SHOULD be used when the form of the name is 4981 not known. When comparing names, a name of type UNKNOWN will match 4982 principals authenticated with names of any type. A principal 4983 authenticated with a name of type UNKNOWN, however, will only 4984 match other names of type UNKNOWN. 4986 Names of any type with an initial component of 'krbtgt' are 4987 reserved for the Kerberos ticket granting service. See section 7.3 4988 for the form of such names. 4990 6.2.1. Name of server principals 4992 The principal identifier for a server on a host will generally be 4993 composed of two parts: (1) the realm of the KDC with which the 4994 server is registered, and (2) a two-component name of type NT-SRV- 4995 HST if the host name is an Internet domain name or a multi- 4996 component name of type NT-SRV-XHST if the name of the host is of a 4997 form such as X.500 that allows slash (/) separators. The first 4998 component of the two- or multi-component name will identify the 4999 service and the latter components will identify the host. Where 5000 the name of the host is not case sensitive (for example, with 5001 Internet domain names) the name of the host MUST be lower case. If 5002 specified by the application protocol for services such as telnet 5003 and the Berkeley R commands which run with system privileges, the 5004 first component MAY be the string 'host' instead of a service 5005 specific identifier. 5007 7. Constants and other defined values 5009 7.1. Host address types 5011 All negative values for the host address type are reserved for 5012 local use. All non-negative values are reserved for officially 5013 assigned type fields and interpretations. 5015 Internet (IPv4) Addresses 5017 Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded 5018 in MSB order. The IPv4 loopback address SHOULD NOT appear in a 5019 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5021 Kerberos packet. The type of IPv4 addresses is two (2). 5023 Internet (IPv6) Addresses 5025 IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities, 5026 encoded in MSB order. The type of IPv6 addresses is twenty-four 5027 (24). The following addresses MUST NOT appear in any Kerberos 5028 packet: 5030 * the Unspecified Address 5031 * the Loopback Address 5032 * Link-Local addresses 5034 IPv4-mapped IPv6 addresses MUST be represented as addresses of 5035 type 2. 5037 DECnet Phase IV addresses 5039 DECnet Phase IV addresses are 16-bit addresses, encoded in LSB 5040 order. The type of DECnet Phase IV addresses is twelve (12). 5042 Netbios addresses 5044 Netbios addresses are 16-octet addresses typically composed of 1 5045 to 15 alphanumeric characters and padded with the US-ASCII SPC 5046 character (code 32). The 16th octet MUST be the US-ASCII NUL 5047 character (code 0). The type of Netbios addresses is twenty (20). 5049 Directional Addresses 5051 In many environments, including the sender address in KRB_SAFE and 5052 KRB_PRIV messages is undesirable because the addresses may be 5053 changed in transport by network address translators. However, if 5054 these addresses are removed, the messages may be subject to a 5055 reflection attack in which a message is reflected back to its 5056 originator. The directional address type provides a way to avoid 5057 transport addresses and reflection attacks. Directional addresses 5058 are encoded as four byte unsigned integers in network byte order. 5059 If the message is originated by the party sending the original 5060 KRB_AP_REQ message, then an address of 0 SHOULD be used. If the 5061 message is originated by the party to whom that KRB_AP_REQ was 5062 sent, then the address 1 SHOULD be used. Applications involving 5063 multiple parties can specify the use of other addresses. 5065 Directional addresses MUST only be used for the sender address 5066 field in the KRB_SAFE or KRB_PRIV messages. They MUST NOT be used 5067 as a ticket address or in a KRB_AP_REQ message. This address type 5068 SHOULD only be used in situations where the sending party knows 5069 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5071 that the receiving party supports the address type. This generally 5072 means that directional addresses may only be used when the 5073 application protocol requires their support. Directional addresses 5074 are type (3). 5076 7.2. KDC messaging - IP Transports 5078 Kerberos defines two IP transport mechanisms for communication 5079 between clients and servers: UDP/IP and TCP/IP. 5081 7.2.1. UDP/IP transport 5083 Kerberos servers (KDCs) supporting IP transports MUST accept UDP 5084 requests and SHOULD listen for such requests on port 88 (decimal) 5085 unless specifically configured to listen on an alternative UDP 5086 port. Alternate ports MAY be used when running multiple KDCs for 5087 multiple realms on the same host. 5089 Kerberos clients supporting IP transports SHOULD support the 5090 sending of UDP requests. Clients SHOULD use KDC discovery [7.2.3] 5091 to identify the IP address and port to which they will send their 5092 request. 5094 When contacting a KDC for a KRB_KDC_REQ request using UDP/IP 5095 transport, the client shall send a UDP datagram containing only an 5096 encoding of the request to the KDC. The KDC will respond with a 5097 reply datagram containing only an encoding of the reply message 5098 (either a KRB_ERROR or a KRB_KDC_REP) to the sending port at the 5099 sender's IP address. The response to a request made through UDP/IP 5100 transport MUST also use UDP/IP transport. If the response can not 5101 be handled using UDP (for example because it is too large), the 5102 KDC MUST return KRB_ERR_RESPONSE_TOO_BIG, forcing the client to 5103 retry the request using the TCP transport. 5105 7.2.2. TCP/IP transport 5107 Kerberos servers (KDCs) supporting IP transports MUST accept TCP 5108 requests and SHOULD listen for such requests on port 88 (decimal) 5109 unless specifically configured to listen on an alternate TCP port. 5110 Alternate ports MAY be used when running multiple KDCs for 5111 multiple realms on the same host. 5113 Clients MUST support the sending of TCP requests, but MAY choose 5114 to initially try a request using the UDP transport. Clients SHOULD 5115 use KDC discovery [7.2.3] to identify the IP address and port to 5116 which they will send their request. 5118 Implementation note: Some extensions to the Kerberos protocol will 5119 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5121 not succeed if any client or KDC not supporting the TCP transport 5122 is involved. Implementations of RFC 1510 were not required to 5123 support TCP/IP transports. 5125 When the KRB_KDC_REQ message is sent to the KDC over a TCP stream, 5126 the response (KRB_KDC_REP or KRB_ERROR message) MUST be returned 5127 to the client on the same TCP stream that was established for the 5128 request. The KDC MAY close the TCP stream after sending a 5129 response, but MAY leave the stream open for a reasonable period of 5130 time if it expects a followup. Care must be taken in managing 5131 TCP/IP connections on the KDC to prevent denial of service attacks 5132 based on the number of open TCP/IP connections. 5134 The client MUST be prepared to have the stream closed by the KDC 5135 at anytime after the receipt of a response. A stream closure 5136 SHOULD NOT be treated as a fatal error. Instead, if multiple 5137 exchanges are required (e.g., certain forms of pre-authentication) 5138 the client may need to establish a new connection when it is ready 5139 to send subsequent messages. A client MAY close the stream after 5140 receiving a response, and SHOULD close the stream if it does not 5141 expect to send followup messages. 5143 A client MAY send multiple requests before receiving responses, 5144 though it must be prepared to handle the connection being closed 5145 after the first response. 5147 Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR) 5148 sent over the TCP stream is preceded by the length of the request 5149 as 4 octets in network byte order. The high bit of the length is 5150 reserved for future expansion and MUST currently be set to zero. 5151 If a KDC that does not understand how to interpret a set high bit 5152 of the length encoding receives a request with the high order bit 5153 of the length set, it MUST return a KRB-ERROR message with the 5154 error KRB_ERR_FIELD_TOOLONG and MUST close the TCP stream. 5156 If multiple requests are sent over a single TCP connection, and 5157 the KDC sends multiple responses, the KDC is not required to send 5158 the responses in the order of the corresponding requests. This may 5159 permit some implementations to send each response as soon as it is 5160 ready even if earlier requests are still being processed (for 5161 example, waiting for a response from an external device or 5162 database). 5164 7.2.3. KDC Discovery on IP Networks 5166 Kerberos client implementations MUST provide a means for the 5167 client to determine the location of the Kerberos Key Distribution 5168 Centers (KDCs). Traditionally, Kerberos implementations have 5169 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5171 stored such configuration information in a file on each client 5172 machine. Experience has shown this method of storing configuration 5173 information presents problems with out-of-date information and 5174 scaling problems, especially when using cross-realm 5175 authentication. This section describes a method for using the 5176 Domain Name System [RFC 1035] for storing KDC location 5177 information. 5179 7.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names 5181 In Kerberos, realm names are case sensitive. While it is strongly 5182 encouraged that all realm names be all upper case this 5183 recommendation has not been adopted by all sites. Some sites use 5184 all lower case names and other use mixed case. DNS on the other 5185 hand is case insensitive for queries. Since the realm names 5186 "MYREALM", "myrealm", and "MyRealm" are all different, but resolve 5187 the same in the domain name system, it is necessary that only one 5188 of the possible combinations of upper and lower case characters be 5189 used in realm names. 5191 7.2.3.2. Specifying KDC Location information with DNS SRV records 5193 KDC location information is to be stored using the DNS SRV RR [RFC 5194 2782]. The format of this RR is as follows: 5196 _Service._Proto.Realm TTL Class SRV Priority Weight Port Target 5198 The Service name for Kerberos is always "kerberos". 5200 The Proto can be one of "udp", "tcp". If these SRV records are to 5201 be used, both "udp" and "tcp" records MUST be specified for all 5202 KDC deployments. 5204 The Realm is the Kerberos realm that this record corresponds to. 5205 The realm MUST be a domain style realm name. 5207 TTL, Class, SRV, Priority, Weight, and Target have the standard 5208 meaning as defined in RFC 2782. 5210 As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV 5211 records SHOULD be the value assigned to "kerberos" by the Internet 5212 Assigned Number Authority: 88 (decimal) unless the KDC is 5213 configured to listen on an alternate TCP port. 5215 Implementation note: Many existing client implementations do not 5216 support KDC Discovery and are configured to send requests to the 5217 IANA assigned port (88 decimal), so it is strongly recommended 5218 that KDCs be configured to listen on that port. 5220 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5222 7.2.3.3. KDC Discovery for Domain Style Realm Names on IP Networks 5224 These are DNS records for a Kerberos realm EXAMPLE.COM. It has two 5225 Kerberos servers, kdc1.example.com and kdc2.example.com. Queries 5226 should be directed to kdc1.example.com first as per the specified 5227 priority. Weights are not used in these sample records. 5229 _kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. 5230 _kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. 5231 _kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. 5232 _kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. 5234 7.3. Name of the TGS 5236 The principal identifier of the ticket-granting service shall be 5237 composed of three parts: (1) the realm of the KDC issuing the TGS 5238 ticket (2) a two-part name of type NT-SRV-INST, with the first 5239 part "krbtgt" and the second part the name of the realm which will 5240 accept the ticket-granting ticket. For example, a ticket-granting 5241 ticket issued by the ATHENA.MIT.EDU realm to be used to get 5242 tickets from the ATHENA.MIT.EDU KDC has a principal identifier of 5243 "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A 5244 ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be 5245 used to get tickets from the MIT.EDU realm has a principal 5246 identifier of "ATHENA.MIT.EDU" (realm), ("krbtgt", "MIT.EDU") 5247 (name). 5249 7.4. OID arc for KerberosV5 5251 This OID MAY be used to identify Kerberos protocol messages 5252 encapsulated in other protocols. It also designates the OID arc 5253 for KerberosV5-related OIDs assigned by future IETF action. 5254 Implementation note:: RFC 1510 had an incorrect value (5) for 5255 "dod" in its OID. 5257 id-krb5 OBJECT IDENTIFIER ::= { 5258 iso(1) identified-organization(3) dod(6) internet(1) 5259 security(5) kerberosV5(2) 5260 } 5262 Assignment of OIDs beneath the id-krb5 arc must be obtained by 5263 contacting the registrar for the id-krb5 arc, or its designee. At 5264 the time of the issuance of this RFC, such registrations can be 5265 obtained by contacting krb5-oid-registrar@mit.edu. 5267 7.5. Protocol constants and associated values 5268 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5270 The following tables list constants used in the protocol and 5271 define their meanings. Ranges are specified in the "specification" 5272 section that limit the values of constants for which values are 5273 defined here. This allows implementations to make assumptions 5274 about the maximum values that will be received for these 5275 constants. Implementation receiving values outside the range 5276 specified in the "specification" section MAY reject the request, 5277 but they MUST recover cleanly. 5279 7.5.1. Key usage numbers 5281 The encryption and checksum specifications in [@KCRYPTO] require 5282 as input a "key usage number", to alter the encryption key used in 5283 any specific message, to make certain types of cryptographic 5284 attack more difficult. These are the key usage values assigned in 5285 this document: 5287 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted 5288 with the client key (section 5.2.7.2) 5289 2. AS-REP Ticket and TGS-REP Ticket (includes TGS session 5290 key or application session key), encrypted with the 5291 service key (section 5.3) 5292 3. AS-REP encrypted part (includes TGS session key or 5293 application session key), encrypted with the client key 5294 (section 5.4.2) 5295 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with 5296 the TGS session key (section 5.4.1) 5297 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with 5298 the TGS authenticator subkey (section 5.4.1) 5299 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, 5300 keyed with the TGS session key (sections 5.5.1) 5301 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator 5302 (includes TGS authenticator subkey), encrypted with the 5303 TGS session key (section 5.5.1) 5304 8. TGS-REP encrypted part (includes application session 5305 key), encrypted with the TGS session key (section 5306 5.4.2) 5307 9. TGS-REP encrypted part (includes application session 5308 key), encrypted with the TGS authenticator subkey 5309 (section 5.4.2) 5310 10. AP-REQ Authenticator cksum, keyed with the application 5311 session key (section 5.5.1) 5312 11. AP-REQ Authenticator (includes application 5313 authenticator subkey), encrypted with the application 5314 session key (section 5.5.1) 5315 12. AP-REP encrypted part (includes application session 5316 subkey), encrypted with the application session key 5317 (section 5.5.2) 5318 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5320 13. KRB-PRIV encrypted part, encrypted with a key chosen by 5321 the application (section 5.7.1) 5322 14. KRB-CRED encrypted part, encrypted with a key chosen by 5323 the application (section 5.8.1) 5324 15. KRB-SAFE cksum, keyed with a key chosen by the 5325 application (section 5.6.1) 5326 19. AD-KDC-ISSUED checksum (ad-checksum in 5.2.6.4) 5327 22-25. Reserved for use in GSSAPI mechanisms derived from RFC 5328 1964. (raeburn/MIT) 5329 16-18,20-21,26-511. Reserved for future use in Kerberos and related 5330 protocols. 5331 512-1023. Reserved for uses internal to a Kerberos 5332 implementation. 5333 1024. Encryption for application use in protocols that 5334 do not specify key usage values 5335 1025. Checksums for application use in protocols that 5336 do not specify key usage values 5337 1026-2047. Reserved for application use. 5339 7.5.2. PreAuthentication Data Types 5341 padata and data types padata-type value comment 5343 PA-TGS-REQ 1 5344 PA-ENC-TIMESTAMP 2 5345 PA-PW-SALT 3 5346 [reserved] 4 5347 PA-ENC-UNIX-TIME 5 (deprecated) 5348 PA-SANDIA-SECUREID 6 5349 PA-SESAME 7 5350 PA-OSF-DCE 8 5351 PA-CYBERSAFE-SECUREID 9 5352 PA-AFS3-SALT 10 5353 PA-ETYPE-INFO 11 5354 PA-SAM-CHALLENGE 12 (sam/otp) 5355 PA-SAM-RESPONSE 13 (sam/otp) 5356 PA-PK-AS-REQ 14 (pkinit) 5357 PA-PK-AS-REP 15 (pkinit) 5358 PA-ETYPE-INFO2 19 (replaces pa-etype-info) 5359 PA-USE-SPECIFIED-KVNO 20 5360 PA-SAM-REDIRECT 21 (sam/otp) 5361 PA-GET-FROM-TYPED-DATA 22 (embedded in typed data) 5362 TD-PADATA 22 (embeds padata) 5363 PA-SAM-ETYPE-INFO 23 (sam/otp) 5364 PA-ALT-PRINC 24 (crawdad@fnal.gov) 5365 PA-SAM-CHALLENGE2 30 (kenh@pobox.com) 5366 PA-SAM-RESPONSE2 31 (kenh@pobox.com) 5367 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5369 PA-EXTRA-TGT 41 Reserved extra TGT 5370 TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS 5371 TD-KRB-PRINCIPAL 102 PrincipalName 5372 TD-KRB-REALM 103 Realm 5373 TD-TRUSTED-CERTIFIERS 104 from PKINIT 5374 TD-CERTIFICATE-INDEX 105 from PKINIT 5375 TD-APP-DEFINED-ERROR 106 application specific 5376 TD-REQ-NONCE 107 INTEGER 5377 TD-REQ-SEQ 108 INTEGER 5378 PA-PAC-REQUEST 128 (jbrezak@exchange.microsoft.com) 5380 7.5.3. Address Types 5382 Address type value 5384 IPv4 2 5385 Directional 3 5386 ChaosNet 5 5387 XNS 6 5388 ISO 7 5389 DECNET Phase IV 12 5390 AppleTalk DDP 16 5391 NetBios 20 5392 IPv6 24 5394 7.5.4. Authorization Data Types 5396 authorization data type ad-type value 5397 AD-IF-RELEVANT 1 5398 AD-INTENDED-FOR-SERVER 2 5399 AD-INTENDED-FOR-APPLICATION-CLASS 3 5400 AD-KDC-ISSUED 4 5401 AD-AND-OR 5 5402 AD-MANDATORY-TICKET-EXTENSIONS 6 5403 AD-IN-TICKET-EXTENSIONS 7 5404 AD-MANDATORY-FOR-KDC 8 5405 reserved values 9-63 5406 OSF-DCE 64 5407 SESAME 65 5408 AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com) 5409 AD-WIN2K-PAC 128 (jbrezak@exchange.microsoft.com) 5411 7.5.5. Transited Encoding Types 5413 transited encoding type tr-type value 5414 DOMAIN-X500-COMPRESS 1 5415 reserved values all others 5416 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5418 7.5.6. Protocol Version Number 5420 Label Value Meaning or MIT code 5422 pvno 5 current Kerberos protocol version number 5424 7.5.7. Kerberos Message Types 5426 message types 5428 KRB_AS_REQ 10 Request for initial authentication 5429 KRB_AS_REP 11 Response to KRB_AS_REQ request 5430 KRB_TGS_REQ 12 Request for authentication based on TGT 5431 KRB_TGS_REP 13 Response to KRB_TGS_REQ request 5432 KRB_AP_REQ 14 application request to server 5433 KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL 5434 KRB_RESERVED16 16 Reserved for user-to-user krb_tgt_request 5435 KRB_RESERVED17 17 Reserved for user-to-user krb_tgt_reply 5436 KRB_SAFE 20 Safe (checksummed) application message 5437 KRB_PRIV 21 Private (encrypted) application message 5438 KRB_CRED 22 Private (encrypted) message to forward credentials 5439 KRB_ERROR 30 Error response 5441 7.5.8. Name Types 5443 name types 5445 KRB_NT_UNKNOWN 0 Name type not known 5446 KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users 5447 KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) 5448 KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands) 5449 KRB_NT_SRV_XHST 4 Service with host as remaining components 5450 KRB_NT_UID 5 Unique ID 5451 KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] 5452 KRB_NT_SMTP_NAME 7 Name in form of SMTP email name (e.g. user@foo.com) 5453 KRB_NT_ENTERPRISE 10 Enterprise name - may be mapped to principal name 5455 7.5.9. Error Codes 5457 error codes 5459 KDC_ERR_NONE 0 No error 5460 KDC_ERR_NAME_EXP 1 Client's entry in database has expired 5461 KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired 5462 KDC_ERR_BAD_PVNO 3 Requested protocol version number 5463 not supported 5464 KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key 5465 KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key 5466 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5468 KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database 5469 KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database 5470 KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database 5471 KDC_ERR_NULL_KEY 9 The client or server has a null key 5472 KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating 5473 KDC_ERR_NEVER_VALID 11 Requested start time is later than end time 5474 KDC_ERR_POLICY 12 KDC policy rejects request 5475 KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option 5476 KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type 5477 KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type 5478 KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type 5479 KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type 5480 KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked 5481 KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked 5482 KDC_ERR_TGT_REVOKED 20 TGT has been revoked 5483 KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later 5484 KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later 5485 KDC_ERR_KEY_EXPIRED 23 Password has expired 5486 - change password to reset 5487 KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid 5488 KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired 5489 KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match 5490 KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user only 5491 KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path 5492 KDC_ERR_SVC_UNAVAILABLE 29 A service is not available 5493 KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed 5494 KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired 5495 KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid 5496 KRB_AP_ERR_REPEAT 34 Request is a replay 5497 KRB_AP_ERR_NOT_US 35 The ticket isn't for us 5498 KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match 5499 KRB_AP_ERR_SKEW 37 Clock skew too great 5500 KRB_AP_ERR_BADADDR 38 Incorrect net address 5501 KRB_AP_ERR_BADVERSION 39 Protocol version mismatch 5502 KRB_AP_ERR_MSG_TYPE 40 Invalid msg type 5503 KRB_AP_ERR_MODIFIED 41 Message stream modified 5504 KRB_AP_ERR_BADORDER 42 Message out of order 5505 KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available 5506 KRB_AP_ERR_NOKEY 45 Service key not available 5507 KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed 5508 KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction 5509 KRB_AP_ERR_METHOD 48 Alternative authentication method required 5510 KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message 5511 KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message 5512 KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path 5513 KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP, retry with TCP 5514 KRB_ERR_GENERIC 60 Generic error (description in e-text) 5515 KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation 5516 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5518 KDC_ERROR_CLIENT_NOT_TRUSTED 62 Reserved for PKINIT 5519 KDC_ERROR_KDC_NOT_TRUSTED 63 Reserved for PKINIT 5520 KDC_ERROR_INVALID_SIG 64 Reserved for PKINIT 5521 KDC_ERR_KEY_TOO_WEAK 65 Reserved for PKINIT 5522 KDC_ERR_CERTIFICATE_MISMATCH 66 Reserved for PKINIT 5523 KRB_AP_ERR_NO_TGT 67 No TGT available to validate USER-TO-USER 5524 KDC_ERR_WRONG_REALM 68 USER-TO-USER TGT issued different KDC 5525 KRB_AP_ERR_USER_TO_USER_REQUIRED 69 Ticket must be for USER-TO-USER 5526 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 Reserved for PKINIT 5527 KDC_ERR_INVALID_CERTIFICATE 71 Reserved for PKINIT 5528 KDC_ERR_REVOKED_CERTIFICATE 72 Reserved for PKINIT 5529 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 Reserved for PKINIT 5530 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 Reserved for PKINIT 5531 KDC_ERR_CLIENT_NAME_MISMATCH 75 Reserved for PKINIT 5532 KDC_ERR_KDC_NAME_MISMATCH 76 Reserved for PKINIT 5534 8. Interoperability requirements 5536 Version 5 of the Kerberos protocol supports a myriad of options. 5537 Among these are multiple encryption and checksum types, 5538 alternative encoding schemes for the transited field, optional 5539 mechanisms for pre-authentication, the handling of tickets with no 5540 addresses, options for mutual authentication, user-to-user 5541 authentication, support for proxies, forwarding, postdating, and 5542 renewing tickets, the format of realm names, and the handling of 5543 authorization data. 5545 In order to ensure the interoperability of realms, it is necessary 5546 to define a minimal configuration which must be supported by all 5547 implementations. This minimal configuration is subject to change 5548 as technology does. For example, if at some later date it is 5549 discovered that one of the required encryption or checksum 5550 algorithms is not secure, it will be replaced. 5552 8.1. Specification 2 5554 This section defines the second specification of these options. 5555 Implementations which are configured in this way can be said to 5556 support Kerberos Version 5 Specification 2 (5.2). Specification 1 5557 (deprecated) may be found in RFC1510. 5559 Transport 5561 TCP/IP and UDP/IP transport MUST be supported by clients and KDCs 5562 claiming conformance to specification 2. 5564 Encryption and checksum methods 5565 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5567 The following encryption and checksum mechanisms MUST be 5568 supported. 5570 Encryption: AES256-CTS-HMAC-SHA1-96 5571 Checksums: HMAC-SHA1-96-AES256 5573 Implementations SHOULD support other mechanisms as well, but the 5574 additional mechanisms may only be used when communicating with 5575 principals known to also support them. The mechanisms that SHOULD 5576 be supported are: 5578 Encryption: DES-CBC-MD5, DES3-CBC-SHA1-KD 5579 Checksums: DES-MD5, HMAC-SHA1-DES3-KD 5581 Implementations MAY support other mechanisms as well, but the 5582 additional mechanisms may only be used when communicating with 5583 principals known to also support them. 5585 Implementation note: earlier implementations of Kerberos generate 5586 messages using the CRC-32, RSA-MD5 checksum methods. For 5587 interoperability with these earlier releases implementors MAY 5588 consider supporting these checksum methods but should carefully 5589 analyze the security impplications to limit the situations within 5590 which these methods are accepted. 5592 Realm Names 5594 All implementations MUST understand hierarchical realms in both 5595 the Internet Domain and the X.500 style. When a ticket-granting 5596 ticket for an unknown realm is requested, the KDC MUST be able to 5597 determine the names of the intermediate realms between the KDCs 5598 realm and the requested realm. 5600 Transited field encoding 5602 DOMAIN-X500-COMPRESS (described in section 3.3.3.2) MUST be 5603 supported. Alternative encodings MAY be supported, but they may 5604 be used only when that encoding is supported by ALL intermediate 5605 realms. 5607 Pre-authentication methods 5609 The TGS-REQ method MUST be supported. The TGS-REQ method is not 5610 used on the initial request. The PA-ENC-TIMESTAMP method MUST be 5611 supported by clients but whether it is enabled by default MAY be 5612 determined on a realm by realm basis. If not used in the initial 5613 request and the error KDC_ERR_PREAUTH_REQUIRED is returned 5614 specifying PA-ENC-TIMESTAMP as an acceptable method, the client 5615 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5617 SHOULD retry the initial request using the PA-ENC-TIMESTAMP pre- 5618 authentication method. Servers need not support the PA-ENC- 5619 TIMESTAMP method, but if not supported the server SHOULD ignore 5620 the presence of PA-ENC-TIMESTAMP pre-authentication in a request. 5622 The ETYPE-INFO2 method MUST be supported; this method is used to 5623 communicate the set of supported encryption types, and 5624 corresponding salt and string to key paramters. The ETYPE-INFO 5625 method SHOULD be supported for interoperability with older 5626 implementation. 5628 Mutual authentication 5630 Mutual authentication (via the KRB_AP_REP message) MUST be 5631 supported. 5633 Ticket addresses and flags 5635 All KDCs MUST pass through tickets that carry no addresses (i.e. 5636 if a TGT contains no addresses, the KDC will return derivative 5637 tickets). Implementations SHOULD default to requesting 5638 addressless tickets as this significantly increases 5639 interoperability with network address translation. In some cases 5640 realms or application servers MAY require that tickets have an 5641 address. 5643 Implementations SHOULD accept directional address type for the 5644 KRB_SAFE and KRB_PRIV message and SHOULD include directional 5645 addresses in these messages when other address types are not 5646 available. 5648 Proxies and forwarded tickets MUST be supported. Individual realms 5649 and application servers can set their own policy on when such 5650 tickets will be accepted. 5652 All implementations MUST recognize renewable and postdated 5653 tickets, but need not actually implement them. If these options 5654 are not supported, the starttime and endtime in the ticket shall 5655 specify a ticket's entire useful life. When a postdated ticket is 5656 decoded by a server, all implementations shall make the presence 5657 of the postdated flag visible to the calling server. 5659 User-to-user authentication 5661 Support for user-to-user authentication (via the ENC-TKT-IN-SKEY 5662 KDC option) MUST be provided by implementations, but individual 5663 realms MAY decide as a matter of policy to reject such requests on 5664 a per-principal or realm-wide basis. 5666 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5668 Authorization data 5670 Implementations MUST pass all authorization data subfields from 5671 ticket-granting tickets to any derivative tickets unless directed 5672 to suppress a subfield as part of the definition of that 5673 registered subfield type (it is never incorrect to pass on a 5674 subfield, and no registered subfield types presently specify 5675 suppression at the KDC). 5677 Implementations MUST make the contents of any authorization data 5678 subfields available to the server when a ticket is used. 5679 Implementations are not required to allow clients to specify the 5680 contents of the authorization data fields. 5682 Constant ranges 5684 All protocol constants are constrained to 32 bit (signed) values 5685 unless further constrained by the protocol definition. This limit 5686 is provided to allow implementations to make assumptions about the 5687 maximum values that will be received for these constants. 5688 Implementation receiving values outside this range MAY reject the 5689 request, but they MUST recover cleanly. 5691 8.2. Recommended KDC values 5693 Following is a list of recommended values for a KDC configuration. 5695 minimum lifetime 5 minutes 5696 maximum renewable lifetime 1 week 5697 maximum ticket lifetime 1 day 5698 acceptable clock skew 5 minutes 5699 empty addresses Allowed. 5700 proxiable, etc. Allowed. 5702 9. IANA considerations 5704 Section 7 of this document specifies protocol constants and other 5705 defined values required for the interoperability of multiple 5706 implementations. Until otherwise specified in a subsequent RFC, or 5707 upon disbanding of the Kerberos working group, allocations of 5708 additional protocol constants and other defined values required 5709 for extensions to the Kerberos protocol will be administered by 5710 the kerberos working group. Following the recomendations outlined 5711 in [RFC 2434], guidance is provided to the IANA as follows: 5713 "reserved" realm name types in section 6.1 and "other" realm types 5714 except those beginning with "X-" or "x-" will not be registered 5715 without IETF standards action, at which point guidlines for 5716 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5718 further assignment will be specified. Realm name types beginning 5719 with "X-" or "x-" are for private use. 5721 For host address types described in section 7.1, negative values 5722 are for private use. Assignment of additional positive numbers is 5723 subject to review by the kerberos working group or other expert 5724 review. 5726 Additional key usage numbers as defined in section 7.5.1 will be 5727 assigned subject to review by the kerberos working group or other 5728 expert review. 5730 Additional preauthentciation data type values as defined in 5731 section 7.5.2 will be assigned subject to review by the kerberos 5732 working group or other expert review. 5734 Additional Authorization Data Types as defined in section 7.5.4 5735 will be assigned subject to review by the kerberos working group 5736 or other expert review. Although it is anticipated that there may 5737 be significant demand for private use types, provision is 5738 intentionaly not made for a private use portion of the namespace 5739 because conficts between privately assigned values coule have 5740 detrimental security implications. 5742 Additional Transited Encoding Types as defined in section 7.5.5 5743 present special concerns for interoperability with existing 5744 implementations. As such, such assignments will only be made by 5745 standards action, except that the Kerberos working group or 5746 another other working group with competent jurisdiction may make 5747 preliminary assignments for documents which are moving through the 5748 standards process. 5750 Additional Kerberos Message Types as described in section 7.5.7 5751 will be assigned subject to review by the kerberos working group 5752 or other expert review. 5754 Additional Name Types as described in section 7.5.8 will be 5755 assigned subject to review by the kerberos working group or other 5756 expert review. 5758 Additional error codes described in section 7.5.9 will be assigned 5759 subject to review by the kerberos working group or other expert 5760 review. 5762 10. Security Considerations 5764 As an authentication service, Kerberos provides a means of 5765 verifying the identity of principals on a network. Kerberos does 5766 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5768 not, by itself, provide authorization. Applications should not 5769 accept the issuance of a service ticket by the Kerberos server as 5770 granting authority to use the service, since such applications may 5771 become vulnerable to the bypass of this authorization check in an 5772 environment if they inter-operate with other KDCs or where other 5773 options for application authentication are provided. 5775 Denial of service attacks are not solved with Kerberos. There are 5776 places in the protocols where an intruder can prevent an 5777 application from participating in the proper authentication steps. 5778 Because authentication is a required step for the use of many 5779 services, successful denial of service attacks on a Kerberos 5780 server might result in the denial of other network services that 5781 rely on Kerberos for authentication. Kerberos is vulnerable to 5782 many kinds of denial of service attacks: denial of service attacks 5783 on the network which would prevent clients from contacting the 5784 KDC; denial of service attacks on the domain name system which 5785 could prevent a client from finding the IP address of the Kerberos 5786 server; and denial of service attack by overloading the Kerberos 5787 KDC itself with repeated requests. 5789 Interoperability conflicts caused by incompatible character-set 5790 usage (see 5.2.1) can result in denial of service for clients that 5791 utilize character-sets in Kerberos strings other than those stored 5792 in the KDC database. 5794 Authentication servers maintain a database of principals (i.e., 5795 users and servers) and their secret keys. The security of the 5796 authentication server machines is critical. The breach of security 5797 of an authentication server will compromise the security of all 5798 servers that rely upon the compromised KDC, and will compromise 5799 the authentication of any principals registered in the realm of 5800 the compromised KDC. 5802 Principals must keep their secret keys secret. If an intruder 5803 somehow steals a principal's key, it will be able to masquerade as 5804 that principal or impersonate any server to the legitimate 5805 principal. 5807 Password guessing attacks are not solved by Kerberos. If a user 5808 chooses a poor password, it is possible for an attacker to 5809 successfully mount an off-line dictionary attack by repeatedly 5810 attempting to decrypt, with successive entries from a dictionary, 5811 messages obtained which are encrypted under a key derived from the 5812 user's password. 5814 Unless pre-authentication options are required by the policy of a 5815 realm, the KDC will not know whether a request for authentication 5816 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5818 succeeds. An attacker can request a reply with credentials for any 5819 principal. These credentials will likely not be of much use to the 5820 attacker unless it knows the client's secret key, but the 5821 availability of the response encrypted in the client's secret key 5822 provides the attacker with ciphertext that may be used to mount 5823 brute force or dictionary attacks to decrypt the credentials, by 5824 guessing the user's password. For this reason it is strongly 5825 encouraged that Kerberos realms require the use of pre- 5826 authentication. Even with pre-authentication, attackers may try 5827 brute force or dictionary attacks against credentials that are 5828 observed by eavesdropping on the network. 5830 Because a client can request a ticket for any server principal and 5831 can attempt a brute force or dictionary attack against the server 5832 principal's key using that ticket, it is strongly encouraged that 5833 keys be randomly generated (rather than generated from passwords) 5834 for any principals that are usable as the target principal for a 5835 KRB_TGS_REQ or KRB_AS_REQ messages. [RFC1750] 5837 Although the DES-CBC-MD5 encryption method and DES-MD5 checksum 5838 methods are listed as SHOULD be implemented for backward 5839 compatibility, the single DES encryption algorithm on which these 5840 are based is weak and stronger algorithms should be used whenever 5841 possible. 5843 Each host on the network must have a clock which is loosely 5844 synchronized to the time of the other hosts; this synchronization 5845 is used to reduce the bookkeeping needs of application servers 5846 when they do replay detection. The degree of "looseness" can be 5847 configured on a per-server basis, but is typically on the order of 5848 5 minutes. If the clocks are synchronized over the network, the 5849 clock synchronization protocol MUST itself be secured from network 5850 attackers. 5852 Principal identifiers must not recycled on a short-term basis. A 5853 typical mode of access control will use access control lists 5854 (ACLs) to grant permissions to particular principals. If a stale 5855 ACL entry remains for a deleted principal and the principal 5856 identifier is reused, the new principal will inherit rights 5857 specified in the stale ACL entry. By not reusing principal 5858 identifiers, the danger of inadvertent access is removed. 5860 Proper decryption of an KRB_AS_REP message from the KDC is not 5861 sufficient for the host to verify the identity of the user; the 5862 user and an attacker could cooperate to generate a KRB_AS_REP 5863 format message which decrypts properly but is not from the proper 5864 KDC. To authenticate a user logging on to a local system, the 5865 credentials obtained in the AS exchange may first be used in a TGS 5866 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5868 exchange to obtain credentials for a local server. Those 5869 credentials must then be verified by a local server through 5870 successful completion of the Client/Server exchange. 5872 Many RFC 1510 compliant implementations ignore unknown 5873 authorization data elements. Depending on these implementations to 5874 honor authorization data restrictions may create a security 5875 weakness. 5877 Kerberos credentials contain clear-text information identifying 5878 the principals to which they apply. If privacy of this information 5879 is needed, this exchange should itself be encapsulated in a 5880 protocol providing for confidentiality on the exchange of these 5881 credentials. 5883 Applications must take care to protect communications subsequent 5884 to authentication either by using the KRB_PRIV or KRB_SAFE 5885 messages as appropriate, or by applying their own confidentiality 5886 or integrity mechanisms on such communications. Completion of the 5887 KRB_AP_REQ and KRB_AP_REP exchange without subsequent use of 5888 confidentiality and integrity mechanisms provides only for 5889 authentication of the parties to the communication and not 5890 confidentiality and integrity of the subsequent communication. 5891 Application applying confidentiality and integrity protection 5892 mechanisms other than KRB_PRIV and KRB_SAFE must make sure that 5893 the authentication step is appropriately linked with the protected 5894 communication channel that is established by the application. 5896 Unless the application server provides its own suitable means to 5897 protect against replay (for example, a challenge-response sequence 5898 initiated by the server after authentication, or use of a server- 5899 generated encryption subkey), the server must utilize a replay 5900 cache to remember any authenticator presented within the allowable 5901 clock skew. All services sharing a key need to use the same replay 5902 cache. If separate replay caches are used, then and authenticator 5903 used with one such service could later be replayed to a different 5904 service with the same service principal. 5906 If a server loses track of authenticators presented within the 5907 allowable clock skew, it must reject all requests until the clock 5908 skew interval has passed, providing assurance that any lost or 5909 replayed authenticators will fall outside the allowable clock skew 5910 and can no longer be successfully replayed. 5912 Implementations of Kerberos should not use untrusted directory 5913 servers to determine the realm of a host. To allow such would 5914 allow the compromise of the directory server to enable an attacker 5915 to direct the client to accept authentication with the wrong 5916 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5918 principal (i.e. one with a similar name, but in a realm with which 5919 the legitimate host was not registered). 5921 Implementations of Kerberos must not use DNS to map one name to 5922 another (canonicalize) to determine the host part of the principal 5923 name with which one is to communicate. To allow such 5924 canonicalization would allow a compromise of the DNS to result in 5925 a client obtaining credentials and correctly authenticating to the 5926 wrong principal. Though the client will know who it is 5927 communicating with, it will not be the principal with which it 5928 intended to communicate. 5930 If the Kerberos server returns a TGT for a 'closer' realm other 5931 than the desired realm, the client may use local policy 5932 configuration to verify that the authentication path used is an 5933 acceptable one. Alternatively, a client may choose its own 5934 authentication path, rather than relying on the Kerberos server to 5935 select one. In either case, any policy or configuration 5936 information used to choose or validate authentication paths, 5937 whether by the Kerberos server or client, must be obtained from a 5938 trusted source. 5940 The Kerberos protocol in its basic form does not provide perfect 5941 forward secrecy for communications. If traffic has been recorded 5942 by an eavesdropper, then messages encrypted using the KRB_PRIV 5943 message, or messages encrypted using application specific 5944 encryption under keys exchanged using Kerberos can be decrypted if 5945 any of the user's, application server's, or KDC's key is 5946 subsequently discovered. This is because the session key use to 5947 encrypt such messages is transmitted over the network encrypted in 5948 the key of the application server, and also encrypted under the 5949 session key from the user's ticket-granting ticket when returned 5950 to the user in the KRB_TGS_REP message. The session key from the 5951 ticket-granting ticket was sent to the user in the KRB_AS_REP 5952 message encrypted in the user's secret key, and embedded in the 5953 ticket-granting ticket, which was encrypted in the key of the KDC. 5954 Application requiring perfect forward secrecy must exchange keys 5955 through mechanisms that provide such assurance, but may use 5956 Kerberos for authentication of the encrypted channel established 5957 through such other means. 5959 11. Author's Addresses 5961 Clifford Neuman 5962 Information Sciences Institute 5963 University of Southern California 5964 4676 Admiralty Way 5965 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 5967 Marina del Rey, CA 90292, USA 5968 Email: bcn@isi.edu 5970 Tom Yu 5971 Massachusetts Institute of Technology 5972 77 Massachusetts Avenue 5973 Cambridge, MA 02139, USA 5974 Email: tlyu@mit.edu 5976 Sam Hartman 5977 Massachusetts Institute of Technology 5978 77 Massachusetts Avenue 5979 Cambridge, MA 02139, USA 5980 Email: hartmans@mit.edu 5982 Kenneth Raeburn 5983 Massachusetts Institute of Technology 5984 77 Massachusetts Avenue 5985 Cambridge, MA 02139, USA 5986 Email: raeburn@MIT.EDU 5988 12. Acknowledgements 5990 This document is a revision to RFC1510 which was co-authored with 5991 John Kohl. The specification of the Kerberos protocol described 5992 in this document is the result of many years of effort. Over this 5993 period many individuals have contributed to the definition of the 5994 protocol and to the writing of the specification. Unfortunately it 5995 is not possible to list all contributors as authors of this 5996 document, though there are many not listed who are authors in 5997 spirit, because they contributed text for parts of some sections, 5998 because they contributed to the design of parts of the protocol, 5999 or because they contributed significantly to the discussion of the 6000 protocol in the IETF common authentication technology (CAT) and 6001 Kerberos working groups. 6003 Among those contributing to the development and specification of 6004 Kerberos were Jeffrey Altman, John Brezak, Marc Colan, Johan 6005 Danielsson, Don Davis, Doug Engert, Dan Geer, Paul Hill, John 6006 Kohl, Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John 6007 Linn, Ari Medvinsky, Sasha Medvinsky, Steve Miller, Jon Rochlis, 6008 Jerome Saltzer, Jeffrey Schiller, Jennifer Steiner, Ralph Swick, 6009 Mike Swift, Jonathan Trostle, Theodore Ts'o, Brian Tung, Jacques 6010 Vidrine, Assar Westerlund, and Nicolas Williams. Many other 6011 members of MIT Project Athena, the MIT networking group, and the 6012 Kerberos and CAT working groups of the IETF contributed but are 6013 not listed. 6015 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6017 Funding for the RFC Editor function is currently provided by the 6018 Internet Society. 6020 13. REFERENCES 6022 13.1 NORMATIVE REFERENCES 6024 [@KCRYPTO] 6025 RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg- 6026 crypto. 6028 [@AES] 6029 RFC-Editor: To be replaced by RFC number for draft-raeburn0krb- 6030 rijndael-krb. 6032 [ISO-646/ECMA-6] 6033 7-bit Coded Character Set 6035 [ISO-2022/ECMA-35] 6036 Character Code Structure and Extension Techniques 6038 [ISO-4873/ECMA-43] 6039 8-bit Coded Character Set Structure and Rules 6041 [RFC1035] 6042 P.V. Mockapetris, RFC1035: "Domain Names - Implementations and 6043 Specification," November 1, 1987, Obsoletes - RFC973, RFC882, 6044 RFC883. Updated by RFC1101, RFC1183, RFC1348, RFCRFC1876, RFC1982, 6045 RFC1995, RFC1996, RFC2065, RFC2136, RFC2137, RFC2181, RFC2308, 6046 RFC2535, RFC2845, and RFC3425. Status: Standard. 6048 [RFC2119] 6050 S. Bradner, RFC2119: "Key words for use in RFC's to Indicate 6051 Requirement Levels", March 1997. 6053 [RFC2434] 6054 T. Narten, H. Alvestrand, RFC2434: "Guidelines for writing IANA 6055 Consideration Secionts in RFCs" October, 1998. 6057 [RFC2782] 6058 A. Gulbrandsen, P. Vixie and L. Esibov., RFC2782: "A DNS RR for 6059 Specifying the Location of Services (DNS SRV)," February 2000. 6061 [RFC2253] 6062 M. Wahl, S. Killie, and T. Howes, RFC2253: "Lightweight Directory 6063 Access Protocol (v3): UTF-8 String Representation or Distinguished 6064 Names," December 1997, Obsoletes - RFC1779, Updated by RFC3377, 6065 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6067 Status: Proposed Standard. 6069 [RFC2373] 6070 R. Hinden, S. Deering, RFC2373: "IP Version 6 Addressing 6071 Architecture," July 1998, Status: Proposed Standard. 6073 [X680] 6074 Abstract Syntax Notation One (ASN.1): Specification of Basic 6075 Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC 6076 International Standard 8824-1:1998. 6078 [X690] 6079 ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), 6080 Canonical Encoding Rules (CER) and Distinguished Encoding Rules 6081 (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International 6082 Standard 8825-1:1998. 6084 13.2 INFORMATIVE REFERENCES 6086 [DGT96] 6087 Don Davis, Daniel Geer, and Theodore Ts'o, "Kerberos With Clocks 6088 Adrift: History, Protocols, and Implementation", USENIX Computing 6089 Systems 9:1 (January 1996). 6091 [DS81] 6092 Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key 6093 Distribution Protocols," Communications of the ACM, Vol. 24(8), 6094 pp. 533-536 (August 1981). 6096 [KNT94] 6098 John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The 6099 Evolution of the Kerberos Authentication System". In Distributed 6100 Open Systems, pages 78-94. IEEE Computer Society Press, 1994. 6102 [MNSS87] 6103 S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer, 6104 Section E.2.1: Kerberos Authentication and Authorization System, 6105 M.I.T. Project Athena, Cambridge, Massachusetts (December 21, 6106 1987). 6108 [NS78] 6109 Roger M. Needham and Michael D. Schroeder, "Using Encryption for 6110 Authentication in Large Networks of Computers," Communications of 6111 the ACM, Vol. 21(12), pp. 993-999 (December, 1978). 6113 [Neu93] 6114 B. Clifford Neuman, "Proxy-Based Authorization and Accounting for 6115 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6117 Distributed Systems," in Proceedings of the 13th International 6118 Conference on Distributed Computing Systems, Pittsburgh, PA (May, 6119 1993). 6121 [NT94] 6122 B. Clifford Neuman and Theodore Y. Ts'o, "An Authentication 6123 Service for Computer Networks," IEEE Communications Magazine, Vol. 6124 32(9), pp. 33-38 (September 1994). 6126 [Pat92]. 6127 J. Pato, Using Pre-Authentication to Avoid Password Guessing 6128 Attacks, Open Software Foundation DCE Request for Comments 26 6129 (December 1992). 6131 [RFC1510] 6132 J. Kohl and B. C. Neuman, RFC1510: "The Kerberos Network 6133 Authentication Service (v5)," September 1993, Status: Proposed 6134 Standard. 6136 [RFC1750] 6137 D. Eastlake, S. Crocker, and J. Schiller "Randomness 6138 Recommendation for Security" December 1994, Status: Informational. 6140 [RFC2026] 6141 S. Bradner, RFC2026: "The Internet Standard Process - Revision 6142 3," October 1996, Obsoletes - RFC 1602, Status: Best Current 6143 Practice. 6145 [SNS88] 6146 J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Kerberos: An 6147 Authentication Service for Open Network Systems," pp. 191-202 in 6148 Usenix Conference Proceedings, Dallas, Texas (February, 1988). 6150 14. Copyright Statement 6152 Copyright (C) The Internet Society (2004). This document is 6153 subject to the rights, licenses and restrictions contained in BCP 6154 78 and except as set forth therein, the authors retain all their 6155 rights. 6157 This document and the information contained herein are provided on 6158 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 6159 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 6160 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 6161 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 6162 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 6163 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 6164 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6166 PARTICULAR PURPOSE. 6168 15. Intellectual Property 6170 The IETF takes no position regarding the validity or scope of any 6171 Intellectual Property Rights or other rights that might be claimed 6172 to pertain to the implementation or use of the technology 6173 described in this document or the extent to which any license 6174 under such rights might or might not be available; nor does it 6175 represent that it has made any independent effort to identify any 6176 such rights. Information on the procedures with respect to rights 6177 in RFC documents can be found in BCP 78 and BCP 79. 6179 Copies of IPR disclosures made to the IETF Secretariat and any 6180 assurances of licenses to be made available, or the result of an 6181 attempt made to obtain a general license or permission for the use 6182 of such proprietary rights by implementers or users of this 6183 specification can be obtained from the IETF on-line IPR repository 6184 at http://www.ietf.org/ipr. 6186 The IETF invites any interested party to bring to its attention 6187 any copyrights, patents or patent applications, or other 6188 proprietary rights that may cover technology that may be required 6189 to implement this standard. Please address the information to the 6190 IETF at ietf-ipr@ietf.org. 6192 A. ASN.1 module 6194 KerberosV5Spec2 { 6195 iso(1) identified-organization(3) dod(6) internet(1) 6196 security(5) kerberosV5(2) modules(4) krb5spec2(2) 6197 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 6199 -- OID arc for KerberosV5 6200 -- 6201 -- This OID may be used to identify Kerberos protocol messages 6202 -- encapsulated in other protocols. 6203 -- 6204 -- This OID also designates the OID arc for KerberosV5-related OIDs. 6205 -- 6206 -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its OID. 6207 id-krb5 OBJECT IDENTIFIER ::= { 6208 iso(1) identified-organization(3) dod(6) internet(1) 6209 security(5) kerberosV5(2) 6210 } 6212 Int32 ::= INTEGER (-2147483648..2147483647) 6213 -- signed values representable in 32 bits 6214 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6216 UInt32 ::= INTEGER (0..4294967295) 6217 -- unsigned 32 bit values 6219 Microseconds ::= INTEGER (0..999999) 6220 -- microseconds 6222 KerberosString ::= GeneralString (IA5String) 6224 Realm ::= KerberosString 6226 PrincipalName ::= SEQUENCE { 6227 name-type [0] Int32, 6228 name-string [1] SEQUENCE OF KerberosString 6229 } 6231 KerberosTime ::= GeneralizedTime -- with no fractional seconds 6233 HostAddress ::= SEQUENCE { 6234 addr-type [0] Int32, 6235 address [1] OCTET STRING 6236 } 6238 -- NOTE: HostAddresses is always used as an OPTIONAL field and 6239 -- should not be empty. 6240 HostAddresses -- NOTE: subtly different from rfc1510, 6241 -- but has a value mapping and encodes the same 6242 ::= SEQUENCE OF HostAddress 6244 -- NOTE: AuthorizationData is always used as an OPTIONAL field and 6245 -- should not be empty. 6246 AuthorizationData ::= SEQUENCE OF SEQUENCE { 6247 ad-type [0] Int32, 6248 ad-data [1] OCTET STRING 6249 } 6251 PA-DATA ::= SEQUENCE { 6252 -- NOTE: first tag is [1], not [0] 6253 padata-type [1] Int32, 6254 padata-value [2] OCTET STRING -- might be encoded AP-REQ 6255 } 6257 KerberosFlags ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits 6258 -- shall be sent, but no fewer than 32 6260 EncryptedData ::= SEQUENCE { 6261 etype [0] Int32 -- EncryptionType --, 6262 kvno [1] UInt32 OPTIONAL, 6263 cipher [2] OCTET STRING -- ciphertext 6264 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6266 } 6268 EncryptionKey ::= SEQUENCE { 6269 keytype [0] Int32 -- actually encryption type --, 6270 keyvalue [1] OCTET STRING 6271 } 6273 Checksum ::= SEQUENCE { 6274 cksumtype [0] Int32, 6275 checksum [1] OCTET STRING 6276 } 6278 Ticket ::= [APPLICATION 1] SEQUENCE { 6279 tkt-vno [0] INTEGER (5), 6280 realm [1] Realm, 6281 sname [2] PrincipalName, 6282 enc-part [3] EncryptedData -- EncTicketPart 6283 } 6285 -- Encrypted part of ticket 6286 EncTicketPart ::= [APPLICATION 3] SEQUENCE { 6287 flags [0] TicketFlags, 6288 key [1] EncryptionKey, 6289 crealm [2] Realm, 6290 cname [3] PrincipalName, 6291 transited [4] TransitedEncoding, 6292 authtime [5] KerberosTime, 6293 starttime [6] KerberosTime OPTIONAL, 6294 endtime [7] KerberosTime, 6295 renew-till [8] KerberosTime OPTIONAL, 6296 caddr [9] HostAddresses OPTIONAL, 6297 authorization-data [10] AuthorizationData OPTIONAL 6298 } 6300 -- encoded Transited field 6301 TransitedEncoding ::= SEQUENCE { 6302 tr-type [0] Int32 -- must be registered --, 6303 contents [1] OCTET STRING 6304 } 6306 TicketFlags ::= KerberosFlags 6307 -- reserved(0), 6308 -- forwardable(1), 6309 -- forwarded(2), 6310 -- proxiable(3), 6311 -- proxy(4), 6312 -- may-postdate(5), 6313 -- postdated(6), 6314 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6316 -- invalid(7), 6317 -- renewable(8), 6318 -- initial(9), 6319 -- pre-authent(10), 6320 -- hw-authent(11), 6321 -- the following are new since 1510 6322 -- transited-policy-checked(12), 6323 -- ok-as-delegate(13) 6325 AS-REQ ::= [APPLICATION 10] KDC-REQ 6327 TGS-REQ ::= [APPLICATION 12] KDC-REQ 6329 KDC-REQ ::= SEQUENCE { 6330 -- NOTE: first tag is [1], not [0] 6331 pvno [1] INTEGER (5) , 6332 msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --), 6333 padata [3] SEQUENCE OF PA-DATA OPTIONAL 6334 -- NOTE: not empty --, 6335 req-body [4] KDC-REQ-BODY 6336 } 6338 KDC-REQ-BODY ::= SEQUENCE { 6339 kdc-options [0] KDCOptions, 6340 cname [1] PrincipalName OPTIONAL 6341 -- Used only in AS-REQ --, 6342 realm [2] Realm 6343 -- Server's realm 6344 -- Also client's in AS-REQ --, 6345 sname [3] PrincipalName OPTIONAL, 6346 from [4] KerberosTime OPTIONAL, 6347 till [5] KerberosTime, 6348 rtime [6] KerberosTime OPTIONAL, 6349 nonce [7] UInt32, 6350 etype [8] SEQUENCE OF Int32 -- EncryptionType 6351 -- in preference order --, 6352 addresses [9] HostAddresses OPTIONAL, 6353 enc-authorization-data [10] EncryptedData -- AuthorizationData --, 6354 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 6355 -- NOTE: not empty 6356 } 6358 KDCOptions ::= KerberosFlags 6359 -- reserved(0), 6360 -- forwardable(1), 6361 -- forwarded(2), 6362 -- proxiable(3), 6363 -- proxy(4), 6364 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6366 -- allow-postdate(5), 6367 -- postdated(6), 6368 -- unused7(7), 6369 -- renewable(8), 6370 -- unused9(9), 6371 -- unused10(10), 6372 -- opt-hardware-auth(11), 6373 -- unused12(12), 6374 -- unused13(13), 6375 -- 15 is reserved for canonicalize 6376 -- unused15(15), 6377 -- 26 was unused in 1510 6378 -- disable-transited-check(26), 6379 -- 6380 -- renewable-ok(27), 6381 -- enc-tkt-in-skey(28), 6382 -- renew(30), 6383 -- validate(31) 6385 AS-REP ::= [APPLICATION 11] KDC-REP 6387 TGS-REP ::= [APPLICATION 13] KDC-REP 6389 KDC-REP ::= SEQUENCE { 6390 pvno [0] INTEGER (5), 6391 msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --), 6392 padata [2] SEQUENCE OF PA-DATA OPTIONAL 6393 -- NOTE: not empty --, 6394 crealm [3] Realm, 6395 cname [4] PrincipalName, 6396 ticket [5] Ticket, 6397 enc-part [6] EncryptedData 6398 -- EncASRepPart or EncTGSRepPart, 6399 -- as appropriate 6400 } 6402 EncASRepPart ::= [APPLICATION 25] EncKDCRepPart 6404 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 6406 EncKDCRepPart ::= SEQUENCE { 6407 key [0] EncryptionKey, 6408 last-req [1] LastReq, 6409 nonce [2] UInt32, 6410 key-expiration [3] KerberosTime OPTIONAL, 6411 flags [4] TicketFlags, 6412 authtime [5] KerberosTime, 6413 starttime [6] KerberosTime OPTIONAL, 6414 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6416 endtime [7] KerberosTime, 6417 renew-till [8] KerberosTime OPTIONAL, 6418 srealm [9] Realm, 6419 sname [10] PrincipalName, 6420 caddr [11] HostAddresses OPTIONAL 6421 } 6423 LastReq ::= SEQUENCE OF SEQUENCE { 6424 lr-type [0] Int32, 6425 lr-value [1] KerberosTime 6426 } 6428 AP-REQ ::= [APPLICATION 14] SEQUENCE { 6429 pvno [0] INTEGER (5), 6430 msg-type [1] INTEGER (14), 6431 ap-options [2] APOptions, 6432 ticket [3] Ticket, 6433 authenticator [4] EncryptedData -- Authenticator 6434 } 6436 APOptions ::= KerberosFlags 6437 -- reserved(0), 6438 -- use-session-key(1), 6439 -- mutual-required(2) 6441 -- Unencrypted authenticator 6442 Authenticator ::= [APPLICATION 2] SEQUENCE { 6443 authenticator-vno [0] INTEGER (5), 6444 crealm [1] Realm, 6445 cname [2] PrincipalName, 6446 cksum [3] Checksum OPTIONAL, 6447 cusec [4] Microseconds, 6448 ctime [5] KerberosTime, 6449 subkey [6] EncryptionKey OPTIONAL, 6450 seq-number [7] UInt32 OPTIONAL, 6451 authorization-data [8] AuthorizationData OPTIONAL 6452 } 6454 AP-REP ::= [APPLICATION 15] SEQUENCE { 6455 pvno [0] INTEGER (5), 6456 msg-type [1] INTEGER (15), 6457 enc-part [2] EncryptedData -- EncAPRepPart 6458 } 6460 EncAPRepPart ::= [APPLICATION 27] SEQUENCE { 6461 ctime [0] KerberosTime, 6462 cusec [1] Microseconds, 6463 subkey [2] EncryptionKey OPTIONAL, 6464 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6466 seq-number [3] UInt32 OPTIONAL 6467 } 6469 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 6470 pvno [0] INTEGER (5), 6471 msg-type [1] INTEGER (20), 6472 safe-body [2] KRB-SAFE-BODY, 6473 cksum [3] Checksum 6474 } 6476 KRB-SAFE-BODY ::= SEQUENCE { 6477 user-data [0] OCTET STRING, 6478 timestamp [1] KerberosTime OPTIONAL, 6479 usec [2] Microseconds OPTIONAL, 6480 seq-number [3] UInt32 OPTIONAL, 6481 s-address [4] HostAddress, 6482 r-address [5] HostAddress OPTIONAL 6483 } 6485 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 6486 pvno [0] INTEGER (5), 6487 msg-type [1] INTEGER (21), 6488 -- NOTE: there is no [2] tag 6489 enc-part [3] EncryptedData -- EncKrbPrivPart 6490 } 6492 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 6493 user-data [0] OCTET STRING, 6494 timestamp [1] KerberosTime OPTIONAL, 6495 usec [2] Microseconds OPTIONAL, 6496 seq-number [3] UInt32 OPTIONAL, 6497 s-address [4] HostAddress -- sender's addr --, 6498 r-address [5] HostAddress OPTIONAL -- recip's addr 6499 } 6501 KRB-CRED ::= [APPLICATION 22] SEQUENCE { 6502 pvno [0] INTEGER (5), 6503 msg-type [1] INTEGER (22), 6504 tickets [2] SEQUENCE OF Ticket, 6505 enc-part [3] EncryptedData -- EncKrbCredPart 6506 } 6508 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 6509 ticket-info [0] SEQUENCE OF KrbCredInfo, 6510 nonce [1] UInt32 OPTIONAL, 6511 timestamp [2] KerberosTime OPTIONAL, 6512 usec [3] Microseconds OPTIONAL, 6513 s-address [4] HostAddress OPTIONAL, 6514 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6516 r-address [5] HostAddress OPTIONAL 6517 } 6519 KrbCredInfo ::= SEQUENCE { 6520 key [0] EncryptionKey, 6521 prealm [1] Realm OPTIONAL, 6522 pname [2] PrincipalName OPTIONAL, 6523 flags [3] TicketFlags OPTIONAL, 6524 authtime [4] KerberosTime OPTIONAL, 6525 starttime [5] KerberosTime OPTIONAL, 6526 endtime [6] KerberosTime OPTIONAL, 6527 renew-till [7] KerberosTime OPTIONAL, 6528 srealm [8] Realm OPTIONAL, 6529 sname [9] PrincipalName OPTIONAL, 6530 caddr [10] HostAddresses OPTIONAL 6531 } 6533 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 6534 pvno [0] INTEGER (5), 6535 msg-type [1] INTEGER (30), 6536 ctime [2] KerberosTime OPTIONAL, 6537 cusec [3] Microseconds OPTIONAL, 6538 stime [4] KerberosTime, 6539 susec [5] Microseconds, 6540 error-code [6] Int32, 6541 crealm [7] Realm OPTIONAL, 6542 cname [8] PrincipalName OPTIONAL, 6543 realm [9] Realm -- service realm --, 6544 sname [10] PrincipalName -- service name --, 6545 e-text [11] KerberosString OPTIONAL, 6546 e-data [12] OCTET STRING OPTIONAL 6547 } 6549 METHOD-DATA ::= SEQUENCE OF PA-DATA 6551 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 6552 data-type [0] INTEGER, 6553 data-value [1] OCTET STRING OPTIONAL 6554 } 6556 -- preauth stuff follows 6558 PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC 6560 PA-ENC-TS-ENC ::= SEQUENCE { 6561 patimestamp [0] KerberosTime -- client's time --, 6562 pausec [1] Microseconds OPTIONAL 6563 } 6564 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6566 ETYPE-INFO-ENTRY ::= SEQUENCE { 6567 etype [0] Int32, 6568 salt [1] OCTET STRING OPTIONAL 6569 } 6571 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY 6573 ETYPE-INFO2-ENTRY ::= SEQUENCE { 6574 etype [0] Int32, 6575 salt [1] KerberosString OPTIONAL, 6576 s2kparams [2] OCTET STRING OPTIONAL 6577 } 6579 ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY 6581 AD-IF-RELEVANT ::= AuthorizationData 6583 AD-KDCIssued ::= SEQUENCE { 6584 ad-checksum [0] Checksum, 6585 i-realm [1] Realm OPTIONAL, 6586 i-sname [2] PrincipalName OPTIONAL, 6587 elements [3] AuthorizationData 6588 } 6590 AD-AND-OR ::= SEQUENCE { 6591 condition-count [0] INTEGER, 6592 elements [1] AuthorizationData 6593 } 6595 AD-MANDATORY-FOR-KDC ::= AuthorizationData 6597 END 6599 B. Changes since RFC-1510 6601 This document replaces RFC-1510 and clarifies specification of 6602 items that were not completely specified. Where changes to 6603 recommended implementation choices were made, or where new options 6604 were added, those changes are described within the document and 6605 listed in this section. More significantly, "Specification 2" in 6606 section 8 changes the required encryption and checksum methods to 6607 bring them in line with the best current practices and to 6608 deprecate methods that are no longer considered sufficiently 6609 strong. 6611 Discussion was added to section 1 regarding the ability to rely on 6612 the KDC to check the transited field, and on the inclusion of a 6613 flag in a ticket indicating that this check has occurred. This is 6614 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6616 a new capability not present in RFC1510. Pre-existing 6617 implementations may ignore or not set this flag without negative 6618 security implications. 6620 The definition of the secret key says that in the case of a user 6621 the key may be derived from a password. In 1510, it said that the 6622 key was derived from the password. This change was made to 6623 accommodate situations where the user key might be stored on a 6624 smart-card, or otherwise obtained independent of a password. 6626 The introduction mentions the use of public key cryptography for 6627 initial authentication in Kerberos by reference. RFC1510 did not 6628 include such a reference. 6630 Section 1.2 was added to explain that while Kerberos provides 6631 authentication of a named principal, it is still the 6632 responsibility of the application to ensure that the authenticated 6633 name is the entity with which the application wishes to 6634 communicate. 6636 Discussion of extensibility has been added to the introduction. 6638 Discussion of how extensibility affects ticket flags and KDC 6639 options was added to the introduction of section 2. No changes 6640 were made to existing options and flags specified in RFC1510, 6641 though some of the sections in the specification were renumbered, 6642 and text was revised to make the description and intent of 6643 existing options clearer, especially with respect to the ENC-TKT- 6644 IN-SKEY option (now section 2.9.2) which is used for user-to-user 6645 authentication. The new option and ticket flag transited policy 6646 checking (section 2.7) was added. 6648 A warning regarding generation of session keys for application use 6649 was added to section 3, urging the inclusion of key entropy from 6650 the KDC generated session key in the ticket. An example regarding 6651 use of the sub-session key was added to section 3.2.6. 6652 Descriptions of the pa-etype-info, pa-etype-info2, and pa-pw-salt 6653 pre-authentication data items were added. The recommendation for 6654 use of pre-authentication was changed from "may" to "should" and a 6655 note was added regarding known plaintext attacks. 6657 In RFC 1510, section 4 described the database in the KDC. This 6658 discussion was not necessary for interoperability and 6659 unnecessarily constrained implementation. The old section 4 was 6660 removed. 6662 The current section 4 was formerly section 6 on encryption and 6663 checksum specifications. The major part of this section was 6664 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6666 brought up to date to support new encryption methods, and move to 6667 a separate document. Those few remaining aspects of the encryption 6668 and checksum specification specific to Kerberos are now specified 6669 in section 4. 6671 Significant changes were made to the layout of section 5 to 6672 clarify the correct behavior for optional fields. Many of these 6673 changes were made necessary because of improper ASN.1 description 6674 in the original Kerberos specification which left the correct 6675 behavior underspecified. Additionally, the wording in this section 6676 was tightened wherever possible to ensure that implementations 6677 conforming to this specification will be extensible with the 6678 addition of new fields in future specifications. 6680 Text was added describing time_t=0 issues in the ASN.1. Text was 6681 also added, clarifying issues with implementations treating 6682 omitted optional integers as zero. Text was added clarifying 6683 behavior for optional SEQUENCE or SEQUENCE OF that may be empty. 6684 Discussion was added regarding sequence numbers and behavior of 6685 some implementations, including "zero" behavior and negative 6686 numbers. A compatibility note was added regarding the 6687 unconditional sending of EncTGSRepPart regardless of the enclosing 6688 reply type. Minor changes were made to the description of the 6689 HostAddresses type. Integer types were constrained. KerberosString 6690 was defined as a (significantly) constrained GeneralString. 6691 KerberosFlags was defined to reflect existing implementation 6692 behavior that departs from the definition in RFC 1510. The 6693 transited-policy-checked(12) and the ok-as-delegate(13) ticket 6694 flags were added. The disable-transited-check(26) KDC option was 6695 added. 6697 Descriptions of commonly implemented PA-DATA were added to section 6698 5. The description of KRB-SAFE has been updated to note the 6699 existing implementation behavior of double-encoding. 6701 There were two definitions of METHOD-DATA in RFC 1510. The second 6702 one, intended for use with KRB_AP_ERR_METHOD was removed leaving 6703 the SEQUENCE OF PA-DATA definition. 6705 Section 7, naming constraints, from RFC1510 was moved to section 6706 6. 6708 Words were added describing the convention that domain based realm 6709 names for newly created realms should be specified as upper case. 6710 This recommendation does not make lower case realm names illegal. 6711 Words were added highlighting that the slash separated components 6712 in the X500 style of realm names is consistent with existing 6713 RFC1510 based implementations, but that it conflicts with the 6714 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6716 general recommendation of X.500 name representation specified in 6717 RFC2253. 6719 Section 8, network transport, constants and defined values, from 6720 RFC1510 was moved to section 7. Since RFC1510, the definition of 6721 the TCP transport for Kerberos messages was added, and the 6722 encryption and checksum number assignments have been moved into a 6723 separate document. 6725 "Specification 2" in section 8 of the current document changes the 6726 required encryption and checksum methods to bring them in line 6727 with the best current practices and to deprecate methods that are 6728 no longer considered sufficiently strong. 6730 Two new sections, on IANA considerations and security 6731 considerations were added. 6733 The pseudo-code has been removed from the appendix. The pseudo- 6734 code was sometimes misinterpreted to limit implementation choices 6735 and in RFC 1510, it was not always consistent with the words in 6736 the specification. Effort was made to clear up any ambiguities in 6737 the specification, rather than to rely on the pseudo-code. 6739 An appendix was added containing the complete ASN.1 module drawn 6740 from the discussion in section 5 of the current document. 6742 END NOTES 6744 [TM] Project Athena, Athena, and Kerberos are trademarks of the 6745 Massachusetts Institute of Technology (MIT). No commercial use of 6746 these trademarks may be made without prior written permission of 6747 MIT. 6749 [1] Note, however, that many applications use Kerberos' functions 6750 only upon the initiation of a stream-based network connection. 6751 Unless an application subsequently provides integrity protection 6752 for the data stream, the identity verification applies only to the 6753 initiation of the connection, and does not guarantee that 6754 subsequent messages on the connection originate from the same 6755 principal. 6757 [2] Secret and private are often used interchangeably in the 6758 literature. In our usage, it takes two (or more) to share a 6759 secret, thus a shared DES key is a secret key. Something is only 6760 private when no one but its owner knows it. Thus, in public key 6761 cryptosystems, one has a public and a private key. 6763 [3] Of course, with appropriate permission the client could 6764 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6766 arrange registration of a separately-named principal in a remote 6767 realm, and engage in normal exchanges with that realm's services. 6768 However, for even small numbers of clients this becomes 6769 cumbersome, and more automatic methods as described here are 6770 necessary. 6772 [4] Though it is permissible to request or issue tickets with no 6773 network addresses specified. 6775 [5] The password-changing request must not be honored unless the 6776 requester can provide the old password (the user's current secret 6777 key). Otherwise, it would be possible for someone to walk up to an 6778 unattended session and change another user's password. 6780 [6] To authenticate a user logging on to a local system, the 6781 credentials obtained in the AS exchange may first be used in a TGS 6782 exchange to obtain credentials for a local server. Those 6783 credentials must then be verified by a local server through 6784 successful completion of the Client/Server exchange. 6786 [7] "Random" means that, among other things, it should be 6787 impossible to guess the next session key based on knowledge of 6788 past session keys. This can only be achieved in a pseudo-random 6789 number generator if it is based on cryptographic principles. It is 6790 more desirable to use a truly random number generator, such as one 6791 based on measurements of random physical phenomena. See [RFC1750] 6792 for an in depth discussion of randomness. 6794 [8] Tickets contain both an encrypted and unencrypted portion, so 6795 cleartext here refers to the entire unit, which can be copied from 6796 one message and replayed in another without any cryptographic 6797 skill. 6799 [9] Note that this can make applications based on unreliable 6800 transports difficult to code correctly. If the transport might 6801 deliver duplicated messages, either a new authenticator must be 6802 generated for each retry, or the application server must match 6803 requests and replies and replay the first reply in response to a 6804 detected duplicate. 6806 [10] Note also that the rejection here is restricted to 6807 authenticators from the same principal to the same server. Other 6808 client principals communicating with the same server principal 6809 should not be have their authenticators rejected if the time and 6810 microsecond fields happen to match some other client's 6811 authenticator. 6813 [11] If this is not done, an attacker could subvert the 6814 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT 6816 authentication by recording the ticket and authenticator sent over 6817 the network to a server and replaying them following an event that 6818 caused the server to lose track of recently seen authenticators. 6820 [12] In the Kerberos version 4 protocol, the timestamp in the 6821 reply was the client's timestamp plus one. This is not necessary 6822 in version 5 because version 5 messages are formatted in such a 6823 way that it is not possible to create the reply by judicious 6824 message surgery (even in encrypted form) without knowledge of the 6825 appropriate encryption keys. 6827 [13] Note that for encrypting the KRB_AP_REP message, the sub- 6828 session key is not used, even if present in the Authenticator. 6830 [14] Implementations of the protocol may provide routines to 6831 choose subkeys based on session keys and random numbers and to 6832 generate a negotiated key to be returned in the KRB_AP_REP 6833 message. 6835 [15]This can be accomplished in several ways. It might be known 6836 beforehand (since the realm is part of the principal identifier), 6837 it might be stored in a nameserver, or it might be obtained from a 6838 configuration file. If the realm to be used is obtained from a 6839 nameserver, there is a danger of being spoofed if the nameservice 6840 providing the realm name is not authenticated. This might result 6841 in the use of a realm which has been compromised, and would result 6842 in an attacker's ability to compromise the authentication of the 6843 application server to the client. 6845 [16] If the client selects a sub-session key, care must be taken 6846 to ensure the randomness of the selected sub-session key. One 6847 approach would be to generate a random number and XOR it with the 6848 session key from the ticket-granting ticket.