idnits 2.17.1 draft-ietf-krb-wg-kerberos-clarifications-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 258 instances of too long lines in the document, the longest one being 10 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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 421: '...thentication and SHOULD check the tran...' RFC 2119 keyword, line 429: '... are SHOULD honor this flag....' RFC 2119 keyword, line 460: '...d protocols based on Kerberos MUST NOT...' RFC 2119 keyword, line 463: '...lication authors MAY append a statical...' RFC 2119 keyword, line 467: '...onicalization by the client SHOULD NOT...' (399 more instances...) -- The abstract seems to indicate that this document updates RFC1510, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 4749 has weird spacing: '...ticator non-P...' == Line 4751 has weird spacing: '...ketPart non-P...' == Line 4781 has weird spacing: '...RepPart non-...' == Line 4783 has weird spacing: '...RepPart non-P...' == Line 4787 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: 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 will 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 19, 2003) is 7614 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '15' is mentioned on line 1703, but not defined == Missing Reference: 'RFC1964' is mentioned on line 2468, but not defined == Missing Reference: 'ISO-646' is mentioned on line 2571, but not defined == Missing Reference: 'ECMA-6' is mentioned on line 2571, but not defined == Missing Reference: 'ISO-8859' is mentioned on line 2578, but not defined == Missing Reference: '0' is mentioned on line 6436, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 6117, but not defined == Missing Reference: 'APPLICATION 3' is mentioned on line 6125, but not defined == Missing Reference: 'APPLICATION 10' is mentioned on line 6165, but not defined == Missing Reference: 'APPLICATION 12' is mentioned on line 6167, but not defined == Missing Reference: 'APPLICATION 11' is mentioned on line 6226, but not defined == Missing Reference: 'APPLICATION 13' is mentioned on line 6228, but not defined == Missing Reference: 'APPLICATION 25' is mentioned on line 6243, but not defined == Missing Reference: 'APPLICATION 26' is mentioned on line 6245, but not defined == Missing Reference: 'APPLICATION 14' is mentioned on line 6270, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 6284, but not defined == Missing Reference: 'APPLICATION 15' is mentioned on line 6296, but not defined == Missing Reference: 'APPLICATION 27' is mentioned on line 6302, but not defined == Missing Reference: 'APPLICATION 20' is mentioned on line 6312, but not defined == Missing Reference: 'APPLICATION 21' is mentioned on line 6328, but not defined == Missing Reference: 'APPLICATION 28' is mentioned on line 6335, but not defined == Missing Reference: 'APPLICATION 22' is mentioned on line 6344, but not defined == Missing Reference: 'APPLICATION 29' is mentioned on line 6351, but not defined == Missing Reference: 'APPLICATION 30' is mentioned on line 6377, but not defined == Missing Reference: 'RFC 2253' is mentioned on line 5406, but not defined ** Obsolete undefined reference: RFC 2253 (Obsoleted by RFC 4510, RFC 4514) == Missing Reference: 'RFC 1035' is mentioned on line 5130, but not defined == Unused Reference: 'RFC1035' is defined on line 5970, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 5986, but no explicit reference was found in the text == Unused Reference: 'RFC2052' is defined on line 5991, but no explicit reference was found in the text == Unused Reference: 'RFC2253' is defined on line 5996, but no explicit reference was found in the text == Unused Reference: 'RFC2273' is defined on line 6004, but no explicit reference was found in the text == Unused Reference: 'TM' is defined on line 6585, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DGT96' -- Possible downref: Non-RFC (?) normative reference: ref. 'DS81' -- Possible downref: Non-RFC (?) normative reference: ref. 'KNT94' -- Possible downref: Non-RFC (?) normative reference: ref. 'MNSS87' -- Possible downref: Non-RFC (?) normative reference: ref. 'Neu93' -- Possible downref: Non-RFC (?) normative reference: ref. 'NS78' -- Possible downref: Non-RFC (?) normative reference: ref. 'NT94' ** Downref: Normative reference to an Not Issued RFC: RFC 26 (ref. 'Pat92') ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 1602 (ref. 'RFC2026') (Obsoleted by RFC 2026) ** Obsolete normative reference: RFC 3377 (ref. 'RFC2253') (Obsoleted by RFC 4510) ** Obsolete normative reference: RFC 2573 (ref. 'RFC2273') (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) -- Possible downref: Non-RFC (?) normative reference: ref. 'SNS88' -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' -- Possible downref: Non-RFC (?) normative reference: ref. 'TM' -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '16' Summary: 15 errors (**), 0 flaws (~~), 42 warnings (==), 30 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Clifford Neuman 3 USC-ISI 4 Tom Yu 5 Sam Hartman 6 Ken Raeburn 7 MIT 8 June 19, 2003 9 Expires 19 December, 2003 11 The Kerberos Network Authentication Service (V5) 12 draft-ietf-krb-wg-kerberos-clarifications-04.txt 14 STATUS OF THIS MEMO 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC 2026. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 To learn the current status of any Internet-Draft, please check the 34 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 35 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 36 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 38 The distribution of this memo is unlimited. It is filed as draft- 39 ietf-krb-wg-kerberos-clarifications-04.txt, and expires 19 December 40 2003. Please send comments to: ietf-krb-wg@anl.gov 42 ABSTRACT 44 This document provides an overview and specification of Version 5 of 45 the Kerberos protocol, and updates RFC1510 to clarify aspects of the 46 protocol and its intended use that require more detailed or clearer 47 explanation than was provided in RFC1510. This document is intended 48 to provide a detailed description of the protocol, suitable for 49 implementation, together with descriptions of the appropriate use of 50 protocol messages and fields within those messages. 52 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 54 This document contains a subset of the changes considered and 55 discussed in the Kerberos working group and is intended as an interim 56 description of Kerberos. Additional changes to the Kerberos protocol 57 have been proposed and will appear in a subsequent extensions 58 document. 60 This document is not intended to describe Kerberos to the end user, 61 system administrator, or application developer. Higher level papers 62 describing Version 5 of the Kerberos system [NT94] and documenting 63 version 4 [SNS88], are available elsewhere. 65 OVERVIEW 67 This INTERNET-DRAFT describes the concepts and model upon which the 68 Kerberos network authentication system is based. It also specifies 69 Version 5 of the Kerberos protocol. 71 The motivations, goals, assumptions, and rationale behind most design 72 decisions are treated cursorily; they are more fully described in a 73 paper available in IEEE communications [NT94] and earlier in the 74 Kerberos portion of the Athena Technical Plan [MNSS87]. The protocols 75 have been a proposed standard and are being considered for 76 advancement for draft standard through the IETF standard process. 77 Comments are encouraged on the presentation, but only minor 78 refinements to the protocol as implemented or extensions that fit 79 within current protocol framework will be considered at this time. 81 Requests for addition to an electronic mailing list for discussion of 82 Kerberos, kerberos@MIT.EDU, may be addressed to kerberos- 83 request@MIT.EDU. This mailing list is gatewayed onto the Usenet as 84 the group comp.protocols.kerberos. Requests for further information, 85 including documents and code availability, may be sent to info- 86 kerberos@MIT.EDU. 88 BACKGROUND 90 The Kerberos model is based in part on Needham and Schroeder's 91 trusted third-party authentication protocol [NS78] and on 92 modifications suggested by Denning and Sacco [DS81]. The original 93 design and implementation of Kerberos Versions 1 through 4 was the 94 work of two former Project Athena staff members, Steve Miller of 95 Digital Equipment Corporation and Clifford Neuman (now at the 96 Information Sciences Institute of the University of Southern 97 California), along with Jerome Saltzer, Technical Director of Project 98 Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other 99 members of Project Athena have also contributed to the work on 100 Kerberos. 102 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 104 Version 5 of the Kerberos protocol (described in this document) has 105 evolved from Version 4 based on new requirements and desires for 106 features not available in Version 4. The design of Version 5 of the 107 Kerberos protocol was led by Clifford Neuman and John Kohl with much 108 input from the community. The development of the MIT reference 109 implementation was led at MIT by John Kohl and Theodore Ts'o, with 110 help and contributed code from many others. Since RFC1510 was issued, 111 extensions and revisions to the protocol have been proposed by many 112 individuals. Some of these proposals are reflected in this document. 113 Where such changes involved significant effort, the document cites 114 the contribution of the proposer. 116 Reference implementations of both version 4 and version 5 of Kerberos 117 are publicly available and commercial implementations have been 118 developed and are widely used. Details on the differences between 119 Kerberos Versions 4 and 5 can be found in [KNT94]. 121 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 123 Table of Contents 125 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 7 126 1.1. Cross-realm operation . . . . . . . . . . . . . . . . . . . . . 9 127 1.2. Choosing a principal with which to communicate . . . . . . . . 10 128 1.3. Authorization . . . . . . . . . . . . . . . . . . . . . . . . . 11 129 1.4. Extending Kerberos Without Breaking Interoperability . . . . . 11 130 1.4.1. Compatibility with RFC 1510 . . . . . . . . . . . . . . . . . 12 131 1.4.2. Sending Extensible Messages . . . . . . . . . . . . . . . . . 13 132 1.5. Environmental assumptions . . . . . . . . . . . . . . . . . . . 13 133 1.6. Glossary of terms . . . . . . . . . . . . . . . . . . . . . . . 14 134 2. Ticket flag uses and requests . . . . . . . . . . . . . . . . . . 17 135 2.1. Initial, pre-authenticated, and hardware authenticated 136 tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 137 2.2. Invalid tickets . . . . . . . . . . . . . . . . . . . . . . . . 18 138 2.3. Renewable tickets . . . . . . . . . . . . . . . . . . . . . . . 18 139 2.4. Postdated tickets . . . . . . . . . . . . . . . . . . . . . . . 19 140 2.5. Proxiable and proxy tickets . . . . . . . . . . . . . . . . . . 19 141 2.6. Forwardable tickets . . . . . . . . . . . . . . . . . . . . . . 20 142 2.7. Transited Policy Checking . . . . . . . . . . . . . . . . . . . 21 143 2.8. OK as Delegate . . . . . . . . . . . . . . . . . . . . . . . . 21 144 2.9. Other KDC options . . . . . . . . . . . . . . . . . . . . . . . 22 145 2.9.1. Renewable-OK . . . . . . . . . . . . . . . . . . . . . . . . 22 146 2.9.2. ENC-TKT-IN-SKEY . . . . . . . . . . . . . . . . . . . . . . . 22 147 2.9.3. Passwordless Hardware Authentication . . . . . . . . . . . . 23 148 3. Message Exchanges . . . . . . . . . . . . . . . . . . . . . . . . 23 149 3.1. The Authentication Service Exchange . . . . . . . . . . . . . . 23 150 3.1.1. Generation of KRB_AS_REQ message . . . . . . . . . . . . . . 24 151 3.1.2. Receipt of KRB_AS_REQ message . . . . . . . . . . . . . . . . 25 152 3.1.3. Generation of KRB_AS_REP message . . . . . . . . . . . . . . 25 153 3.1.4. Generation of KRB_ERROR message . . . . . . . . . . . . . . . 28 154 3.1.5. Receipt of KRB_AS_REP message . . . . . . . . . . . . . . . . 28 155 3.1.6. Receipt of KRB_ERROR message . . . . . . . . . . . . . . . . 29 156 3.2. The Client/Server Authentication Exchange . . . . . . . . . . . 29 157 3.2.1. The KRB_AP_REQ message . . . . . . . . . . . . . . . . . . . 29 158 3.2.2. Generation of a KRB_AP_REQ message . . . . . . . . . . . . . 29 159 3.2.3. Receipt of KRB_AP_REQ message . . . . . . . . . . . . . . . . 30 160 3.2.4. Generation of a KRB_AP_REP message . . . . . . . . . . . . . 32 161 3.2.5. Receipt of KRB_AP_REP message . . . . . . . . . . . . . . . . 33 162 3.2.6. Using the encryption key . . . . . . . . . . . . . . . . . . 33 163 3.3. The Ticket-Granting Service (TGS) Exchange . . . . . . . . . . 34 164 3.3.1. Generation of KRB_TGS_REQ message . . . . . . . . . . . . . . 35 165 3.3.2. Receipt of KRB_TGS_REQ message . . . . . . . . . . . . . . . 36 166 3.3.3. Generation of KRB_TGS_REP message . . . . . . . . . . . . . . 37 167 3.3.3.1. Checking for revoked tickets . . . . . . . . . . . . . . . 39 168 3.3.3.2. Encoding the transited field . . . . . . . . . . . . . . . 39 169 3.3.4. Receipt of KRB_TGS_REP message . . . . . . . . . . . . . . . 41 170 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 172 3.4. The KRB_SAFE Exchange . . . . . . . . . . . . . . . . . . . . . 41 173 3.4.1. Generation of a KRB_SAFE message . . . . . . . . . . . . . . 42 174 3.4.2. Receipt of KRB_SAFE message . . . . . . . . . . . . . . . . . 42 175 3.5. The KRB_PRIV Exchange . . . . . . . . . . . . . . . . . . . . . 43 176 3.5.1. Generation of a KRB_PRIV message . . . . . . . . . . . . . . 43 177 3.5.2. Receipt of KRB_PRIV message . . . . . . . . . . . . . . . . . 44 178 3.6. The KRB_CRED Exchange . . . . . . . . . . . . . . . . . . . . . 44 179 3.6.1. Generation of a KRB_CRED message . . . . . . . . . . . . . . 45 180 3.6.2. Receipt of KRB_CRED message . . . . . . . . . . . . . . . . . 45 181 3.7. User to User Authentication Exchanges . . . . . . . . . . . . . 46 182 4. Encryption and Checksum Specifications . . . . . . . . . . . . . 47 183 5. Message Specifications . . . . . . . . . . . . . . . . . . . . . 49 184 5.1. Specific Compatibility Notes on ASN.1 . . . . . . . . . . . . . 50 185 5.1.1. ASN.1 Distinguished Encoding Rules . . . . . . . . . . . . . 50 186 5.1.2. Optional Integer Fields . . . . . . . . . . . . . . . . . . . 51 187 5.1.3. Empty SEQUENCE OF Types . . . . . . . . . . . . . . . . . . . 51 188 5.1.4. Unrecognized Tag Numbers . . . . . . . . . . . . . . . . . . 51 189 5.1.5. Tag Numbers Greater Than 30 . . . . . . . . . . . . . . . . . 51 190 5.2. Basic Kerberos Types . . . . . . . . . . . . . . . . . . . . . 52 191 5.2.1. KerberosString . . . . . . . . . . . . . . . . . . . . . . . 52 192 5.2.2. Realm and PrincipalName . . . . . . . . . . . . . . . . . . . 53 193 5.2.3. KerberosTime . . . . . . . . . . . . . . . . . . . . . . . . 54 194 5.2.4. Constrained Integer types . . . . . . . . . . . . . . . . . . 54 195 5.2.5. HostAddress and HostAddresses . . . . . . . . . . . . . . . . 55 196 5.2.6. AuthorizationData . . . . . . . . . . . . . . . . . . . . . . 55 197 5.2.6.1. IF-RELEVANT . . . . . . . . . . . . . . . . . . . . . . . . 57 198 5.2.6.2. KDCIssued . . . . . . . . . . . . . . . . . . . . . . . . . 57 199 5.2.6.3. AND-OR . . . . . . . . . . . . . . . . . . . . . . . . . . 58 200 5.2.6.4. MANDATORY-FOR-KDC . . . . . . . . . . . . . . . . . . . . . 59 201 5.2.7. PA-DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 202 5.2.7.1. PA-TGS-REQ . . . . . . . . . . . . . . . . . . . . . . . . 60 203 5.2.7.2. Encrypted Timestamp Pre-authentication . . . . . . . . . . 60 204 5.2.7.3. PA-PW-SALT . . . . . . . . . . . . . . . . . . . . . . . . 60 205 5.2.7.4. PA-ETYPE-INFO . . . . . . . . . . . . . . . . . . . . . . . 61 206 5.2.7.5. PA-ETYPE-INFO2 . . . . . . . . . . . . . . . . . . . . . . 62 207 5.2.8. KerberosFlags . . . . . . . . . . . . . . . . . . . . . . . . 62 208 5.2.9. Cryptosystem-related Types . . . . . . . . . . . . . . . . . 63 209 5.3. Tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 210 5.4. Specifications for the AS and TGS exchanges . . . . . . . . . . 72 211 5.4.1. KRB_KDC_REQ definition . . . . . . . . . . . . . . . . . . . 72 212 5.4.2. KRB_KDC_REP definition . . . . . . . . . . . . . . . . . . . 80 213 5.5. Client/Server (CS) message specifications . . . . . . . . . . . 83 214 5.5.1. KRB_AP_REQ definition . . . . . . . . . . . . . . . . . . . . 83 215 5.5.2. KRB_AP_REP definition . . . . . . . . . . . . . . . . . . . . 86 216 5.5.3. Error message reply . . . . . . . . . . . . . . . . . . . . . 87 217 5.6. KRB_SAFE message specification . . . . . . . . . . . . . . . . 88 218 5.6.1. KRB_SAFE definition . . . . . . . . . . . . . . . . . . . . . 88 219 5.7. KRB_PRIV message specification . . . . . . . . . . . . . . . . 89 220 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 222 5.7.1. KRB_PRIV definition . . . . . . . . . . . . . . . . . . . . . 90 223 5.8. KRB_CRED message specification . . . . . . . . . . . . . . . . 90 224 5.8.1. KRB_CRED definition . . . . . . . . . . . . . . . . . . . . . 91 225 5.9. Error message specification . . . . . . . . . . . . . . . . . . 93 226 5.9.1. KRB_ERROR definition . . . . . . . . . . . . . . . . . . . . 93 227 5.10. Application Tag Numbers . . . . . . . . . . . . . . . . . . . 95 228 6. Naming Constraints . . . . . . . . . . . . . . . . . . . . . . . 96 229 6.1. Realm Names . . . . . . . . . . . . . . . . . . . . . . . . . . 96 230 6.2. Principal Names . . . . . . . . . . . . . . . . . . . . . . . . 97 231 6.2.1. Name of server principals . . . . . . . . . . . . . . . . . . 99 232 7. Constants and other defined values . . . . . . . . . . . . . . . 99 233 7.1. Host address types . . . . . . . . . . . . . . . . . . . . . . 99 234 7.2. KDC messaging - IP Transports . . . . . . . . . . . . . . . . . 100 235 7.2.1. UDP/IP transport . . . . . . . . . . . . . . . . . . . . . . 100 236 7.2.2. TCP/IP transport . . . . . . . . . . . . . . . . . . . . . . 101 237 7.2.3. KDC Discovery on IP Networks . . . . . . . . . . . . . . . . 102 238 7.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names . . . . 102 239 7.2.3.2. Specifying KDC Location information with DNS SRV 240 records . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 241 7.2.3.3. KDC Discovery for Domain Style Realm Names on IP 242 Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 243 7.3. Name of the TGS . . . . . . . . . . . . . . . . . . . . . . . . 103 244 7.4. OID arc for KerberosV5 . . . . . . . . . . . . . . . . . . . . 104 245 7.5. Protocol constants and associated values . . . . . . . . . . . 104 246 7.5.1. Key usage numbers . . . . . . . . . . . . . . . . . . . . . . 104 247 7.5.2. PreAuthentication Data Types . . . . . . . . . . . . . . . . 105 248 7.5.3. Address Types . . . . . . . . . . . . . . . . . . . . . . . . 106 249 7.5.4. Authorization Data Types . . . . . . . . . . . . . . . . . . 107 250 7.5.5. Transited Encoding Types . . . . . . . . . . . . . . . . . . 107 251 7.5.6. Protocol Version Number . . . . . . . . . . . . . . . . . . . 107 252 7.5.7. Kerberos Message Types . . . . . . . . . . . . . . . . . . . 107 253 7.5.8. Name Types . . . . . . . . . . . . . . . . . . . . . . . . . 108 254 7.5.9. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 108 255 8. Interoperability requirements . . . . . . . . . . . . . . . . . . 109 256 8.1. Specification 2 . . . . . . . . . . . . . . . . . . . . . . . . 110 257 8.2. Recommended KDC values . . . . . . . . . . . . . . . . . . . . 112 258 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . . . 113 259 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 113 260 11. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 116 261 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 117 262 13. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 263 A. ASN.1 module . . . . . . . . . . . . . . . . . . . . . . . . . . 120 264 B. Changes since RFC-1510 . . . . . . . . . . . . . . . . . . . . . 128 265 END NOTES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 266 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 268 1. Introduction 270 Kerberos provides a means of verifying the identities of principals, 271 (e.g. a workstation user or a network server) on an open 272 (unprotected) network. This is accomplished without relying on 273 assertions by the host operating system, without basing trust on host 274 addresses, without requiring physical security of all the hosts on 275 the network, and under the assumption that packets traveling along 276 the network can be read, modified, and inserted at will[1]. Kerberos 277 performs authentication under these conditions as a trusted third- 278 party authentication service by using conventional (shared secret key 279 [2]) cryptography. Kerberos extensions (outside the scope of this 280 document) can provide for the use of public key cryptography during 281 certain phases of the authentication protocol [@RFCE: if PKINIT 282 advances concurrently include reference to the RFC here]. Such 283 extensions support Kerberos authentication for users registered with 284 public key certification authorities and provide certain benefits of 285 public key cryptography in situations where they are needed. 287 The basic Kerberos authentication process proceeds as follows: A 288 client sends a request to the authentication server (AS) requesting 289 "credentials" for a given server. The AS responds with these 290 credentials, encrypted in the client's key. The credentials consist 291 of a "ticket" for the server and a temporary encryption key (often 292 called a "session key"). The client transmits the ticket (which 293 contains the client's identity and a copy of the session key, all 294 encrypted in the server's key) to the server. The session key (now 295 shared by the client and server) is used to authenticate the client, 296 and may optionally be used to authenticate the server. It may also be 297 used to encrypt further communication between the two parties or to 298 exchange a separate sub-session key to be used to encrypt further 299 communication. 301 Implementation of the basic protocol consists of one or more 302 authentication servers running on physically secure hosts. The 303 authentication servers maintain a database of principals (i.e., users 304 and servers) and their secret keys. Code libraries provide encryption 305 and implement the Kerberos protocol. In order to add authentication 306 to its transactions, a typical network application adds calls to the 307 Kerberos library directly or through the Generic Security Services 308 Application Programming Interface, GSSAPI, described in separate 309 document [ref to GSSAPI RFC]. These calls result in the transmission 310 of the necessary messages to achieve authentication. 312 The Kerberos protocol consists of several sub-protocols (or 313 exchanges). There are two basic methods by which a client can ask a 314 Kerberos server for credentials. In the first approach, the client 315 sends a cleartext request for a ticket for the desired server to the 317 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 319 AS. The reply is sent encrypted in the client's secret key. Usually 320 this request is for a ticket-granting ticket (TGT) which can later be 321 used with the ticket-granting server (TGS). In the second method, 322 the client sends a request to the TGS. The client uses the TGT to 323 authenticate itself to the TGS in the same manner as if it were 324 contacting any other application server that requires Kerberos 325 authentication. The reply is encrypted in the session key from the 326 TGT. Though the protocol specification describes the AS and the TGS 327 as separate servers, they are implemented in practice as different 328 protocol entry points within a single Kerberos server. 330 Once obtained, credentials may be used to verify the identity of the 331 principals in a transaction, to ensure the integrity of messages 332 exchanged between them, or to preserve privacy of the messages. The 333 application is free to choose whatever protection may be necessary. 335 To verify the identities of the principals in a transaction, the 336 client transmits the ticket to the application server. Since the 337 ticket is sent "in the clear" (parts of it are encrypted, but this 338 encryption doesn't thwart replay) and might be intercepted and reused 339 by an attacker, additional information is sent to prove that the 340 message originated with the principal to whom the ticket was issued. 341 This information (called the authenticator) is encrypted in the 342 session key, and includes a timestamp. The timestamp proves that the 343 message was recently generated and is not a replay. Encrypting the 344 authenticator in the session key proves that it was generated by a 345 party possessing the session key. Since no one except the requesting 346 principal and the server know the session key (it is never sent over 347 the network in the clear) this guarantees the identity of the client. 349 The integrity of the messages exchanged between principals can also 350 be guaranteed using the session key (passed in the ticket and 351 contained in the credentials). This approach provides detection of 352 both replay attacks and message stream modification attacks. It is 353 accomplished by generating and transmitting a collision-proof 354 checksum (elsewhere called a hash or digest function) of the client's 355 message, keyed with the session key. Privacy and integrity of the 356 messages exchanged between principals can be secured by encrypting 357 the data to be passed using the session key contained in the ticket 358 or the sub-session key found in the authenticator. 360 The authentication exchanges mentioned above require read-only access 361 to the Kerberos database. Sometimes, however, the entries in the 362 database must be modified, such as when adding new principals or 363 changing a principal's key. This is done using a protocol between a 364 client and a third Kerberos server, the Kerberos Administration 365 Server (KADM). There is also a protocol for maintaining multiple 366 copies of the Kerberos database. Neither of these protocols are 368 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 370 described in this document. 372 1.1. Cross-realm operation 374 The Kerberos protocol is designed to operate across organizational 375 boundaries. A client in one organization can be authenticated to a 376 server in another. Each organization wishing to run a Kerberos server 377 establishes its own "realm". The name of the realm in which a client 378 is registered is part of the client's name, and can be used by the 379 end-service to decide whether to honor a request. 381 By establishing "inter-realm" keys, the administrators of two realms 382 can allow a client authenticated in the local realm to prove its 383 identity to servers in other realms[3]. The exchange of inter-realm 384 keys (a separate key may be used for each direction) registers the 385 ticket-granting service of each realm as a principal in the other 386 realm. A client is then able to obtain a ticket-granting ticket for 387 the remote realm's ticket-granting service from its local realm. When 388 that ticket-granting ticket is used, the remote ticket-granting 389 service uses the inter-realm key (which usually differs from its own 390 normal TGS key) to decrypt the ticket-granting ticket, and is thus 391 certain that it was issued by the client's own TGS. Tickets issued by 392 the remote ticket-granting service will indicate to the end-service 393 that the client was authenticated from another realm. 395 A realm is said to communicate with another realm if the two realms 396 share an inter-realm key, or if the local realm shares an inter-realm 397 key with an intermediate realm that communicates with the remote 398 realm. An authentication path is the sequence of intermediate realms 399 that are transited in communicating from one realm to another. 401 Realms may be organized hierarchically. Each realm shares a key with 402 its parent and a different key with each child. If an inter-realm key 403 is not directly shared by two realms, the hierarchical organization 404 allows an authentication path to be easily constructed. If a 405 hierarchical organization is not used, it may be necessary to consult 406 a database in order to construct an authentication path between 407 realms. 409 Although realms are typically hierarchical, intermediate realms may 410 be bypassed to achieve cross-realm authentication through alternate 411 authentication paths (these might be established to make 412 communication between two realms more efficient). It is important for 413 the end-service to know which realms were transited when deciding how 414 much faith to place in the authentication process. To facilitate this 415 decision, a field in each ticket contains the names of the realms 416 that were involved in authenticating the client. 418 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 420 The application server is ultimately responsible for accepting or 421 rejecting authentication and SHOULD check the transited field. The 422 application server may choose to rely on the KDC for the application 423 server's realm to check the transited field. The application server's 424 KDC will set the TRANSITED-POLICY-CHECKED flag in this case. The KDCs 425 for intermediate realms may also check the transited field as they 426 issue ticket-granting tickets for other realms, but they are 427 encouraged not to do so. A client may request that the KDCs not check 428 the transited field by setting the DISABLE-TRANSITED-CHECK flag. KDCs 429 are SHOULD honor this flag. 431 1.2. Choosing a principal with which to communicate 433 The Kerberos protocol provides the means for verifying (subject to 434 the assumptions in 1.5) that the entity with which one communicates 435 is the same entity that was registered with the KDC using the claimed 436 identity (principal name). It is still necessary to determine whether 437 that identity corresponds to the entity with which one intends to 438 communicate. 440 When appropriate data has been exchanged in advance, this 441 determination may be performed syntactically by the application based 442 on the application protocol specification, information provided by 443 the user, and configuration files. For example, the server principal 444 name (including realm) for a telnet server might be derived from the 445 user specified host name (from the telnet command line), the "host/" 446 prefix specified in the application protocol specification, and a 447 mapping to a Kerberos realm derived syntactically from the domain 448 part of the specified hostname and information from the local 449 Kerberos realms database. 451 One can also rely on trusted third parties to make this 452 determination, but only when the data obtained from the third party 453 is suitably integrity protected while resident on the third party 454 server and when transmitted. Thus, for example, one should not rely 455 on an unprotected domain name system record to map a host alias to 456 the primary name of a server, accepting the primary name as the party 457 one intends to contact, since an attacker can modify the mapping and 458 impersonate the party with which one intended to communicate. 460 Implementations of Kerberos and protocols based on Kerberos MUST NOT 461 use insecure DNS queries to canonicalize the hostname components of 462 the service principal names. In an environment without secure name 463 service, application authors MAY append a statically configured 464 domain name to unqualified hostnames before passing the name to the 465 security mechanisms, but should do no more than that. Secure name 466 service facilities, if available, might be trusted for hostname 467 canonicalization, but such canonicalization by the client SHOULD NOT 469 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 471 be required by KDC implementations. 473 Implementation note: Many current implementations do some degree of 474 canonicalization of the provided service name, often using DNS even 475 though it creates security problems. However there is no consistency 476 among implementations about whether the service name is case folded 477 to lower case or whether reverse resolution is used. To maximize 478 interoperability and security, applications SHOULD provide security 479 mechanisms with names which result from folding the user-entered name 480 to lower case, without performing any other modifications or 481 canonicalization. 483 1.3. Authorization 485 As an authentication service, Kerberos provides a means of verifying 486 the identity of principals on a network. Authentication is usually 487 useful primarily as a first step in the process of authorization, 488 determining whether a client may use a service, which objects the 489 client is allowed to access, and the type of access allowed for each. 490 Kerberos does not, by itself, provide authorization. Possession of a 491 client ticket for a service provides only for authentication of the 492 client to that service, and in the absence of a separate 493 authorization procedure, it should not be considered by an 494 application as authorizing the use of that service. 496 Such separate authorization methods MAY be implemented as application 497 specific access control functions and may utilize files on the 498 application server, or on separately issued authorization credentials 499 such as those based on proxies [Neu93], or on other authorization 500 services. Separately authenticated authorization credentials MAY be 501 embedded in a ticket's authorization data when encapsulated by the 502 KDC-issued authorization data element. 504 Applications should not accept the mere issuance of a service ticket 505 by the Kerberos server (even by a modified Kerberos server) as 506 granting authority to use the service, since such applications may 507 become vulnerable to the bypass of this authorization check in an 508 environment if they interoperate with other KDCs or where other 509 options for application authentication (e.g. the PKTAPP proposal) 510 are provided. 512 1.4. Extending Kerberos Without Breaking Interoperability 514 As the deployed base of Kerberos implementations grows, extending 515 Kerberos becomes more important. Unfortunately some extensions to the 516 existing Kerberos protocol create interoperability issues because of 517 uncertainty regarding the treatment of certain extensibility options 518 by some implementations. This section includes guidelines that will 520 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 522 enable future implementations to maintain interoperability. 524 Kerberos provides a general mechanism for protocol extensibility. 525 Some protocol messages contain typed holes -- sub-messages that 526 contain an octet-string along with an integer that defines how to 527 interpret the octet-string. The integer types are registered 528 centrally, but can be used both for vendor extensions and for 529 extensions standardized through the IETF. 531 In this document, the word "extension" means an extension by defining 532 a new type to insert into an existing typed hole in a protocol 533 message. It does not mean extension by addition of new fields to 534 ASN.1 types, unless explicitly indicated otherwise in the text. 536 1.4.1. Compatibility with RFC 1510 538 It is important to note that existing Kerberos message formats can 539 not be readily extended by adding fields to the ASN.1 types. Sending 540 additional fields often results in the entire message being discarded 541 without an error indication. Future versions of this specification 542 will provide guidelines to ensure that ASN.1 fields can be added 543 without creating an interoperability problem. 545 In the meantime, all new or modified implementations of Kerberos that 546 receive an unknown message extension SHOULD preserve the encoding of 547 the extension but otherwise ignore the presence of the extension. 548 Recipients MUST NOT decline a request simply because an extension is 549 present. 551 There is one exception to this rule. If an unknown authorization data 552 element type is received by a server other than the ticket granting 553 service either in an AP-REQ or in a ticket contained in an AP-REQ, 554 then authentication MUST fail. One of the primary uses of 555 authorization data is to restrict the use of the ticket. If the 556 service cannot determine whether the restriction applies to that 557 service then a security weakness may result if the ticket can be used 558 for that service. Authorization elements that are optional SHOULD be 559 enclosed in the AD-IF-RELEVANT element. 561 The ticket granting service MUST ignore but propagate to derivative 562 tickets any unknown authorization data types, unless those data types 563 are embedded in a MANDATORY-FOR-KDC element, in which case the 564 request will be rejected. This behavior is appropriate because 565 requiring that the ticket granting service understand unknown 566 authorization data types would require that KDC software be upgraded 567 to understand new application-level restrictions before applications 568 used these restrictions, decreasing the utility of authorization data 569 as a mechanism for restricting the use of tickets. No security 571 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 573 problem is created because services to which the tickets are issued 574 will verify the authorization data. 576 Implementation note: Many RFC 1510 implementations ignore unknown 577 authorization data elements. Depending on these implementations to 578 honor authorization data restrictions may create a security weakness. 580 1.4.2. Sending Extensible Messages 582 Care must be taken to ensure that old implementations can understand 583 messages sent to them even if they do not understand an extension 584 that is used. Unless the sender knows an extension is supported, the 585 extension cannot change the semantics of the core message or 586 previously defined extensions. 588 For example, an extension including key information necessary to 589 decrypt the encrypted part of a KDC-REP could only be used in 590 situations where the recipient was known to support the extension. 591 Thus when designing such extensions it is important to provide a way 592 for the recipient to notify the sender of support for the extension. 593 For example in the case of an extension that changes the KDC-REP 594 reply key, the client could indicate support for the extension by 595 including a padata element in the AS-REQ sequence. The KDC should 596 only use the extension if this padata element is present in the AS- 597 REQ. Even if policy requires the use of the extension, it is better 598 to return an error indicating that the extension is required than to 599 use the extension when the recipient may not support it; debugging 600 why implementations do not interoperate is easier when errors are 601 returned. 603 1.5. Environmental assumptions 605 Kerberos imposes a few assumptions on the environment in which it can 606 properly function: 608 * "Denial of service" attacks are not solved with Kerberos. There 609 are places in the protocols where an intruder can prevent an 610 application from participating in the proper authentication steps. 611 Detection and solution of such attacks (some of which can appear 612 to be not-uncommon "normal" failure modes for the system) is 613 usually best left to the human administrators and users. 615 * Principals MUST keep their secret keys secret. If an intruder 616 somehow steals a principal's key, it will be able to masquerade as 617 that principal or impersonate any server to the legitimate 618 principal. 620 * "Password guessing" attacks are not solved by Kerberos. If a user 622 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 624 chooses a poor password, it is possible for an attacker to 625 successfully mount an offline dictionary attack by repeatedly 626 attempting to decrypt, with successive entries from a dictionary, 627 messages obtained which are encrypted under a key derived from the 628 user's password. 630 * Each host on the network MUST have a clock which is "loosely 631 synchronized" to the time of the other hosts; this synchronization 632 is used to reduce the bookkeeping needs of application servers 633 when they do replay detection. The degree of "looseness" can be 634 configured on a per-server basis, but is typically on the order of 635 5 minutes. If the clocks are synchronized over the network, the 636 clock synchronization protocol MUST itself be secured from network 637 attackers. 639 * Principal identifiers are not recycled on a short-term basis. A 640 typical mode of access control will use access control lists 641 (ACLs) to grant permissions to particular principals. If a stale 642 ACL entry remains for a deleted principal and the principal 643 identifier is reused, the new principal will inherit rights 644 specified in the stale ACL entry. By not re-using principal 645 identifiers, the danger of inadvertent access is removed. 647 1.6. Glossary of terms 649 Below is a list of terms used throughout this document. 651 Authentication 652 Verifying the claimed identity of a principal. 654 Authentication header 655 A record containing a Ticket and an Authenticator to be presented 656 to a server as part of the authentication process. 658 Authentication path 659 A sequence of intermediate realms transited in the authentication 660 process when communicating from one realm to another. 662 Authenticator 663 A record containing information that can be shown to have been 664 recently generated using the session key known only by the client 665 and server. 667 Authorization 668 The process of determining whether a client may use a service, 669 which objects the client is allowed to access, and the type of 670 access allowed for each. 672 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 674 Capability 675 A token that grants the bearer permission to access an object or 676 service. In Kerberos, this might be a ticket whose use is 677 restricted by the contents of the authorization data field, but 678 which lists no network addresses, together with the session key 679 necessary to use the ticket. 681 Ciphertext 682 The output of an encryption function. Encryption transforms 683 plaintext into ciphertext. 685 Client 686 A process that makes use of a network service on behalf of a user. 687 Note that in some cases a Server may itself be a client of some 688 other server (e.g. a print server may be a client of a file 689 server). 691 Credentials 692 A ticket plus the secret session key necessary to successfully use 693 that ticket in an authentication exchange. 695 Encryption Type (etype) 696 When associated with encrypted data, an encryption type identifies 697 the algorithm used to encrypt the data and is used to select the 698 appropriate algorithm for decrypting the data. Encryption type 699 tags are communicated in other messages to enumerate algorithms 700 that are desired, supported, preferred, or allowed to be used for 701 encryption of data between parties. This preference is combined 702 with local information and policy to select an algorithm to be 703 used. 705 KDC 706 Key Distribution Center, a network service that supplies tickets 707 and temporary session keys; or an instance of that service or the 708 host on which it runs. The KDC services both initial ticket and 709 ticket-granting ticket requests. The initial ticket portion is 710 sometimes referred to as the Authentication Server (or service). 711 The ticket-granting ticket portion is sometimes referred to as the 712 ticket-granting server (or service). 714 Kerberos 715 The name given to the Project Athena's authentication service, the 716 protocol used by that service, or the code used to implement the 717 authentication service. The name is adopted from the three-headed 718 dog which guards Hades. 720 Key Version Number (kvno) 721 A tag associated with encrypted data identifies which key was used 723 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 725 for encryption when a long lived key associated with a principal 726 changes over time. It is used during the transition to a new key 727 so that the party decrypting a message can tell whether the data 728 was encrypted using the old or the new key. 730 Plaintext 731 The input to an encryption function or the output of a decryption 732 function. Decryption transforms ciphertext into plaintext. 734 Principal 735 A named client or server entity that participates in a network 736 communication, with one name that is considered canonical. 738 Principal identifier 739 The canonical name used to uniquely identify each different 740 principal. 742 Seal 743 To encipher a record containing several fields in such a way that 744 the fields cannot be individually replaced without either 745 knowledge of the encryption key or leaving evidence of tampering. 747 Secret key 748 An encryption key shared by a principal and the KDC, distributed 749 outside the bounds of the system, with a long lifetime. In the 750 case of a human user's principal, the secret key MAY be derived 751 from a password. 753 Server 754 A particular Principal which provides a resource to network 755 clients. The server is sometimes referred to as the Application 756 Server. 758 Service 759 A resource provided to network clients; often provided by more 760 than one server (for example, remote file service). 762 Session key 763 A temporary encryption key used between two principals, with a 764 lifetime limited to the duration of a single login "session". In 765 the Kerberos system, a session key is generated by the KDC. The 766 session key is distinct from the sub-session key, described next.. 768 Sub-session key 769 A temporary encryption key used between two principals, selected 770 and exchanged by the principals using the session key, and with a 771 lifetime limited to the duration of a single association. The sub- 772 session key is also referred to as the subkey. 774 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 776 Ticket 777 A record that helps a client authenticate itself to a server; it 778 contains the client's identity, a session key, a timestamp, and 779 other information, all sealed using the server's secret key. It 780 only serves to authenticate a client when presented along with a 781 fresh Authenticator. 783 2. Ticket flag uses and requests 785 Each Kerberos ticket contains a set of flags which are used to 786 indicate attributes of that ticket. Most flags may be requested by a 787 client when the ticket is obtained; some are automatically turned on 788 and off by a Kerberos server as required. The following sections 789 explain what the various flags mean and give examples of reasons to 790 use them. With the exception of the INVALID flag clients MUST ignore 791 ticket flags that are not recognized. KDCs MUST ignore KDC options 792 that are not recognized. Some implementations of RFC 1510 are known 793 to reject unknown KDC options, so clients may need to resend a 794 request without new KDC options if the request was rejected when sent 795 with options added since RFC 1510. Since new KDCs will ignore unknown 796 options, clients MUST confirm that the ticket returned by the KDC 797 meets their needs. 799 Note that it is not, in general, possible to determine whether an 800 option was not honored because it was not understood or because it 801 was rejected either through configuration or policy. When adding a 802 new option to the Kerberos protocol, designers should consider 803 whether the distinction is important for their option. In cases where 804 it is, a mechanism for the KDC to return an indication that the 805 option was understood but rejected needs to be provided in the 806 specification of the option. Often in such cases, the mechanism needs 807 to be broad enough to permit an error or reason to be returned. 809 2.1. Initial, pre-authenticated, and hardware authenticated tickets 811 The INITIAL flag indicates that a ticket was issued using the AS 812 protocol, rather than issued based on a ticket-granting ticket. 813 Application servers that want to require the demonstrated knowledge 814 of a client's secret key (e.g. a password-changing program) can 815 insist that this flag be set in any tickets they accept, and thus be 816 assured that the client's key was recently presented to the 817 application client. 819 The PRE-AUTHENT and HW-AUTHENT flags provide additional information 820 about the initial authentication, regardless of whether the current 821 ticket was issued directly (in which case INITIAL will also be set) 822 or issued on the basis of a ticket-granting ticket (in which case the 824 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 826 INITIAL flag is clear, but the PRE-AUTHENT and HW-AUTHENT flags are 827 carried forward from the ticket-granting ticket). 829 2.2. Invalid tickets 831 The INVALID flag indicates that a ticket is invalid. Application 832 servers MUST reject tickets which have this flag set. A postdated 833 ticket will be issued in this form. Invalid tickets MUST be validated 834 by the KDC before use, by presenting them to the KDC in a TGS request 835 with the VALIDATE option specified. The KDC will only validate 836 tickets after their starttime has passed. The validation is required 837 so that postdated tickets which have been stolen before their 838 starttime can be rendered permanently invalid (through a hot-list 839 mechanism) (see section 3.3.3.1). 841 2.3. Renewable tickets 843 Applications may desire to hold tickets which can be valid for long 844 periods of time. However, this can expose their credentials to 845 potential theft for equally long periods, and those stolen 846 credentials would be valid until the expiration time of the 847 ticket(s). Simply using short-lived tickets and obtaining new ones 848 periodically would require the client to have long-term access to its 849 secret key, an even greater risk. Renewable tickets can be used to 850 mitigate the consequences of theft. Renewable tickets have two 851 "expiration times": the first is when the current instance of the 852 ticket expires, and the second is the latest permissible value for an 853 individual expiration time. An application client must periodically 854 (i.e. before it expires) present a renewable ticket to the KDC, with 855 the RENEW option set in the KDC request. The KDC will issue a new 856 ticket with a new session key and a later expiration time. All other 857 fields of the ticket are left unmodified by the renewal process. When 858 the latest permissible expiration time arrives, the ticket expires 859 permanently. At each renewal, the KDC MAY consult a hot-list to 860 determine if the ticket had been reported stolen since its last 861 renewal; it will refuse to renew such stolen tickets, and thus the 862 usable lifetime of stolen tickets is reduced. 864 The RENEWABLE flag in a ticket is normally only interpreted by the 865 ticket-granting service (discussed below in section 3.3). It can 866 usually be ignored by application servers. However, some particularly 867 careful application servers MAY disallow renewable tickets. 869 If a renewable ticket is not renewed by its expiration time, the KDC 870 will not renew the ticket. The RENEWABLE flag is reset by default, 871 but a client MAY request it be set by setting the RENEWABLE option in 872 the KRB_AS_REQ message. If it is set, then the renew-till field in 873 the ticket contains the time after which the ticket may not be 875 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 877 renewed. 879 2.4. Postdated tickets 881 Applications may occasionally need to obtain tickets for use much 882 later, e.g. a batch submission system would need tickets to be valid 883 at the time the batch job is serviced. However, it is dangerous to 884 hold valid tickets in a batch queue, since they will be on-line 885 longer and more prone to theft. Postdated tickets provide a way to 886 obtain these tickets from the KDC at job submission time, but to 887 leave them "dormant" until they are activated and validated by a 888 further request of the KDC. If a ticket theft were reported in the 889 interim, the KDC would refuse to validate the ticket, and the thief 890 would be foiled. 892 The MAY-POSTDATE flag in a ticket is normally only interpreted by the 893 ticket-granting service. It can be ignored by application servers. 894 This flag MUST be set in a ticket-granting ticket in order to issue a 895 postdated ticket based on the presented ticket. It is reset by 896 default; it MAY be requested by a client by setting the ALLOW- 897 POSTDATE option in the KRB_AS_REQ message. This flag does not allow 898 a client to obtain a postdated ticket-granting ticket; postdated 899 ticket-granting tickets can only by obtained by requesting the 900 postdating in the KRB_AS_REQ message. The life (endtime-starttime) of 901 a postdated ticket will be the remaining life of the ticket-granting 902 ticket at the time of the request, unless the RENEWABLE option is 903 also set, in which case it can be the full life (endtime-starttime) 904 of the ticket-granting ticket. The KDC MAY limit how far in the 905 future a ticket may be postdated. 907 The POSTDATED flag indicates that a ticket has been postdated. The 908 application server can check the authtime field in the ticket to see 909 when the original authentication occurred. Some services MAY choose 910 to reject postdated tickets, or they may only accept them within a 911 certain period after the original authentication. When the KDC issues 912 a POSTDATED ticket, it will also be marked as INVALID, so that the 913 application client MUST present the ticket to the KDC to be validated 914 before use. 916 2.5. Proxiable and proxy tickets 918 At times it may be necessary for a principal to allow a service to 919 perform an operation on its behalf. The service must be able to take 920 on the identity of the client, but only for a particular purpose. A 921 principal can allow a service to take on the principal's identity for 922 a particular purpose by granting it a proxy. 924 The process of granting a proxy using the proxy and proxiable flags 926 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 928 is used to provide credentials for use with specific services. Though 929 conceptually also a proxy, users wishing to delegate their identity 930 in a form usable for all purpose MUST use the ticket forwarding 931 mechanism described in the next section to forward a ticket-granting 932 ticket. 934 The PROXIABLE flag in a ticket is normally only interpreted by the 935 ticket-granting service. It can be ignored by application servers. 936 When set, this flag tells the ticket-granting server that it is OK to 937 issue a new ticket (but not a ticket-granting ticket) with a 938 different network address based on this ticket. This flag is set if 939 requested by the client on initial authentication. By default, the 940 client will request that it be set when requesting a ticket-granting 941 ticket, and reset when requesting any other ticket. 943 This flag allows a client to pass a proxy to a server to perform a 944 remote request on its behalf (e.g. a print service client can give 945 the print server a proxy to access the client's files on a particular 946 file server in order to satisfy a print request). 948 In order to complicate the use of stolen credentials, Kerberos 949 tickets are usually valid from only those network addresses 950 specifically included in the ticket[4]. When granting a proxy, the 951 client MUST specify the new network address from which the proxy is 952 to be used, or indicate that the proxy is to be issued for use from 953 any address. 955 The PROXY flag is set in a ticket by the TGS when it issues a proxy 956 ticket. Application servers MAY check this flag and at their option 957 they MAY require additional authentication from the agent presenting 958 the proxy in order to provide an audit trail. 960 2.6. Forwardable tickets 962 Authentication forwarding is an instance of a proxy where the service 963 that is granted is complete use of the client's identity. An example 964 where it might be used is when a user logs in to a remote system and 965 wants authentication to work from that system as if the login were 966 local. 968 The FORWARDABLE flag in a ticket is normally only interpreted by the 969 ticket-granting service. It can be ignored by application servers. 970 The FORWARDABLE flag has an interpretation similar to that of the 971 PROXIABLE flag, except ticket-granting tickets may also be issued 972 with different network addresses. This flag is reset by default, but 973 users MAY request that it be set by setting the FORWARDABLE option in 974 the AS request when they request their initial ticket-granting 975 ticket. 977 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 979 This flag allows for authentication forwarding without requiring the 980 user to enter a password again. If the flag is not set, then 981 authentication forwarding is not permitted, but the same result can 982 still be achieved if the user engages in the AS exchange specifying 983 the requested network addresses and supplies a password. 985 The FORWARDED flag is set by the TGS when a client presents a ticket 986 with the FORWARDABLE flag set and requests a forwarded ticket by 987 specifying the FORWARDED KDC option and supplying a set of addresses 988 for the new ticket. It is also set in all tickets issued based on 989 tickets with the FORWARDED flag set. Application servers may choose 990 to process FORWARDED tickets differently than non-FORWARDED tickets. 992 If addressless tickets are forwarded from one system to another, 993 clients SHOULD still use this option to obtain a new TGT in order to 994 have different session keys on the different systems. 996 2.7. Transited Policy Checking 998 In Kerberos, the application server is ultimately responsible for 999 accepting or rejecting authentication and SHOULD check that only 1000 suitably trusted KDCs are relied upon to authenticate a principal. 1001 The transited field in the ticket identifies which realms (and thus 1002 which KDCs) were involved in the authentication process and an 1003 application server would normally check this field. If any of these 1004 are untrusted to authenticate the indicated client principal 1005 (probably determined by a realm-based policy), the authentication 1006 attempt MUST be rejected. The presence of trusted KDCs in this list 1007 does not provide any guarantee; an untrusted KDC may have fabricated 1008 the list. 1010 While the end server ultimately decides whether authentication is 1011 valid, the KDC for the end server's realm MAY apply a realm specific 1012 policy for validating the transited field and accepting credentials 1013 for cross-realm authentication. When the KDC applies such checks and 1014 accepts such cross-realm authentication it will set the TRANSITED- 1015 POLICY-CHECKED flag in the service tickets it issues based on the 1016 cross-realm TGT. A client MAY request that the KDCs not check the 1017 transited field by setting the DISABLE-TRANSITED-CHECK flag. KDCs are 1018 encouraged but not required to honor this flag. 1020 Application servers MUST either do the transited-realm checks 1021 themselves, or reject cross-realm tickets without TRANSITED-POLICY- 1022 CHECKED set. 1024 2.8. OK as Delegate 1026 For some applications a client may need to delegate authority to a 1028 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 1030 server to act on its behalf in contacting other services. This 1031 requires that the client forward credentials to an intermediate 1032 server. The ability for a client to obtain a service ticket to a 1033 server conveys no information to the client about whether the server 1034 should be trusted to accept delegated credentials. The OK-AS- 1035 DELEGATE provides a way for a KDC to communicate local realm policy 1036 to a client regarding whether an intermediate server is trusted to 1037 accept such credentials. 1039 The copy of the ticket flags in the encrypted part of the KDC reply 1040 may have the OK-AS-DELEGATE flag set to indicates to the client that 1041 the server specified in the ticket has been determined by policy of 1042 the realm to be a suitable recipient of delegation. A client can use 1043 the presence of this flag to help it make a decision whether to 1044 delegate credentials (either grant a proxy or a forwarded ticket- 1045 granting ticket) to this server. It is acceptable to ignore the 1046 value of this flag. When setting this flag, an administrator should 1047 consider the security and placement of the server on which the 1048 service will run, as well as whether the service requires the use of 1049 delegated credentials. 1051 2.9. Other KDC options 1053 There are three additional options which MAY be set in a client's 1054 request of the KDC. 1056 2.9.1. Renewable-OK 1058 The RENEWABLE-OK option indicates that the client will accept a 1059 renewable ticket if a ticket with the requested life cannot otherwise 1060 be provided. If a ticket with the requested life cannot be provided, 1061 then the KDC MAY issue a renewable ticket with a renew-till equal to 1062 the requested endtime. The value of the renew-till field MAY still be 1063 adjusted by site-determined limits or limits imposed by the 1064 individual principal or server. 1066 2.9.2. ENC-TKT-IN-SKEY 1068 In its basic form the Kerberos protocol supports authentication in a 1069 client-server 1070 setting and is not well suited to authentication in a peer-to-peer 1071 environment because the long term key of the user does not remain on 1072 the workstation after initial login. Authentication of such peers may 1073 be supported by Kerberos in its user-to-user variant. The ENC-TKT-IN- 1074 SKEY option supports user-to-user authentication by allowing the KDC 1075 to issue a service ticket encrypted using the session key from 1076 another ticket-granting ticket issued to another user. The ENC-TKT- 1077 IN-SKEY option is honored only by the ticket-granting service. It 1079 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 1081 indicates that the ticket to be issued for the end server is to be 1082 encrypted in the session key from the additional second ticket- 1083 granting ticket provided with the request. See section 3.3.3 for 1084 specific details. 1086 2.9.3. Passwordless Hardware Authentication 1088 The OPT-HARDWARE-AUTH option indicates that the client wishes to use 1089 some form of hardware authentication instead of or in addition to the 1090 client's password or other long-lived encryption key. OPT-HARDWARE- 1091 AUTH is honored only by the authentication service. If supported and 1092 allowed by policy, the KDC will return an errorcode 1093 KDC_ERR_PREAUTH_REQUIRED and include the required METHOD-DATA to 1094 perform such authentication. 1096 3. Message Exchanges 1098 The following sections describe the interactions between network 1099 clients and servers and the messages involved in those exchanges. 1101 3.1. The Authentication Service Exchange 1103 Summary 1105 Message direction Message type Section 1106 1. Client to Kerberos KRB_AS_REQ 5.4.1 1107 2. Kerberos to client KRB_AS_REP or 5.4.2 1108 KRB_ERROR 5.9.1 1110 The Authentication Service (AS) Exchange between the client and the 1111 Kerberos Authentication Server is initiated by a client when it 1112 wishes to obtain authentication credentials for a given server but 1113 currently holds no credentials. In its basic form, the client's 1114 secret key is used for encryption and decryption. This exchange is 1115 typically used at the initiation of a login session to obtain 1116 credentials for a Ticket-Granting Server which will subsequently be 1117 used to obtain credentials for other servers (see section 3.3) 1118 without requiring further use of the client's secret key. This 1119 exchange is also used to request credentials for services which must 1120 not be mediated through the Ticket-Granting Service, but rather 1121 require a principal's secret key, such as the password-changing 1122 service[5]. This exchange does not by itself provide any assurance of 1123 the identity of the user[6]. 1125 The exchange consists of two messages: KRB_AS_REQ from the client to 1126 Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these 1127 messages are described in sections 5.4.1, 5.4.2, and 5.9.1. 1129 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 1131 In the request, the client sends (in cleartext) its own identity and 1132 the identity of the server for which it is requesting credentials, 1133 other information about the credentials it is requesting, and a 1134 randomly generated nonce which can be used to detect replays, and to 1135 associate replies with the matching requests. This nonce MUST be 1136 generated randomly by the client and remembered for checking against 1137 the nonce in the expected reply. The response, KRB_AS_REP, contains a 1138 ticket for the client to present to the server, and a session key 1139 that will be shared by the client and the server. The session key 1140 and additional information are encrypted in the client's secret key. 1141 The encrypted part of the KRB_AS_REP message also contains the nonce 1142 which MUST be matched with the nonce from the KRB_AS_REQ message. 1144 Without pre-authentication, the authentication server does not know 1145 whether the client is actually the principal named in the request. It 1146 simply sends a reply without knowing or caring whether they are the 1147 same. This is acceptable because nobody but the principal whose 1148 identity was given in the request will be able to use the reply. Its 1149 critical information is encrypted in that principal's key. However, 1150 an attacker can send a KRB_AS_REQ message to get known plaintext in 1151 order to attack the principal's key. Especially if the key is based 1152 on a password, this may create a security exposure. So, the initial 1153 request supports an optional field that can be used to pass 1154 additional information that might be needed for the initial exchange. 1155 This field SHOULD be used for pre-authentication as described in 1156 sections 3.1.1 and 5.2.7. 1158 Various errors can occur; these are indicated by an error response 1159 (KRB_ERROR) instead of the KRB_AS_REP response. The error message is 1160 not encrypted. The KRB_ERROR message contains information which can 1161 be used to associate it with the message to which it replies. The 1162 contents of the KRB_ERROR message are not integrity-protected. As 1163 such, the client cannot detect replays, fabrications or 1164 modifications. A solution to this problem will be included in a 1165 future version of the protocol. 1167 3.1.1. Generation of KRB_AS_REQ message 1169 The client may specify a number of options in the initial request. 1170 Among these options are whether pre-authentication is to be 1171 performed; whether the requested ticket is to be renewable, 1172 proxiable, or forwardable; whether it should be postdated or allow 1173 postdating of derivative tickets; and whether a renewable ticket will 1174 be accepted in lieu of a non-renewable ticket if the requested ticket 1175 expiration date cannot be satisfied by a non-renewable ticket (due to 1176 configuration constraints). 1178 The client prepares the KRB_AS_REQ message and sends it to the KDC. 1180 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 1182 3.1.2. Receipt of KRB_AS_REQ message 1184 If all goes well, processing the KRB_AS_REQ message will result in 1185 the creation of a ticket for the client to present to the server. The 1186 format for the ticket is described in section 5.3. 1188 Because Kerberos can run over unreliable transports such as UDP, the 1189 KDC MUST be prepared to retransmit responses in case they are lost. 1190 If a KDC receives a request identical to one it has recently 1191 successfully processed, the KDC MUST respond with a KRB_AS_REP 1192 message rather than a replay error. In order to reduce ciphertext 1193 given to a potential attacker, KDCs MAY send the same response 1194 generated when the request was first handled. KDCs MUST obey this 1195 replay behavior even if the actual transport in use is reliable. 1197 3.1.3. Generation of KRB_AS_REP message 1199 The authentication server looks up the client and server principals 1200 named in the KRB_AS_REQ in its database, extracting their respective 1201 keys. If the requested client principal named in the request is not 1202 known because it doesn't exist in the KDC's principal database, then 1203 an error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is returned. 1205 If required, the server pre-authenticates the request, and if the 1206 pre-authentication check fails, an error message with the code 1207 KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is 1208 required, but was not present in the request, an error message with 1209 the code KDC_ERR_PREAUTH_REQUIRED is returned and a METHOD-DATA 1210 object will be stored in the e-data field of the KRB-ERROR message to 1211 specify which pre-authentication mechanisms are acceptable. Usually 1212 this will include PA-ETYPE-INFO and/or PA-ETYPE-INFO2 elements as 1213 described below. If the server cannot accommodate any encryption type 1214 requested by the client, an error message with code 1215 KDC_ERR_ETYPE_NOSUPP is returned. Otherwise the KDC generates a 1216 'random' session key[7]. 1218 When responding to an AS request, if there are multiple encryption 1219 keys registered for a client in the Kerberos database, then the etype 1220 field from the AS request is used by the KDC to select the encryption 1221 method to be used to protect the encrypted part of the KRB_AS_REP 1222 message which is sent to the client. If there is more than one 1223 supported strong encryption type in the etype list, the KDC SHOULD 1224 use the first valid strong etype for which an encryption key is 1225 available. 1227 When the user's key is generated from a password or pass phrase, the 1228 string-to-key function for the particular encryption key type is 1229 used, as specified in [@KCRYPTO]. The salt value and additional 1231 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 1233 parameters for the string-to-key function have default values 1234 (specified by section 4 and by the encryption mechanism 1235 specification, respectively) that may be overridden by pre- 1236 authentication data (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA- 1237 ETYPE-INFO2, etc). Since the KDC is presumed to store a copy of the 1238 resulting key only, these values should not be changed for password- 1239 based keys except when changing the principal's key. 1241 When the AS server is to include pre-authentication data in a KRB- 1242 ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE-INFO, 1243 if the etype field of the client's AS-REQ lists at least one "newer" 1244 encryption type. Otherwise (when the etype field of the client's AS- 1245 REQ does not list any "newer" encryption types) it MUST send both, 1246 PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an entry for each 1247 enctype). A "newer" enctype is any enctype first officially 1248 specified concurrently with or subsequent to the issue of this RFC. 1249 The enctypes DES, 3DES or RC4 and any defined in [RFC1510] are not 1250 newer enctypes. 1252 It is not possible to reliably generate a user's key given a pass 1253 phrase without contacting the KDC, since it will not be known whether 1254 alternate salt or parameter values are required. 1256 The KDC will attempt to assign the type of the random session key 1257 from the list of methods in the etype field. The KDC will select the 1258 appropriate type using the list of methods provided together with 1259 information from the Kerberos database indicating acceptable 1260 encryption methods for the application server. The KDC will not issue 1261 tickets with a weak session key encryption type. 1263 If the requested start time is absent, indicates a time in the past, 1264 or is within the window of acceptable clock skew for the KDC and the 1265 POSTDATE option has not been specified, then the start time of the 1266 ticket is set to the authentication server's current time. If it 1267 indicates a time in the future beyond the acceptable clock skew, but 1268 the POSTDATED option has not been specified then the error 1269 KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the requested start 1270 time is checked against the policy of the local realm (the 1271 administrator might decide to prohibit certain types or ranges of 1272 postdated tickets), and if acceptable, the ticket's start time is set 1273 as requested and the INVALID flag is set in the new ticket. The 1274 postdated ticket MUST be validated before use by presenting it to the 1275 KDC after the start time has been reached. 1277 The expiration time of the ticket will be set to the earlier of the 1278 requested endtime and a time determined by local policy, possibly 1279 determined using realm or principal specific factors. For example, 1280 the expiration time MAY be set to the earliest of the following: 1282 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 1284 * The expiration time (endtime) requested in the KRB_AS_REQ 1285 message. 1287 * The ticket's start time plus the maximum allowable lifetime 1288 associated with the client principal from the authentication 1289 server's database. 1291 * The ticket's start time plus the maximum allowable lifetime 1292 associated with the server principal. 1294 * The ticket's start time plus the maximum lifetime set by the 1295 policy of the local realm. 1297 If the requested expiration time minus the start time (as determined 1298 above) is less than a site-determined minimum lifetime, an error 1299 message with code KDC_ERR_NEVER_VALID is returned. If the requested 1300 expiration time for the ticket exceeds what was determined as above, 1301 and if the 'RENEWABLE-OK' option was requested, then the 'RENEWABLE' 1302 flag is set in the new ticket, and the renew-till value is set as if 1303 the 'RENEWABLE' option were requested (the field and option names are 1304 described fully in section 5.4.1). 1306 If the RENEWABLE option has been requested or if the RENEWABLE-OK 1307 option has been set and a renewable ticket is to be issued, then the 1308 renew-till field MAY be set to the earliest of: 1310 * Its requested value. 1312 * The start time of the ticket plus the minimum of the two 1313 maximum renewable lifetimes associated with the principals' 1314 database entries. 1316 * The start time of the ticket plus the maximum renewable 1317 lifetime set by the policy of the local realm. 1319 The flags field of the new ticket will have the following options set 1320 if they have been requested and if the policy of the local realm 1321 allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. 1322 If the new ticket is postdated (the start time is in the future), its 1323 INVALID flag will also be set. 1325 If all of the above succeed, the server will encrypt the ciphertext 1326 part of the ticket using the encryption key extracted from the server 1327 principal's record in the Kerberos database using the encryption type 1328 associated with the server principal's key (this choice is NOT 1329 affected by the etype field in the request). It then formats a 1330 KRB_AS_REP message (see section 5.4.2), copying the addresses in the 1331 request into the caddr of the response, placing any required pre- 1333 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 1335 authentication data into the padata of the response, and encrypts the 1336 ciphertext part in the client's key using an acceptable encryption 1337 method requested in the etype field of the request, or in some key 1338 specified by pre-authentication mechanisms being used. 1340 3.1.4. Generation of KRB_ERROR message 1342 Several errors can occur, and the Authentication Server responds by 1343 returning an error message, KRB_ERROR, to the client, with the error- 1344 code and e-text fields set to appropriate values. The error message 1345 contents and details are described in Section 5.9.1. 1347 3.1.5. Receipt of KRB_AS_REP message 1349 If the reply message type is KRB_AS_REP, then the client verifies 1350 that the cname and crealm fields in the cleartext portion of the 1351 reply match what it requested. If any padata fields are present, they 1352 may be used to derive the proper secret key to decrypt the message. 1353 The client decrypts the encrypted part of the response using its 1354 secret key, verifies that the nonce in the encrypted part matches the 1355 nonce it supplied in its request (to detect replays). It also 1356 verifies that the sname and srealm in the response match those in the 1357 request (or are otherwise expected values), and that the host address 1358 field is also correct. It then stores the ticket, session key, start 1359 and expiration times, and other information for later use. The last- 1360 req field (and the deprecated key-expiration field) from the 1361 encrypted part of the response MAY be checked to notify the user of 1362 impending key expiration. This enables the client program to suggest 1363 remedial action, such as a password change. 1365 Upon validation of the KRB_AS_REP message (by checking the returned 1366 nonce against that sent in the KRB_AS_REQ message) the client knows 1367 that the current time on the KDC is that read from the authtime field 1368 of the encrypted part of the reply. The client can optionally use 1369 this value for clock synchronization in subsequent messages by 1370 recording with the ticket the difference (offset) between the 1371 authtime value and the local clock. This offset can then be used by 1372 the same user to adjust the time read from the system clock when 1373 generating messages [DGT96]. 1375 This technique MUST be used when adjusting for clock skew instead of 1376 directly changing the system clock because the KDC reply is only 1377 authenticated to the user whose secret key was used, but not to the 1378 system or workstation. If the clock were adjusted, an attacker 1379 colluding with a user logging into a workstation could agree on a 1380 password, resulting in a KDC reply that would be correctly validated 1381 even though it did not originate from a KDC trusted by the 1382 workstation. 1384 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 1386 Proper decryption of the KRB_AS_REP message is not sufficient for the 1387 host to verify the identity of the user; the user and an attacker 1388 could cooperate to generate a KRB_AS_REP format message which 1389 decrypts properly but is not from the proper KDC. If the host wishes 1390 to verify the identity of the user, it MUST require the user to 1391 present application credentials which can be verified using a 1392 securely-stored secret key for the host. If those credentials can be 1393 verified, then the identity of the user can be assured. 1395 3.1.6. Receipt of KRB_ERROR message 1397 If the reply message type is KRB_ERROR, then the client interprets it 1398 as an error and performs whatever application-specific tasks are 1399 necessary to recover. 1401 3.2. The Client/Server Authentication Exchange 1403 Summary 1404 Message direction Message type Section 1405 Client to Application server KRB_AP_REQ 5.5.1 1406 [optional] Application server to client KRB_AP_REP or 5.5.2 1407 KRB_ERROR 5.9.1 1409 The client/server authentication (CS) exchange is used by network 1410 applications to authenticate the client to the server and vice versa. 1411 The client MUST have already acquired credentials for the server 1412 using the AS or TGS exchange. 1414 3.2.1. The KRB_AP_REQ message 1416 The KRB_AP_REQ contains authentication information which SHOULD be 1417 part of the first message in an authenticated transaction. It 1418 contains a ticket, an authenticator, and some additional bookkeeping 1419 information (see section 5.5.1 for the exact format). The ticket by 1420 itself is insufficient to authenticate a client, since tickets are 1421 passed across the network in cleartext[8], so the authenticator is 1422 used to prevent invalid replay of tickets by proving to the server 1423 that the client knows the session key of the ticket and thus is 1424 entitled to use the ticket. The KRB_AP_REQ message is referred to 1425 elsewhere as the 'authentication header.' 1427 3.2.2. Generation of a KRB_AP_REQ message 1429 When a client wishes to initiate authentication to a server, it 1430 obtains (either through a credentials cache, the AS exchange, or the 1431 TGS exchange) a ticket and session key for the desired service. The 1432 client MAY re-use any tickets it holds until they expire. To use a 1433 ticket the client constructs a new Authenticator from the system 1435 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 1437 time, its name, and optionally an application specific checksum, an 1438 initial sequence number to be used in KRB_SAFE or KRB_PRIV messages, 1439 and/or a session subkey to be used in negotiations for a session key 1440 unique to this particular session. Authenticators MAY NOT be re-used 1441 and will be rejected if replayed to a server[9]. If a sequence number 1442 is to be included, it SHOULD be randomly chosen so that even after 1443 many messages have been exchanged it is not likely to collide with 1444 other sequence numbers in use. 1446 The client MAY indicate a requirement of mutual authentication or the 1447 use of a session-key based ticket (for user to user authentication - 1448 see section 3.7) by setting the appropriate flag(s) in the ap-options 1449 field of the message. 1451 The Authenticator is encrypted in the session key and combined with 1452 the ticket to form the KRB_AP_REQ message which is then sent to the 1453 end server along with any additional application-specific 1454 information. 1456 3.2.3. Receipt of KRB_AP_REQ message 1458 Authentication is based on the server's current time of day (clocks 1459 MUST be loosely synchronized), the authenticator, and the ticket. 1460 Several errors are possible. If an error occurs, the server is 1461 expected to reply to the client with a KRB_ERROR message. This 1462 message MAY be encapsulated in the application protocol if its 'raw' 1463 form is not acceptable to the protocol. The format of error messages 1464 is described in section 5.9.1. 1466 The algorithm for verifying authentication information is as follows. 1467 If the message type is not KRB_AP_REQ, the server returns the 1468 KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the Ticket 1469 in the KRB_AP_REQ is not one the server can use (e.g., it indicates 1470 an old key, and the server no longer possesses a copy of the old 1471 key), the KRB_AP_ERR_BADKEYVER error is returned. If the USE-SESSION- 1472 KEY flag is set in the ap-options field, it indicates to the server 1473 that user-to-user authentication is in use, and that the ticket is 1474 encrypted in the session key from the server's ticket-granting ticket 1475 rather than in the server's secret key. See section 3.7 for a more 1476 complete description of the effect of user to user authentication on 1477 all messages in the Kerberos protocol. 1479 Since it is possible for the server to be registered in multiple 1480 realms, with different keys in each, the srealm field in the 1481 unencrypted portion of the ticket in the KRB_AP_REQ is used to 1482 specify which secret key the server should use to decrypt that 1483 ticket. The KRB_AP_ERR_NOKEY error code is returned if the server 1484 doesn't have the proper key to decipher the ticket. 1486 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 1488 The ticket is decrypted using the version of the server's key 1489 specified by the ticket. If the decryption routines detect a 1490 modification of the ticket (each encryption system MUST provide 1491 safeguards to detect modified ciphertext), the 1492 KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that 1493 different keys were used to encrypt and decrypt). 1495 The authenticator is decrypted using the session key extracted from 1496 the decrypted ticket. If decryption shows it to have been modified, 1497 the KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of 1498 the client from the ticket are compared against the same fields in 1499 the authenticator. If they don't match, the KRB_AP_ERR_BADMATCH 1500 error is returned; this normally is caused by a client error or 1501 attempted attack. The addresses in the ticket (if any) are then 1502 searched for an address matching the operating-system reported 1503 address of the client. If no match is found or the server insists on 1504 ticket addresses but none are present in the ticket, the 1505 KRB_AP_ERR_BADADDR error is returned. If the local (server) time and 1506 the client time in the authenticator differ by more than the 1507 allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW error is 1508 returned. 1510 Unless the application server provides its own suitable means to 1511 protect against replay (for example, a challenge-response sequence 1512 initiated by the server after authentication, or use of a server- 1513 generated encryption subkey), the server MUST utilize a replay cache 1514 to remember any authenticator presented within the allowable clock 1515 skew. Careful analysis of the application protocol and implementation 1516 is recommended before eliminating this cache. The replay cache will 1517 store at least the server name, along with the client name, time and 1518 microsecond fields from the recently-seen authenticators and if a 1519 matching tuple is found, the KRB_AP_ERR_REPEAT error is returned 1520 [10]. If a server loses track of authenticators presented within the 1521 allowable clock skew, it MUST reject all requests until the clock 1522 skew interval has passed, providing assurance that any lost or 1523 replayed authenticators will fall outside the allowable clock skew 1524 and can no longer be successfully replayed [11]. 1526 Implementation note: If a client generates multiple requests to the 1527 KDC with the same timestamp, including the microsecond field, all but 1528 the first of the requests received will be rejected as replays. This 1529 might happen, for example, if the resolution of the client's clock is 1530 too coarse. Implementations SHOULD ensure that the timestamps are 1531 not reused, possibly by incrementing the microseconds field in the 1532 time stamp when the clock returns the same time for multiple 1533 requests. 1535 If multiple servers (for example, different services on one machine, 1537 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 1539 or a single service implemented on multiple machines) share a service 1540 principal (a practice we do not recommend in general, but acknowledge 1541 will be used in some cases), they MUST either share this replay 1542 cache, or the application protocol MUST be designed so as to 1543 eliminate the need for it. Note that this applies to all of the 1544 services, if any of the application protocols does not have replay 1545 protection built in; an authenticator used with such a service could 1546 later be replayed to a different service with the same service 1547 principal but no replay protection, if the former doesn't record the 1548 authenticator information in the common replay cache. 1550 If a sequence number is provided in the authenticator, the server 1551 saves it for later use in processing KRB_SAFE and/or KRB_PRIV 1552 messages. If a subkey is present, the server either saves it for 1553 later use or uses it to help generate its own choice for a subkey to 1554 be returned in a KRB_AP_REP message. 1556 The server computes the age of the ticket: local (server) time minus 1557 the start time inside the Ticket. If the start time is later than the 1558 current time by more than the allowable clock skew or if the INVALID 1559 flag is set in the ticket, the KRB_AP_ERR_TKT_NYV error is returned. 1560 Otherwise, if the current time is later than end time by more than 1561 the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error is 1562 returned. 1564 If all these checks succeed without an error, the server is assured 1565 that the client possesses the credentials of the principal named in 1566 the ticket and thus, the client has been authenticated to the server. 1568 Passing these checks provides only authentication of the named 1569 principal; it does not imply authorization to use the named service. 1570 Applications MUST make a separate authorization decision based upon 1571 the authenticated name of the user, the requested operation, local 1572 access control information such as that contained in a .k5login or 1573 .k5users file, and possibly a separate distributed authorization 1574 service. 1576 3.2.4. Generation of a KRB_AP_REP message 1578 Typically, a client's request will include both the authentication 1579 information and its initial request in the same message, and the 1580 server need not explicitly reply to the KRB_AP_REQ. However, if 1581 mutual authentication (not only authenticating the client to the 1582 server, but also the server to the client) is being performed, the 1583 KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options 1584 field, and a KRB_AP_REP message is required in response. As with the 1585 error message, this message MAY be encapsulated in the application 1586 protocol if its "raw" form is not acceptable to the application's 1588 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 1590 protocol. The timestamp and microsecond field used in the reply MUST 1591 be the client's timestamp and microsecond field (as provided in the 1592 authenticator) [12]. If a sequence number is to be included, it 1593 SHOULD be randomly chosen as described above for the authenticator. A 1594 subkey MAY be included if the server desires to negotiate a different 1595 subkey. The KRB_AP_REP message is encrypted in the session key 1596 extracted from the ticket. 1598 3.2.5. Receipt of KRB_AP_REP message 1600 If a KRB_AP_REP message is returned, the client uses the session key 1601 from the credentials obtained for the server [13] to decrypt the 1602 message, and verifies that the timestamp and microsecond fields match 1603 those in the Authenticator it sent to the server. If they match, then 1604 the client is assured that the server is genuine. The sequence number 1605 and subkey (if present) are retained for later use. 1607 3.2.6. Using the encryption key 1609 After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and 1610 server share an encryption key which can be used by the application. 1611 In some cases, the use of this session key will be implicit in the 1612 protocol; in others the method of use must be chosen from several 1613 alternatives. The actual encryption key to be used for KRB_PRIV, 1614 KRB_SAFE, or other application-specific uses MAY be chosen by the 1615 application based on the session key from the ticket and subkeys in 1616 the KRB_AP_REP message and the authenticator [14]. To mitigate the 1617 effect of failures in random number generation on the client it is 1618 strongly encouraged that any key derived by an application for 1619 subsequent use include the full key entropy derived from the KDC 1620 generated session key carried in the ticket. We leave the protocol 1621 negotiations of how to use the key (e.g. selecting an encryption or 1622 checksum type) to the application programmer; the Kerberos protocol 1623 does not constrain the implementation options, but an example of how 1624 this might be done follows. 1626 One way that an application may choose to negotiate a key to be used 1627 for subsequent integrity and privacy protection is for the client to 1628 propose a key in the subkey field of the authenticator. The server 1629 can then choose a key using the proposed key from the client as 1630 input, returning the new subkey in the subkey field of the 1631 application reply. This key could then be used for subsequent 1632 communication. 1634 With both the one-way and mutual authentication exchanges, the peers 1635 should take care not to send sensitive information to each other 1636 without proper assurances. In particular, applications that require 1637 privacy or integrity SHOULD use the KRB_AP_REP response from the 1639 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 1641 server to client to assure both client and server of their peer's 1642 identity. If an application protocol requires privacy of its 1643 messages, it can use the KRB_PRIV message (section 3.5). The KRB_SAFE 1644 message (section 3.4) can be used to assure integrity. 1646 3.3. The Ticket-Granting Service (TGS) Exchange 1648 Summary 1649 Message direction Message type Section 1650 1. Client to Kerberos KRB_TGS_REQ 5.4.1 1651 2. Kerberos to client KRB_TGS_REP or 5.4.2 1652 KRB_ERROR 5.9.1 1654 The TGS exchange between a client and the Kerberos Ticket-Granting 1655 Server is initiated by a client when it wishes to obtain 1656 authentication credentials for a given server (which might be 1657 registered in a remote realm), when it wishes to renew or validate an 1658 existing ticket, or when it wishes to obtain a proxy ticket. In the 1659 first case, the client must already have acquired a ticket for the 1660 Ticket-Granting Service using the AS exchange (the ticket-granting 1661 ticket is usually obtained when a client initially authenticates to 1662 the system, such as when a user logs in). The message format for the 1663 TGS exchange is almost identical to that for the AS exchange. The 1664 primary difference is that encryption and decryption in the TGS 1665 exchange does not take place under the client's key. Instead, the 1666 session key from the ticket-granting ticket or renewable ticket, or 1667 sub-session key from an Authenticator is used. As is the case for all 1668 application servers, expired tickets are not accepted by the TGS, so 1669 once a renewable or ticket-granting ticket expires, the client must 1670 use a separate exchange to obtain valid tickets. 1672 The TGS exchange consists of two messages: A request (KRB_TGS_REQ) 1673 from the client to the Kerberos Ticket-Granting Server, and a reply 1674 (KRB_TGS_REP or KRB_ERROR). The KRB_TGS_REQ message includes 1675 information authenticating the client plus a request for credentials. 1676 The authentication information consists of the authentication header 1677 (KRB_AP_REQ) which includes the client's previously obtained ticket- 1678 granting, renewable, or invalid ticket. In the ticket-granting 1679 ticket and proxy cases, the request MAY include one or more of: a 1680 list of network addresses, a collection of typed authorization data 1681 to be sealed in the ticket for authorization use by the application 1682 server, or additional tickets (the use of which are described later). 1683 The TGS reply (KRB_TGS_REP) contains the requested credentials, 1684 encrypted in the session key from the ticket-granting ticket or 1685 renewable ticket, or if present, in the sub-session key from the 1686 Authenticator (part of the authentication header). The KRB_ERROR 1687 message contains an error code and text explaining what went wrong. 1688 The KRB_ERROR message is not encrypted. The KRB_TGS_REP message 1690 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 1692 contains information which can be used to detect replays, and to 1693 associate it with the message to which it replies. The KRB_ERROR 1694 message also contains information which can be used to associate it 1695 with the message to which it replies. The same comments about 1696 integrity protection of KRB_ERROR messages mentioned in section 3.1 1697 apply to the TGS exchange. 1699 3.3.1. Generation of KRB_TGS_REQ message 1701 Before sending a request to the ticket-granting service, the client 1702 MUST determine in which realm the application server is believed to 1703 be registered [15]. If the client knows the service principal name 1704 and realm and it does not already possess a ticket-granting ticket 1705 for the appropriate realm, then one must be obtained. This is first 1706 attempted by requesting a ticket-granting ticket for the destination 1707 realm from a Kerberos server for which the client possesses a ticket- 1708 granting ticket (using the KRB_TGS_REQ message recursively). The 1709 Kerberos server MAY return a TGT for the desired realm in which case 1710 one can proceed. Alternatively, the Kerberos server MAY return a TGT 1711 for a realm which is 'closer' to the desired realm (further along the 1712 standard hierarchical path between the client's realm and the 1713 requested realm server's realm). It should be noted in this case that 1714 misconfiguration of the Kerberos servers may cause loops in the 1715 resulting authentication path, which the client should be careful to 1716 detect and avoid. 1718 If the Kerberos server returns a TGT for a 'closer' realm other than 1719 the desired realm, the client MAY use local policy configuration to 1720 verify that the authentication path used is an acceptable one. 1721 Alternatively, a client MAY choose its own authentication path, 1722 rather than relying on the Kerberos server to select one. In either 1723 case, any policy or configuration information used to choose or 1724 validate authentication paths, whether by the Kerberos server or 1725 client, MUST be obtained from a trusted source. 1727 When a client obtains a ticket-granting ticket that is 'closer' to 1728 the destination realm, the client MAY cache this ticket and reuse it 1729 in future KRB-TGS exchanges with services in the 'closer' realm. 1730 However, if the client were to obtain a ticket-granting ticket for 1731 the 'closer' realm by starting at the initial KDC rather than as part 1732 of obtaining another ticket, then a shorter path to the 'closer' 1733 realm might be used. This shorter path may be desirable because fewer 1734 intermediate KDCs would know the session key of the ticket involved. 1735 For this reason, clients SHOULD evaluate whether they trust the 1736 realms transited in obtaining the 'closer' ticket when making a 1737 decision to use the ticket in future. 1739 Once the client obtains a ticket-granting ticket for the appropriate 1741 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 1743 realm, it determines which Kerberos servers serve that realm, and 1744 contacts one. The list might be obtained through a configuration file 1745 or network service or it MAY be generated from the name of the realm; 1746 as long as the secret keys exchanged by realms are kept secret, only 1747 denial of service results from using a false Kerberos server. 1749 (This paragraph changed) As in the AS exchange, the client MAY 1750 specify a number of options in the KRB_TGS_REQ message. One of these 1751 options is the ENC-TKT-IN-SKEY option used for user-to-user 1752 authentication. An overview of user to user authentication can be 1753 found in section 3.7. When generating the KRB_TGS_REQ message, this 1754 option indicates that the client is including a ticket-granting 1755 ticket obtained from the application server in the additional tickets 1756 field of the request and that the KDC SHOULD encrypt the ticket for 1757 the application server using the session key from this additional 1758 ticket, instead of using a server key from the principal database. 1760 The client prepares the KRB_TGS_REQ message, providing an 1761 authentication header as an element of the padata field, and 1762 including the same fields as used in the KRB_AS_REQ message along 1763 with several optional fields: the enc-authorizatfion-data field for 1764 application server use and additional tickets required by some 1765 options. 1767 In preparing the authentication header, the client can select a sub- 1768 session key under which the response from the Kerberos server will be 1769 encrypted [16]. If the sub-session key is not specified, the session 1770 key from the ticket-granting ticket will be used. If the enc- 1771 authorization-data is present, it MUST be encrypted in the sub- 1772 session key, if present, from the authenticator portion of the 1773 authentication header, or if not present, using the session key from 1774 the ticket-granting ticket. 1776 Once prepared, the message is sent to a Kerberos server for the 1777 destination realm. 1779 3.3.2. Receipt of KRB_TGS_REQ message 1781 The KRB_TGS_REQ message is processed in a manner similar to the 1782 KRB_AS_REQ message, but there are many additional checks to be 1783 performed. First, the Kerberos server MUST determine which server the 1784 accompanying ticket is for and it MUST select the appropriate key to 1785 decrypt it. For a normal KRB_TGS_REQ message, it will be for the 1786 ticket granting service, and the TGS's key will be used. If the TGT 1787 was issued by another realm, then the appropriate inter-realm key 1788 MUST be used. If the accompanying ticket is not a ticket-granting 1789 ticket for the current realm, but is for an application server in the 1790 current realm, the RENEW, VALIDATE, or PROXY options are specified in 1792 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 1794 the request, and the server for which a ticket is requested is the 1795 server named in the accompanying ticket, then the KDC will decrypt 1796 the ticket in the authentication header using the key of the server 1797 for which it was issued. If no ticket can be found in the padata 1798 field, the KDC_ERR_PADATA_TYPE_NOSUPP error is returned. 1800 Once the accompanying ticket has been decrypted, the user-supplied 1801 checksum in the Authenticator MUST be verified against the contents 1802 of the request, and the message rejected if the checksums do not 1803 match (with an error code of KRB_AP_ERR_MODIFIED) or if the checksum 1804 is not collision-proof (with an error code of 1805 KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported, the 1806 KDC_ERR_SUMTYPE_NOSUPP error is returned. If the authorization-data 1807 are present, they are decrypted using the sub-session key from the 1808 Authenticator. 1810 If any of the decryptions indicate failed integrity checks, the 1811 KRB_AP_ERR_BAD_INTEGRITY error is returned. 1813 As discussed in section 3.1.2, the KDC MUST send a valid KRB_TGS_REP 1814 message if it receives a KRB_TGS_REQ message identical to one it has 1815 recently processed. However, if the authenticator is a replay, but 1816 the rest of the request is not identical, then the KDC SHOULD return 1817 KRB_AP_ERR_REPEAT. 1819 3.3.3. Generation of KRB_TGS_REP message 1821 The KRB_TGS_REP message shares its format with the KRB_AS_REP 1822 (KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The 1823 detailed specification is in section 5.4.2. 1825 The response will include a ticket for the requested server or for a 1826 ticket granting server of an intermediate KDC to be contacted to 1827 obtain the requested ticket. The Kerberos database is queried to 1828 retrieve the record for the appropriate server (including the key 1829 with which the ticket will be encrypted). If the request is for a 1830 ticket-granting ticket for a remote realm, and if no key is shared 1831 with the requested realm, then the Kerberos server will select the 1832 realm 'closest' to the requested realm with which it does share a 1833 key, and use that realm instead. Thss is theonly cases where the 1834 response for the KDC will be for a different server than that 1835 requested by the client. 1837 By default, the address field, the client's name and realm, the list 1838 of transited realms, the time of initial authentication, the 1839 expiration time, and the authorization data of the newly-issued 1840 ticket will be copied from the ticket-granting ticket (TGT) or 1841 renewable ticket. If the transited field needs to be updated, but the 1843 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 1845 transited type is not supported, the KDC_ERR_TRTYPE_NOSUPP error is 1846 returned. 1848 If the request specifies an endtime, then the endtime of the new 1849 ticket is set to the minimum of (a) that request, (b) the endtime 1850 from the TGT, and (c) the starttime of the TGT plus the minimum of 1851 the maximum life for the application server and the maximum life for 1852 the local realm (the maximum life for the requesting principal was 1853 already applied when the TGT was issued). If the new ticket is to be 1854 a renewal, then the endtime above is replaced by the minimum of (a) 1855 the value of the renew_till field of the ticket and (b) the starttime 1856 for the new ticket plus the life (endtime-starttime) of the old 1857 ticket. 1859 If the FORWARDED option has been requested, then the resulting ticket 1860 will contain the addresses specified by the client. This option will 1861 only be honored if the FORWARDABLE flag is set in the TGT. The PROXY 1862 option is similar; the resulting ticket will contain the addresses 1863 specified by the client. It will be honored only if the PROXIABLE 1864 flag in the TGT is set. The PROXY option will not be honored on 1865 requests for additional ticket-granting tickets. 1867 If the requested start time is absent, indicates a time in the past, 1868 or is within the window of acceptable clock skew for the KDC and the 1869 POSTDATE option has not been specified, then the start time of the 1870 ticket is set to the authentication server's current time. If it 1871 indicates a time in the future beyond the acceptable clock skew, but 1872 the POSTDATED option has not been specified or the MAY-POSTDATE flag 1873 is not set in the TGT, then the error KDC_ERR_CANNOT_POSTDATE is 1874 returned. Otherwise, if the ticket-granting ticket has the MAY- 1875 POSTDATE flag set, then the resulting ticket will be postdated and 1876 the requested starttime is checked against the policy of the local 1877 realm. If acceptable, the ticket's start time is set as requested, 1878 and the INVALID flag is set. The postdated ticket MUST be validated 1879 before use by presenting it to the KDC after the starttime has been 1880 reached. However, in no case may the starttime, endtime, or renew- 1881 till time of a newly-issued postdated ticket extend beyond the renew- 1882 till time of the ticket-granting ticket. 1884 If the ENC-TKT-IN-SKEY option has been specified and an additional 1885 ticket has been included in the request, it indicates that the client 1886 is using user- to-user authentication to prove its identity to a 1887 server that does not have access to a persistent key. Section 3.7 1888 describes the affect of this option on the entire Kerberos protocol. 1889 When generating the KRB_TGS_REP message, this option in the 1890 KRB_TGS_REQ message tells the KDC to decrypt the additional ticket 1891 using the key for the server to which the additional ticket was 1892 issued and verify that it is a ticket-granting ticket. If the name of 1894 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 1896 the requested server is missing from the request, the name of the 1897 client in the additional ticket will be used. Otherwise the name of 1898 the requested server will be compared to the name of the client in 1899 the additional ticket and if different, the request will be rejected. 1900 If the request succeeds, the session key from the additional ticket 1901 will be used to encrypt the new ticket that is issued instead of 1902 using the key of the server for which the new ticket will be used. 1904 If the name of the server in the ticket that is presented to the KDC 1905 as part of the authentication header is not that of the ticket- 1906 granting server itself, the server is registered in the realm of the 1907 KDC, and the RENEW option is requested, then the KDC will verify that 1908 the RENEWABLE flag is set in the ticket, that the INVALID flag is not 1909 set in the ticket, and that the renew_till time is still in the 1910 future. If the VALIDATE option is requested, the KDC will check that 1911 the starttime has passed and the INVALID flag is set. If the PROXY 1912 option is requested, then the KDC will check that the PROXIABLE flag 1913 is set in the ticket. If the tests succeed, and the ticket passes the 1914 hotlist check described in the next section, the KDC will issue the 1915 appropriate new ticket. 1917 The ciphertext part of the response in the KRB_TGS_REP message is 1918 encrypted in the sub-session key from the Authenticator, if present, 1919 or the session key from the ticket-granting ticket. It is not 1920 encrypted using the client's secret key. Furthermore, the client's 1921 key's expiration date and the key version number fields are left out 1922 since these values are stored along with the client's database 1923 record, and that record is not needed to satisfy a request based on a 1924 ticket-granting ticket. 1926 3.3.3.1. Checking for revoked tickets 1928 Whenever a request is made to the ticket-granting server, the 1929 presented ticket(s) is(are) checked against a hot-list of tickets 1930 which have been canceled. This hot-list might be implemented by 1931 storing a range of issue timestamps for 'suspect tickets'; if a 1932 presented ticket had an authtime in that range, it would be rejected. 1933 In this way, a stolen ticket-granting ticket or renewable ticket 1934 cannot be used to gain additional tickets (renewals or otherwise) 1935 once the theft has been reported to the KDC for the realm in which 1936 the server resides. Any normal ticket obtained before it was reported 1937 stolen will still be valid (because they require no interaction with 1938 the KDC), but only until their normal expiration time. If TGT's have 1939 been issued for cross-realm authentication, use of the cross-realm 1940 TGT will not be affected unless the hot-list is propagated to the 1941 KDCs for the realms for which such cross-realm tickets were issued. 1943 3.3.3.2. Encoding the transited field 1944 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 1946 If the identity of the server in the TGT that is presented to the KDC 1947 as part of the authentication header is that of the ticket-granting 1948 service, but the TGT was issued from another realm, the KDC will look 1949 up the inter-realm key shared with that realm and use that key to 1950 decrypt the ticket. If the ticket is valid, then the KDC will honor 1951 the request, subject to the constraints outlined above in the section 1952 describing the AS exchange. The realm part of the client's identity 1953 will be taken from the ticket-granting ticket. The name of the realm 1954 that issued the ticket-granting ticket, if it is not the realm of the 1955 client principal, will be added to the transited field of the ticket 1956 to be issued. This is accomplished by reading the transited field 1957 from the ticket-granting ticket (which is treated as an unordered set 1958 of realm names), adding the new realm to the set, then constructing 1959 and writing out its encoded (shorthand) form (this may involve a 1960 rearrangement of the existing encoding). 1962 Note that the ticket-granting service does not add the name of its 1963 own realm. Instead, its responsibility is to add the name of the 1964 previous realm. This prevents a malicious Kerberos server from 1965 intentionally leaving out its own name (it could, however, omit other 1966 realms' names). 1968 The names of neither the local realm nor the principal's realm are to 1969 be included in the transited field. They appear elsewhere in the 1970 ticket and both are known to have taken part in authenticating the 1971 principal. Since the endpoints are not included, both local and 1972 single-hop inter-realm authentication result in a transited field 1973 that is empty. 1975 Because the name of each realm transited is added to this field, it 1976 might potentially be very long. To decrease the length of this field, 1977 its contents are encoded. The initially supported encoding is 1978 optimized for the normal case of inter-realm communication: a 1979 hierarchical arrangement of realms using either domain or X.500 style 1980 realm names. This encoding (called DOMAIN-X500-COMPRESS) is now 1981 described. 1983 Realm names in the transited field are separated by a ",". The ",", 1984 "\", trailing "."s, and leading spaces (" ") are special characters, 1985 and if they are part of a realm name, they MUST be quoted in the 1986 transited field by preceding them with a "\". 1988 A realm name ending with a "." is interpreted as being prepended to 1989 the previous realm. For example, we can encode traversal of EDU, 1990 MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as: 1992 "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". 1994 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 1996 Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, 1997 that they would not be included in this field, and we would have: 1999 "EDU,MIT.,WASHINGTON.EDU" 2001 A realm name beginning with a "/" is interpreted as being appended to 2002 the previous realm. For the purpose of appending, the realm 2003 preceding the first listed realm is considered to be the null realm 2004 (""). If a realm name beginning with a "/" is to stand by itself, 2005 then it SHOULD be preceded by a space (" "). For example, we can 2006 encode traversal of /COM/HP/APOLLO, /COM/HP, /COM, and /COM/DEC as: 2008 "/COM,/HP,/APOLLO, /COM/DEC". 2010 Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, 2011 they would not be included in this field, and we would have: 2013 "/COM,/HP" 2015 A null subfield preceding or following a "," indicates that all 2016 realms between the previous realm and the next realm have been 2017 traversed. For the purpose of interpreting null subfields, the 2018 client's realm is considered to precede those in the transited field, 2019 and the server's realm is considered to follow them. Thus, "," means 2020 that all realms along the path between the client and the server have 2021 been traversed. ",EDU, /COM," means that all realms from the client's 2022 realm up to EDU (in a domain style hierarchy) have been traversed, 2023 and that everything from /COM down to the server's realm in an X.500 2024 style has also been traversed. This could occur if the EDU realm in 2025 one hierarchy shares an inter-realm key directly with the /COM realm 2026 in another hierarchy. 2028 3.3.4. Receipt of KRB_TGS_REP message 2030 When the KRB_TGS_REP is received by the client, it is processed in 2031 the same manner as the KRB_AS_REP processing described above. The 2032 primary difference is that the ciphertext part of the response must 2033 be decrypted using the sub-session key from the Authenticator, if it 2034 was specified in the request, or the session key from the ticket- 2035 granting ticket, rather than the client's secret key. The server name 2036 returned in the reply is the true principal name of the service. 2038 3.4. The KRB_SAFE Exchange 2040 The KRB_SAFE message MAY be used by clients requiring the ability to 2041 detect modifications of messages they exchange. It achieves this by 2042 including a keyed collision-proof checksum of the user data and some 2043 control information. The checksum is keyed with an encryption key 2045 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 2047 (usually the last key negotiated via subkeys, or the session key if 2048 no negotiation has occurred). 2050 3.4.1. Generation of a KRB_SAFE message 2052 When an application wishes to send a KRB_SAFE message, it collects 2053 its data and the appropriate control information and computes a 2054 checksum over them. The checksum algorithm should be the keyed 2055 checksum mandated to be implemented along with the crypto system used 2056 for the sub-session or session key. The checksum is generated using 2057 the sub-session key if present or the session key. Some 2058 implementations use a different checksum algorithm for the KRB_SAFE 2059 messages but doing so in a interoperable manner is not always 2060 possible. 2062 The control information for the KRB_SAFE message includes both a 2063 timestamp and a sequence number. The designer of an application using 2064 the KRB_SAFE message MUST choose at least one of the two mechanisms. 2065 This choice SHOULD be based on the needs of the application protocol. 2067 Sequence numbers are useful when all messages sent will be received 2068 by one's peer. Connection state is presently required to maintain the 2069 session key, so maintaining the next sequence number should not 2070 present an additional problem. 2072 If the application protocol is expected to tolerate lost messages 2073 without them being resent, the use of the timestamp is the 2074 appropriate replay detection mechanism. Using timestamps is also the 2075 appropriate mechanism for multi-cast protocols where all of one's 2076 peers share a common sub-session key, but some messages will be sent 2077 to a subset of one's peers. 2079 After computing the checksum, the client then transmits the 2080 information and checksum to the recipient in the message format 2081 specified in section 5.6.1. 2083 3.4.2. Receipt of KRB_SAFE message 2085 When an application receives a KRB_SAFE message, it verifies it as 2086 follows. If any error occurs, an error code is reported for use by 2087 the application. 2089 The message is first checked by verifying that the protocol version 2090 and type fields match the current version and KRB_SAFE, respectively. 2091 A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE 2092 error. The application verifies that the checksum used is a 2093 collision-proof keyed checksum that uses keys compatible with the 2094 sub-session or session key as appropriate (or with the application 2096 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 2098 key derived from the session or sub-session keys), and if it is not, 2099 a KRB_AP_ERR_INAPP_CKSUM error is generated. The sender's address 2100 MUST be included in the control information; the recipient verifies 2101 that the operating system's report of the sender's address matches 2102 the sender's address in the message, and (if a recipient address is 2103 specified or the recipient requires an address) that one of the 2104 recipient's addresses appears as the recipient's address in the 2105 message. To work with network address translation, senders MAY use 2106 the directional address type specified in section 8.1 for the sender 2107 address and not include recipient addresses. A failed match for 2108 either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp 2109 and usec and/or the sequence number fields are checked. If timestamp 2110 and usec are expected and not present, or they are present but not 2111 current, the KRB_AP_ERR_SKEW error is generated. If the server name, 2112 along with the client name, time and microsecond fields from the 2113 Authenticator match any recently-seen (sent or received) such tuples, 2114 the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence 2115 number is included, or a sequence number is expected but not present, 2116 the KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp 2117 and usec or a sequence number is present, a KRB_AP_ERR_MODIFIED error 2118 is generated. Finally, the checksum is computed over the data and 2119 control information, and if it doesn't match the received checksum, a 2120 KRB_AP_ERR_MODIFIED error is generated. 2122 If all the checks succeed, the application is assured that the 2123 message was generated by its peer and was not modified in transit. 2125 Implementations SHOULD accept any checksum algorithm they implement 2126 that both have adequate security and that have keys compatible with 2127 the sub-session or session key. Unkeyed or non-collision-proof 2128 checksums are not suitable for this use. 2130 3.5. The KRB_PRIV Exchange 2132 The KRB_PRIV message MAY be used by clients requiring confidentiality 2133 and the ability to detect modifications of exchanged messages. It 2134 achieves this by encrypting the messages and adding control 2135 information. 2137 3.5.1. Generation of a KRB_PRIV message 2139 When an application wishes to send a KRB_PRIV message, it collects 2140 its data and the appropriate control information (specified in 2141 section 5.7.1) and encrypts them under an encryption key (usually the 2142 last key negotiated via subkeys, or the session key if no negotiation 2143 has occurred). As part of the control information, the client MUST 2144 choose to use either a timestamp or a sequence number (or both); see 2145 the discussion in section 3.4.1 for guidelines on which to use. After 2147 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 2149 the user data and control information are encrypted, the client 2150 transmits the ciphertext and some 'envelope' information to the 2151 recipient. 2153 3.5.2. Receipt of KRB_PRIV message 2155 When an application receives a KRB_PRIV message, it verifies it as 2156 follows. If any error occurs, an error code is reported for use by 2157 the application. 2159 The message is first checked by verifying that the protocol version 2160 and type fields match the current version and KRB_PRIV, respectively. 2161 A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE 2162 error. The application then decrypts the ciphertext and processes the 2163 resultant plaintext. If decryption shows the data to have been 2164 modified, a KRB_AP_ERR_BAD_INTEGRITY error is generated. 2166 The sender's address MUST be included in the control information; the 2167 recipient verifies that the operating system's report of the sender's 2168 address matches the sender's address in the message. If a recipient 2169 address is specified or the recipient requires an address then one of 2170 the recipient's addresses MUST also appear as the recipient's address 2171 in the message. Where a sender's or receiver's address might not 2172 otherwise match the address in a message because of network address 2173 translation, an application MAY be written to use addresses of the 2174 directional address type in place of the actual network address. 2176 A failed match for either case generates a KRB_AP_ERR_BADADDR error. 2177 To work with network address translation, implementations MAY use the 2178 directional address type defined in section 7.1 for the sender 2179 address and include no recipient address. 2181 Then the timestamp and usec and/or the sequence number fields are 2182 checked. If timestamp and usec are expected and not present, or they 2183 are present but not current, the KRB_AP_ERR_SKEW error is generated. 2184 If the server name, along with the client name, time and microsecond 2185 fields from the Authenticator match any recently-seen such tuples, 2186 the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence 2187 number is included, or a sequence number is expected but not present, 2188 the KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp 2189 and usec or a sequence number is present, a KRB_AP_ERR_MODIFIED error 2190 is generated. 2192 If all the checks succeed, the application can assume the message was 2193 generated by its peer, and was securely transmitted (without 2194 intruders able to see the unencrypted contents). 2196 3.6. The KRB_CRED Exchange 2197 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 2199 The KRB_CRED message MAY be used by clients requiring the ability to 2200 send Kerberos credentials from one host to another. It achieves this 2201 by sending the tickets together with encrypted data containing the 2202 session keys and other information associated with the tickets. 2204 3.6.1. Generation of a KRB_CRED message 2206 When an application wishes to send a KRB_CRED message it first (using 2207 the KRB_TGS exchange) obtains credentials to be sent to the remote 2208 host. It then constructs a KRB_CRED message using the ticket or 2209 tickets so obtained, placing the session key needed to use each 2210 ticket in the key field of the corresponding KrbCredInfo sequence of 2211 the encrypted part of the KRB_CRED message. 2213 Other information associated with each ticket and obtained during the 2214 KRB_TGS exchange is also placed in the corresponding KrbCredInfo 2215 sequence in the encrypted part of the KRB_CRED message. The current 2216 time and, if specifically required by the application the nonce, s- 2217 address, and r-address fields, are placed in the encrypted part of 2218 the KRB_CRED message which is then encrypted under an encryption key 2219 previously exchanged in the KRB_AP exchange (usually the last key 2220 negotiated via subkeys, or the session key if no negotiation has 2221 occurred). 2223 Implementation note: When constructing a KRB_CRED message for 2224 inclusion in a GSSAPI initial context token, the MIT implementation 2225 of Kerberos will not encrypt the KRB_CRED message if the session key 2226 is a DES or triple DES key. For interoperability with MIT, the 2227 Microsoft implementation will not encrypt the KRB_CRED in a GSSAPI 2228 token if it is using a DES session key. Starting at version 1.2.5, 2229 MIT Kerberos can receive and decode either encrypted or unencrypted 2230 KRB_CRED tokens in the GSSAPI exchange. The Heimdal implementation of 2231 Kerberos can also accept either encrypted or unencrypted KRB_CRED 2232 messages. Since the KRB_CRED message in a GSSAPI token is encrypted 2233 in the authenticator, the MIT behavior does not present a security 2234 problem, although it is a violation of the Kerberos specification. 2236 3.6.2. Receipt of KRB_CRED message 2238 When an application receives a KRB_CRED message, it verifies it. If 2239 any error occurs, an error code is reported for use by the 2240 application. The message is verified by checking that the protocol 2241 version and type fields match the current version and KRB_CRED, 2242 respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or 2243 KRB_AP_ERR_MSG_TYPE error. The application then decrypts the 2244 ciphertext and processes the resultant plaintext. If decryption shows 2245 the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is 2246 generated. 2248 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 2250 If present or required, the recipient MAY verify that the operating 2251 system's report of the sender's address matches the sender's address 2252 in the message, and that one of the recipient's addresses appears as 2253 the recipient's address in the message. The address check does not 2254 provide any added security, since the address if present has already 2255 been checked in the KRB_AP_REQ message and there is not any benefit 2256 to be gained by an attacker in reflecting a KRB_CRED message back to 2257 its originator. Thus, the recipient MAY ignore the address even if 2258 present in order to work better in NAT environments. A failed match 2259 for either case generates a KRB_AP_ERR_BADADDR error. Recipients MAY 2260 skip the address check as the KRB_CRED message cannot generally be 2261 reflected back to the originator. The timestamp and usec fields (and 2262 the nonce field if required) are checked next. If the timestamp and 2263 usec are not present, or they are present but not current, the 2264 KRB_AP_ERR_SKEW error is generated. 2266 If all the checks succeed, the application stores each of the new 2267 tickets in its credentials cache together with the session key and 2268 other information in the corresponding KrbCredInfo sequence from the 2269 encrypted part of the KRB_CRED message. 2271 3.7. User to User Authentication Exchanges 2273 User to User authentication provides a method to perform 2274 authentication when the verifier does not have a access to long term 2275 service key. This might be the case when running a server (for 2276 example a window server) as a user on a workstation. In such cases, 2277 the server may have access to the ticket-granting ticket obtained 2278 when the user logged in to the workstation, but because the server is 2279 running as an unprivileged user it might not have access to system 2280 keys. Similar situations may arise when running peer-to-peer 2281 applications. 2283 Summary 2284 Message direction Message type Sections 2285 0. Message from application server Not Specified 2286 1. Client to Kerberos KRB_TGS_REQ 3.3 + 5.4.1 2287 2. Kerberos to client KRB_TGS_REP or 3.3 + 5.4.2 2288 KRB_ERROR 5.9.1 2289 3. Client to Application server KRB_AP_REQ 3.2 + 5.5.1 2291 To address this problem, the Kerberos protocol allows the client to 2292 request that the ticket issued by the KDC be encrypted using a 2293 session key from a ticket-granting ticket issued to the party that 2294 will verify the authentication. This ticket-granting ticket must be 2295 obtained from the verifier by means of an exchange external to the 2296 Kerberos protocol, usually as part of the application protocol. This 2297 message is shown in the summary above as message 0. Note that because 2299 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 2301 the ticket-granting ticket is encrypted in the KDC's secret key, it 2302 can not be used for authentication without posession of the 2303 corresponding secret key. Furthermore, because the verifier does not 2304 reveal the corresponding secret key, providing a copy of the 2305 verifier's ticket-granting ticket does not allow impersonation of the 2306 verifier. 2308 Message 0 in the table above represents an application specific 2309 negotation between the client and server, at the end of which both 2310 have determined that they will use user to user authentication and 2311 the client has obtained the server's TGT. 2313 Next, the client includes the server's TGT as an additional ticket in 2314 its KRB_TGS_REQ request to the KDC (message 1 in the table above) and 2315 specifyies the ENC-TKT-IN-SKEY option in its request. 2317 If validated according to the instructions in 3.3.3, the application 2318 ticket returned to the client (message 2 in the table above) will be 2319 encrypted using the session key from the additional ticket and the 2320 client will note this when it uses or stores the application ticket. 2322 When contacting the server using a ticket obtained for user to user 2323 authentication (message 3 in the table above), the client MUST 2324 specify the USE-SESSION-KEY flag in the ap-options field. This tells 2325 the application server to use the session key associated with its 2326 ticket-granting ticket to decrypt the server ticket provided in the 2327 application request. 2329 4. Encryption and Checksum Specifications 2331 The Kerberos protocols described in this document are designed to 2332 encrypt messages of arbitrary sizes, using stream or block encryption 2333 ciphers. Encryption is used to prove the identities of the network 2334 entities participating in message exchanges. The Key Distribution 2335 Center for each realm is trusted by all principals registered in that 2336 realm to store a secret key in confidence. Proof of knowledge of this 2337 secret key is used to verify the authenticity of a principal. 2339 The KDC uses the principal's secret key (in the AS exchange) or a 2340 shared session key (in the TGS exchange) to encrypt responses to 2341 ticket requests; the ability to obtain the secret key or session key 2342 implies the knowledge of the appropriate keys and the identity of the 2343 KDC. The ability of a principal to decrypt the KDC response and 2344 present a Ticket and a properly formed Authenticator (generated with 2345 the session key from the KDC response) to a service verifies the 2346 identity of the principal; likewise the ability of the service to 2347 extract the session key from the Ticket and prove its knowledge 2348 thereof in a response verifies the identity of the service. 2350 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 2352 [@KCRYPTO] defines a framework for defining encryption and checksum 2353 mechanisms for use with Kerberos. It also defines several such 2354 mechanisms, and more may be added in future updates to that document. 2356 The string-to-key operation provided by [@KCRYPTO] is used to produce 2357 a long-term key for a principal (generally for a user). The default 2358 salt string, if none is provided via pre-authentication data, is the 2359 concatenation of the principal's realm and name components, in order, 2360 with no separators. Unless otherwise indicated, the default string- 2361 to-key opaque parameter set as defined in [@KCRYPTO] is used. 2363 Encrypted data, keys and checksums are transmitted using the 2364 EncryptedData, EncryptionKey and Checksum data objects defined in 2365 section 5.2.9. The encryption, decryption, and checksum operations 2366 described in this document use the corresponding encryption, 2367 decryption, and get_mic operations described in [@KCRYPTO], with 2368 implicit "specific key" generation using the "key usage" values 2369 specified in the description of each EncryptedData or Checksum object 2370 to vary the key for each operation. Note that in some cases, the 2371 value to be used is dependent on the method of choosing the key or 2372 the context of the message. 2374 Key usages are unsigned 32 bit integers; zero is not permitted. The 2375 key usage values for encrypting or checksumming Kerberos messages are 2376 indicated in section 5 along with the message definitions. Key usage 2377 values 512-1023 are reserved for uses internal to a Kerberos 2378 implementation. (For example, seeding a pseudo-random number 2379 generator with a value produced by encrypting something with a 2380 session key and a key usage value not used for any other purpose.) 2381 Key usage values between 1024 and 2047 (inclusive) are reserved for 2382 application use; applications SHOULD use even values for encryption 2383 and odd values for checksums within this range. Key usage values are 2384 also summarized in a table in section 7.5.1. 2386 There might exist other documents which define protocols in terms of 2387 the RFC1510 encryption types or checksum types. Such documents would 2388 not know about key usages. In order that these specifications 2389 continue to be meaningful until they are updated, if not key usage 2390 values are specified then key usages 1024 and 1025 must be used to 2391 derive keys for encryption and checksums, respectively (this does not 2392 apply to protocols that do their own encryption independent of this 2393 framework, directly using the key resulting from the Kerberos 2394 authentication exchange.) New protocols defined in terms of the 2395 Kerberos encryption and checksum types SHOULD use their own key usage 2396 values. 2398 Unless otherwise indicated, no cipher state chaining is done from one 2399 encryption operation to another. 2401 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 2403 Implementation note: While not recommended, some application 2404 protocols will continue to use the key data directly, even if only in 2405 currently existing protocol specifications. An implementation 2406 intended to support general Kerberos applications may therefore need 2407 to make key data available, as well as the attributes and operations 2408 described in [@KCRYPTO]. One of the more common reasons for directly 2409 performing encryption is direct control over negotiation and 2410 selection of a "sufficiently strong" encryption algorithm (in the 2411 context of a given application). While Kerberos does not directly 2412 provide a facility for negotiating encryption types between the 2413 application client and server, there are approaches for using 2414 Kerberos to facilitate this negotiation - for example, a client may 2415 request only "sufficiently strong" session key types from the KDC and 2416 expect that any type returned by the KDC will be understood and 2417 supported by the application server. 2419 5. Message Specifications 2421 NOTE: The ASN.1 collected here should be identical to the contents of 2422 Appendix A. In case of conflict, the contents of Appendix A shall 2423 take precedence. 2425 The Kerberos protocol is defined here in terms of Abstract Syntax 2426 Notation One (ASN.1) [X680], which provides a syntax for specifying 2427 both the abstract layout of protocol messages as well as their 2428 encodings. Implementors not utilizing an existing ASN.1 compiler or 2429 support library are cautioned to thoroughly understand the actual 2430 ASN.1 specification to ensure correct implementation behavior, as 2431 there is more complexity in the notation than is immediately obvious, 2432 and some tutorials and guides to ASN.1 are misleading or erroneous. 2434 Note that in several places, there have been changes here from RFC 2435 1510 that change the abstract types. This is in part to address 2436 widespread assumptions that various implementors have made, in some 2437 cases resulting in unintentional violations of the ASN.1 standard. 2438 These are clearly flagged where they occur. The differences between 2439 the abstract types in RFC 1510 and abstract types in this document 2440 can cause incompatible encodings to be emitted when certain encoding 2441 rules, e.g. the Packed Encoding Rules (PER), are used. This 2442 theoretical incompatibility should not be relevant for Kerberos, 2443 since Kerberos explicitly specifies the use of the Distinguished 2444 Encoding Rules (DER). It might be an issue for protocols wishing to 2445 use Kerberos types with other encoding rules. (This practice is not 2446 recommended.) With very few exceptions (most notably the usages of 2447 BIT STRING), the encodings resulting from using the DER remain 2448 identical between the types defined in RFC 1510 and the types defined 2449 in this document. 2451 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 2453 The type definitions in this section assume an ASN.1 module 2454 definition of the following form: 2456 KerberosV5Spec2 { 2457 iso(1) identified-organization(3) dod(6) internet(1) 2458 security(5) kerberosV5(2) modules(4) krb5spec2(2) 2459 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 2461 -- rest of definitions here 2463 END 2465 This specifies that the tagging context for the module will be 2466 explicit and non-automatic. 2468 Note that in some other publications [RFC1510] [RFC1964], the "dod" 2469 portion of the object identifier is erroneously specified as having 2470 the value "5". In the case of RFC 1964, use of the "correct" OID 2471 value would result in a change in the wire protocol; therefore, it 2472 remains unchanged for now. 2474 Note that elsewhere in this document, nomenclature for various 2475 message types is inconsistent, but seems to largely follow C language 2476 conventions, including use of underscore (_) characters and all-caps 2477 spelling of names intended to be numeric constants. Also, in some 2478 places, identifiers (especially ones refering to constants) are 2479 written in all-caps in order to distinguish them from surrounding 2480 explanatory text. 2482 The ASN.1 notation does not permit underscores in identifiers, so in 2483 actual ASN.1 definitions, underscores are replaced with hyphens (-). 2484 Additionally, structure member names and defined values in ASN.1 MUST 2485 begin with a lowercase letter, while type names MUST begin with an 2486 uppercase letter. 2488 5.1. Specific Compatibility Notes on ASN.1 2490 For compatibility purposes, implementors should heed the following 2491 specific notes regarding the use of ASN.1 in Kerberos. These notes do 2492 not describe deviations from standard usage of ASN.1. The purpose of 2493 these notes is to instead describe some historical quirks and non- 2494 compliance of various implementations, as well as historical 2495 ambiguities, which, while being valid ASN.1, can lead to confusion 2496 during implementation. 2498 5.1.1. ASN.1 Distinguished Encoding Rules 2500 The encoding of Kerberos protocol messages shall obey the 2502 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 2504 Distinguished Encoding Rules (DER) of ASN.1 as described in [X690]. 2505 Some implementations (believed to be primarly ones derived from DCE 2506 1.1 and earlier) are known to use the more general Basic Encoding 2507 Rules (BER); in particular, these implementations send indefinite 2508 encodings of lengths. Implementations MAY accept such encodings in 2509 the interests of backwards compatibility, though implementors are 2510 warned that decoding fully-general BER is fraught with peril. 2512 5.1.2. Optional Integer Fields 2514 Some implementations do not internally distinguish between an omitted 2515 optional integer value and a transmitted value of zero. The places in 2516 the protocol where this is relevant include various microseconds 2517 fields, nonces, and sequence numbers. Implementations SHOULD treat 2518 omitted optional integer values as having been transmitted with a 2519 value of zero, if the application is expecting this. 2521 5.1.3. Empty SEQUENCE OF Types 2523 There are places in the protocol where a message contains a SEQUENCE 2524 OF type as an optional member. This can result in an encoding that 2525 contains an empty SEQUENCE OF encoding. The Kerberos protocol does 2526 not semantically distinguish between an absent optional SEQUENCE OF 2527 type and a present optional but empty SEQUENCE OF type. 2528 Implementations SHOULD NOT send empty SEQUENCE OF encodings that are 2529 marked OPTIONAL, but SHOULD accept them as being equivalent to an 2530 omitted OPTIONAL type. In the ASN.1 syntax describing Kerberos 2531 messages, instances of these problematic optional SEQUENCE OF types 2532 are indicated with a comment. 2534 5.1.4. Unrecognized Tag Numbers 2536 Future revisions to this protocol may include new message types with 2537 different APPLICATION class tag numbers. Such revisions should 2538 protect older implementations by only sending the message types to 2539 parties that are known to understand them, e.g. by means of a flag 2540 bit set by the receiver in a preceding request. In the interest of 2541 robust error handling, implementations SHOULD gracefully handle 2542 receiving a message with an unrecognized tag anyway, and return an 2543 error message if appropriate. 2545 5.1.5. Tag Numbers Greater Than 30 2547 A naive implementation of a DER ASN.1 decoder may experience problems 2548 with ASN.1 tag numbers greater than 30, due to such tag numbers being 2549 encoded using more than one byte. Future revisions of this protocol 2550 may utilize tag numbers greater than 30, and implementations SHOULD 2551 be prepared to gracefully return an error, if appropriate, if they do 2553 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 2555 not recognize the tag. 2557 5.2. Basic Kerberos Types 2559 This section defines a number of basic types that are potentially 2560 used in multiple Kerberos protocol messages. 2562 5.2.1. KerberosString 2564 The original specification of the Kerberos protocol in RFC 1510 uses 2565 GeneralString in numerous places for human-readable string data. 2566 Historical implementations of Kerberos cannot utilize the full power 2567 of GeneralString. This ASN.1 type requires the use of designation 2568 and invocation escape sequences as specified in ISO-2022/ECMA-35 2569 [ISO-2022/ECMA-35] to switch character sets, and the default 2570 character set that is designated as G0 is the ISO-646/ECMA-6 2571 [ISO-646,ECMA-6] International Reference Version (IRV) (aka U.S. 2572 ASCII), which mostly works. 2574 ISO-2022/ECMA-35 defines four character-set code elements (G0..G3) 2575 and two Control-function code elements (C0..C1). DER prohibits the 2576 designation of character sets as any but the G0 and C0 sets. 2577 Unfortunately, this seems to have the side effect of prohibiting the 2578 use of ISO-8859 (ISO Latin) [ISO-8859] character-sets or any other 2579 character-sets that utilize a 96-character set, since it is 2580 prohibited by ISO-2022/ECMA-35 to designate them as the G0 code 2581 element. This side effect is being investigated in the ASN.1 2582 standards community. 2584 In practice, many implementations treat GeneralStrings as if they 2585 were 8-bit strings of whichever character set the implementation 2586 defaults to, without regard for correct usage of character-set 2587 designation escape sequences. The default character set is often 2588 determined by the current user's operating system dependent locale. 2589 At least one major implementation places unescaped UTF-8 encoded 2590 Unicode characters in the GeneralString. This failure to adhere to 2591 the GeneralString specifications results in interoperability issues 2592 when conflicting character encodings are utilized by the Kerberos 2593 clients, services, and KDC. 2595 This unfortunate situation is the result of improper documentation of 2596 the restrictions of the ASN.1 GeneralString type in prior Kerberos 2597 specifications. 2599 The new (post-RFC 1510) type KerberosString, defined below, is a 2600 GeneralString that is constrained to only contain characters in 2601 IA5String 2603 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 2605 KerberosString ::= GeneralString (IA5String) 2607 US-ASCII control characters should in general not be used in 2608 KerberosString, except for cases such as newlines in lengthy error 2609 messages. Control characters SHOULD NOT be used in principal names or 2610 realm names. 2612 For compatibility, implementations MAY choose to accept GeneralString 2613 values that contain characters other than those permitted by 2614 IA5String, but they should be aware that character set designation 2615 codes will likely be absent, and that the encoding should probably be 2616 treated as locale-specific in almost every way. Implementations MAY 2617 also choose to emit GeneralString values that are beyond those 2618 permitted by IA5String, but should be aware that doing so is 2619 extraordinarily risky from an interoperability perspective. 2621 Some existing implementations use GeneralString to encode unescaped 2622 locale-specific characters. This is a violation of the ASN.1 2623 standard. Most of these implementations encode US-ASCII in the left- 2624 hand half, so as long the implementation transmits only US-ASCII, the 2625 ASN.1 standard is not violated in this regard. As soon as such an 2626 implementation encodes unescaped locale-specific characters with the 2627 high bit set, it violates the ASN.1 standard. 2629 Other implementations have been known to use GeneralString to contain 2630 a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8 2631 is a different encoding, not a 94 or 96 character "G" set as defined 2632 by ISO 2022. It is believed that these implementations do not even 2633 use the ISO 2022 escape sequence to change the character encoding. 2634 Even if implementations were to announce the change of encoding by 2635 using that escape sequence, the ASN.1 standard prohibits the use of 2636 any escape sequences other than those used to designate/invoke "G" or 2637 "C" sets allowed by GeneralString. 2639 Future revisions to this protocol will almost certainly allow for a 2640 more interoperable representation of principal names, probably 2641 including UTF8String. 2643 Note that applying a new constraint to a previously unconstrained 2644 type constitutes creation of a new ASN.1 type. In this particular 2645 case, the change does not result in a changed encoding under DER. 2647 5.2.2. Realm and PrincipalName 2649 Realm ::= KerberosString 2651 PrincipalName ::= SEQUENCE { 2652 name-type [0] Int32, 2654 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 2656 name-string [1] SEQUENCE OF KerberosString 2657 } 2659 Kerberos realm names are encoded as KerberosStrings. Realms shall not 2660 contain a character with the code 0 (the US-ASCII NUL). Most realms 2661 will usually consist of several components separated by periods (.), 2662 in the style of Internet Domain Names, or separated by slashes (/) in 2663 the style of X.500 names. Acceptable forms for realm names are 2664 specified in section 6.1.. A PrincipalName is a typed sequence of 2665 components consisting of the following sub-fields: 2667 name-type 2668 This field specifies the type of name that follows. Pre-defined 2669 values for this field are specified in section 6.2. The name-type 2670 SHOULD be treated as a hint. Ignoring the name type, no two names 2671 can be the same (i.e. at least one of the components, or the 2672 realm, must be different). 2674 name-string 2675 This field encodes a sequence of components that form a name, each 2676 component encoded as a KerberosString. Taken together, a 2677 PrincipalName and a Realm form a principal identifier. Most 2678 PrincipalNames will have only a few components (typically one or 2679 two). 2681 5.2.3. KerberosTime 2683 KerberosTime ::= GeneralizedTime -- with no fractional seconds 2685 The timestamps used in Kerberos are encoded as GeneralizedTimes. A 2686 KerberosTime value shall not include any fractional portions of the 2687 seconds. As required by the DER, it further shall not include any 2688 separators, and it shall specify the UTC time zone (Z). Example: The 2689 only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6 2690 November 1985 is 19851106210627Z. 2692 5.2.4. Constrained Integer types 2694 Some integer members of types SHOULD be constrained to values 2695 representable in 32 bits, for compatibility with reasonable 2696 implementation limits. 2698 Int32 ::= INTEGER (-2147483648..2147483647) 2699 -- signed values representable in 32 bits 2701 UInt32 ::= INTEGER (0..4294967295) 2702 -- unsigned 32 bit values 2704 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 2706 Microseconds ::= INTEGER (0..999999) 2707 -- microseconds 2709 While this results in changes to the abstract types from the RFC 1510 2710 version, the encoding in DER should be unaltered. Historical 2711 implementations were typically limited to 32-bit integer values 2712 anyway, and assigned numbers SHOULD fall in the space of integer 2713 values representable in 32 bits in order to promote interoperability 2714 anyway. 2716 There are several integer fields in messages that are constrained to 2717 fixed values. 2719 pvno 2720 also TKT-VNO or AUTHENTICATOR-VNO, this recurring field is always 2721 the constant integer 5. There is no easy way to make this field 2722 into a useful protocol version number, so its value is fixed. 2724 msg-type 2725 this integer field is usually identical to the application tag 2726 number of the containing message type. 2728 5.2.5. HostAddress and HostAddresses 2730 HostAddress ::= SEQUENCE { 2731 addr-type [0] Int32, 2732 address [1] OCTET STRING 2733 } 2735 -- NOTE: HostAddresses is always used as an OPTIONAL field and 2736 -- should not be empty. 2737 HostAddresses -- NOTE: subtly different from rfc1510, 2738 -- but has a value mapping and encodes the same 2739 ::= SEQUENCE OF HostAddress 2741 The host address encodings consists of two fields: 2743 addr-type 2744 This field specifies the type of address that follows. Pre-defined 2745 values for this field are specified in section 7.5.3. 2747 address 2748 This field encodes a single address of type addr-type. 2750 5.2.6. AuthorizationData 2752 -- NOTE: AuthorizationData is always used as an OPTIONAL field and 2753 -- should not be empty. 2755 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 2757 AuthorizationData ::= SEQUENCE OF SEQUENCE { 2758 ad-type [0] Int32, 2759 ad-data [1] OCTET STRING 2760 } 2762 ad-data 2763 This field contains authorization data to be interpreted according 2764 to the value of the corresponding ad-type field. 2766 ad-type 2767 This field specifies the format for the ad-data subfield. All 2768 negative values are reserved for local use. Non-negative values 2769 are reserved for registered use. 2771 Each sequence of type and data is referred to as an authorization 2772 element. Elements MAY be application specific, however, there is a 2773 common set of recursive elements that should be understood by all 2774 implementations. These elements contain other elements embedded 2775 within them, and the interpretation of the encapsulating element 2776 determines which of the embedded elements must be interpreted, and 2777 which may be ignored. 2779 These common authorization data elements are recursively defined, 2780 meaning the ad-data for these types will itself contain a sequence of 2781 authorization data whose interpretation is affected by the 2782 encapsulating element. Depending on the meaning of the encapsulating 2783 element, the encapsulated elements may be ignored, might be 2784 interpreted as issued directly by the KDC, or they might be stored in 2785 a separate plaintext part of the ticket. The types of the 2786 encapsulating elements are specified as part of the Kerberos 2787 specification because the behavior based on these values should be 2788 understood across implementations whereas other elements need only be 2789 understood by the applications which they affect. 2791 Authorization data elements are considered critical if present in a 2792 ticket or authenticator. Unless encapsulated in a known authorization 2793 data element amending the criticality of the elements it contains, if 2794 an unknown authorization data element type is received by a server 2795 either in an AP-REQ or in a ticket contained in an AP-REQ, then 2796 authentication MUST fail. Authorization data is intended to restrict 2797 the use of a ticket. If the service cannot determine whether the 2798 restriction applies to that service then a security weakness may 2799 result if the ticket can be used for that service. Authorization 2800 elements that are optional can be enclosed in AD-IF-RELEVANT element. 2802 In the definitions that follow, the value of the ad-type for the 2803 element will be specified as the least significant part of the 2804 subsection number, and the value of the ad-data will be as shown in 2806 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 2808 the ASN.1 structure that follows the subsection heading. 2810 contents of ad-data ad-type 2812 DER encoding of AD-IF-RELEVANT 1 2814 DER encoding of AD-KDCIssued 4 2816 DER encoding of AD-AND-OR 5 2818 DER encoding of AD-MANDATORY-FOR-KDC 8 2820 5.2.6.1. IF-RELEVANT 2822 AD-IF-RELEVANT ::= AuthorizationData 2824 AD elements encapsulated within the if-relevant element are intended 2825 for interpretation only by application servers that understand the 2826 particular ad-type of the embedded element. Application servers that 2827 do not understand the type of an element embedded within the if- 2828 relevant element MAY ignore the uninterpretable element. This element 2829 promotes interoperability across implementations which may have local 2830 extensions for authorization. The ad-type for AD-IF-RELEVANT is (1). 2832 5.2.6.2. KDCIssued 2834 AD-KDCIssued ::= SEQUENCE { 2835 ad-checksum [0] Checksum, 2836 i-realm [1] Realm OPTIONAL, 2837 i-sname [2] PrincipalName OPTIONAL, 2838 elements [3] AuthorizationData 2839 } 2841 ad-checksum 2842 A cryptographic checksum computed over the DER encoding of the 2843 AuthorizationData in the "elements" field, keyed with the session 2844 key. Its checksumtype is the mandatory checksum type for the 2845 encryption type of the session key, and its key usage value is 19. 2847 i-realm, i-sname 2848 The name of the issuing principal if different from the KDC 2849 itself. This field would be used when the KDC can verify the 2850 authenticity of elements signed by the issuing principal and it 2851 allows this KDC to notify the application server of the validity 2852 of those elements. 2854 elements 2855 A sequence of authorization data elements issued by the KDC. 2857 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 2859 The KDC-issued ad-data field is intended to provide a means for 2860 Kerberos principal credentials to embed within themselves privilege 2861 attributes and other mechanisms for positive authorization, 2862 amplifying the privileges of the principal beyond what can be done 2863 using a credentials without such an a-data element. 2865 This can not be provided without this element because the definition 2866 of the authorization-data field allows elements to be added at will 2867 by the bearer of a TGT at the time that they request service tickets 2868 and elements may also be added to a delegated ticket by inclusion in 2869 the authenticator. 2871 For KDC-issued elements this is prevented because the elements are 2872 signed by the KDC by including a checksum encrypted using the 2873 server's key (the same key used to encrypt the ticket - or a key 2874 derived from that key). Elements encapsulated with in the KDC-issued 2875 element MUST be ignored by the application server if this 2876 "signature" is not present. Further, elements encapsulated within 2877 this element from a ticket-granting ticket MAY be interpreted by the 2878 KDC, and used as a basis according to policy for including new signed 2879 elements within derivative tickets, but they will not be copied to a 2880 derivative ticket directly. If they are copied directly to a 2881 derivative ticket by a KDC that is not aware of this element, the 2882 signature will not be correct for the application ticket elements, 2883 and the field will be ignored by the application server. 2885 This element and the elements it encapsulates MAY be safely ignored 2886 by applications, application servers, and KDCs that do not implement 2887 this element. 2889 The ad-type for AD-KDC-ISSUED is (4). 2891 5.2.6.3. AND-OR 2893 AD-AND-OR ::= SEQUENCE { 2894 condition-count [0] INTEGER, 2895 elements [1] AuthorizationData 2896 } 2898 When restrictive AD elements are encapsulated within the and-or 2899 element, the and-or element is considered satisfied if and only if at 2900 least the number of encapsulated elements specified in condition- 2901 count are satisifed. Therefore, this element MAY be used to 2902 implement an "or" operation by setting the condition-count field to 2903 1, and it MAY specify an "and" operation by setting the condition 2904 count to the number of embedded elements. Application servers that do 2905 not implement this element MUST reject tickets that contain 2907 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 2909 authorization data elements of this type. 2911 The ad-type for AD-AND-OR is (5). 2913 5.2.6.4. MANDATORY-FOR-KDC 2915 AD-MANDATORY-FOR-KDC ::= AuthorizationData 2917 AD elements encapsulated within the mandatory-for-kdc element are to 2918 be interpreted by the KDC. KDCs that do not understand the type of an 2919 element embedded within the mandatory-for-kdc element MUST reject the 2920 request. 2922 The ad-type for AD-MANDATORY-FOR-KDC is (8). 2924 5.2.7. PA-DATA 2926 Historically, PA-DATA have been known as "pre-authentication data", 2927 meaning that they were used to augment the initial authentication 2928 with the KDC. Since that time, they have also been used as a typed 2929 hole with which to extend protocol exchanges with the KDC. 2931 PA-DATA ::= SEQUENCE { 2932 -- NOTE: first tag is [1], not [0] 2933 padata-type [1] Int32, 2934 padata-value [2] OCTET STRING -- might be encoded AP-REQ 2935 } 2937 padata-type 2938 indicates the way that the padata-value element is to be 2939 interpreted. Negative values of padata-type are reserved for 2940 unregistered use; non-negative values are used for a registered 2941 interpretation of the element type. 2943 padata-value 2944 Usually contains the DER encoding of another type; the padata-type 2945 field identifies which type is encoded here. 2947 padata-type name contents of padata-value 2949 1 pa-tgs-req DER encoding of AP-REQ 2951 2 pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP 2953 3 pa-pw-salt salt (not ASN.1 encoded) 2955 11 pa-etype-info DER encoding of ETYPE-INFO 2957 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 2959 19 pa-etype-info2 DER encoding of ETYPE-INFO2 2961 This field MAY also contain information needed by certain 2962 extensions to the Kerberos protocol. For example, it might be used 2963 to initially verify the identity of a client before any response 2964 is returned. 2966 The padata field can also contain information needed to help the 2967 KDC or the client select the key needed for generating or 2968 decrypting the response. This form of the padata is useful for 2969 supporting the use of certain token cards with Kerberos. The 2970 details of such extensions are specified in separate documents. 2971 See [Pat92] for additional uses of this field. 2973 5.2.7.1. PA-TGS-REQ 2975 In the case of requests for additional tickets (KRB_TGS_REQ), padata- 2976 value will contain an encoded AP-REQ. The checksum in the 2977 authenticator (which MUST be collision-proof) is to be computed over 2978 the KDC-REQ-BODY encoding. 2980 5.2.7.2. Encrypted Timestamp Pre-authentication 2982 There are pre-authentication types that may be used to pre- 2983 authenticate a client by means of an encrypted timestamp. 2985 PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC 2987 PA-ENC-TS-ENC ::= SEQUENCE { 2988 patimestamp [0] KerberosTime -- client's time --, 2989 pausec [1] Microseconds OPTIONAL 2990 } 2992 Patimestamp contains the client's time, and pausec contains the 2993 microseconds, which MAY be omitted if a client will not generate more 2994 than one request per second. The ciphertext (padata-value) consists 2995 of the PA-ENC-TS-ENC encoding, encrypted using the client's secret 2996 key and a key usage value of 1. 2998 This pre-authentication type was not present in RFC 1510, but many 2999 implementations support it. 3001 5.2.7.3. PA-PW-SALT 3003 The padata-value for this pre-authentication type contains the salt 3004 for the string-to-key to be used by the client to obtain the key for 3005 decrypting the encrypted part of an AS-REP message. Unfortunately, 3006 for historical reasons, the character set to be used is unspecified 3008 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 3010 and probably locale-specific. 3012 This pre-authentication type was not present in RFC 1510, but many 3013 implementations support it. It is necessary in any case where the 3014 salt for the string-to-key algorithm is not the default. 3016 In the trivial example, a zero-length salt string is very commonplace 3017 for realms that have converted their principal databases from 3018 Kerberos 4. 3020 A KDC SHOULD NOT send PA-PW-SALT when issuing a KRB-ERROR message 3021 that requests additional pre-authentication. Implementation note: 3022 some KDC implementations issue an erroneous PA-PW-SALT when issuing a 3023 KRB-ERROR message that requests additional pre-authentication. 3024 Therefore, clients SHOULD ignore a PA-PW-SALT accompanying a KRB- 3025 ERROR message that requests additional pre-authentication. As noted 3026 in section 3.1.3, a KDC MUST NOT send PA-PW-SALT when the client's 3027 AS-REQ includes at least one "newer" etype. 3029 5.2.7.4. PA-ETYPE-INFO 3031 The ETYPE-INFO pre-authentication type is sent by the KDC in a KRB- 3032 ERROR indicating a requirement for additional pre-authentication. It 3033 is usually used to notify a client of which key to use for the 3034 encryption of an encrypted timestamp for the purposes of sending a 3035 PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an 3036 AS-REP to provide information to the client about which key salt to 3037 use for the string-to-key to be used by the client to obtain the key 3038 for decrypting the encrypted part the AS-REP. 3040 ETYPE-INFO-ENTRY ::= SEQUENCE { 3041 etype [0] Int32, 3042 salt [1] OCTET STRING OPTIONAL 3043 } 3045 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY 3047 The salt, like that of PA-PW-SALT, is also completely unspecified 3048 with respect to character set and is probably locale-specific. 3050 If ETYPE-INFO is sent in an AS-REP, there shall be exactly one ETYPE- 3051 INFO-ENTRY, and its etype shall match that of the enc-part in the AS- 3052 REP. 3054 This pre-authentication type was not present in RFC 1510, but many 3055 implementations that support encrypted timestamps for pre- 3056 authentication need to support ETYPE-INFO as well. As noted in 3057 section 3.1.3, a KDC MUST NOT send PA-ETYPE-INFO when the client's 3059 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 3061 AS-REQ includes at least one "newer" etype. 3063 5.2.7.5. PA-ETYPE-INFO2 3065 The ETYPE-INFO2 pre-authentication type is sent by the KDC in a KRB- 3066 ERROR indicating a requirement for additional pre-authentication. It 3067 is usually used to notify a client of which key to use for the 3068 encryption of an encrypted timestamp for the purposes of sending a 3069 PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an 3070 AS-REP to provide information to the client about which key salt to 3071 use for the string-to-key to be used by the client to obtain the key 3072 for decrypting the encrypted part the AS-REP. 3074 ETYPE-INFO2-ENTRY ::= SEQUENCE { 3075 etype [0] Int32, 3076 salt [1] KerberosString OPTIONAL, 3077 s2kparams [2] OCTET STRING OPTIONAL 3078 } 3080 ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY 3082 The type of the salt is KerberosString, but existing installations 3083 might have locale-specific characters stored in salt strings, and 3084 implementors MAY choose to handle them. 3086 The interpretation of s2kparams is specified in the cryptosystem 3087 description associated with the etype. Each cryptosystem has a 3088 default interpretation of s2kparams that will hold if that element is 3089 omitted from the encoding of ETYPE-INFO2-ENTRY. 3091 If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one 3092 ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part in 3093 the AS-REP. 3095 The preferred ordering of the "hint" pre-authentication data that 3096 affect client key selection is: ETYPE-INFO2, followed by ETYPE-INFO, 3097 followed by PW-SALT. As noted in section 3.1.3, a KDC MUST NOT send 3098 ETYPE-INFO or PW-SALT when the client's AS-REQ includes at least one 3099 "newer" etype. 3101 The ETYPE-INFO2 pre-authentication type was not present in RFC 1510. 3103 5.2.8. KerberosFlags 3105 For several message types, a specific constrained bit string type, 3106 KerberosFlags, is used. 3108 KerberosFlags ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits 3110 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 3112 -- shall be sent, but no fewer than 32 3114 Compatibility note: the following paragraphs describe a change from 3115 the RFC1510 description of bit strings that would result in 3116 incompatility in the case of an implementation that strictly 3117 conformed to ASN.1 DER and RFC1510. 3119 ASN.1 bit strings have multiple uses. The simplest use of a bit 3120 string is to contain a vector of bits, with no particular meaning 3121 attached to individual bits. This vector of bits is not necessarily a 3122 multiple of eight bits long. The use in Kerberos of a bit string as 3123 a compact boolean vector wherein each element has a distinct meaning 3124 poses some problems. The natural notation for a compact boolean 3125 vector is the ASN.1 "NamedBit" notation, and the DER require that 3126 encodings of a bit string using "NamedBit" notation exclude any 3127 trailing zero bits. This truncation is easy to neglect, especially 3128 given C language implementations that naturally choose to store 3129 boolean vectors as 32 bit integers. 3131 For example, if the notation for KDCOptions were to include the 3132 "NamedBit" notation, as in RFC 1510, and a KDCOptions value to be 3133 encoded had only the "forwardable" (bit number one) bit set, the DER 3134 encoding MUST include only two bits: the first reserved bit 3135 ("reserved", bit number zero, value zero) and the one-valued bit (bit 3136 number one) for "forwardable". 3138 Most existing implementations of Kerberos unconditionally send 32 3139 bits on the wire when encoding bit strings used as boolean vectors. 3140 This behavior violates the ASN.1 syntax used for flag values in RFC 3141 1510, but occurs on such a widely installed base that the protocol 3142 description is being modified to accomodate it. 3144 Consequently, this document removes the "NamedBit" notations for 3145 individual bits, relegating them to comments. The size constraint on 3146 the KerberosFlags type requires that at least 32 bits be encoded at 3147 all times, though a lenient implementation MAY choose to accept fewer 3148 than 32 bits and to treat the missing bits as set to zero. 3150 Currently, no uses of KerberosFlags specify more than 32 bits worth 3151 of flags, although future revisions of this document may do so. When 3152 more than 32 bits are to be transmitted in a KerberosFlags value, 3153 future revisions to this document will likely specify that the 3154 smallest number of bits needed to encode the highest-numbered one- 3155 valued bit should be sent. This is somewhat similar to the DER 3156 encoding of a bit string that is declared with the "NamedBit" 3157 notation. 3159 5.2.9. Cryptosystem-related Types 3160 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 3162 Many Kerberos protocol messages contain an EncryptedData as a 3163 container for arbitrary encrypted data, which is often the encrypted 3164 encoding of another data type. Fields within EncryptedData assist the 3165 recipient in selecting a key with which to decrypt the enclosed data. 3167 EncryptedData ::= SEQUENCE { 3168 etype [0] Int32 -- EncryptionType --, 3169 kvno [1] UInt32 OPTIONAL, 3170 cipher [2] OCTET STRING -- ciphertext 3171 } 3173 etype 3174 This field identifies which encryption algorithm was used to 3175 encipher the cipher. 3177 kvno 3178 This field contains the version number of the key under which data 3179 is encrypted. It is only present in messages encrypted under long 3180 lasting keys, such as principals' secret keys. 3182 cipher 3183 This field contains the enciphered text, encoded as an OCTET 3184 STRING. (Note that the encryption mechanisms defined in 3185 [@KCRYPTO] MUST incorporate integrity protection as well, so no 3186 additional checksum is required.) 3188 The EncryptionKey type is the means by which cryptographic keys used 3189 for encryption are transfered. 3191 EncryptionKey ::= SEQUENCE { 3192 keytype [0] Int32 -- actually encryption type --, 3193 keyvalue [1] OCTET STRING 3194 } 3196 keytype 3197 This field specifies the encryption type of the encryption key 3198 that follows in the keyvalue field. While its name is "keytype", 3199 it actually specifies an encryption type. Previously, multiple 3200 cryptosystems that performed encryption differently but were 3201 capable of using keys with the same characteristics were permitted 3202 to share an assigned number to designate the type of key; this 3203 usage is now deprecated. 3205 keyvalue 3206 This field contains the key itself, encoded as an octet string. 3208 Messages containing cleartext data to be authenticated will usually 3209 do so by using a member of type Checksum. Most instances of Checksum 3211 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 3213 use a keyed hash, though exceptions will be noted. 3215 Checksum ::= SEQUENCE { 3216 cksumtype [0] Int32, 3217 checksum [1] OCTET STRING 3218 } 3220 cksumtype 3221 This field indicates the algorithm used to generate the 3222 accompanying checksum. 3224 checksum 3225 This field contains the checksum itself, encoded as an octet 3226 string. 3228 See section 4 for a brief description of the use of encryption and 3229 checksums in Kerberos. 3231 5.3. Tickets 3233 This section describes the format and encryption parameters for 3234 tickets and authenticators. When a ticket or authenticator is 3235 included in a protocol message it is treated as an opaque object. A 3236 ticket is a record that helps a client authenticate to a service. A 3237 Ticket contains the following information: 3239 Ticket ::= [APPLICATION 1] SEQUENCE { 3240 tkt-vno [0] INTEGER (5), 3241 realm [1] Realm, 3242 sname [2] PrincipalName, 3243 enc-part [3] EncryptedData -- EncTicketPart 3244 } 3246 -- Encrypted part of ticket 3247 EncTicketPart ::= [APPLICATION 3] SEQUENCE { 3248 flags [0] TicketFlags, 3249 key [1] EncryptionKey, 3250 crealm [2] Realm, 3251 cname [3] PrincipalName, 3252 transited [4] TransitedEncoding, 3253 authtime [5] KerberosTime, 3254 starttime [6] KerberosTime OPTIONAL, 3255 endtime [7] KerberosTime, 3256 renew-till [8] KerberosTime OPTIONAL, 3257 caddr [9] HostAddresses OPTIONAL, 3258 authorization-data [10] AuthorizationData OPTIONAL 3259 } 3261 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 3263 -- encoded Transited field 3264 TransitedEncoding ::= SEQUENCE { 3265 tr-type [0] Int32 -- must be registered --, 3266 contents [1] OCTET STRING 3267 } 3269 TicketFlags ::= KerberosFlags 3270 -- reserved(0), 3271 -- forwardable(1), 3272 -- forwarded(2), 3273 -- proxiable(3), 3274 -- proxy(4), 3275 -- may-postdate(5), 3276 -- postdated(6), 3277 -- invalid(7), 3278 -- renewable(8), 3279 -- initial(9), 3280 -- pre-authent(10), 3281 -- hw-authent(11), 3282 -- the following are new since 1510 3283 -- transited-policy-checked(12), 3284 -- ok-as-delegate(13) 3286 tkt-vno 3287 This field specifies the version number for the ticket format. 3288 This document describes version number 5. 3290 realm 3291 This field specifies the realm that issued a ticket. It also 3292 serves to identify the realm part of the server's principal 3293 identifier. Since a Kerberos server can only issue tickets for 3294 servers within its realm, the two will always be identical. 3296 sname 3297 This field specifies all components of the name part of the 3298 server's identity, including those parts that identify a specific 3299 instance of a service. 3301 enc-part 3302 This field holds the encrypted encoding of the EncTicketPart 3303 sequence. It is encrypted in the key shared by Kerberos and the 3304 end server (the server's secret key), using a key usage value of 3305 2. 3307 flags 3308 This field indicates which of various options were used or 3309 requested when the ticket was issued. The meanings of the flags 3310 are: 3312 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 3314 Bit(s) Name Description 3316 0 reserved Reserved for future expansion of this 3317 field. 3319 The FORWARDABLE flag is normally only 3320 interpreted by the TGS, and can be 3321 ignored by end servers. When set, this 3322 1 forwardable flag tells the ticket-granting server 3323 that it is OK to issue a new 3324 ticket-granting ticket with a 3325 different network address based on the 3326 presented ticket. 3328 When set, this flag indicates that the 3329 ticket has either been forwarded or 3330 2 forwarded was issued based on authentication 3331 involving a forwarded ticket-granting 3332 ticket. 3334 The PROXIABLE flag is normally only 3335 interpreted by the TGS, and can be 3336 ignored by end servers. The PROXIABLE 3337 flag has an interpretation identical 3338 3 proxiable to that of the FORWARDABLE flag, 3339 except that the PROXIABLE flag tells 3340 the ticket-granting server that only 3341 non-ticket-granting tickets may be 3342 issued with different network 3343 addresses. 3345 4 proxy When set, this flag indicates that a 3346 ticket is a proxy. 3348 The MAY-POSTDATE flag is normally only 3349 interpreted by the TGS, and can be 3350 5 may-postdate ignored by end servers. This flag 3351 tells the ticket-granting server that 3352 a post-dated ticket MAY be issued 3353 based on this ticket-granting ticket. 3355 This flag indicates that this ticket 3356 has been postdated. The end-service 3357 6 postdated can check the authtime field to see 3358 when the original authentication 3359 occurred. 3361 This flag indicates that a ticket is 3363 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 3365 invalid, and it must be validated by 3366 7 invalid the KDC before use. Application 3367 servers must reject tickets which have 3368 this flag set. 3370 The RENEWABLE flag is normally only 3371 interpreted by the TGS, and can 3372 usually be ignored by end servers 3373 8 renewable (some particularly careful servers MAY 3374 disallow renewable tickets). A 3375 renewable ticket can be used to obtain 3376 a replacement ticket that expires at a 3377 later date. 3379 This flag indicates that this ticket 3380 9 initial was issued using the AS protocol, and 3381 not issued based on a ticket-granting 3382 ticket. 3384 This flag indicates that during 3385 initial authentication, the client was 3386 authenticated by the KDC before a 3387 10 pre-authent ticket was issued. The strength of the 3388 pre-authentication method is not 3389 indicated, but is acceptable to the 3390 KDC. 3392 This flag indicates that the protocol 3393 employed for initial authentication 3394 required the use of hardware expected 3395 11 hw-authent to be possessed solely by the named 3396 client. The hardware authentication 3397 method is selected by the KDC and the 3398 strength of the method is not 3399 indicated. 3401 This flag indicates that the KDC for 3402 the realm has checked the transited 3403 field against a realm defined policy 3404 for trusted certifiers. If this flag 3405 is reset (0), then the application 3406 server must check the transited field 3407 itself, and if unable to do so it must 3408 reject the authentication. If the flag 3409 12 transited- is set (1) then the application server 3410 policy-checked MAY skip its own validation of the 3411 transited field, relying on the 3412 validation performed by the KDC. At 3414 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 3416 its option the application server MAY 3417 still apply its own validation based 3418 on a separate policy for acceptance. 3420 This flag is new since RFC 1510. 3422 This flag indicates that the server 3423 (not the client) specified in the 3424 ticket has been determined by policy 3425 of the realm to be a suitable 3426 recipient of delegation. A client can 3427 use the presence of this flag to help 3428 it make a decision whether to delegate 3429 credentials (either grant a proxy or a 3430 forwarded ticket-granting ticket) to 3431 13 ok-as-delegate this server. The client is free to 3432 ignore the value of this flag. When 3433 setting this flag, an administrator 3434 should consider the Security and 3435 placement of the server on which the 3436 service will run, as well as whether 3437 the service requires the use of 3438 delegated credentials. 3440 This flag is new since RFC 1510. 3442 14-31 reserved Reserved for future use. 3444 key 3445 This field exists in the ticket and the KDC response and is used 3446 to pass the session key from Kerberos to the application server 3447 and the client. 3449 crealm 3450 This field contains the name of the realm in which the client is 3451 registered and in which initial authentication took place. 3453 cname 3454 This field contains the name part of the client's principal 3455 identifier. 3457 transited 3458 This field lists the names of the Kerberos realms that took part 3459 in authenticating the user to whom this ticket was issued. It does 3460 not specify the order in which the realms were transited. See 3461 section 3.3.3.2 for details on how this field encodes the 3462 traversed realms. When the names of CA's are to be embedded in 3463 the transited field (as specified for some extensions to the 3465 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 3467 protocol), the X.500 names of the CA's SHOULD be mapped into items 3468 in the transited field using the mapping defined by RFC2253. 3470 authtime 3471 This field indicates the time of initial authentication for the 3472 named principal. It is the time of issue for the original ticket 3473 on which this ticket is based. It is included in the ticket to 3474 provide additional information to the end service, and to provide 3475 the necessary information for implementation of a `hot list' 3476 service at the KDC. An end service that is particularly paranoid 3477 could refuse to accept tickets for which the initial 3478 authentication occurred "too far" in the past. This field is also 3479 returned as part of the response from the KDC. When returned as 3480 part of the response to initial authentication (KRB_AS_REP), this 3481 is the current time on the Kerberos server. It is NOT recommended 3482 that this time value be used to adjust the workstation's clock 3483 since the workstation cannot reliably determine that such a 3484 KRB_AS_REP actually came from the proper KDC in a timely manner. 3486 starttime 3488 This field in the ticket specifies the time after which the ticket 3489 is valid. Together with endtime, this field specifies the life of 3490 the ticket. If the starttime field is absent from the ticket, then 3491 the authtime field SHOULD be used in its place to determine the 3492 life of the ticket. 3494 endtime 3495 This field contains the time after which the ticket will not be 3496 honored (its expiration time). Note that individual services MAY 3497 place their own limits on the life of a ticket and MAY reject 3498 tickets which have not yet expired. As such, this is really an 3499 upper bound on the expiration time for the ticket. 3501 renew-till 3502 This field is only present in tickets that have the RENEWABLE flag 3503 set in the flags field. It indicates the maximum endtime that may 3504 be included in a renewal. It can be thought of as the absolute 3505 expiration time for the ticket, including all renewals. 3507 caddr 3508 This field in a ticket contains zero (if omitted) or more (if 3509 present) host addresses. These are the addresses from which the 3510 ticket can be used. If there are no addresses, the ticket can be 3511 used from any location. The decision by the KDC to issue or by the 3512 end server to accept addressless tickets is a policy decision and 3513 is left to the Kerberos and end-service administrators; they MAY 3515 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 3517 refuse to issue or accept such tickets. Because of the wide 3518 deployment of network address translation, it is recommended that 3519 policy allow the issue and acceptance of such tickets. 3521 Network addresses are included in the ticket to make it harder for 3522 an attacker to use stolen credentials. Because the session key is 3523 not sent over the network in cleartext, credentials can't be 3524 stolen simply by listening to the network; an attacker has to gain 3525 access to the session key (perhaps through operating system 3526 security breaches or a careless user's unattended session) to make 3527 use of stolen tickets. 3529 It is important to note that the network address from which a 3530 connection is received cannot be reliably determined. Even if it 3531 could be, an attacker who has compromised the client's workstation 3532 could use the credentials from there. Including the network 3533 addresses only makes it more difficult, not impossible, for an 3534 attacker to walk off with stolen credentials and then use them 3535 from a "safe" location. 3537 authorization-data 3538 The authorization-data field is used to pass authorization data 3539 from the principal on whose behalf a ticket was issued to the 3540 application service. If no authorization data is included, this 3541 field will be left out. Experience has shown that the name of this 3542 field is confusing, and that a better name for this field would be 3543 restrictions. Unfortunately, it is not possible to change the name 3544 of this field at this time. 3546 This field contains restrictions on any authority obtained on the 3547 basis of authentication using the ticket. It is possible for any 3548 principal in posession of credentials to add entries to the 3549 authorization data field since these entries further restrict what 3550 can be done with the ticket. Such additions can be made by 3551 specifying the additional entries when a new ticket is obtained 3552 during the TGS exchange, or they MAY be added during chained 3553 delegation using the authorization data field of the 3554 authenticator. 3556 Because entries may be added to this field by the holder of 3557 credentials, except when an entry is separately authenticated by 3558 encapsulation in the KDC-issued element, it is not allowable for 3559 the presence of an entry in the authorization data field of a 3560 ticket to amplify the privileges one would obtain from using a 3561 ticket. 3563 The data in this field may be specific to the end service; the 3564 field will contain the names of service specific objects, and the 3566 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 3568 rights to those objects. The format for this field is described in 3569 section 5.2.6. Although Kerberos is not concerned with the format 3570 of the contents of the sub-fields, it does carry type information 3571 (ad-type). 3573 By using the authorization_data field, a principal is able to 3574 issue a proxy that is valid for a specific purpose. For example, a 3575 client wishing to print a file can obtain a file server proxy to 3576 be passed to the print server. By specifying the name of the file 3577 in the authorization_data field, the file server knows that the 3578 print server can only use the client's rights when accessing the 3579 particular file to be printed. 3581 A separate service providing authorization or certifying group 3582 membership may be built using the authorization-data field. In 3583 this case, the entity granting authorization (not the authorized 3584 entity), may obtain a ticket in its own name (e.g. the ticket is 3585 issued in the name of a privilege server), and this entity adds 3586 restrictions on its own authority and delegates the restricted 3587 authority through a proxy to the client. The client would then 3588 present this authorization credential to the application server 3589 separately from the authentication exchange. Alternatively, such 3590 authorization credentials MAY be embedded in the ticket 3591 authenticating the authorized entity, when the authorization is 3592 separately authenticated using the KDC-issued authorization data 3593 element (see 5.2.6.2). 3595 Similarly, if one specifies the authorization-data field of a 3596 proxy and leaves the host addresses blank, the resulting ticket 3597 and session key can be treated as a capability. See [Neu93] for 3598 some suggested uses of this field. 3600 The authorization-data field is optional and does not have to be 3601 included in a ticket. 3603 5.4. Specifications for the AS and TGS exchanges 3605 This section specifies the format of the messages used in the 3606 exchange between the client and the Kerberos server. The format of 3607 possible error messages appears in section 5.9.1. 3609 5.4.1. KRB_KDC_REQ definition 3611 The KRB_KDC_REQ message has no application tag number of its own. 3612 Instead, it is incorporated into one of KRB_AS_REQ or KRB_TGS_REQ, 3613 which each have an application tag, depending on whether the request 3614 is for an initial ticket or an additional ticket. In either case, the 3615 message is sent from the client to the KDC to request credentials for 3617 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 3619 a service. 3621 The message fields are: 3623 AS-REQ ::= [APPLICATION 10] KDC-REQ 3625 TGS-REQ ::= [APPLICATION 12] KDC-REQ 3627 KDC-REQ ::= SEQUENCE { 3628 -- NOTE: first tag is [1], not [0] 3629 pvno [1] INTEGER (5) , 3630 msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --), 3631 padata [3] SEQUENCE OF PA-DATA OPTIONAL 3632 -- NOTE: not empty --, 3633 req-body [4] KDC-REQ-BODY 3634 } 3636 KDC-REQ-BODY ::= SEQUENCE { 3637 kdc-options [0] KDCOptions, 3638 cname [1] PrincipalName OPTIONAL 3639 -- Used only in AS-REQ --, 3640 realm [2] Realm 3641 -- Server's realm 3642 -- Also client's in AS-REQ --, 3643 sname [3] PrincipalName OPTIONAL, 3644 from [4] KerberosTime OPTIONAL, 3645 till [5] KerberosTime, 3646 rtime [6] KerberosTime OPTIONAL, 3647 nonce [7] UInt32, 3648 etype [8] SEQUENCE OF Int32 -- EncryptionType 3649 -- in preference order --, 3650 addresses [9] HostAddresses OPTIONAL, 3651 enc-authorization-data [10] EncryptedData -- AuthorizationData --, 3652 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 3653 -- NOTE: not empty 3654 } 3656 KDCOptions ::= KerberosFlags 3657 -- reserved(0), 3658 -- forwardable(1), 3659 -- forwarded(2), 3660 -- proxiable(3), 3661 -- proxy(4), 3662 -- allow-postdate(5), 3663 -- postdated(6), 3664 -- unused7(7), 3665 -- renewable(8), 3666 -- unused9(9), 3668 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 3670 -- unused10(10), 3671 -- opt-hardware-auth(11), 3672 -- unused12(12), 3673 -- unused13(13), 3674 -- 15 is reserved for canonicalize 3675 -- unused15(15), 3676 -- 26 was unused in 1510 3677 -- disable-transited-check(26), 3678 -- 3679 -- renewable-ok(27), 3680 -- enc-tkt-in-skey(28), 3681 -- renew(30), 3682 -- validate(31) 3684 The fields in this message are: 3686 pvno 3687 This field is included in each message, and specifies the protocol 3688 version number. This document specifies protocol version 5. 3690 msg-type 3691 This field indicates the type of a protocol message. It will 3692 almost always be the same as the application identifier associated 3693 with a message. It is included to make the identifier more readily 3694 accessible to the application. For the KDC-REQ message, this type 3695 will be KRB_AS_REQ or KRB_TGS_REQ. 3697 padata 3698 Contains pre-authentication data. Requests for additional tickets 3699 (KRB_TGS_REQ) MUST contain a padata of PA-TGS-REQ. 3701 The padata (pre-authentication data) field contains a sequence of 3702 authentication information which may be needed before credentials 3703 can be issued or decrypted. 3705 req-body 3706 This field is a placeholder delimiting the extent of the remaining 3707 fields. If a checksum is to be calculated over the request, it is 3708 calculated over an encoding of the KDC-REQ-BODY sequence which is 3709 enclosed within the req-body field. 3711 kdc-options 3712 This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to 3713 the KDC and indicates the flags that the client wants set on the 3714 tickets as well as other information that is to modify the 3715 behavior of the KDC. Where appropriate, the name of an option may 3716 be the same as the flag that is set by that option. Although in 3717 most case, the bit in the options field will be the same as that 3719 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 3721 in the flags field, this is not guaranteed, so it is not 3722 acceptable to simply copy the options field to the flags field. 3723 There are various checks that must be made before honoring an 3724 option anyway. 3726 The kdc_options field is a bit-field, where the selected options 3727 are indicated by the bit being set (1), and the unselected options 3728 and reserved fields being reset (0). The encoding of the bits is 3729 specified in section 5.2. The options are described in more detail 3730 above in section 2. The meanings of the options are: 3732 Bits Name Description 3734 0 RESERVED Reserved for future expansion of 3735 this field. 3737 The FORWARDABLE option indicates 3738 that the ticket to be issued is to 3739 have its forwardable flag set. It 3740 1 FORWARDABLE may only be set on the initial 3741 request, or in a subsequent request 3742 if the ticket-granting ticket on 3743 which it is based is also 3744 forwardable. 3746 The FORWARDED option is only 3747 specified in a request to the 3748 ticket-granting server and will only 3749 be honored if the ticket-granting 3750 ticket in the request has its 3751 2 FORWARDED FORWARDABLE bit set. This option 3752 indicates that this is a request for 3753 forwarding. The address(es) of the 3754 host from which the resulting ticket 3755 is to be valid are included in the 3756 addresses field of the request. 3758 The PROXIABLE option indicates that 3759 the ticket to be issued is to have 3760 its proxiable flag set. It may only 3761 3 PROXIABLE be set on the initial request, or in 3762 a subsequent request if the 3763 ticket-granting ticket on which it 3764 is based is also proxiable. 3766 The PROXY option indicates that this 3767 is a request for a proxy. This 3768 option will only be honored if the 3770 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 3772 ticket-granting ticket in the 3773 4 PROXY request has its PROXIABLE bit set. 3774 The address(es) of the host from 3775 which the resulting ticket is to be 3776 valid are included in the addresses 3777 field of the request. 3779 The ALLOW-POSTDATE option indicates 3780 that the ticket to be issued is to 3781 have its MAY-POSTDATE flag set. It 3782 5 ALLOW-POSTDATE may only be set on the initial 3783 request, or in a subsequent request 3784 if the ticket-granting ticket on 3785 which it is based also has its 3786 MAY-POSTDATE flag set. 3788 The POSTDATED option indicates that 3789 this is a request for a postdated 3790 ticket. This option will only be 3791 honored if the ticket-granting 3792 ticket on which it is based has its 3793 6 POSTDATED MAY-POSTDATE flag set. The resulting 3794 ticket will also have its INVALID 3795 flag set, and that flag may be reset 3796 by a subsequent request to the KDC 3797 after the starttime in the ticket 3798 has been reached. 3800 7 RESERVED This option is presently unused. 3802 The RENEWABLE option indicates that 3803 the ticket to be issued is to have 3804 its RENEWABLE flag set. It may only 3805 be set on the initial request, or 3806 when the ticket-granting ticket on 3807 8 RENEWABLE which the request is based is also 3808 renewable. If this option is 3809 requested, then the rtime field in 3810 the request contains the desired 3811 absolute expiration time for the 3812 ticket. 3814 9 RESERVED Reserved for PK-Cross 3816 10 RESERVED Reserved for future use. 3818 11 RESERVED Reserved for opt-hardware-auth. 3820 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 3822 12-25 RESERVED Reserved for future use. 3824 By default the KDC will check the 3825 transited field of a 3826 ticket-granting-ticket against the 3827 policy of the local realm before it 3828 will issue derivative tickets based 3829 on the ticket-granting ticket. If 3830 this flag is set in the request, 3831 checking of the transited field is 3832 disabled. Tickets issued without the 3833 26 DISABLE-TRANSITED-CHECK performance of this check will be 3834 noted by the reset (0) value of the 3835 TRANSITED-POLICY-CHECKED flag, 3836 indicating to the application server 3837 that the tranisted field must be 3838 checked locally. KDCs are 3839 encouraged but not required to honor 3840 the DISABLE-TRANSITED-CHECK option. 3842 This flag is new since RFC 1510 3844 The RENEWABLE-OK option indicates 3845 that a renewable ticket will be 3846 acceptable if a ticket with the 3847 requested life cannot otherwise be 3848 provided. If a ticket with the 3849 requested life cannot be provided, 3850 27 RENEWABLE-OK then a renewable ticket may be 3851 issued with a renew-till equal to 3852 the requested endtime. The value 3853 of the renew-till field may still be 3854 limited by local limits, or limits 3855 selected by the individual principal 3856 or server. 3858 This option is used only by the 3859 ticket-granting service. The 3860 ENC-TKT-IN-SKEY option indicates 3861 28 ENC-TKT-IN-SKEY that the ticket for the end server 3862 is to be encrypted in the session 3863 key from the additional 3864 ticket-granting ticket provided. 3866 29 RESERVED Reserved for future use. 3868 This option is used only by the 3869 ticket-granting service. The RENEW 3871 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 3873 option indicates that the present 3874 request is for a renewal. The ticket 3875 provided is encrypted in the secret 3876 key for the server on which it is 3877 30 RENEW valid. This option will only be 3878 honored if the ticket to be renewed 3879 has its RENEWABLE flag set and if 3880 the time in its renew-till field has 3881 not passed. The ticket to be renewed 3882 is passed in the padata field as 3883 part of the authentication header. 3885 This option is used only by the 3886 ticket-granting service. The 3887 VALIDATE option indicates that the 3888 request is to validate a postdated 3889 ticket. It will only be honored if 3890 the ticket presented is postdated, 3891 presently has its INVALID flag set, 3892 31 VALIDATE and would be otherwise usable at 3893 this time. A ticket cannot be 3894 validated before its starttime. The 3895 ticket presented for validation is 3896 encrypted in the key of the server 3897 for which it is valid and is passed 3898 in the padata field as part of the 3899 authentication header. 3900 cname and sname 3901 These fields are the same as those described for the ticket in 3902 section 5.3. The sname may only be absent when the ENC-TKT-IN-SKEY 3903 option is specified. If absent, the name of the server is taken 3904 from the name of the client in the ticket passed as additional- 3905 tickets. 3907 enc-authorization-data 3908 The enc-authorization-data, if present (and it can only be present 3909 in the TGS_REQ form), is an encoding of the desired authorization- 3910 data encrypted under the sub-session key if present in the 3911 Authenticator, or alternatively from the session key in the 3912 ticket-granting ticket (both the Authenticator and ticket-granting 3913 ticket come from the padata field in the KRB_TGS_REQ). The key 3914 usage value used when encrypting is 5 if a sub-session key is 3915 used, or 4 if the session key is used. 3917 realm 3918 This field specifies the realm part of the server's principal 3919 identifier. In the AS exchange, this is also the realm part of the 3920 client's principal identifier. 3922 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 3924 from 3925 This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket 3926 requests when the requested ticket is to be postdated. It 3927 specifies the desired start time for the requested ticket. If this 3928 field is omitted then the KDC SHOULD use the current time instead. 3930 till 3931 This field contains the expiration date requested by the client in 3932 a ticket request. It is not optional, but if the requested endtime 3933 is "19700101000000Z", the requested ticket is to have the maximum 3934 endtime permitted according to KDC policy. Implementation note: 3935 This special timestamp corresponds to a UNIX time_t value of zero 3936 on most systems. 3938 rtime 3939 This field is the requested renew-till time sent from a client to 3940 the KDC in a ticket request. It is optional. 3942 nonce 3943 This field is part of the KDC request and response. It is intended 3944 to hold a random number generated by the client. If the same 3945 number is included in the encrypted response from the KDC, it 3946 provides evidence that the response is fresh and has not been 3947 replayed by an attacker. Nonces MUST NEVER be reused. 3949 etype 3950 This field specifies the desired encryption algorithm to be used 3951 in the response. 3953 addresses 3954 This field is included in the initial request for tickets, and 3955 optionally included in requests for additional tickets from the 3956 ticket-granting server. It specifies the addresses from which the 3957 requested ticket is to be valid. Normally it includes the 3958 addresses for the client's host. If a proxy is requested, this 3959 field will contain other addresses. The contents of this field are 3960 usually copied by the KDC into the caddr field of the resulting 3961 ticket. 3963 additional-tickets 3964 Additional tickets MAY be optionally included in a request to the 3965 ticket-granting server. If the ENC-TKT-IN-SKEY option has been 3966 specified, then the session key from the additional ticket will be 3967 used in place of the server's key to encrypt the new ticket. When 3968 the ENC-TKT-IN-SKEY option is used for user-to-user 3969 authentication, this addional ticket MAY be a TGT issued by the 3970 local realm or an inter-realm TGT issued for the current KDC's 3971 realm by a remote KDC. If more than one option which requires 3973 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 3975 additional tickets has been specified, then the additional tickets 3976 are used in the order specified by the ordering of the options 3977 bits (see kdc-options, above). 3979 The application tag number will be either ten (10) or twelve (12) 3980 depending on whether the request is for an initial ticket (AS-REQ) or 3981 for an additional ticket (TGS-REQ). 3983 The optional fields (addresses, authorization-data and additional- 3984 tickets) are only included if necessary to perform the operation 3985 specified in the kdc-options field. 3987 It should be noted that in KRB_TGS_REQ, the protocol version number 3988 appears twice and two different message types appear: the KRB_TGS_REQ 3989 message contains these fields as does the authentication header 3990 (KRB_AP_REQ) that is passed in the padata field. 3992 5.4.2. KRB_KDC_REP definition 3994 The KRB_KDC_REP message format is used for the reply from the KDC for 3995 either an initial (AS) request or a subsequent (TGS) request. There 3996 is no message type for KRB_KDC_REP. Instead, the type will be either 3997 KRB_AS_REP or KRB_TGS_REP. The key used to encrypt the ciphertext 3998 part of the reply depends on the message type. For KRB_AS_REP, the 3999 ciphertext is encrypted in the client's secret key, and the client's 4000 key version number is included in the key version number for the 4001 encrypted data. For KRB_TGS_REP, the ciphertext is encrypted in the 4002 sub-session key from the Authenticator, or if absent, the session key 4003 from the ticket-granting ticket used in the request. In that case, 4004 no version number will be present in the EncryptedData sequence. 4006 The KRB_KDC_REP message contains the following fields: 4008 AS-REP ::= [APPLICATION 11] KDC-REP 4010 TGS-REP ::= [APPLICATION 13] KDC-REP 4012 KDC-REP ::= SEQUENCE { 4013 pvno [0] INTEGER (5), 4014 msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --), 4015 padata [2] SEQUENCE OF PA-DATA OPTIONAL 4016 -- NOTE: not empty --, 4017 crealm [3] Realm, 4018 cname [4] PrincipalName, 4019 ticket [5] Ticket, 4020 enc-part [6] EncryptedData 4021 -- EncASRepPart or EncTGSRepPart, 4022 -- as appropriate 4024 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 4026 } 4028 EncASRepPart ::= [APPLICATION 25] EncKDCRepPart 4030 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 4032 EncKDCRepPart ::= SEQUENCE { 4033 key [0] EncryptionKey, 4034 last-req [1] LastReq, 4035 nonce [2] UInt32, 4036 key-expiration [3] KerberosTime OPTIONAL, 4037 flags [4] TicketFlags, 4038 authtime [5] KerberosTime, 4039 starttime [6] KerberosTime OPTIONAL, 4040 endtime [7] KerberosTime, 4041 renew-till [8] KerberosTime OPTIONAL, 4042 srealm [9] Realm, 4043 sname [10] PrincipalName, 4044 caddr [11] HostAddresses OPTIONAL 4045 } 4047 LastReq ::= SEQUENCE OF SEQUENCE { 4048 lr-type [0] Int32, 4049 lr-value [1] KerberosTime 4050 } 4052 pvno and msg-type 4053 These fields are described above in section 5.4.1. msg-type is 4054 either KRB_AS_REP or KRB_TGS_REP. 4056 padata 4057 This field is described in detail in section 5.4.1. One possible 4058 use for this field is to encode an alternate "salt" string to be 4059 used with a string-to-key algorithm. This ability is useful to 4060 ease transitions if a realm name needs to change (e.g. when a 4061 company is acquired); in such a case all existing password-derived 4062 entries in the KDC database would be flagged as needing a special 4063 salt string until the next password change. 4065 crealm, cname, srealm and sname 4066 These fields are the same as those described for the ticket in 4067 section 5.3. 4069 ticket 4070 The newly-issued ticket, from section 5.3. 4072 enc-part 4073 This field is a place holder for the ciphertext and related 4075 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 4077 information that forms the encrypted part of a message. The 4078 description of the encrypted part of the message follows each 4079 appearance of this field. 4081 The key usage value for encrypting this field is 3 in an AS-REP 4082 message, using the client's long-term key or another key selected 4083 via pre-authentication mechanisms. In a TGS-REP message, the key 4084 usage value is 8 if the TGS session key is used, or 9 if a TGS 4085 authenticator subkey is used. 4087 Compatibility note: Some implementations unconditionally send an 4088 encrypted EncTGSRepPart (application tag number 26) in this field 4089 regardless of whether the reply is a AS-REP or a TGS-REP. In the 4090 interests of compatibility, implementors MAY relax the check on 4091 the tag number of the decrypted ENC-PART. 4093 key 4094 This field is the same as described for the ticket in section 5.3. 4096 last-req 4097 This field is returned by the KDC and specifies the time(s) of the 4098 last request by a principal. Depending on what information is 4099 available, this might be the last time that a request for a 4100 ticket-granting ticket was made, or the last time that a request 4101 based on a ticket-granting ticket was successful. It also might 4102 cover all servers for a realm, or just the particular server. Some 4103 implementations MAY display this information to the user to aid in 4104 discovering unauthorized use of one's identity. It is similar in 4105 spirit to the last login time displayed when logging into 4106 timesharing systems. 4108 lr-type 4109 This field indicates how the following lr-value field is to be 4110 interpreted. Negative values indicate that the information 4111 pertains only to the responding server. Non-negative values 4112 pertain to all servers for the realm. 4114 If the lr-type field is zero (0), then no information is 4115 conveyed by the lr-value subfield. If the absolute value of the 4116 lr-type field is one (1), then the lr-value subfield is the 4117 time of last initial request for a TGT. If it is two (2), then 4118 the lr-value subfield is the time of last initial request. If 4119 it is three (3), then the lr-value subfield is the time of 4120 issue for the newest ticket-granting ticket used. If it is four 4121 (4), then the lr-value subfield is the time of the last 4122 renewal. If it is five (5), then the lr-value subfield is the 4123 time of last request (of any type). If it is (6), then the lr- 4124 value subfield is the time when the password will expire. If 4126 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 4128 it is (7), then the lr-value subfield is the time when the 4129 account will expire. 4131 lr-value 4132 This field contains the time of the last request. The time MUST 4133 be interpreted according to the contents of the accompanying 4134 lr-type subfield. 4136 nonce 4137 This field is described above in section 5.4.1. 4139 key-expiration 4140 The key-expiration field is part of the response from the KDC and 4141 specifies the time that the client's secret key is due to expire. 4142 The expiration might be the result of password aging or an account 4143 expiration. If present, it SHOULD be set to the earliest of the 4144 user's key expiration and account expiration. The use of this 4145 field is deprecated and the last-req field SHOULD be used to 4146 convey this information instead. This field will usually be left 4147 out of the TGS reply since the response to the TGS request is 4148 encrypted in a session key and no client information need be 4149 retrieved from the KDC database. It is up to the application 4150 client (usually the login program) to take appropriate action 4151 (such as notifying the user) if the expiration time is imminent. 4153 flags, authtime, starttime, endtime, renew-till and caddr 4154 These fields are duplicates of those found in the encrypted 4155 portion of the attached ticket (see section 5.3), provided so the 4156 client MAY verify they match the intended request and to assist in 4157 proper ticket caching. If the message is of type KRB_TGS_REP, the 4158 caddr field will only be filled in if the request was for a proxy 4159 or forwarded ticket, or if the user is substituting a subset of 4160 the addresses from the ticket-granting ticket. If the client- 4161 requested addresses are not present or not used, then the 4162 addresses contained in the ticket will be the same as those 4163 included in the ticket-granting ticket. 4165 5.5. Client/Server (CS) message specifications 4167 This section specifies the format of the messages used for the 4168 authentication of the client to the application server. 4170 5.5.1. KRB_AP_REQ definition 4172 The KRB_AP_REQ message contains the Kerberos protocol version number, 4173 the message type KRB_AP_REQ, an options field to indicate any options 4174 in use, and the ticket and authenticator themselves. The KRB_AP_REQ 4175 message is often referred to as the 'authentication header'. 4177 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 4179 AP-REQ ::= [APPLICATION 14] SEQUENCE { 4180 pvno [0] INTEGER (5), 4181 msg-type [1] INTEGER (14), 4182 ap-options [2] APOptions, 4183 ticket [3] Ticket, 4184 authenticator [4] EncryptedData -- Authenticator 4185 } 4187 APOptions ::= KerberosFlags 4188 -- reserved(0), 4189 -- use-session-key(1), 4190 -- mutual-required(2) 4192 pvno and msg-type 4193 These fields are described above in section 5.4.1. msg-type is 4194 KRB_AP_REQ. 4196 ap-options 4197 This field appears in the application request (KRB_AP_REQ) and 4198 affects the way the request is processed. It is a bit-field, where 4199 the selected options are indicated by the bit being set (1), and 4200 the unselected options and reserved fields being reset (0). The 4201 encoding of the bits is specified in section 5.2. The meanings of 4202 the options are: 4204 Bit(s) Name Description 4206 0 reserved Reserved for future expansion of this field. 4208 The USE-SESSION-KEY option indicates that the 4209 ticket the client is presenting to a server 4210 1 use-session-key is encrypted in the session key from the 4211 server's ticket-granting ticket. When this 4212 option is not specified, the ticket is 4213 encrypted in the server's secret key. 4215 The MUTUAL-REQUIRED option tells the server 4216 2 mutual-required that the client requires mutual 4217 authentication, and that it must respond with 4218 a KRB_AP_REP message. 4220 3-31 reserved Reserved for future use. 4222 ticket 4223 This field is a ticket authenticating the client to the server. 4225 authenticator 4226 This contains the encrypted authenticator, which includes the 4228 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 4230 client's choice of a subkey. 4232 The encrypted authenticator is included in the AP-REQ; it certifies 4233 to a server that the sender has recent knowledge of the encryption 4234 key in the accompanying ticket, to help the server detect replays. It 4235 also assists in the selection of a "true session key" to use with the 4236 particular session. The DER encoding of the following is encrypted 4237 in the ticket's session key, with a key usage value of 11 in normal 4238 application exchanges, or 7 when used as the PA-TGS-REQ PA-DATA field 4239 of a TGS-REQ exchange (see section 5.4.1): 4241 -- Unencrypted authenticator 4242 Authenticator ::= [APPLICATION 2] SEQUENCE { 4243 authenticator-vno [0] INTEGER (5), 4244 crealm [1] Realm, 4245 cname [2] PrincipalName, 4246 cksum [3] Checksum OPTIONAL, 4247 cusec [4] Microseconds, 4248 ctime [5] KerberosTime, 4249 subkey [6] EncryptionKey OPTIONAL, 4250 seq-number [7] UInt32 OPTIONAL, 4251 authorization-data [8] AuthorizationData OPTIONAL 4252 } 4254 authenticator-vno 4255 This field specifies the version number for the format of the 4256 authenticator. This document specifies version 5. 4258 crealm and cname 4259 These fields are the same as those described for the ticket in 4260 section 5.3. 4262 cksum 4263 This field contains a checksum of the application data that 4264 accompanies the KRB_AP_REQ, computed using a key usage value of 10 4265 in normal application exchanges, or 6 when used in the TGS-REQ PA- 4266 TGS-REQ AP-DATA field. 4268 cusec 4269 This field contains the microsecond part of the client's 4270 timestamp. Its value (before encryption) ranges from 0 to 999999. 4271 It often appears along with ctime. The two fields are used 4272 together to specify a reasonably accurate timestamp. 4274 ctime 4275 This field contains the current time on the client's host. 4277 subkey 4279 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 4281 This field contains the client's choice for an encryption key 4282 which is to be used to protect this specific application session. 4283 Unless an application specifies otherwise, if this field is left 4284 out the session key from the ticket will be used. 4286 seq-number 4287 This optional field includes the initial sequence number to be 4288 used by the KRB_PRIV or KRB_SAFE messages when sequence numbers 4289 are used to detect replays (It may also be used by application 4290 specific messages). When included in the authenticator this field 4291 specifies the initial sequence number for messages from the client 4292 to the server. When included in the AP-REP message, the initial 4293 sequence number is that for messages from the server to the 4294 client. When used in KRB_PRIV or KRB_SAFE messages, it is 4295 incremented by one after each message is sent. Sequence numbers 4296 fall in the range of 0 through 2^32 - 1 and wrap to zero following 4297 the value 2^32 - 1. 4299 For sequence numbers to adequately support the detection of 4300 replays they SHOULD be non-repeating, even across connection 4301 boundaries. The initial sequence number SHOULD be random and 4302 uniformly distributed across the full space of possible sequence 4303 numbers, so that it cannot be guessed by an attacker and so that 4304 it and the successive sequence numbers do not repeat other 4305 sequences. 4307 Implmentation note: historically, some implementations transmit 4308 signed twos-complement numbers for sequence numbers. In the 4309 interests of compatibility, implementations MAY accept the 4310 equivalent negative number where a positive number greater than 4311 2^31 - 1 is expected. 4313 Implementation note: as noted before, some implementations omit 4314 the optional sequence number when its value would be zero. 4315 Implementations MAY accept an omitted sequence number when 4316 expecting a value of zero, and SHOULD NOT transmit an 4317 Authenticator with a initial sequence number of zero. 4319 authorization-data 4320 This field is the same as described for the ticket in section 5.3. 4321 It is optional and will only appear when additional restrictions 4322 are to be placed on the use of a ticket, beyond those carried in 4323 the ticket itself. 4325 5.5.2. KRB_AP_REP definition 4327 The KRB_AP_REP message contains the Kerberos protocol version number, 4328 the message type, and an encrypted time-stamp. The message is sent in 4330 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 4332 response to an application request (KRB_AP_REQ) where the mutual 4333 authentication option has been selected in the ap-options field. 4335 AP-REP ::= [APPLICATION 15] SEQUENCE { 4336 pvno [0] INTEGER (5), 4337 msg-type [1] INTEGER (15), 4338 enc-part [2] EncryptedData -- EncAPRepPart 4339 } 4341 EncAPRepPart ::= [APPLICATION 27] SEQUENCE { 4342 ctime [0] KerberosTime, 4343 cusec [1] Microseconds, 4344 subkey [2] EncryptionKey OPTIONAL, 4345 seq-number [3] UInt32 OPTIONAL 4346 } 4348 The encoded EncAPRepPart is encrypted in the shared session key of 4349 the ticket. The optional subkey field can be used in an application- 4350 arranged negotiation to choose a per association session key. 4352 pvno and msg-type 4353 These fields are described above in section 5.4.1. msg-type is 4354 KRB_AP_REP. 4356 enc-part 4357 This field is described above in section 5.4.2. It is computed 4358 with a key usage value of 12. 4360 ctime 4361 This field contains the current time on the client's host. 4363 cusec 4364 This field contains the microsecond part of the client's 4365 timestamp. 4367 subkey 4368 This field contains an encryption key which is to be used to 4369 protect this specific application session. See section 3.2.6 for 4370 specifics on how this field is used to negotiate a key. Unless an 4371 application specifies otherwise, if this field is left out, the 4372 sub-session key from the authenticator, or if also left out, the 4373 session key from the ticket will be used. 4375 seq-number 4376 This field is described above in section 5.3.2. 4378 5.5.3. Error message reply 4379 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 4381 If an error occurs while processing the application request, the 4382 KRB_ERROR message will be sent in response. See section 5.9.1 for the 4383 format of the error message. The cname and crealm fields MAY be left 4384 out if the server cannot determine their appropriate values from the 4385 corresponding KRB_AP_REQ message. If the authenticator was 4386 decipherable, the ctime and cusec fields will contain the values from 4387 it. 4389 5.6. KRB_SAFE message specification 4391 This section specifies the format of a message that can be used by 4392 either side (client or server) of an application to send a tamper- 4393 proof message to its peer. It presumes that a session key has 4394 previously been exchanged (for example, by using the 4395 KRB_AP_REQ/KRB_AP_REP messages). 4397 5.6.1. KRB_SAFE definition 4399 The KRB_SAFE message contains user data along with a collision-proof 4400 checksum keyed with the last encryption key negotiated via subkeys, 4401 or the session key if no negotiation has occurred. The message fields 4402 are: 4404 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 4405 pvno [0] INTEGER (5), 4406 msg-type [1] INTEGER (20), 4407 safe-body [2] KRB-SAFE-BODY, 4408 cksum [3] Checksum 4409 } 4411 KRB-SAFE-BODY ::= SEQUENCE { 4412 user-data [0] OCTET STRING, 4413 timestamp [1] KerberosTime OPTIONAL, 4414 usec [2] Microseconds OPTIONAL, 4415 seq-number [3] UInt32 OPTIONAL, 4416 s-address [4] HostAddress, 4417 r-address [5] HostAddress OPTIONAL 4418 } 4420 pvno and msg-type 4421 These fields are described above in section 5.4.1. msg-type is 4422 KRB_SAFE. 4424 safe-body 4425 This field is a placeholder for the body of the KRB-SAFE message. 4427 cksum 4428 This field contains the checksum of the application data, computed 4430 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 4432 with a key usage value of 15. 4434 The checksum is computed over the encoding of the KRB-SAFE 4435 sequence. First, the cksum is set to a type zero, zero-length 4436 value and the checksum is computed over the encoding of the KRB- 4437 SAFE sequence, then the checksum is set to the result of that 4438 computation, and finally the KRB-SAFE sequence is encoded again. 4439 This method, while different than the one specified in RFC 1510, 4440 corresponds to existing practice. 4442 user-data 4443 This field is part of the KRB_SAFE and KRB_PRIV messages and 4444 contain the application specific data that is being passed from 4445 the sender to the recipient. 4447 timestamp 4448 This field is part of the KRB_SAFE and KRB_PRIV messages. Its 4449 contents are the current time as known by the sender of the 4450 message. By checking the timestamp, the recipient of the message 4451 is able to make sure that it was recently generated, and is not a 4452 replay. 4454 usec 4455 This field is part of the KRB_SAFE and KRB_PRIV headers. It 4456 contains the microsecond part of the timestamp. 4458 seq-number 4459 This field is described above in section 5.3.2. 4461 s-address 4462 Sender's address. 4464 This field specifies the address in use by the sender of the 4465 message. 4467 r-address 4468 This field specifies the address in use by the recipient of the 4469 message. It MAY be omitted for some uses (such as broadcast 4470 protocols), but the recipient MAY arbitrarily reject such 4471 messages. This field, along with s-address, can be used to help 4472 detect messages which have been incorrectly or maliciously 4473 delivered to the wrong recipient. 4475 5.7. KRB_PRIV message specification 4477 This section specifies the format of a message that can be used by 4478 either side (client or server) of an application to securely and 4479 privately send a message to its peer. It presumes that a session key 4481 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 4483 has previously been exchanged (for example, by using the 4484 KRB_AP_REQ/KRB_AP_REP messages). 4486 5.7.1. KRB_PRIV definition 4488 The KRB_PRIV message contains user data encrypted in the Session Key. 4489 The message fields are: 4491 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 4492 pvno [0] INTEGER (5), 4493 msg-type [1] INTEGER (21), 4494 -- NOTE: there is no [2] tag 4495 enc-part [3] EncryptedData -- EncKrbPrivPart 4496 } 4498 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 4499 user-data [0] OCTET STRING, 4500 timestamp [1] KerberosTime OPTIONAL, 4501 usec [2] Microseconds OPTIONAL, 4502 seq-number [3] UInt32 OPTIONAL, 4503 s-address [4] HostAddress -- sender's addr --, 4504 r-address [5] HostAddress OPTIONAL -- recip's addr 4505 } 4507 pvno and msg-type 4508 These fields are described above in section 5.4.1. msg-type is 4509 KRB_PRIV. 4511 enc-part 4512 This field holds an encoding of the EncKrbPrivPart sequence 4513 encrypted under the session key, with a key usage value of 13. 4514 This encrypted encoding is used for the enc-part field of the KRB- 4515 PRIV message. 4517 user-data, timestamp, usec, s-address and r-address 4518 These fields are described above in section 5.6.1. 4520 seq-number 4521 This field is described above in section 5.3.2. 4523 5.8. KRB_CRED message specification 4525 This section specifies the format of a message that can be used to 4526 send Kerberos credentials from one principal to another. It is 4527 presented here to encourage a common mechanism to be used by 4528 applications when forwarding tickets or providing proxies to 4529 subordinate servers. It presumes that a session key has already been 4530 exchanged perhaps by using the KRB_AP_REQ/KRB_AP_REP messages. 4532 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 4534 5.8.1. KRB_CRED definition 4536 The KRB_CRED message contains a sequence of tickets to be sent and 4537 information needed to use the tickets, including the session key from 4538 each. The information needed to use the tickets is encrypted under 4539 an encryption key previously exchanged or transferred alongside the 4540 KRB_CRED message. The message fields are: 4542 KRB-CRED ::= [APPLICATION 22] SEQUENCE { 4543 pvno [0] INTEGER (5), 4544 msg-type [1] INTEGER (22), 4545 tickets [2] SEQUENCE OF Ticket, 4546 enc-part [3] EncryptedData -- EncKrbCredPart 4547 } 4549 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 4550 ticket-info [0] SEQUENCE OF KrbCredInfo, 4551 nonce [1] UInt32 OPTIONAL, 4552 timestamp [2] KerberosTime OPTIONAL, 4553 usec [3] Microseconds OPTIONAL, 4554 s-address [4] HostAddress OPTIONAL, 4555 r-address [5] HostAddress OPTIONAL 4556 } 4558 KrbCredInfo ::= SEQUENCE { 4559 key [0] EncryptionKey, 4560 prealm [1] Realm OPTIONAL, 4561 pname [2] PrincipalName OPTIONAL, 4562 flags [3] TicketFlags OPTIONAL, 4563 authtime [4] KerberosTime OPTIONAL, 4564 starttime [5] KerberosTime OPTIONAL, 4565 endtime [6] KerberosTime OPTIONAL, 4566 renew-till [7] KerberosTime OPTIONAL, 4567 srealm [8] Realm OPTIONAL, 4568 sname [9] PrincipalName OPTIONAL, 4569 caddr [10] HostAddresses OPTIONAL 4570 } 4572 pvno and msg-type 4573 These fields are described above in section 5.4.1. msg-type is 4574 KRB_CRED. 4576 tickets 4577 These are the tickets obtained from the KDC specifically for use 4578 by the intended recipient. Successive tickets are paired with the 4579 corresponding KrbCredInfo sequence from the enc-part of the KRB- 4580 CRED message. 4582 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 4584 enc-part 4585 This field holds an encoding of the EncKrbCredPart sequence 4586 encrypted under the session key shared between the sender and the 4587 intended recipient, with a key usage value of 14. This encrypted 4588 encoding is used for the enc-part field of the KRB-CRED message. 4590 Implementation note: implementations of certain applications, most 4591 notably certain implementations of the Kerberos GSS-API mechanism, 4592 do not separately encrypt the contents of the EncKrbCredPart of 4593 the KRB-CRED message when sending it. In the case of those GSS- 4594 API mechanisms, this is not a security vulnerability, as the 4595 entire KRB-CRED message is itself embedded in an encrypted 4596 message. 4598 nonce 4599 If practical, an application MAY require the inclusion of a nonce 4600 generated by the recipient of the message. If the same value is 4601 included as the nonce in the message, it provides evidence that 4602 the message is fresh and has not been replayed by an attacker. A 4603 nonce MUST NEVER be reused. 4605 timestamp and usec 4606 These fields specify the time that the KRB-CRED message was 4607 generated. The time is used to provide assurance that the message 4608 is fresh. 4610 s-address and r-address 4611 These fields are described above in section 5.6.1. They are used 4612 optionally to provide additional assurance of the integrity of the 4613 KRB-CRED message. 4615 key 4616 This field exists in the corresponding ticket passed by the KRB- 4617 CRED message and is used to pass the session key from the sender 4618 to the intended recipient. The field's encoding is described in 4619 section 5.2.9. 4621 The following fields are optional. If present, they can be associated 4622 with the credentials in the remote ticket file. If left out, then it 4623 is assumed that the recipient of the credentials already knows their 4624 value. 4626 prealm and pname 4627 The name and realm of the delegated principal identity. 4629 flags, authtime, starttime, endtime, renew-till, srealm, sname, and 4630 caddr 4631 These fields contain the values of the corresponding fields from 4633 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 4635 the ticket found in the ticket field. Descriptions of the fields 4636 are identical to the descriptions in the KDC-REP message. 4638 5.9. Error message specification 4640 This section specifies the format for the KRB_ERROR message. The 4641 fields included in the message are intended to return as much 4642 information as possible about an error. It is not expected that all 4643 the information required by the fields will be available for all 4644 types of errors. If the appropriate information is not available when 4645 the message is composed, the corresponding field will be left out of 4646 the message. 4648 Note that since the KRB_ERROR message is not integrity protected, it 4649 is quite possible for an intruder to synthesize or modify such a 4650 message. In particular, this means that the client SHOULD NOT use any 4651 fields in this message for security-critical purposes, such as 4652 setting a system clock or generating a fresh authenticator. The 4653 message can be useful, however, for advising a user on the reason for 4654 some failure. 4656 5.9.1. KRB_ERROR definition 4658 The KRB_ERROR message consists of the following fields: 4660 amKRB-ERROR ::= [APPLICATION 30] SEQUENCE { 4661 pvno [0] INTEGER (5), 4662 msg-type [1] INTEGER (30), 4663 ctime [2] KerberosTime OPTIONAL, 4664 cusec [3] Microseconds OPTIONAL, 4665 stime [4] KerberosTime, 4666 susec [5] Microseconds, 4667 error-code [6] Int32, 4668 crealm [7] Realm OPTIONAL, 4669 cname [8] PrincipalName OPTIONAL, 4670 realm [9] Realm -- service realm --, 4671 sname [10] PrincipalName -- service name --, 4672 e-text [11] KerberosString OPTIONAL, 4673 e-data [12] OCTET STRING OPTIONAL 4674 } 4676 pvno and msg-type 4677 These fields are described above in section 5.4.1. +A msg-type is 4678 KRB_ERROR. 4680 ctime 4681 This field is described above in section 5.4.1. 4683 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 4685 cusec 4686 This field is described above in section 5.5.2. 4688 stime 4689 This field contains the current time on the server. It is of type 4690 KerberosTime. 4692 susec 4693 This field contains the microsecond part of the server's 4694 timestamp. Its value ranges from 0 to 999999. It appears along 4695 with stime. The two fields are used in conjunction to specify a 4696 reasonably accurate timestamp. 4698 error-code 4699 This field contains the error code returned by Kerberos or the 4700 server when a request fails. To interpret the value of this field 4701 see the list of error codes in section 7.5.9. Implementations are 4702 encouraged to provide for national language support in the display 4703 of error messages. 4705 crealm, cname, srealm and sname 4706 These fields are described above in section 5.3. 4708 e-text 4709 This field contains additional text to help explain the error code 4710 associated with the failed request (for example, it might include 4711 a principal name which was unknown). 4713 e-data 4714 This field contains additional data about the error for use by the 4715 application to help it recover from or handle the error. If the 4716 errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will 4717 contain an encoding of a sequence of padata fields, each 4718 corresponding to an acceptable pre-authentication method and 4719 optionally containing data for the method: 4721 METHOD-DATA ::= SEQUENCE OF PA-DATA 4723 For error codes defined in this document other than 4724 KDC_ERR_PREAUTH_REQUIRED, the format and contents of the e-data field 4725 are implementation-defined. Similarly, for future error codes, the 4726 format and contents of the e-data field are implementation-defined 4727 unless specified. Whether defined by the implementation or in a 4728 future document, the e-data field MAY take the form of TYPED-DATA: 4730 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 4731 data-type [0] INTEGER, 4732 data-value [1] OCTET STRING OPTIONAL 4734 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 4736 } 4738 5.10. Application Tag Numbers 4740 The following table lists the application class tag numbers used by 4741 various data types defined in this section. 4743 Tag Number(s) Type Name Comments 4745 0 unused 4747 1 Ticket PDU 4749 2 Authenticator non-PDU 4751 3 EncTicketPart non-PDU 4753 4-9 unused 4755 10 AS-REQ PDU 4757 11 AS-REP PDU 4759 12 TGS-REQ PDU 4761 13 TGS-REP PDU 4763 14 AP-REQ PDU 4765 15 AP-REP PDU 4767 16 RESERVED16 TGT-REQ (for user-to-user) 4769 17 RESERVED17 TGT-REP (for user-to-user) 4771 18-19 unused 4773 20 KRB-SAFE PDU 4775 21 KRB-PRIV PDU 4777 22 KRB-CRED PDU 4779 23-24 unused 4781 25 EncASRepPart non-PDU 4783 26 EncTGSRepPart non-PDU 4785 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 4787 27 EncApRepPart non-PDU 4789 28 EncKrbPrivPart non-PDU 4791 29 EncKrbCredPart non-PDU 4793 30 KRB-ERROR PDU 4795 The ASN.1 types marked as "PDU" (Protocol Data Unit) in the above are 4796 the only ASN.1 types intended as top-level types of the Kerberos 4797 protcol, and are the only types that may be used as elements in 4798 another protocol that makes use of Kerberos. 4800 6. Naming Constraints 4802 6.1. Realm Names 4804 Although realm names are encoded as GeneralStrings and although a 4805 realm can technically select any name it chooses, interoperability 4806 across realm boundaries requires agreement on how realm names are to 4807 be assigned, and what information they imply. 4809 To enforce these conventions, each realm MUST conform to the 4810 conventions itself, and it MUST require that any realms with which 4811 inter-realm keys are shared also conform to the conventions and 4812 require the same from its neighbors. 4814 Kerberos realm names are case sensitive. Realm names that differ only 4815 in the case of the characters are not equivalent. There are presently 4816 three styles of realm names: domain, X500, and other. Examples of 4817 each style follow: 4819 domain: ATHENA.MIT.EDU 4820 X500: C=US/O=OSF 4821 other: NAMETYPE:rest/of.name=without-restrictions 4823 Domain syle realm names MUST look like domain names: they consist of 4824 components separated by periods (.) and they contain neither colons 4825 (:) nor slashes (/). Though domain names themselves are case 4826 insensitive, in order for realms to match, the case must match as 4827 well. When establishing a new realm name based on an internet domain 4828 name it is recommended by convention that the characters be converted 4829 to upper case. 4831 X.500 names contain an equal (=) and cannot contain a colon (:) 4832 before the equal. The realm names for X.500 names will be string 4833 representations of the names with components separated by slashes. 4834 Leading and trailing slashes will not be included. Note that the 4836 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 4838 slash separator is consistent with Kerberos implementations based on 4839 RFC1510, but it is different from the separator recommended in 4840 RFC2253. 4842 Names that fall into the other category MUST begin with a prefix that 4843 contains no equal (=) or period (.) and the prefix MUST be followed 4844 by a colon (:) and the rest of the name. All prefixes must be 4845 assigned before they may be used. Presently none are assigned. 4847 The reserved category includes strings which do not fall into the 4848 first three categories. All names in this category are reserved. It 4849 is unlikely that names will be assigned to this category unless there 4850 is a very strong argument for not using the 'other' category. 4852 These rules guarantee that there will be no conflicts between the 4853 various name styles. The following additional constraints apply to 4854 the assignment of realm names in the domain and X.500 categories: the 4855 name of a realm for the domain or X.500 formats must either be used 4856 by the organization owning (to whom it was assigned) an Internet 4857 domain name or X.500 name, or in the case that no such names are 4858 registered, authority to use a realm name MAY be derived from the 4859 authority of the parent realm. For example, if there is no domain 4860 name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can 4861 authorize the creation of a realm with that name. 4863 This is acceptable because the organization to which the parent is 4864 assigned is presumably the organization authorized to assign names to 4865 its children in the X.500 and domain name systems as well. If the 4866 parent assigns a realm name without also registering it in the domain 4867 name or X.500 hierarchy, it is the parent's responsibility to make 4868 sure that there will not in the future exist a name identical to the 4869 realm name of the child unless it is assigned to the same entity as 4870 the realm name. 4872 6.2. Principal Names 4874 As was the case for realm names, conventions are needed to ensure 4875 that all agree on what information is implied by a principal name. 4876 The name-type field that is part of the principal name indicates the 4877 kind of information implied by the name. The name-type SHOULD be 4878 treated only as a hint to interpreting the meaning of a name. It is 4879 not significant when checking for equivalence. Principal names that 4880 differ only in the name-type identify the same principal. The name 4881 type does not partition the name space. Ignoring the name type, no 4882 two names can be the same (i.e. at least one of the components, or 4883 the realm, MUST be different). The following name types are defined: 4885 name-type value meaning 4887 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 4889 name types 4891 NT-UNKNOWN 0 Name type not known 4892 NT-PRINCIPAL 1 Just the name of the principal as in DCE, or for users 4893 NT-SRV-INST 2 Service and other unique instance (krbtgt) 4894 NT-SRV-HST 3 Service with host name as instance (telnet, rcommands) 4895 NT-SRV-XHST 4 Service with host as remaining components 4896 NT-UID 5 Unique ID 4897 NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] 4898 NT-SMTP-NAME 7 Name in form of SMTP email name (e.g. user@foo.com) 4899 NT-ENTERPRISE 10 Enterprise name - may be mapped to principal name 4901 When a name implies no information other than its uniqueness at a 4902 particular time the name type PRINCIPAL SHOULD be used. The principal 4903 name type SHOULD be used for users, and it might also be used for a 4904 unique server. If the name is a unique machine generated ID that is 4905 guaranteed never to be reassigned then the name type of UID SHOULD be 4906 used (note that it is generally a bad idea to reassign names of any 4907 type since stale entries might remain in access control lists). 4909 If the first component of a name identifies a service and the 4910 remaining components identify an instance of the service in a server 4911 specified manner, then the name type of SRV-INST SHOULD be used. An 4912 example of this name type is the Kerberos ticket-granting service 4913 whose name has a first component of krbtgt and a second component 4914 identifying the realm for which the ticket is valid. 4916 If the first component of a name identifies a service and there is a 4917 single component following the service name identifying the instance 4918 as the host on which the server is running, then the name type SRV- 4919 HST SHOULD be used. This type is typically used for Internet services 4920 such as telnet and the Berkeley R commands. If the separate 4921 components of the host name appear as successive components following 4922 the name of the service, then the name type SRV-XHST SHOULD be used. 4923 This type might be used to identify servers on hosts with X.500 names 4924 where the slash (/) might otherwise be ambiguous. 4926 A name type of NT-X500-PRINCIPAL SHOULD be used when a name from an 4927 X.509 certificate is translated into a Kerberos name. The encoding of 4928 the X.509 name as a Kerberos principal shall conform to the encoding 4929 rules specified in RFC 2253. 4931 A name type of SMTP allows a name to be of a form that resembles a 4932 SMTP email name. This name, including an "@" and a domain name, is 4933 used as the one component of the principal name. 4935 A name type of UNKNOWN SHOULD be used when the form of the name is 4936 not known. When comparing names, a name of type UNKNOWN will match 4938 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 4940 principals authenticated with names of any type. A principal 4941 authenticated with a name of type UNKNOWN, however, will only match 4942 other names of type UNKNOWN. 4944 Names of any type with an initial component of 'krbtgt' are reserved 4945 for the Kerberos ticket granting service. See section 7.5.8 for the 4946 form of such names. 4948 6.2.1. Name of server principals 4950 The principal identifier for a server on a host will generally be 4951 composed of two parts: (1) the realm of the KDC with which the server 4952 is registered, and (2) a two-component name of type NT-SRV-HST if the 4953 host name is an Internet domain name or a multi-component name of 4954 type NT-SRV-XHST if the name of the host is of a form such as X.500 4955 that allows slash (/) separators. The first component of the two- or 4956 multi-component name will identify the service and the latter 4957 components will identify the host. Where the name of the host is not 4958 case sensitive (for example, with Internet domain names) the name of 4959 the host MUST be lower case. If specified by the application protocol 4960 for services such as telnet and the Berkeley R commands which run 4961 with system privileges, the first component MAY be the string 'host' 4962 instead of a service specific identifier. 4964 7. Constants and other defined values 4966 7.1. Host address types 4968 All negative values for the host address type are reserved for local 4969 use. All non-negative values are reserved for officially assigned 4970 type fields and interpretations. 4972 Internet (IPv4) Addresses 4974 Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded 4975 in MSB order. The IPv4 loopback address SHOULD NOT appear in a 4976 Kerberos packet. The type of IPv4 addresses is two (2). 4978 Internet (IPv6) Addresses 4980 IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities, 4981 encoded in MSB order. The type of IPv6 addresses is twenty-four 4982 (24). The following addresses MUST NOT appear in any Kerberos 4983 packet: 4985 * the Unspecified Address 4986 * the Loopback Address 4987 * Link-Local addresses 4989 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 4991 IPv4-mapped IPv6 addresses MUST be represented as addresses of 4992 type 2. 4994 DECnet Phase IV addresses 4996 DECnet Phase IV addresses are 16-bit addresses, encoded in LSB 4997 order. The type of DECnet Phase IV addresses is twelve (12). 4999 Netbios addresses 5001 Netbios addresses are 16-octet addresses typically composed of 1 5002 to 15 alphanumeric characters and padded with the US-ASCII SPC 5003 character (code 32). The 16th octet MUST be the US-ASCII NUL 5004 character (code 0). The type of Netbios addresses is twenty (20). 5006 Directional Addresses 5008 In many environments, including the sender address in KRB_SAFE and 5009 KRB_PRIV messages is undesirable because the addresses may be 5010 changed in transport by network address translators. However, if 5011 these addresses are removed, the messages may be subject to a 5012 reflection attack in which a message is reflected back to its 5013 originator. The directional address type provides a way to avoid 5014 transport addresses and reflection attacks. Directional addresses 5015 are encoded as four byte unsigned integers in network byte order. 5016 If the message is originated by the party sending the original 5017 KRB_AP_REQ message, then an address of 0 SHOULD be used. If the 5018 message is originated by the party to whom that KRB_AP_REQ was 5019 sent, then the address 1 SHOULD be used. Applications involving 5020 multiple parties can specify the use of other addresses. 5022 Directional addresses MUST only be used for the sender address 5023 field in the KRB_SAFE or KRB_PRIV messages. They MUST NOT be used 5024 as a ticket address or in a KRB_AP_REQ message. This address type 5025 SHOULD only be used in situations where the sending party knows 5026 that the receiving party supports the address type. This generally 5027 means that directional addresses may only be used when the 5028 application protocol requires their support. Directional addresses 5029 are type (3). 5031 7.2. KDC messaging - IP Transports 5033 Kerberos defines two IP transport mechanisms for communication 5034 between clients and servers: UDP/IP and TCP/IP. 5036 7.2.1. UDP/IP transport 5038 Kerberos servers (KDCs) supporting IP transports MUST accept UDP 5040 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 5042 requests and SHOULD listen for such requests on port 88 (decimal) 5043 unless specifically configured to listen on an alternative UDP port. 5044 Alternate ports MAY be used when running multiple KDCs for multiple 5045 realms on the same host. 5047 Kerberos clients supporting IP transports SHOULD support the sending 5048 of UDP requests. Clients SHOULD use KDC discovery [7.2.3] to identify 5049 the IP address and port to which they will send their request. 5051 When contacting a KDC for a KRB_KDC_REQ request using UDP/IP 5052 transport, the client shall send a UDP datagram containing only an 5053 encoding of the request to the KDC. The KDC will respond with a reply 5054 datagram containing only an encoding of the reply message (either a 5055 KRB_ERROR or a KRB_KDC_REP) to the sending port at the sender's IP 5056 address. The response to a request made through UDP/IP transport MUST 5057 also use UDP/IP transport. If the response can not be handled using 5058 UDP (for example because it is too large), the KDC MUST return 5059 KRB_ERR_RESPONSE_TOO_BIG, forcing the client to retry the request 5060 using the TCP transport. 5062 7.2.2. TCP/IP transport 5064 Kerberos servers (KDCs) supporting IP transports MUST accept TCP 5065 requests and SHOULD listen for such requests on port 88 (decimal) 5066 unless specifically configured to listen on an alternate TCP port. 5067 Alternate ports MAY be used when running multiple KDCs for multiple 5068 realms on the same host. 5070 Clients MUST support the sending of TCP requests, but MAY choose to 5071 initially try a request using the UDP transport. Clients SHOULD use 5072 KDC discovery [7.2.3] to identify the IP address and port to which 5073 they will send their request. 5075 Implementation note: Some extensions to the Kerberos protocol will 5076 not succeed if any client or KDC not supporting the TCP transport is 5077 involved. Implementations of RFC 1510 were not required to support 5078 TCP/IP transports. 5080 When the KRB_KDC_REQ message is sent to the KDC over a TCP stream, 5081 the response (KRB_KDC_REP or KRB_ERROR message) MUST be returned to 5082 the client on the same TCP stream that was established for the 5083 request. The KDC MAY close the TCP stream after sending a response, 5084 but MAY leave the stream open for a reasonable period of time if it 5085 expects a followup. Care must be taken in managing TCP/IP connections 5086 on the KDC to prevent denial of service attacks based on the number 5087 of open TCP/IP connections. 5089 The client MUST be prepared to have the stream closed by the KDC at 5091 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 5093 anytime after the receipt of a response. A stream closure SHOULD NOT 5094 be treated as a fatal error. Instead, if multiple exchanges are 5095 required (e.g., certain forms of pre-authentication) the client may 5096 need to establish a new connection when it is ready to send 5097 subsequent messages. A client MAY close the stream after receiving a 5098 response, and SHOULD close the stream if it does not expect to send 5099 followup messages. 5101 A client MAY send multiple requests before receiving responses, 5102 though it must be prepared to handle the connection being closed 5103 after the first response. 5105 Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR) 5106 sent over the TCP stream is preceded by the length of the request as 5107 4 octets in network byte order. The high bit of the length is 5108 reserved for future expansion and MUST currently be set to zero. If 5109 a KDC that does not understand how to interpret a set high bit of the 5110 length encoding receives a request with the high order bit of the 5111 length set, it MUST return a KRB-ERROR message with the error 5112 KRB_ERR_FIELD_TOOLONG and MUST close the TCP stream. 5114 If multiple requests are sent over a single TCP connection, and the 5115 KDC sends multiple responses, the KDC is not required to send the 5116 responses in the order of the corresponding requests. This may permit 5117 some implementations to send each response as soon as it is ready 5118 even if earlier requests are still being processed (for example, 5119 waiting for a response from an external device or database). 5121 7.2.3. KDC Discovery on IP Networks 5123 Kerberos client implementations MUST provide a means for the client 5124 to determine the location of the Kerberos Key Distribution Centers 5125 (KDCs). Traditionally, Kerberos implementations have stored such 5126 configuration information in a file on each client machine. 5127 Experience has shown this method of storing configuration information 5128 presents problems with out-of-date information and scaling problems, 5129 especially when using cross-realm authentication. This section 5130 describes a method for using the Domain Name System [RFC 1035] for 5131 storing KDC location information. 5133 7.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names 5135 In Kerberos, realm names are case sensitive. While it is strongly 5136 encouraged that all realm names be all upper case this recommendation 5137 has not been adopted by all sites. Some sites use all lower case 5138 names and other use mixed case. DNS on the other hand is case 5139 insensitive for queries. Since "MYREALM", "myrealm", and "MyRealm" 5140 are all different it is necessary that only one of the possible 5142 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 5144 combinations of upper and lower case characters be used. This 5145 restriction may be lifted in the future as the DNS naming scheme is 5146 expanded to support non-US-ASCII names. 5148 7.2.3.2. Specifying KDC Location information with DNS SRV records 5150 KDC location information is to be stored using the DNS SRV RR [RFC 5151 2052]. The format of this RR is as follows: 5153 Service.Proto.Realm TTL Class SRV Priority Weight Port Target 5155 The Service name for Kerberos is always "_kerberos". 5157 The Proto can be one of "_udp", "_tcp". If these SRV records are to 5158 be used, both "_udp" and "_tcp" records MUST be specified for all KDC 5159 deployments. 5161 The Realm is the Kerberos realm that this record corresponds to. 5163 TTL, Class, SRV, Priority, Weight, and Target have the standard 5164 meaning as defined in RFC 2052. 5166 As per RFC 2052 the Port number used for "_udp" and "_tcp" SRV 5167 records SHOULD be the value assigned to "kerberos" by the Internet 5168 Assigned Number Authority: 88 (decimal) unless the KDC is configured 5169 to listen on an alternate TCP port. 5171 Implementation note: Many existing client implementations do not 5172 support KDC Discovery and are configured to send requests to the IANA 5173 assigned port (88 decimal), so it is strongly recommended that KDCs 5174 be configured to listen on that port. 5176 7.2.3.3. KDC Discovery for Domain Style Realm Names on IP Networks 5178 These are DNS records for a Kerberos realm EXAMPLE.COM. It has two 5179 Kerberos servers, kdc1.example.com and kdc2.example.com. Queries 5180 should be directed to kdc1.example.com first as per the specified 5181 priority. Weights are not used in these sample records. 5183 _kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. 5184 _kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. 5185 _kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. 5186 _kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. 5188 7.3. Name of the TGS 5190 The principal identifier of the ticket-granting service shall be 5191 composed of three parts: (1) the realm of the KDC issuing the TGS 5193 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 5195 ticket (2) a two-part name of type NT-SRV-INST, with the first part 5196 "krbtgt" and the second part the name of the realm which will accept 5197 the ticket-granting ticket. For example, a ticket-granting ticket 5198 issued by the ATHENA.MIT.EDU realm to be used to get tickets from the 5199 ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU" 5200 (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting 5201 ticket issued by the ATHENA.MIT.EDU realm to be used to get tickets 5202 from the MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" 5203 (realm), ("krbtgt", "MIT.EDU") (name). 5205 7.4. OID arc for KerberosV5 5207 This OID MAY be used to identify Kerberos protocol messages 5208 encapsulated in other protocols. It also designates the OID arc for 5209 KerberosV5-related OIDs assigned by future IETF action. 5210 Implementation note:: RFC 1510 had an incorrect value (5) for "dod" 5211 in its OID. 5213 id-krb5 OBJECT IDENTIFIER ::= { 5214 iso(1) identified-organization(3) dod(6) internet(1) 5215 security(5) kerberosV5(2) 5216 } 5218 Assignment of OIDs beneath the id-krb5 arc must be obtained by 5219 contacting krb5-oid-registrar@mit.edu. 5221 7.5. Protocol constants and associated values 5223 The following tables list constants used in the protocol and define 5224 their meanings. Ranges are specified in the "specification" section 5225 that limit the values of constants for which values are defined here. 5226 This allows implementations to make assumptions about the maximum 5227 values that will be received for these constants. Implementation 5228 receiving values outside the range specified in the "specification" 5229 section MAY reject the request, but they MUST recover cleanly. 5231 7.5.1. Key usage numbers 5233 The encryption and checksum specifications in [@KCRYPTO] require as 5234 input a "key usage number", to alter the encryption key used in any 5235 specific message, to make certain types of cryptographic attack more 5236 difficult. These are the key usage values assigned in this document: 5238 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted 5239 with the client key (section 5.2.7.2) 5240 2. AS-REP Ticket and TGS-REP Ticket (includes TGS session 5241 key or application session key), encrypted with the 5242 service key (section 5.3) 5244 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 5246 3. AS-REP encrypted part (includes TGS session key or 5247 application session key), encrypted with the client key 5248 (section 5.4.2) 5249 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with 5250 the TGS session key (section 5.4.1) 5251 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with 5252 the TGS authenticator subkey (section 5.4.1) 5253 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, 5254 keyed with the TGS session key (sections 5.5.1) 5255 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator 5256 (includes TGS authenticator subkey), encrypted with the 5257 TGS session key (section 5.5.1) 5258 8. TGS-REP encrypted part (includes application session 5259 key), encrypted with the TGS session key (section 5260 5.4.2) 5261 9. TGS-REP encrypted part (includes application session 5262 key), encrypted with the TGS authenticator subkey 5263 (section 5.4.2) 5264 10. AP-REQ Authenticator cksum, keyed with the application 5265 session key (section 5.5.1) 5266 11. AP-REQ Authenticator (includes application 5267 authenticator subkey), encrypted with the application 5268 session key (section 5.5.1) 5269 12. AP-REP encrypted part (includes application session 5270 subkey), encrypted with the application session key 5271 (section 5.5.2) 5272 13. KRB-PRIV encrypted part, encrypted with a key chosen by 5273 the application (section 5.7.1) 5274 14. KRB-CRED encrypted part, encrypted with a key chosen by 5275 the application (section 5.8.1) 5276 15. KRB-SAFE cksum, keyed with a key chosen by the 5277 application (section 5.6.1) 5278 19. AD-KDC-ISSUED checksum (ad-checksum in 5.2.6.4) 5279 22-24. Reserved for use in GSSAPI mechanisms derived from RFC 5280 1964. (raeburn/MIT) 5281 16-18,20-21,25-511. Reserved for future use in Kerberos and related 5282 protocols. 5283 512-1023. Reserved for uses internal to a Kerberos 5284 implementation. 5285 1024. Encryption for application use in protocols that 5286 do not specify key usage values 5287 1025. Checksums for application use in protocols that 5288 do not specify key usage values 5289 1026-2047. Reserved for application use. 5291 7.5.2. PreAuthentication Data Types 5292 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 5294 padata and data types padata-type value comment 5296 PA-TGS-REQ 1 5297 PA-ENC-TIMESTAMP 2 5298 PA-PW-SALT 3 5299 [reserved] 4 5300 PA-ENC-UNIX-TIME 5 (deprecated) 5301 PA-SANDIA-SECUREID 6 5302 PA-SESAME 7 5303 PA-OSF-DCE 8 5304 PA-CYBERSAFE-SECUREID 9 5305 PA-AFS3-SALT 10 5306 PA-ETYPE-INFO 11 5307 PA-SAM-CHALLENGE 12 (sam/otp) 5308 PA-SAM-RESPONSE 13 (sam/otp) 5309 PA-PK-AS-REQ 14 (pkinit) 5310 PA-PK-AS-REP 15 (pkinit) 5311 PA-ETYPE-INFO2 19 (replaces pa-etype-info) 5312 PA-USE-SPECIFIED-KVNO 20 5313 PA-SAM-REDIRECT 21 (sam/otp) 5314 PA-GET-FROM-TYPED-DATA 22 (embedded in typed data) 5315 TD-PADATA 22 (embeds padata) 5316 PA-SAM-ETYPE-INFO 23 (sam/otp) 5317 PA-ALT-PRINC 24 (crawdad@fnal.gov) 5318 PA-SAM-CHALLENGE2 30 (kenh@pobox.com) 5319 PA-SAM-RESPONSE2 31 (kenh@pobox.com) 5320 PA-EXTRA-TGT 41 Reserved extra TGT 5321 TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS 5322 TD-KRB-PRINCIPAL 102 PrincipalName 5323 TD-KRB-REALM 103 Realm 5324 TD-TRUSTED-CERTIFIERS 104 from PKINIT 5325 TD-CERTIFICATE-INDEX 105 from PKINIT 5326 TD-APP-DEFINED-ERROR 106 application specific 5327 TD-REQ-NONCE 107 INTEGER 5328 TD-REQ-SEQ 108 INTEGER 5329 PA-PAC-REQUEST 128 (jbrezak@exchange.microsoft.com) 5331 7.5.3. Address Types 5333 Address type value 5335 IPv4 2 5336 Directional 3 5337 ChaosNet 5 5338 XNS 6 5339 ISO 7 5340 DECNET Phase IV 12 5341 AppleTalk DDP 16 5343 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 5345 NetBios 20 5346 IPv6 24 5348 7.5.4. Authorization Data Types 5350 authorization data type ad-type value 5351 AD-IF-RELEVANT 1 5352 AD-INTENDED-FOR-SERVER 2 5353 AD-INTENDED-FOR-APPLICATION-CLASS 3 5354 AD-KDC-ISSUED 4 5355 AD-AND-OR 5 5356 AD-MANDATORY-TICKET-EXTENSIONS 6 5357 AD-IN-TICKET-EXTENSIONS 7 5358 AD-MANDATORY-FOR-KDC 8 5359 reserved values 9-63 5360 OSF-DCE 64 5361 SESAME 65 5362 AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com) 5363 AD-WIN2K-PAC 128 (jbrezak@exchange.microsoft.com) 5365 7.5.5. Transited Encoding Types 5367 transited encoding type tr-type value 5368 DOMAIN-X500-COMPRESS 1 5369 reserved values all others 5371 7.5.6. Protocol Version Number 5373 Label Value Meaning or MIT code 5375 pvno 5 current Kerberos protocol version number 5377 7.5.7. Kerberos Message Types 5379 message types 5381 KRB_AS_REQ 10 Request for initial authentication 5382 KRB_AS_REP 11 Response to KRB_AS_REQ request 5383 KRB_TGS_REQ 12 Request for authentication based on TGT 5384 KRB_TGS_REP 13 Response to KRB_TGS_REQ request 5385 KRB_AP_REQ 14 application request to server 5386 KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL 5387 KRB_RESERVED16 16 Reserved for user-to-user krb_tgt_request 5388 KRB_RESERVED17 17 Reserved for user-to-user krb_tgt_reply 5389 KRB_SAFE 20 Safe (checksummed) application message 5390 KRB_PRIV 21 Private (encrypted) application message 5391 KRB_CRED 22 Private (encrypted) message to forward credentials 5392 KRB_ERROR 30 Error response 5394 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 5396 7.5.8. Name Types 5398 name types 5400 KRB_NT_UNKNOWN 0 Name type not known 5401 KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users 5402 KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) 5403 KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands) 5404 KRB_NT_SRV_XHST 4 Service with host as remaining components 5405 KRB_NT_UID 5 Unique ID 5406 KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] 5407 KRB_NT_SMTP_NAME 7 Name in form of SMTP email name (e.g. user@foo.com) 5408 KRB_NT_ENTERPRISE 10 Enterprise name - may be mapped to principal name 5410 7.5.9. Error Codes 5412 error codes 5414 KDC_ERR_NONE 0 No error 5415 KDC_ERR_NAME_EXP 1 Client's entry in database has expired 5416 KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired 5417 KDC_ERR_BAD_PVNO 3 Requested protocol version number 5418 not supported 5419 KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key 5420 KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key 5421 KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database 5422 KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database 5423 KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database 5424 KDC_ERR_NULL_KEY 9 The client or server has a null key 5425 KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating 5426 KDC_ERR_NEVER_VALID 11 Requested start time is later than end time 5427 KDC_ERR_POLICY 12 KDC policy rejects request 5428 KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option 5429 KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type 5430 KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type 5431 KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type 5432 KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type 5433 KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked 5434 KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked 5435 KDC_ERR_TGT_REVOKED 20 TGT has been revoked 5436 KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later 5437 KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later 5438 KDC_ERR_KEY_EXPIRED 23 Password has expired 5439 - change password to reset 5440 KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid 5441 KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired 5442 KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match 5443 KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user only 5445 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 5447 KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path 5448 KDC_ERR_SVC_UNAVAILABLE 29 A service is not available 5449 KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed 5450 KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired 5451 KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid 5452 KRB_AP_ERR_REPEAT 34 Request is a replay 5453 KRB_AP_ERR_NOT_US 35 The ticket isn't for us 5454 KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match 5455 KRB_AP_ERR_SKEW 37 Clock skew too great 5456 KRB_AP_ERR_BADADDR 38 Incorrect net address 5457 KRB_AP_ERR_BADVERSION 39 Protocol version mismatch 5458 KRB_AP_ERR_MSG_TYPE 40 Invalid msg type 5459 KRB_AP_ERR_MODIFIED 41 Message stream modified 5460 KRB_AP_ERR_BADORDER 42 Message out of order 5461 KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available 5462 KRB_AP_ERR_NOKEY 45 Service key not available 5463 KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed 5464 KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction 5465 KRB_AP_ERR_METHOD 48 Alternative authentication method required 5466 KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message 5467 KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message 5468 KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path 5469 KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP, retry with TCP 5470 KRB_ERR_GENERIC 60 Generic error (description in e-text) 5471 KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation 5472 KDC_ERROR_CLIENT_NOT_TRUSTED 62 Reserved for PKINIT 5473 KDC_ERROR_KDC_NOT_TRUSTED 63 Reserved for PKINIT 5474 KDC_ERROR_INVALID_SIG 64 Reserved for PKINIT 5475 KDC_ERR_KEY_TOO_WEAK 65 Reserved for PKINIT 5476 KDC_ERR_CERTIFICATE_MISMATCH 66 Reserved for PKINIT 5477 KRB_AP_ERR_NO_TGT 67 No TGT available to validate USER-TO-USER 5478 KDC_ERR_WRONG_REALM 68 USER-TO-USER TGT issued different KDC 5479 KRB_AP_ERR_USER_TO_USER_REQUIRED 69 Ticket must be for USER-TO-USER 5480 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 Reserved for PKINIT 5481 KDC_ERR_INVALID_CERTIFICATE 71 Reserved for PKINIT 5482 KDC_ERR_REVOKED_CERTIFICATE 72 Reserved for PKINIT 5483 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 Reserved for PKINIT 5484 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 Reserved for PKINIT 5485 KDC_ERR_CLIENT_NAME_MISMATCH 75 Reserved for PKINIT 5486 KDC_ERR_KDC_NAME_MISMATCH 76 Reserved for PKINIT 5488 8. Interoperability requirements 5490 Version 5 of the Kerberos protocol supports a myriad of options. 5491 Among these are multiple encryption and checksum types, alternative 5492 encoding schemes for the transited field, optional mechanisms for 5493 pre-authentication, the handling of tickets with no addresses, 5494 options for mutual authentication, user to user authentication, 5496 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 5498 support for proxies, forwarding, postdating, and renewing tickets, 5499 the format of realm names, and the handling of authorization data. 5501 In order to ensure the interoperability of realms, it is necessary to 5502 define a minimal configuration which must be supported by all 5503 implementations. This minimal configuration is subject to change as 5504 technology does. For example, if at some later date it is discovered 5505 that one of the required encryption or checksum algorithms is not 5506 secure, it will be replaced. 5508 8.1. Specification 2 5510 This section defines the second specification of these options. 5511 Implementations which are configured in this way can be said to 5512 support Kerberos Version 5 Specification 2 (5.2). Specification 1 5513 (deprecated) may be found in RFC1510. 5515 Transport 5517 TCP/IP and UDP/IP transport MUST be supported by clients and KDCs 5518 claiming conformance to specification 2. 5520 Encryption and checksum methods 5522 The following encryption and checksum mechanisms MUST be 5523 supported. 5525 Encryption: AES256-CTS-HMAC-SHA1-96 5526 Checksums: HMAC-SHA1-96-AES256 5528 Implementations SHOULD support other mechanisms as well, but the 5529 additional mechanisms may only be used when communicating with 5530 principals known to also support them. The mechanisms that SHOULD 5531 be supported are: 5533 Encryption: DES-CBC-MD5, DES3-CBC-SHA1-KD 5534 Checksums: DES-MD5, HMAC-SHA1-DES3-KD 5536 Implementations MAY support other mechanisms as well, but the 5537 additional mechanisms may only be used when communicating with 5538 principals known to also support them. 5540 Implementation note: earlier implementations of Kerberos generate 5541 messages using the CRC-32, RSA-MD5 checksum methods. For 5542 interoperability with these earlier releases implementors MAY 5543 consider supporting these checksum methods but should carefully 5544 analyze the security impplications to limit the situations within 5545 which these methods are accepted. 5547 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 5549 Realm Names 5551 All implementations MUST understand hierarchical realms in both 5552 the Internet Domain and the X.500 style. When a ticket-granting 5553 ticket for an unknown realm is requested, the KDC MUST be able to 5554 determine the names of the intermediate realms between the KDCs 5555 realm and the requested realm. 5557 Transited field encoding 5559 DOMAIN-X500-COMPRESS (described in section 3.3.3.2) MUST be 5560 supported. Alternative encodings MAY be supported, but they may 5561 be used only when that encoding is supported by ALL intermediate 5562 realms. 5564 Pre-authentication methods 5566 The TGS-REQ method MUST be supported. The TGS-REQ method is not 5567 used on the initial request. The PA-ENC-TIMESTAMP method MUST be 5568 supported by clients but whether it is enabled by default MAY be 5569 determined on a realm by realm basis. If not used in the initial 5570 request and the error KDC_ERR_PREAUTH_REQUIRED is returned 5571 specifying PA-ENC-TIMESTAMP as an acceptable method, the client 5572 SHOULD retry the initial request using the PA-ENC-TIMESTAMP pre- 5573 authentication method. Servers need not support the PA-ENC- 5574 TIMESTAMP method, but if not supported the server SHOULD ignore 5575 the presence of PA-ENC-TIMESTAMP pre-authentication in a request. 5577 The ETYPE-INFO2 method MUST be supported; this method is used to 5578 communicate the set of supported encryption types, and 5579 corresponding salt and string to key paramters. The ETYPE-INFO 5580 method SHOULD be supported for interoperability with older 5581 implementation. 5583 Mutual authentication 5585 Mutual authentication (via the KRB_AP_REP message) MUST be 5586 supported. 5588 Ticket addresses and flags 5590 All KDCs MUST pass through tickets that carry no addresses (i.e. 5591 if a TGT contains no addresses, the KDC will return derivative 5592 tickets). Implementations SHOULD default to requesting 5593 addressless tickets as this significantly increases 5594 interoperability with network address translation. In some cases 5595 realms or application servers MAY require that tickets have an 5596 address. 5598 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 5600 Implementations SHOULD accept directional address type for the 5601 KRB_SAFE and KRB_PRIV message and SHOULD include directional 5602 addresses in these messages when other address types are not 5603 available. 5605 Proxies and forwarded tickets MUST be supported. Individual realms 5606 and application servers can set their own policy on when such 5607 tickets will be accepted. 5609 All implementations MUST recognize renewable and postdated 5610 tickets, but need not actually implement them. If these options 5611 are not supported, the starttime and endtime in the ticket shall 5612 specify a ticket's entire useful life. When a postdated ticket is 5613 decoded by a server, all implementations shall make the presence 5614 of the postdated flag visible to the calling server. 5616 User-to-user authentication 5618 Support for user to user authentication (via the ENC-TKT-IN-SKEY 5619 KDC option) MUST be provided by implementations, but individual 5620 realms MAY decide as a matter of policy to reject such requests on 5621 a per-principal or realm-wide basis. 5623 Authorization data 5625 Implementations MUST pass all authorization data subfields from 5626 ticket-granting tickets to any derivative tickets unless directed 5627 to suppress a subfield as part of the definition of that 5628 registered subfield type (it is never incorrect to pass on a 5629 subfield, and no registered subfield types presently specify 5630 suppression at the KDC). 5632 Implementations MUST make the contents of any authorization data 5633 subfields available to the server when a ticket is used. 5634 Implementations are not required to allow clients to specify the 5635 contents of the authorization data fields. 5637 Constant ranges 5639 All protocol constants are constrained to 32 bit (signed) values 5640 unless further constrained by the protocol definition. This limit 5641 is provided to allow implementations to make assumptions about the 5642 maximum values that will be received for these constants. 5643 Implementation receiving values outside this range MAY reject the 5644 request, but they MUST recover cleanly. 5646 8.2. Recommended KDC values 5647 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 5649 Following is a list of recommended values for a KDC configuration. 5651 minimum lifetime 5 minutes 5652 maximum renewable lifetime 1 week 5653 maximum ticket lifetime 1 day 5654 acceptable clock skew 5 minutes 5655 empty addresses Allowed. 5656 proxiable, etc. Allowed. 5658 9. IANA considerations 5660 Section 7 of this document specifies protocol constants and other 5661 defined values required for the interoperability of multiple 5662 implementations. Until otherwise specified in a subsequent RFC, 5663 allocations of additional protocol constants and other defined values 5664 required for extensions to the Kerberos protocol will be administered 5665 by the Kerberos Working Group. 5667 10. Security Considerations 5669 As an authentication service, Kerberos provides a means of verifying 5670 the identity of principals on a network. Kerberos does not, by 5671 itself, provide authorization. Applications should not accept the 5672 issuance of a service ticket by the Kerberos server as granting 5673 authority to use the service, since such applications may become 5674 vulnerable to the bypass of this authorization check in an 5675 environment if they inter-operate with other KDCs or where other 5676 options for application authentication are provided. 5678 Denial of service attacks are not solved with Kerberos. There are 5679 places in the protocols where an intruder can prevent an application 5680 from participating in the proper authentication steps. Because 5681 authentication is a required step for the use of many services, 5682 successful denial of service attacks on a Kerberos server might 5683 result in the denial of other network services that rely on Kerberos 5684 for authentication. Kerberos is vulnerable to many kinds of denial of 5685 service attacks: denial of service attacks on the network which would 5686 prevent clients from contacting the KDC; denial of service attacks on 5687 the domain name system which could prevent a client from finding the 5688 IP address of the Kerberos server; and denial of service attack by 5689 overloading the Kerberos KDC itself with repeated requests. 5691 Interoperability conflicts caused by incompatible character-set usage 5692 (see 5.2.1) can result in denial of service for clients that utilize 5693 character-sets in Kerberos strings other than those stored in the KDC 5694 database. 5696 Authentication servers maintain a database of principals (i.e., users 5698 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 5700 and servers) and their secret keys. The security of the 5701 authentication server machines is critical. The breach of security of 5702 an authentication server will compromise the security of all servers 5703 that rely upon the compromised KDC, and will compromise the 5704 authentication of any principals registered in the realm of the 5705 compromised KDC. 5707 Principals must keep their secret keys secret. If an intruder somehow 5708 steals a principal's key, it will be able to masquerade as that 5709 principal or impersonate any server to the legitimate principal. 5711 Password guessing attacks are not solved by Kerberos. If a user 5712 chooses a poor password, it is possible for an attacker to 5713 successfully mount an off-line dictionary attack by repeatedly 5714 attempting to decrypt, with successive entries from a dictionary, 5715 messages obtained which are encrypted under a key derived from the 5716 user's password. 5718 Unless pre-authentication options are required by the policy of a 5719 realm, the KDC will not know whether a request for authentication 5720 succeeds. An attacker can request a reply with credentials for any 5721 principal. These credentials will likely not be of much use to the 5722 attacker unless it knows the client's secret key, but the 5723 availability of the response encrypted in the client's secret key 5724 provides the attacker with ciphertext that may be used to mount brute 5725 force or dictionary attacks to decrypt the credentials, by guessing 5726 the user's password. For this reason it is strongly encouraged that 5727 Kerberos realms require the use of pre-authentication. Even with pre- 5728 authentication, attackers may try brute force or dictionary attacks 5729 against credentials that are observed by eavesdropping on the 5730 network. 5732 Because a client can request a ticket for any server principal and 5733 can attempt a brute force or dictionary attack against the server 5734 principal's key using that ticket, it is strongly encouraged that 5735 keys be randomly generated (rather than generated from passwords) for 5736 any principals that are usable as the target principal for a 5737 KRB_TGS_REQ or KRB_AS_REQ messages. 5739 Each host on the network must have a clock which is loosely 5740 synchronized to the time of the other hosts; this synchronization is 5741 used to reduce the bookkeeping needs of application servers when they 5742 do replay detection. The degree of "looseness" can be configured on a 5743 per-server basis, but is typically on the order of 5 minutes. If the 5744 clocks are synchronized over the network, the clock synchronization 5745 protocol MUST itself be secured from network attackers. 5747 Principal identifiers must not recycled on a short-term basis. A 5749 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 5751 typical mode of access control will use access control lists (ACLs) 5752 to grant permissions to particular principals. If a stale ACL entry 5753 remains for a deleted principal and the principal identifier is 5754 reused, the new principal will inherit rights specified in the stale 5755 ACL entry. By not reusing principal identifiers, the danger of 5756 inadvertent access is removed. 5758 Proper decryption of an KRB_AS_REP message from the KDC is not 5759 sufficient for the host to verify the identity of the user; the user 5760 and an attacker could cooperate to generate a KRB_AS_REP format 5761 message which decrypts properly but is not from the proper KDC. To 5762 authenticate a user logging on to a local system, the credentials 5763 obtained in the AS exchange may first be used in a TGS exchange to 5764 obtain credentials for a local server. Those credentials must then be 5765 verified by a local server through successful completion of the 5766 Client/Server exchange. 5768 Kerberos credentials contain clear-text information identifying the 5769 principals to which they apply. If privacy of this information is 5770 needed, this exchange should itself be encapsulated in a protocol 5771 providing for confidentiality on the exchange of these credentials. 5773 Applications must take care to protect communications subsequent to 5774 authentication either by using the KRB_PRIV or KRB_SAFE messages as 5775 appropriate, or by applying their own confidentiality or integrity 5776 mechanisms on such communications. Completion of the KRB_AP_REQ and 5777 KRB_AP_REP exchange without subsequent use of confidentiality and 5778 integrity mechanisms provides only for authentication of the parties 5779 to the communication and not confidentiality and integrity of the 5780 subsequent communication. Application applying confidentiality and 5781 protections mechanisms other than KRB_PRIV and KRB_SAFE must make 5782 sure that the authentication step is appropriately linked with the 5783 protected communication channel that is established by the 5784 application. 5786 Unless the application server provides its own suitable means to 5787 protect against replay (for example, a challenge-response sequence 5788 initiated by the server after authentication, or use of a server- 5789 generated encryption subkey), the server must utilize a replay cache 5790 to remember any authenticator presented within the allowable clock 5791 skew. All services sharing a key need to use the same replay cache. 5792 If separate replay caches are used, then and authenticator used with 5793 one such service could later be replayed to a different service with 5794 the same service principal. 5796 If a server loses track of authenticators presented within the 5797 allowable clock skew, it must reject all requests until the clock 5798 skew interval has passed, providing assurance that any lost or 5800 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 5802 replayed authenticators will fall outside the allowable clock skew 5803 and can no longer be successfully replayed. 5805 Implementations of Kerberos should not use untrusted directory 5806 servers to determine the realm of a host. To allow such would allow 5807 the compromise of the directory server to enable an attacker to 5808 direct the client to accept authentication with the wrong principal 5809 (i.e. one with a similar name, but in a realm with which the 5810 legitimate host was not registered). 5812 Implementations of Kerberos must not use DNS to canonicalize the host 5813 components of service principal names. To allow such canonicalization 5814 would allow a compromise of the DNS to result in a client obtaining 5815 credentials and correctly authenticating to the wrong principal. 5816 Though the client will know who it is communicating with, it will not 5817 be the principal with which it intended to communicate. 5819 If the Kerberos server returns a TGT for a 'closer' realm other than 5820 the desired realm, the client may use local policy configuration to 5821 verify that the authentication path used is an acceptable one. 5822 Alternatively, a client may choose its own authentication path, 5823 rather than relying on the Kerberos server to select one. In either 5824 case, any policy or configuration information used to choose or 5825 validate authentication paths, whether by the Kerberos server or 5826 client, must be obtained from a trusted source. 5828 The Kerberos protocol in its basic form does not provide perfect 5829 forward secrecy for communications. If traffic has been recorded by 5830 an eavesdropper, then messages encrypted using the KRB_PRIV message, 5831 or messages encrypted using application specific encryption under 5832 keys exchanged using Kerberos can be decrypted if any of the user's, 5833 application server's, or KDC's key is subsequently discovered. This 5834 is because the session key use to encrypt such messages is 5835 transmitted over the network encrypted in the key of the application 5836 server, and also encrypted under the session key from the user's 5837 ticket-granting ticket when returned to the user in the KRB_TGS_REP 5838 message. The session key from the ticket-granting ticket was sent to 5839 the user in the KRB_AS_REP message encrypted in the user's secret 5840 key, and embedded in the ticket-granting ticket, which was encrypted 5841 in the key of the KDC. Application requiring perfect forward secrecy 5842 must exchange keys through mechanisms that provide such assurance, 5843 but may use Kerberos for authentication of the encrypted channel 5844 established through such other means. 5846 11. Author's Addresses 5848 Clifford Neuman 5850 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 5852 Information Sciences Institute 5853 University of Southern California 5854 4676 Admiralty Way 5855 Marina del Rey, CA 90292, USA 5856 Email: bcn@isi.edu 5858 Tom Yu 5859 Massachusetts Institute of Technology 5860 77 Massachusetts Avenue 5861 Cambridge, MA 02139, USA 5862 Email: tlyu@mit.edu 5864 Sam Hartman 5865 Massachusetts Institute of Technology 5866 77 Massachusetts Avenue 5867 Cambridge, MA 02139, USA 5868 Email: hartmans@mit.edu 5870 Kenneth Raeburn 5871 Massachusetts Institute of Technology 5872 77 Massachusetts Avenue 5873 Cambridge, MA 02139, USA 5874 Email: raeburn@MIT.EDU 5876 12. Acknowledgements 5878 This document is a revision to RFC1510 which was co-authored with 5879 John Kohl. The specification of the Kerberos protocol described in 5880 this document is the result of many years of effort. Over this 5881 period many individuals have contributed to the definition of the 5882 protocol and to the writing of the specification. Unfortunately it is 5883 not possible to list all contributors as authors of this document, 5884 though there are many not listed who are authors in spirit, because 5885 they contributed text for parts of some sections, because they 5886 contributed to the design of parts of the protocol, or because they 5887 contributed significantly to the discussion of the protocol in the 5888 IETF common authentication technology (CAT) and Kerberos working 5889 groups. 5891 Among those contributing to the development and specification of 5892 Kerberos were Jeffrey Altman, John Brezak, Marc Colan, Johan 5893 Danielsson, Don Davis, Doug Engert, Dan Geer, Paul Hill, John Kohl, 5894 Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John Linn, 5895 Ari Medvinsky, Sasha Medvinsky, Steve Miller, Jon Rochlis, Jerome 5896 Saltzer, Jeffrey Schiller, Jennifer Steiner, Ralph Swick, Mike Swift, 5897 Jonathan Trostle, Theodore Ts'o, Brian Tung, Jacques Vidrine, Assar 5898 Westerlund, and Nicolas Williams. Many other members of MIT Project 5900 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 5902 Athena, the MIT networking group, and the Kerberos and CAT working 5903 groups of the IETF contributed but are not listed. 5905 13. REFERENCES 5907 [@KRYPTO] 5908 RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg- 5909 crypto. 5911 [@AES] 5912 RFC-Editor: To be replaced by RFC number for draft-raeburn0krb- 5913 rijndael-krb. 5915 [DGT96] 5916 Don Davis, Daniel Geer, and Theodore Ts'o, "Kerberos With Clocks 5917 Adrift: History, Protocols, and Implementation", USENIX Computing 5918 Systems 9:1 (January 1996). 5920 [DS81] 5921 Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key 5922 Distribution Protocols," Communications of the ACM, Vol. 24(8), 5923 pp. 533-536 (August 1981). 5925 [ISO-646/ECMA-6] 5926 7-bit Coded Character Set 5928 [ISO-2022/ECMA-35] 5929 Character Code Structure and Extension Techniques 5931 [ISO-4873/ECMA-43] 5932 8-bit Coded Character Set Structure and Rules 5934 [KNT94] 5936 John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The 5937 Evolution of the Kerberos Authentication System". In Distributed 5938 Open Systems, pages 78-94. IEEE Computer Society Press, 1994. 5940 [MNSS87] 5941 S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer, 5942 Section E.2.1: Kerberos Authentication and Authorization System, 5943 M.I.T. Project Athena, Cambridge, Massachusetts (December 21, 5944 1987). 5946 [Neu93] 5947 B. Clifford Neuman, "Proxy-Based Authorization and Accounting for 5948 Distributed Systems," in Proceedings of the 13th International 5949 Conference on Distributed Computing Systems, Pittsburgh, PA (May, 5951 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 5953 1993). 5955 [NS78] 5956 Roger M. Needham and Michael D. Schroeder, "Using Encryption for 5957 Authentication in Large Networks of Computers," Communications of 5958 the ACM, Vol. 21(12), pp. 993-999 (December, 1978). 5960 [NT94] 5961 B. Clifford Neuman and Theodore Y. Ts'o, "An Authentication 5962 Service for Computer Networks," IEEE Communications Magazine, Vol. 5963 32(9), pp. 33-38 (September 1994). 5965 [Pat92]. 5966 J. Pato, Using Pre-Authentication to Avoid Password Guessing 5967 Attacks, Open Software Foundation DCE Request for Comments 26 5968 (December 1992). 5970 [RFC1035] 5971 P.V. Mockapetris, RFC1035: "Domain Names - Implementations and 5972 Specification," November 1, 1987, Obsoletes - RFC973, RFC882, 5973 RFC883. Updated by RFC1101, RFC1183, RFC1348, RFCRFC1876, RFC1982, 5974 RFC1995, RFC1996, RFC2065, RFC2136, RFC2137, RFC2181, RFC2308, 5975 RFC2535, RFC2845, and RFC3425. Status: Standard. 5977 [RFC1510] 5978 J. Kohl and B. C. Neuman, RFC1510: "The Kerberos Network 5979 Authentication Service (v5)," September 1993, Status: Proposed 5980 Standard. 5982 [RFC1750] 5983 D. Eastlake, S. Crocker, and J. Schiller "Randomness 5984 Recommendation for Security" December 1994, Status: Informational. 5986 [RFC2026] 5987 S. Bradner, RFC2026: "The Internet Standard Process - Revision 5988 3," October 1996, Obsoletes - RFC 1602, Status: Best Current 5989 Practice. 5991 [RFC2052] 5992 A. Gulbrandsen and P. Vixie, RFC2052: "A DNS RR for Specifying the 5993 Location of Services (DNS SRV)," October 1996, Obseleted by 5994 RFC2782, Status: Experimental 5996 [RFC2253] 5997 M. Wahl, S. Killie, and T. Howes, RFC2253: "Lightweight Directory 5998 Access Protocol (v3): UTF-8 String Representation or Distinguished 5999 Names," December 1997, Obsoletes - RFC1779, Updated by RFC3377, 6000 Status: Proposed Standard. 6002 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 6004 [RFC2273] 6005 D. Levi, P. Meyer, and B. Stewart, RFC2273: "SNMPv3 Applications," 6006 January 1998, Obsoletes - RFC2263, Obsoleted by RFC2573, Status: 6007 Proposed Standard. 6009 [RFC2373] 6010 R. Hinden, S. Deering, RFC2373: "IP Version 6 Addressing 6011 Architecture," July 1998, Status: Proposed Standard. 6013 [SNS88] 6014 J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Kerberos: An 6015 Authentication Service for Open Network Systems," pp. 191-202 in 6016 Usenix Conference Proceedings, Dallas, Texas (February, 1988). 6018 [X680] 6019 Abstract Syntax Notation One (ASN.1): Specification of Basic 6020 Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC 6021 International Standard 8824-1:1998. 6023 [X690] 6024 ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), 6025 Canonical Encoding Rules (CER) and Distinguished Encoding Rules 6026 (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International 6027 Standard 8825-1:1998. 6029 A. ASN.1 module 6031 KerberosV5Spec2 { 6032 iso(1) identified-organization(3) dod(6) internet(1) 6033 security(5) kerberosV5(2) modules(4) krb5spec2(2) 6034 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 6036 -- OID arc for KerberosV5 6037 -- 6038 -- This OID may be used to identify Kerberos protocol messages 6039 -- encapsulated in other protocols. 6040 -- 6041 -- This OID also designates the OID arc for KerberosV5-related OIDs. 6042 -- 6043 -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its OID. 6044 id-krb5 OBJECT IDENTIFIER ::= { 6045 iso(1) identified-organization(3) dod(6) internet(1) 6046 security(5) kerberosV5(2) 6047 } 6049 Int32 ::= INTEGER (-2147483648..2147483647) 6050 -- signed values representable in 32 bits 6052 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 6054 UInt32 ::= INTEGER (0..4294967295) 6055 -- unsigned 32 bit values 6057 Microseconds ::= INTEGER (0..999999) 6058 -- microseconds 6060 KerberosString ::= GeneralString (IA5String) 6062 Realm ::= KerberosString 6064 PrincipalName ::= SEQUENCE { 6065 name-type [0] Int32, 6066 name-string [1] SEQUENCE OF KerberosString 6067 } 6069 KerberosTime ::= GeneralizedTime -- with no fractional seconds 6071 HostAddress ::= SEQUENCE { 6072 addr-type [0] Int32, 6073 address [1] OCTET STRING 6074 } 6076 -- NOTE: HostAddresses is always used as an OPTIONAL field and 6077 -- should not be empty. 6078 HostAddresses -- NOTE: subtly different from rfc1510, 6079 -- but has a value mapping and encodes the same 6080 ::= SEQUENCE OF HostAddress 6082 -- NOTE: AuthorizationData is always used as an OPTIONAL field and 6083 -- should not be empty. 6084 AuthorizationData ::= SEQUENCE OF SEQUENCE { 6085 ad-type [0] Int32, 6086 ad-data [1] OCTET STRING 6087 } 6089 PA-DATA ::= SEQUENCE { 6090 -- NOTE: first tag is [1], not [0] 6091 padata-type [1] Int32, 6092 padata-value [2] OCTET STRING -- might be encoded AP-REQ 6093 } 6095 KerberosFlags ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits 6096 -- shall be sent, but no fewer than 32 6098 EncryptedData ::= SEQUENCE { 6099 etype [0] Int32 -- EncryptionType --, 6100 kvno [1] UInt32 OPTIONAL, 6101 cipher [2] OCTET STRING -- ciphertext 6103 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 6105 } 6107 EncryptionKey ::= SEQUENCE { 6108 keytype [0] Int32 -- actually encryption type --, 6109 keyvalue [1] OCTET STRING 6110 } 6112 Checksum ::= SEQUENCE { 6113 cksumtype [0] Int32, 6114 checksum [1] OCTET STRING 6115 } 6117 Ticket ::= [APPLICATION 1] SEQUENCE { 6118 tkt-vno [0] INTEGER (5), 6119 realm [1] Realm, 6120 sname [2] PrincipalName, 6121 enc-part [3] EncryptedData -- EncTicketPart 6122 } 6124 -- Encrypted part of ticket 6125 EncTicketPart ::= [APPLICATION 3] SEQUENCE { 6126 flags [0] TicketFlags, 6127 key [1] EncryptionKey, 6128 crealm [2] Realm, 6129 cname [3] PrincipalName, 6130 transited [4] TransitedEncoding, 6131 authtime [5] KerberosTime, 6132 starttime [6] KerberosTime OPTIONAL, 6133 endtime [7] KerberosTime, 6134 renew-till [8] KerberosTime OPTIONAL, 6135 caddr [9] HostAddresses OPTIONAL, 6136 authorization-data [10] AuthorizationData OPTIONAL 6137 } 6139 -- encoded Transited field 6140 TransitedEncoding ::= SEQUENCE { 6141 tr-type [0] Int32 -- must be registered --, 6142 contents [1] OCTET STRING 6143 } 6145 TicketFlags ::= KerberosFlags 6146 -- reserved(0), 6147 -- forwardable(1), 6148 -- forwarded(2), 6149 -- proxiable(3), 6150 -- proxy(4), 6151 -- may-postdate(5), 6152 -- postdated(6), 6154 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 6156 -- invalid(7), 6157 -- renewable(8), 6158 -- initial(9), 6159 -- pre-authent(10), 6160 -- hw-authent(11), 6161 -- the following are new since 1510 6162 -- transited-policy-checked(12), 6163 -- ok-as-delegate(13) 6165 AS-REQ ::= [APPLICATION 10] KDC-REQ 6167 TGS-REQ ::= [APPLICATION 12] KDC-REQ 6169 KDC-REQ ::= SEQUENCE { 6170 -- NOTE: first tag is [1], not [0] 6171 pvno [1] INTEGER (5) , 6172 msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --), 6173 padata [3] SEQUENCE OF PA-DATA OPTIONAL 6174 -- NOTE: not empty --, 6175 req-body [4] KDC-REQ-BODY 6176 } 6178 KDC-REQ-BODY ::= SEQUENCE { 6179 kdc-options [0] KDCOptions, 6180 cname [1] PrincipalName OPTIONAL 6181 -- Used only in AS-REQ --, 6182 realm [2] Realm 6183 -- Server's realm 6184 -- Also client's in AS-REQ --, 6185 sname [3] PrincipalName OPTIONAL, 6186 from [4] KerberosTime OPTIONAL, 6187 till [5] KerberosTime, 6188 rtime [6] KerberosTime OPTIONAL, 6189 nonce [7] UInt32, 6190 etype [8] SEQUENCE OF Int32 -- EncryptionType 6191 -- in preference order --, 6192 addresses [9] HostAddresses OPTIONAL, 6193 enc-authorization-data [10] EncryptedData -- AuthorizationData --, 6194 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 6195 -- NOTE: not empty 6196 } 6198 KDCOptions ::= KerberosFlags 6199 -- reserved(0), 6200 -- forwardable(1), 6201 -- forwarded(2), 6202 -- proxiable(3), 6203 -- proxy(4), 6205 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 6207 -- allow-postdate(5), 6208 -- postdated(6), 6209 -- unused7(7), 6210 -- renewable(8), 6211 -- unused9(9), 6212 -- unused10(10), 6213 -- opt-hardware-auth(11), 6214 -- unused12(12), 6215 -- unused13(13), 6216 -- 15 is reserved for canonicalize 6217 -- unused15(15), 6218 -- 26 was unused in 1510 6219 -- disable-transited-check(26), 6220 -- 6221 -- renewable-ok(27), 6222 -- enc-tkt-in-skey(28), 6223 -- renew(30), 6224 -- validate(31) 6226 AS-REP ::= [APPLICATION 11] KDC-REP 6228 TGS-REP ::= [APPLICATION 13] KDC-REP 6230 KDC-REP ::= SEQUENCE { 6231 pvno [0] INTEGER (5), 6232 msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --), 6233 padata [2] SEQUENCE OF PA-DATA OPTIONAL 6234 -- NOTE: not empty --, 6235 crealm [3] Realm, 6236 cname [4] PrincipalName, 6237 ticket [5] Ticket, 6238 enc-part [6] EncryptedData 6239 -- EncASRepPart or EncTGSRepPart, 6240 -- as appropriate 6241 } 6243 EncASRepPart ::= [APPLICATION 25] EncKDCRepPart 6245 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 6247 EncKDCRepPart ::= SEQUENCE { 6248 key [0] EncryptionKey, 6249 last-req [1] LastReq, 6250 nonce [2] UInt32, 6251 key-expiration [3] KerberosTime OPTIONAL, 6252 flags [4] TicketFlags, 6253 authtime [5] KerberosTime, 6254 starttime [6] KerberosTime OPTIONAL, 6256 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 6258 endtime [7] KerberosTime, 6259 renew-till [8] KerberosTime OPTIONAL, 6260 srealm [9] Realm, 6261 sname [10] PrincipalName, 6262 caddr [11] HostAddresses OPTIONAL 6263 } 6265 LastReq ::= SEQUENCE OF SEQUENCE { 6266 lr-type [0] Int32, 6267 lr-value [1] KerberosTime 6268 } 6270 AP-REQ ::= [APPLICATION 14] SEQUENCE { 6271 pvno [0] INTEGER (5), 6272 msg-type [1] INTEGER (14), 6273 ap-options [2] APOptions, 6274 ticket [3] Ticket, 6275 authenticator [4] EncryptedData -- Authenticator 6276 } 6278 APOptions ::= KerberosFlags 6279 -- reserved(0), 6280 -- use-session-key(1), 6281 -- mutual-required(2) 6283 -- Unencrypted authenticator 6284 Authenticator ::= [APPLICATION 2] SEQUENCE { 6285 authenticator-vno [0] INTEGER (5), 6286 crealm [1] Realm, 6287 cname [2] PrincipalName, 6288 cksum [3] Checksum OPTIONAL, 6289 cusec [4] Microseconds, 6290 ctime [5] KerberosTime, 6291 subkey [6] EncryptionKey OPTIONAL, 6292 seq-number [7] UInt32 OPTIONAL, 6293 authorization-data [8] AuthorizationData OPTIONAL 6294 } 6296 AP-REP ::= [APPLICATION 15] SEQUENCE { 6297 pvno [0] INTEGER (5), 6298 msg-type [1] INTEGER (15), 6299 enc-part [2] EncryptedData -- EncAPRepPart 6300 } 6302 EncAPRepPart ::= [APPLICATION 27] SEQUENCE { 6303 ctime [0] KerberosTime, 6304 cusec [1] Microseconds, 6305 subkey [2] EncryptionKey OPTIONAL, 6307 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 6309 seq-number [3] UInt32 OPTIONAL 6310 } 6312 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 6313 pvno [0] INTEGER (5), 6314 msg-type [1] INTEGER (20), 6315 safe-body [2] KRB-SAFE-BODY, 6316 cksum [3] Checksum 6317 } 6319 KRB-SAFE-BODY ::= SEQUENCE { 6320 user-data [0] OCTET STRING, 6321 timestamp [1] KerberosTime OPTIONAL, 6322 usec [2] Microseconds OPTIONAL, 6323 seq-number [3] UInt32 OPTIONAL, 6324 s-address [4] HostAddress, 6325 r-address [5] HostAddress OPTIONAL 6326 } 6328 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 6329 pvno [0] INTEGER (5), 6330 msg-type [1] INTEGER (21), 6331 -- NOTE: there is no [2] tag 6332 enc-part [3] EncryptedData -- EncKrbPrivPart 6333 } 6335 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 6336 user-data [0] OCTET STRING, 6337 timestamp [1] KerberosTime OPTIONAL, 6338 usec [2] Microseconds OPTIONAL, 6339 seq-number [3] UInt32 OPTIONAL, 6340 s-address [4] HostAddress -- sender's addr --, 6341 r-address [5] HostAddress OPTIONAL -- recip's addr 6342 } 6344 KRB-CRED ::= [APPLICATION 22] SEQUENCE { 6345 pvno [0] INTEGER (5), 6346 msg-type [1] INTEGER (22), 6347 tickets [2] SEQUENCE OF Ticket, 6348 enc-part [3] EncryptedData -- EncKrbCredPart 6349 } 6351 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 6352 ticket-info [0] SEQUENCE OF KrbCredInfo, 6353 nonce [1] UInt32 OPTIONAL, 6354 timestamp [2] KerberosTime OPTIONAL, 6355 usec [3] Microseconds OPTIONAL, 6356 s-address [4] HostAddress OPTIONAL, 6358 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 6360 r-address [5] HostAddress OPTIONAL 6361 } 6363 KrbCredInfo ::= SEQUENCE { 6364 key [0] EncryptionKey, 6365 prealm [1] Realm OPTIONAL, 6366 pname [2] PrincipalName OPTIONAL, 6367 flags [3] TicketFlags OPTIONAL, 6368 authtime [4] KerberosTime OPTIONAL, 6369 starttime [5] KerberosTime OPTIONAL, 6370 endtime [6] KerberosTime OPTIONAL, 6371 renew-till [7] KerberosTime OPTIONAL, 6372 srealm [8] Realm OPTIONAL, 6373 sname [9] PrincipalName OPTIONAL, 6374 caddr [10] HostAddresses OPTIONAL 6375 } 6377 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 6378 pvno [0] INTEGER (5), 6379 msg-type [1] INTEGER (30), 6380 ctime [2] KerberosTime OPTIONAL, 6381 cusec [3] Microseconds OPTIONAL, 6382 stime [4] KerberosTime, 6383 susec [5] Microseconds, 6384 error-code [6] Int32, 6385 crealm [7] Realm OPTIONAL, 6386 cname [8] PrincipalName OPTIONAL, 6387 realm [9] Realm -- service realm --, 6388 sname [10] PrincipalName -- service name --, 6389 e-text [11] KerberosString OPTIONAL, 6390 e-data [12] OCTET STRING OPTIONAL 6391 } 6393 METHOD-DATA ::= SEQUENCE OF PA-DATA 6395 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 6396 data-type [0] INTEGER, 6397 data-value [1] OCTET STRING OPTIONAL 6398 } 6400 -- preauth stuff follows 6402 PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC 6404 PA-ENC-TS-ENC ::= SEQUENCE { 6405 patimestamp [0] KerberosTime -- client's time --, 6406 pausec [1] Microseconds OPTIONAL 6407 } 6409 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 6411 ETYPE-INFO-ENTRY ::= SEQUENCE { 6412 etype [0] Int32, 6413 salt [1] OCTET STRING OPTIONAL 6414 } 6416 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY 6418 ETYPE-INFO2-ENTRY ::= SEQUENCE { 6419 etype [0] Int32, 6420 salt [1] KerberosString OPTIONAL, 6421 s2kparams [2] OCTET STRING OPTIONAL 6422 } 6424 ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY 6426 AD-IF-RELEVANT ::= AuthorizationData 6428 AD-KDCIssued ::= SEQUENCE { 6429 ad-checksum [0] Checksum, 6430 i-realm [1] Realm OPTIONAL, 6431 i-sname [2] PrincipalName OPTIONAL, 6432 elements [3] AuthorizationData 6433 } 6435 AD-AND-OR ::= SEQUENCE { 6436 condition-count [0] INTEGER, 6437 elements [1] AuthorizationData 6438 } 6440 AD-MANDATORY-FOR-KDC ::= AuthorizationData 6442 END 6444 B. Changes since RFC-1510 6446 This document replaces RFC-1510 and clarifies specification of items 6447 that were not completely specified. Where changes to recommended 6448 implementation choices were made, or where new options were added, 6449 those changes are described within the document and listed in this 6450 section. More significantly, "Specification 2" in section 8 changes 6451 the required encryption and checksum methods to bring them in line 6452 with the best current practices and to deprecate methods that are no 6453 longer considered sufficiently strong. 6455 Discussion was added to section 1 regarding the ability to rely on 6456 the KDC to check the transited field, and on the inclusion of a flag 6457 in a ticket indicating that this check has occurred. This is a new 6458 capability not present in RFC1510. Pre-existing implementations may 6460 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 6462 ignore or not set this flag without negative security implications. 6464 The definition of the secret key says that in the case of a user the 6465 key may be derived from a password. In 1510, it said that the key was 6466 derived from the password. This change was made to accommodate 6467 situations where the user key might be stored on a smart-card, or 6468 otherwise obtained independent of a password. 6470 The introduction mentions the use of public key cryptography for 6471 initial authentication in Kerberos by reference. RFC1510 did not 6472 include such a reference. 6474 Section 1.2 was added to explain that while Kerberos provides 6475 authentication of a named principal, it is still the responsibility 6476 of the application to ensure that the authenticated name is the 6477 entity with which the application wishes to communicate. 6479 Discussion of extensibility has been added to the introduction. 6481 Discussion of how extensibility affects ticket flags and KDC options 6482 was added to the introduction of section 2. No changes were made to 6483 existing options and flags specified in RFC1510, though some of the 6484 sections in the specification were renumbered, and text was revised 6485 to make the description and intent of existing options clearer, 6486 especially with respect to the ENC-TKT-IN-SKEY option (now section 6487 2.9.2) which is used for user-to-user authentication. The new option 6488 and ticket flag transited policy checking (section 2.7) was added. 6490 A warning regarding generation of session keys for application use 6491 was added to section 3, urging the inclusion of key entropy from the 6492 KDC generated session key in the ticket. An example regarding use of 6493 the sub-session key was added to section 3.2.6. Descriptions of the 6494 pa-etype-info, pa-etype-info2, and pa-pw-salt pre-authentication data 6495 items were added. The recommendation for use of pre-authentication 6496 was changed from "may" to "should" and a note was added regarding 6497 known plaintext attacks. 6499 In RFC 1510, section 4 described the database in the KDC. This 6500 discussion was not necessary for interoperability and unnecessarily 6501 constrained implementation. The old section 4 was removed. 6503 The current section 4 was formerly section 6 on encryption and 6504 checksum specifications. The major part of this section was brought 6505 up to date to support new encryption methods, and move to a separate 6506 document. Those few remaining aspects of the encryption and checksum 6507 specification specific to Kerberos are now specified in section 4. 6509 Significant changes were made to the layout of section 5 to clarify 6511 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 6513 the correct behavior for optional fields. Many of these changes were 6514 made necessary because of improper ASN.1 description in the original 6515 Kerberos specification which left the correct behavior 6516 underspecified. Additionally, the wording in this section was 6517 tightened wherever possible to ensure that implementations conforming 6518 to this specification will be extensible with the addition of new 6519 fields in future specifications. 6521 Text was added describing time_t=0 issues in the ASN.1. Text was also 6522 added, clarifying issues with implementations treating omitted 6523 optional integers as zero. Text was added clarifying behavior for 6524 optional SEQUENCE or SEQUENCE OF that may be empty. Discussion was 6525 added regarding sequence numbers and behavior of some 6526 implementations, including "zero" behavior and negative numbers. A 6527 compatibility note was added regarding the unconditional sending of 6528 EncTGSRepPart regardless of the enclosing reply type. Minor changes 6529 were made to the description of the HostAddresses type. Integer types 6530 were constrained. KerberosString was defined as a (significantly) 6531 constrained GeneralString. KerberosFlags was defined to reflect 6532 existing implementation behavior that departs from the definition in 6533 RFC 1510. The transited-policy-checked(12) and the ok-as-delegate(13) 6534 ticket flags were added. The disable-transited-check(26) KDC option 6535 was added. 6537 Descriptions of commonly implemented PA-DATA were added to section 5. 6538 The description of KRB-SAFE has been updated to note the existing 6539 implementation behavior of double-encoding. 6541 There were two definitions of METHOD-DATA in RFC 1510. The second 6542 one, intended for use with KRB_AP_ERR_METHOD was removed leaving the 6543 SEQUENCE OF PA-DATA definition. 6545 Section 7, naming constraints, from RFC1510 was moved to section 6. 6547 Words were added describing the convention that domain based realm 6548 names for newly created realms should be specified as upper case. 6549 This recommendation does not make lower case realm names illegal. 6550 Words were added highlighting that the slash separated components in 6551 the X500 style of realm names is consistent with existing RFC1510 6552 based implementations, but that it conflicts with the general 6553 recommendation of X.500 name representation specified in RFC2253. 6555 Section 8, network transport, constants and defined values, from 6556 RFC1510 was moved to section 7. Since RFC1510, the definition of the 6557 TCP transport for Kerberos messages was added, and the encryption and 6558 checksum number assignments have been moved into a separate document. 6560 "Specification 2" in section 8 of the current document changes the 6562 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 6564 required encryption and checksum methods to bring them in line with 6565 the best current practices and to deprecate methods that are no 6566 longer considered sufficiently strong. 6568 Two new sections, on IANA considerations and security considerations 6569 were added. 6571 The pseudo-code has been removed from the appendix. The pseudo-code 6572 was sometimes misinterpreted to limit implementation choices and in 6573 RFC 1510, it was not always consistent with the words in the 6574 specification. Effort was made to clear up any ambiguities in the 6575 specification, rather than to rely on the pseudo-code. 6577 An appendix was added containing the complete ASN.1 module drawn from 6578 the discussion in section 5 of the current document. 6580 An appendix was added defining those authorization data elements that 6581 must be understood by all Kerberos implementations. 6583 END NOTES 6585 [TM] Project Athena, Athena, and Kerberos are trademarks of the 6586 Massachusetts Institute of Technology (MIT). No commercial use of 6587 these trademarks may be made without prior written permission of MIT. 6589 [1] Note, however, that many applications use Kerberos' functions 6590 only upon the initiation of a stream-based network connection. Unless 6591 an application subsequently provides integrity protection for the 6592 data stream, the identity verification applies only to the initiation 6593 of the connection, and does not guarantee that subsequent messages on 6594 the connection originate from the same principal. 6596 [2] Secret and private are often used interchangeably in the 6597 literature. In our usage, it takes two (or more) to share a secret, 6598 thus a shared DES key is a secret key. Something is only private when 6599 no one but its owner knows it. Thus, in public key cryptosystems, one 6600 has a public and a private key. 6602 [3] Of course, with appropriate permission the client could arrange 6603 registration of a separately-named principal in a remote realm, and 6604 engage in normal exchanges with that realm's services. However, for 6605 even small numbers of clients this becomes cumbersome, and more 6606 automatic methods as described here are necessary. 6608 [4] Though it is permissible to request or issue tickets with no 6609 network addresses specified. 6611 [5] The password-changing request must not be honored unless the 6613 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 6615 requester can provide the old password (the user's current secret 6616 key). Otherwise, it would be possible for someone to walk up to an 6617 unattended session and change another user's password. 6619 [6] To authenticate a user logging on to a local system, the 6620 credentials obtained in the AS exchange may first be used in a TGS 6621 exchange to obtain credentials for a local server. Those credentials 6622 must then be verified by a local server through successful completion 6623 of the Client/Server exchange. 6625 [7] "Random" means that, among other things, it should be impossible 6626 to guess the next session key based on knowledge of past session 6627 keys. This can only be achieved in a pseudo-random number generator 6628 if it is based on cryptographic principles. It is more desirable to 6629 use a truly random number generator, such as one based on 6630 measurements of random physical phenomena. See [RFC1750] for an in 6631 depth discussion of randomness. 6633 [8] Tickets contain both an encrypted and unencrypted portion, so 6634 cleartext here refers to the entire unit, which can be copied from 6635 one message and replayed in another without any cryptographic skill. 6637 [9] Note that this can make applications based on unreliable 6638 transports difficult to code correctly. If the transport might 6639 deliver duplicated messages, either a new authenticator must be 6640 generated for each retry, or the application server must match 6641 requests and replies and replay the first reply in response to a 6642 detected duplicate. 6644 [10] Note also that the rejection here is restricted to 6645 authenticators from the same principal to the same server. Other 6646 client principals communicating with the same server principal should 6647 not be have their authenticators rejected if the time and microsecond 6648 fields happen to match some other client's authenticator. 6650 [11] If this is not done, an attacker could subvert the 6651 authentication by recording the ticket and authenticator sent over 6652 the network to a server and replaying them following an event that 6653 caused the server to lose track of recently seen authenticators. 6655 [12] In the Kerberos version 4 protocol, the timestamp in the reply 6656 was the client's timestamp plus one. This is not necessary in version 6657 5 because version 5 messages are formatted in such a way that it is 6658 not possible to create the reply by judicious message surgery (even 6659 in encrypted form) without knowledge of the appropriate encryption 6660 keys. 6662 [13] Note that for encrypting the KRB_AP_REP message, the sub-session 6664 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-04.txt DRAFT 6666 key is not used, even if present in the Authenticator. 6668 [14] Implementations of the protocol may provide routines to choose 6669 subkeys based on session keys and random numbers and to generate a 6670 negotiated key to be returned in the KRB_AP_REP message. 6672 [15]This can be accomplished in several ways. It might be known 6673 beforehand (since the realm is part of the principal identifier), it 6674 might be stored in a nameserver, or it might be obtained from a 6675 configuration file. If the realm to be used is obtained from a 6676 nameserver, there is a danger of being spoofed if the nameservice 6677 providing the realm name is not authenticated. This might result in 6678 the use of a realm which has been compromised, and would result in an 6679 attacker's ability to compromise the authentication of the 6680 application server to the client. 6682 [16] If the client selects a sub-session key, care must be taken to 6683 ensure the randomness of the selected sub-session key. One approach 6684 would be to generate a random number and XOR it with the session key 6685 from the ticket-granting ticket.