idnits 2.17.1 draft-ietf-krb-wg-kerberos-clarifications-03.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 == The page length should not exceed 58 lines per page, but there was 132 longer pages, the longest (page 2) being 59 lines 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 259 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** 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 is 8 instances of lines with non-RFC2606-compliant FQDNs in the document. == There is 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 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...' RFC 2119 keyword, line 478: '...ty, applications SHOULD provide securi...' (392 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 4769 has weird spacing: '...ticator non-P...' == Line 4771 has weird spacing: '...ketPart non-P...' == Line 4803 has weird spacing: '...RepPart non-...' == Line 4805 has weird spacing: '...RepPart non-P...' == Line 4807 has weird spacing: '...RepPart non-...' == (2 more instances...) -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: When a client wishes to initiate authentication to a server, it obtains (either through a credentials cache, the AS exchange, or the TGS exchange) a ticket and session key for the desired service. The client MAY re-use any tickets it holds until they expire. To use a ticket the client constructs a new Authenticator from the system time, its name, and optionally an application specific checksum, an initial sequence number to be used in KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in negotiations for a session key unique to this particular session. Authenticators MAY NOT be re-used and 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 -- 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 (March 2, 2003) is 7725 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 1715, but not defined == Missing Reference: 'RFC1964' is mentioned on line 2488, but not defined == Missing Reference: 'ISO-646' is mentioned on line 2591, but not defined == Missing Reference: 'ECMA-6' is mentioned on line 2591, but not defined == Missing Reference: 'ISO-8859' is mentioned on line 2598, but not defined == Missing Reference: '0' is mentioned on line 6451, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 6131, but not defined == Missing Reference: 'APPLICATION 3' is mentioned on line 6139, but not defined == Missing Reference: 'APPLICATION 10' is mentioned on line 6179, but not defined == Missing Reference: 'APPLICATION 12' is mentioned on line 6181, but not defined == Missing Reference: 'APPLICATION 11' is mentioned on line 6240, but not defined == Missing Reference: 'APPLICATION 13' is mentioned on line 6242, but not defined == Missing Reference: 'APPLICATION 25' is mentioned on line 6260, but not defined == Missing Reference: 'APPLICATION 26' is mentioned on line 6262, but not defined == Missing Reference: 'APPLICATION 14' is mentioned on line 6284, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 6298, but not defined == Missing Reference: 'APPLICATION 15' is mentioned on line 6313, but not defined == Missing Reference: 'APPLICATION 27' is mentioned on line 6319, but not defined == Missing Reference: 'APPLICATION 20' is mentioned on line 6326, but not defined == Missing Reference: 'APPLICATION 21' is mentioned on line 6342, but not defined == Missing Reference: 'APPLICATION 28' is mentioned on line 6349, but not defined == Missing Reference: 'APPLICATION 22' is mentioned on line 6361, but not defined == Missing Reference: 'APPLICATION 29' is mentioned on line 6368, but not defined == Missing Reference: 'APPLICATION 30' is mentioned on line 6391, but not defined == Missing Reference: 'RFC 2253' is mentioned on line 5423, but not defined ** Obsolete undefined reference: RFC 2253 (Obsoleted by RFC 4510, RFC 4514) == Missing Reference: 'RFC 1035' is mentioned on line 5151, but not defined == Unused Reference: 'RFC1035' is defined on line 5986, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 6001, but no explicit reference was found in the text == Unused Reference: 'RFC2052' is defined on line 6006, but no explicit reference was found in the text == Unused Reference: 'RFC2253' is defined on line 6011, but no explicit reference was found in the text == Unused Reference: 'RFC2273' is defined on line 6017, but no explicit reference was found in the text == Unused Reference: 'TM' is defined on line 6599, 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 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 (~~), 43 warnings (==), 30 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Clifford Neuman 2 USC-ISI 3 Tom Yu 4 Sam Hartman 5 Ken Raeburn 6 MIT 7 March 2, 2003 8 Expires 2 September, 2003 10 The Kerberos Network Authentication Service (V5) 11 draft-ietf-krb-wg-kerberos-clarifications-03.txt 13 STATUS OF THIS MEMO 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC 2026. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 To learn the current status of any Internet-Draft, please check the 33 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 34 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 35 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 37 The distribution of this memo is unlimited. It is filed as draft- 38 ietf-krb-wg-kerberos-clarifications-03.txt, and expires 2 September 39 2003. Please send comments to: ietf-krb-wg@anl.gov 41 ABSTRACT 43 This document provides an overview and specification of Version 5 of 44 the Kerberos protocol, and updates RFC1510 to clarify aspects of the 45 protocol and its intended use that require more detailed or clearer 46 explanation than was provided in RFC1510. This document is intended 47 to provide a detailed description of the protocol, suitable for 48 implementation, together with descriptions of the appropriate use of 49 protocol messages and fields within those messages. 51 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 53 This document contains a subset of the changes considered and 54 discussed in the Kerberos working group and is intended as an interim 55 description of Kerberos. Additional changes to the Kerberos protocol 56 have been proposed and will appear in a subsequent extensions 57 document. 59 This document is not intended to describe Kerberos to the end user, 60 system administrator, or application developer. Higher level papers 61 describing Version 5 of the Kerberos system [NT94] and documenting 62 version 4 [SNS88], are available elsewhere. 64 OVERVIEW 66 This INTERNET-DRAFT describes the concepts and model upon which the 67 Kerberos network authentication system is based. It also specifies 68 Version 5 of the Kerberos protocol. 70 The motivations, goals, assumptions, and rationale behind most design 71 decisions are treated cursorily; they are more fully described in a 72 paper available in IEEE communications [NT94] and earlier in the 73 Kerberos portion of the Athena Technical Plan [MNSS87]. The protocols 74 have been a proposed standard and are being considered for 75 advancement for draft standard through the IETF standard process. 76 Comments are encouraged on the presentation, but only minor 77 refinements to the protocol as implemented or extensions that fit 78 within current protocol framework will be considered at this time. 80 Requests for addition to an electronic mailing list for discussion of 81 Kerberos, kerberos@MIT.EDU, may be addressed to kerberos- 82 request@MIT.EDU. This mailing list is gatewayed onto the Usenet as 83 the group comp.protocols.kerberos. Requests for further information, 84 including documents and code availability, may be sent to info- 85 kerberos@MIT.EDU. 87 BACKGROUND 89 The Kerberos model is based in part on Needham and Schroeder's 90 trusted third-party authentication protocol [NS78] and on 91 modifications suggested by Denning and Sacco [DS81]. The original 92 design and implementation of Kerberos Versions 1 through 4 was the 93 work of two former Project Athena staff members, Steve Miller of 94 Digital Equipment Corporation and Clifford Neuman (now at the 95 Information Sciences Institute of the University of Southern 96 California), along with Jerome Saltzer, Technical Director of Project 97 Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other 98 members of Project Athena have also contributed to the work on 99 Kerberos. 101 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 103 Version 5 of the Kerberos protocol (described in this document) has 104 evolved from Version 4 based on new requirements and desires for 105 features not available in Version 4. The design of Version 5 of the 106 Kerberos protocol was led by Clifford Neuman and John Kohl with much 107 input from the community. The development of the MIT reference 108 implementation was led at MIT by John Kohl and Theodore Ts'o, with 109 help and contributed code from many others. Since RFC1510 was issued, 110 extensions and revisions to the protocol have been proposed by many 111 individuals. Some of these proposals are reflected in this document. 112 Where such changes involved significant effort, the document cites 113 the contribution of the proposer. 115 Reference implementations of both version 4 and version 5 of Kerberos 116 are publicly available and commercial implementations have been 117 developed and are widely used. Details on the differences between 118 Kerberos Versions 4 and 5 can be found in [KNT94]. 120 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 122 TTaabbllee ooff CCoonntteennttss 124 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 7 125 1.1. Cross-realm operation . . . . . . . . . . . . . . . . . . . . . 9 126 1.2. Choosing a principal with which to communicate . . . . . . . . 10 127 1.3. Authorization . . . . . . . . . . . . . . . . . . . . . . . . . 11 128 1.4. Extending Kerberos Without Breaking Interoperability . . . . . 11 129 1.4.1. Compatibility with RFC 1510 . . . . . . . . . . . . . . . . . 12 130 1.4.2. Sending Extensible Messages . . . . . . . . . . . . . . . . . 13 131 1.5. Environmental assumptions . . . . . . . . . . . . . . . . . . . 13 132 1.6. Glossary of terms . . . . . . . . . . . . . . . . . . . . . . . 14 133 2. Ticket flag uses and requests . . . . . . . . . . . . . . . . . . 16 134 2.1. Initial, pre-authenticated, and hardware authenticated 135 tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 136 2.2. Invalid tickets . . . . . . . . . . . . . . . . . . . . . . . . 17 137 2.3. Renewable tickets . . . . . . . . . . . . . . . . . . . . . . . 18 138 2.4. Postdated tickets . . . . . . . . . . . . . . . . . . . . . . . 18 139 2.5. Proxiable and proxy tickets . . . . . . . . . . . . . . . . . . 19 140 2.6. Forwardable tickets . . . . . . . . . . . . . . . . . . . . . . 20 141 2.7. Transited Policy Checking . . . . . . . . . . . . . . . . . . . 21 142 2.8. OK as Delegate . . . . . . . . . . . . . . . . . . . . . . . . 21 143 2.9. Other KDC options . . . . . . . . . . . . . . . . . . . . . . . 22 144 2.9.1. Renewable-OK . . . . . . . . . . . . . . . . . . . . . . . . 22 145 2.9.2. ENC-TKT-IN-SKEY . . . . . . . . . . . . . . . . . . . . . . . 22 146 2.9.3. Passwordless Hardware Authentication . . . . . . . . . . . . 22 147 3. Message Exchanges . . . . . . . . . . . . . . . . . . . . . . . . 23 148 3.1. The Authentication Service Exchange . . . . . . . . . . . . . . 23 149 3.1.1. Generation of KRB_AS_REQ message . . . . . . . . . . . . . . 24 150 3.1.2. Receipt of KRB_AS_REQ message . . . . . . . . . . . . . . . . 24 151 3.1.3. Generation of KRB_AS_REP message . . . . . . . . . . . . . . 25 152 3.1.4. Generation of KRB_ERROR message . . . . . . . . . . . . . . . 27 153 3.1.5. Receipt of KRB_AS_REP message . . . . . . . . . . . . . . . . 28 154 3.1.6. Receipt of KRB_ERROR message . . . . . . . . . . . . . . . . 29 155 3.2. The Client/Server Authentication Exchange . . . . . . . . . . . 29 156 3.2.1. The KRB_AP_REQ message . . . . . . . . . . . . . . . . . . . 29 157 3.2.2. Generation of a KRB_AP_REQ message . . . . . . . . . . . . . 29 158 3.2.3. Receipt of KRB_AP_REQ message . . . . . . . . . . . . . . . . 30 159 3.2.4. Generation of a KRB_AP_REP message . . . . . . . . . . . . . 32 160 3.2.5. Receipt of KRB_AP_REP message . . . . . . . . . . . . . . . . 33 161 3.2.6. Using the encryption key . . . . . . . . . . . . . . . . . . 33 162 3.3. The Ticket-Granting Service (TGS) Exchange . . . . . . . . . . 34 163 3.3.1. Generation of KRB_TGS_REQ message . . . . . . . . . . . . . . 35 164 3.3.2. Receipt of KRB_TGS_REQ message . . . . . . . . . . . . . . . 37 165 3.3.3. Generation of KRB_TGS_REP message . . . . . . . . . . . . . . 37 166 3.3.3.1. Checking for revoked tickets . . . . . . . . . . . . . . . 40 167 3.3.3.2. Encoding the transited field . . . . . . . . . . . . . . . 40 168 3.3.4. Receipt of KRB_TGS_REP message . . . . . . . . . . . . . . . 42 169 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 171 3.4. The KRB_SAFE Exchange . . . . . . . . . . . . . . . . . . . . . 42 172 3.4.1. Generation of a KRB_SAFE message . . . . . . . . . . . . . . 42 173 3.4.2. Receipt of KRB_SAFE message . . . . . . . . . . . . . . . . . 43 174 3.5. The KRB_PRIV Exchange . . . . . . . . . . . . . . . . . . . . . 44 175 3.5.1. Generation of a KRB_PRIV message . . . . . . . . . . . . . . 44 176 3.5.2. Receipt of KRB_PRIV message . . . . . . . . . . . . . . . . . 44 177 3.6. The KRB_CRED Exchange . . . . . . . . . . . . . . . . . . . . . 45 178 3.6.1. Generation of a KRB_CRED message . . . . . . . . . . . . . . 45 179 3.6.2. Receipt of KRB_CRED message . . . . . . . . . . . . . . . . . 46 180 3.7. User to User Authentication Exchanges . . . . . . . . . . . . . 46 181 4. Encryption and Checksum Specifications . . . . . . . . . . . . . 48 182 5. Message Specifications . . . . . . . . . . . . . . . . . . . . . 49 183 5.1. Specific Compatibility Notes on ASN.1 . . . . . . . . . . . . . 51 184 5.1.1. ASN.1 Distinguished Encoding Rules . . . . . . . . . . . . . 51 185 5.1.2. Optional Integer Fields . . . . . . . . . . . . . . . . . . . 51 186 5.1.3. Empty SEQUENCE OF Types . . . . . . . . . . . . . . . . . . . 51 187 5.1.4. Unrecognized Tag Numbers . . . . . . . . . . . . . . . . . . 52 188 5.1.5. Tag Numbers Greater Than 30 . . . . . . . . . . . . . . . . . 52 189 5.2. Basic Kerberos Types . . . . . . . . . . . . . . . . . . . . . 52 190 5.2.1. KerberosString . . . . . . . . . . . . . . . . . . . . . . . 52 191 5.2.2. Realm and PrincipalName . . . . . . . . . . . . . . . . . . . 54 192 5.2.3. KerberosTime . . . . . . . . . . . . . . . . . . . . . . . . 54 193 5.2.4. Constrained Integer types . . . . . . . . . . . . . . . . . . 55 194 5.2.5. HostAddress and HostAddresses . . . . . . . . . . . . . . . . 55 195 5.2.6. AuthorizationData . . . . . . . . . . . . . . . . . . . . . . 56 196 5.2.6.1. IF-RELEVANT . . . . . . . . . . . . . . . . . . . . . . . . 57 197 5.2.6.2. KDCIssued . . . . . . . . . . . . . . . . . . . . . . . . . 57 198 5.2.6.3. AND-OR . . . . . . . . . . . . . . . . . . . . . . . . . . 59 199 5.2.6.4. MANDATORY-FOR-KDC . . . . . . . . . . . . . . . . . . . . . 59 200 5.2.7. PA-DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 201 5.2.7.1. PA-TGS-REQ . . . . . . . . . . . . . . . . . . . . . . . . 60 202 5.2.7.2. Encrypted Timestamp Pre-authentication . . . . . . . . . . 60 203 5.2.7.3. PA-PW-SALT . . . . . . . . . . . . . . . . . . . . . . . . 61 204 5.2.7.4. PA-ETYPE-INFO . . . . . . . . . . . . . . . . . . . . . . . 61 205 5.2.7.5. PA-ETYPE-INFO2 . . . . . . . . . . . . . . . . . . . . . . 62 206 5.2.8. KerberosFlags . . . . . . . . . . . . . . . . . . . . . . . . 63 207 5.2.9. Cryptosystem-related Types . . . . . . . . . . . . . . . . . 64 208 5.3. Tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 209 5.4. Specifications for the AS and TGS exchanges . . . . . . . . . . 73 210 5.4.1. KRB_KDC_REQ definition . . . . . . . . . . . . . . . . . . . 73 211 5.4.2. KRB_KDC_REP definition . . . . . . . . . . . . . . . . . . . 80 212 5.5. Client/Server (CS) message specifications . . . . . . . . . . . 84 213 5.5.1. KRB_AP_REQ definition . . . . . . . . . . . . . . . . . . . . 84 214 5.5.2. KRB_AP_REP definition . . . . . . . . . . . . . . . . . . . . 87 215 5.5.3. Error message reply . . . . . . . . . . . . . . . . . . . . . 88 216 5.6. KRB_SAFE message specification . . . . . . . . . . . . . . . . 88 217 5.6.1. KRB_SAFE definition . . . . . . . . . . . . . . . . . . . . . 88 218 5.7. KRB_PRIV message specification . . . . . . . . . . . . . . . . 90 219 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 221 5.7.1. KRB_PRIV definition . . . . . . . . . . . . . . . . . . . . . 90 222 5.8. KRB_CRED message specification . . . . . . . . . . . . . . . . 91 223 5.8.1. KRB_CRED definition . . . . . . . . . . . . . . . . . . . . . 91 224 5.9. Error message specification . . . . . . . . . . . . . . . . . . 93 225 5.9.1. KRB_ERROR definition . . . . . . . . . . . . . . . . . . . . 93 226 5.10. Application Tag Numbers . . . . . . . . . . . . . . . . . . . 95 227 6. Naming Constraints . . . . . . . . . . . . . . . . . . . . . . . 96 228 6.1. Realm Names . . . . . . . . . . . . . . . . . . . . . . . . . . 96 229 6.2. Principal Names . . . . . . . . . . . . . . . . . . . . . . . . 98 230 6.2.1. Name of server principals . . . . . . . . . . . . . . . . . . 99 231 7. Constants and other defined values . . . . . . . . . . . . . . . 100 232 7.1. Host address types . . . . . . . . . . . . . . . . . . . . . . 100 233 7.2. KDC messaging - IP Transports . . . . . . . . . . . . . . . . . 101 234 7.2.1. UDP/IP transport . . . . . . . . . . . . . . . . . . . . . . 101 235 7.2.2. TCP/IP transport . . . . . . . . . . . . . . . . . . . . . . 101 236 7.2.3. KDC Discovery on IP Networks . . . . . . . . . . . . . . . . 103 237 7.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names . . . . 103 238 7.2.3.2. Specifying KDC Location information with DNS SRV 239 records . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 240 7.2.3.3. KDC Discovery for Domain Style Realm Names on IP 241 Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 242 7.3. Name of the TGS . . . . . . . . . . . . . . . . . . . . . . . . 104 243 7.4. OID arc for KerberosV5 . . . . . . . . . . . . . . . . . . . . 104 244 7.5. Protocol constants and associated values . . . . . . . . . . . 104 245 7.5.1. Key usage numbers . . . . . . . . . . . . . . . . . . . . . . 105 246 7.5.2. PreAuthentication Data Types . . . . . . . . . . . . . . . . 106 247 7.5.3. Address Types . . . . . . . . . . . . . . . . . . . . . . . . 107 248 7.5.4. Authorization Data Types . . . . . . . . . . . . . . . . . . 107 249 7.5.5. Transited Encoding Types . . . . . . . . . . . . . . . . . . 107 250 7.5.6. Protocol Version Number . . . . . . . . . . . . . . . . . . . 107 251 7.5.7. Kerberos Message Types . . . . . . . . . . . . . . . . . . . 108 252 7.5.8. Name Types . . . . . . . . . . . . . . . . . . . . . . . . . 108 253 7.5.9. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 108 254 8. Interoperability requirements . . . . . . . . . . . . . . . . . . 110 255 8.1. Specification 2 . . . . . . . . . . . . . . . . . . . . . . . . 110 256 8.2. Recommended KDC values . . . . . . . . . . . . . . . . . . . . 113 257 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . . . 113 258 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 113 259 11. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 117 260 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 117 261 13. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 262 A. ASN.1 module . . . . . . . . . . . . . . . . . . . . . . . . . . 120 263 B. Changes since RFC-1510 . . . . . . . . . . . . . . . . . . . . . 129 264 END NOTES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 265 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 267 1. Introduction 269 Kerberos provides a means of verifying the identities of principals, 270 (e.g. a workstation user or a network server) on an open 271 (unprotected) network. This is accomplished without relying on 272 assertions by the host operating system, without basing trust on host 273 addresses, without requiring physical security of all the hosts on 274 the network, and under the assumption that packets traveling along 275 the network can be read, modified, and inserted at will[1]. Kerberos 276 performs authentication under these conditions as a trusted third- 277 party authentication service by using conventional (shared secret key 278 [2]) cryptography. Kerberos extensions (outside the scope of this 279 document) can provide for the use of public key cryptography during 280 certain phases of the authentication protocol [@RFCE: if PKINIT 281 advances concurrently include reference to the RFC here]. Such 282 extensions support Kerberos authentication for users registered with 283 public key certification authorities and provide certain benefits of 284 public key cryptography in situations where they are needed. 286 The basic Kerberos authentication process proceeds as follows: A 287 client sends a request to the authentication server (AS) requesting 288 "credentials" for a given server. The AS responds with these 289 credentials, encrypted in the client's key. The credentials consist 290 of a "ticket" for the server and a temporary encryption key (often 291 called a "session key"). The client transmits the ticket (which 292 contains the client's identity and a copy of the session key, all 293 encrypted in the server's key) to the server. The session key (now 294 shared by the client and server) is used to authenticate the client, 295 and may optionally be used to authenticate the server. It may also be 296 used to encrypt further communication between the two parties or to 297 exchange a separate sub-session key to be used to encrypt further 298 communication. 300 Implementation of the basic protocol consists of one or more 301 authentication servers running on physically secure hosts. The 302 authentication servers maintain a database of principals (i.e., users 303 and servers) and their secret keys. Code libraries provide encryption 304 and implement the Kerberos protocol. In order to add authentication 305 to its transactions, a typical network application adds one or two 306 calls to the Kerberos library directly or through the Generic 307 Security Services Application Programming Interface, GSSAPI, 308 described in separate document [ref to GSSAPI RFC]. These calls 309 result in the transmission of the necessary messages to achieve 310 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 316 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 318 sends a cleartext request for a ticket for the desired server to the 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 367 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 369 copies of the Kerberos database. Neither of these protocols are 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-03.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 encouraged but not required to 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-03.txt DRAFT 471 be required by an KDC implementation. 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-03.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 1.4.1. Compatibility with RFC 1510 533 It is important to note that existing Kerberos message formats can 534 not be readily extended by adding fields to the ASN.1 types. Sending 535 additional fields often results in the entire message being discarded 536 without an error indication. Future versions of this specification 537 will provide guidelines to ensure that ASN.1 fields can be added 538 without creating an interoperability problem. 540 In the meantime, all new or modified implementations of Kerberos that 541 receive an unknown message extension SHOULD preserve the encoding of 542 the extension but otherwise ignore the presence of the extension. 543 Recipients MUST NOT decline a request simply because an extension is 544 present. 546 There is one exception to this rule. If an unknown authorization data 547 element type is received by a server other than the ticket granting 548 service either in an AP-REQ or in a ticket contained in an AP-REQ, 549 then authentication MUST fail. One of the primary uses of 550 authorization data is to restrict the use of the ticket. If the 551 service cannot determine whether the restriction applies to that 552 service then a security weakness may result if the ticket can be used 553 for that service. Authorization elements that are optional SHOULD be 554 enclosed in the AD-IF-RELEVANT element. 556 The ticket granting service MUST ignore but propagate to derivative 557 tickets any unknown authorization data types, unless those data types 558 are embedded in a MANDATORY-FOR-KDC element, in which case the 559 request will be rejected. This behavior is appropriate because 560 requiring that the ticket granting service understand unknown 561 authorization data types would require that KDC software be upgraded 562 to understand new application-level restrictions before applications 563 used these restrictions, decreasing the utility of authorization data 564 as a mechanism for restricting the use of tickets. No security 565 problem is created because services to which the tickets are issued 566 will verify the authorization data. 568 Implementation note: Many RFC 1510 implementations ignore unknown 569 authorization data elements. Depending on these implementations to 571 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 573 honor authorization data restrictions may create a security weakness. 575 1.4.2. Sending Extensible Messages 577 Care must be taken to ensure that old implementations can understand 578 messages sent to them even if they do not understand an extension 579 that is used. Unless the sender knows an extension is supported, the 580 extension cannot change the semantics of the core message or 581 previously defined extensions. 583 For example, an extension including key information necessary to 584 decrypt the encrypted part of a KDC-REP could only be used in 585 situations where the recipient was known to support the extension. 586 Thus when designing such extensions it is important to provide a way 587 for the recipient to notify the sender of support for the extension. 588 For example in the case of an extension that changes the KDC-REP 589 reply key, the client could indicate support for the extension by 590 including a padata element in the AS-REQ sequence. The KDC should 591 only use the extension if this padata element is present in the AS- 592 REQ. Even if policy requires the use of the extension, it is better 593 to return an error indicating that the extension is required than to 594 use the extension when the recipient may not support it; debugging 595 why implementations do not interoperate is easier when errors are 596 returned. 598 1.5. Environmental assumptions 600 Kerberos imposes a few assumptions on the environment in which it can 601 properly function: 603 * "Denial of service" attacks are not solved with Kerberos. There 604 are places in the protocols where an intruder can prevent an 605 application from participating in the proper authentication steps. 606 Detection and solution of such attacks (some of which can appear 607 to be not-uncommon "normal" failure modes for the system) is 608 usually best left to the human administrators and users. 610 * Principals MUST keep their secret keys secret. If an intruder 611 somehow steals a principal's key, it will be able to masquerade as 612 that principal or impersonate any server to the legitimate 613 principal. 615 * "Password guessing" attacks are not solved by Kerberos. If a user 616 chooses a poor password, it is possible for an attacker to 617 successfully mount an offline dictionary attack by repeatedly 618 attempting to decrypt, with successive entries from a dictionary, 619 messages obtained which are encrypted under a key derived from the 620 user's password. 622 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 624 * Each host on the network MUST have a clock which is "loosely 625 synchronized" to the time of the other hosts; this synchronization 626 is used to reduce the bookkeeping needs of application servers 627 when they do replay detection. The degree of "looseness" can be 628 configured on a per-server basis, but is typically on the order of 629 5 minutes. If the clocks are synchronized over the network, the 630 clock synchronization protocol MUST itself be secured from network 631 attackers. 633 * Principal identifiers are not recycled on a short-term basis. A 634 typical mode of access control will use access control lists 635 (ACLs) to grant permissions to particular principals. If a stale 636 ACL entry remains for a deleted principal and the principal 637 identifier is reused, the new principal will inherit rights 638 specified in the stale ACL entry. By not re-using principal 639 identifiers, the danger of inadvertent access is removed. 641 1.6. Glossary of terms 643 Below is a list of terms used throughout this document. 645 Authentication 646 Verifying the claimed identity of a principal. 648 Authentication header 649 A record containing a Ticket and an Authenticator to be presented 650 to a server as part of the authentication process. 652 Authentication path 653 A sequence of intermediate realms transited in the authentication 654 process when communicating from one realm to another. 656 Authenticator 657 A record containing information that can be shown to have been 658 recently generated using the session key known only by the client 659 and server. 661 Authorization 662 The process of determining whether a client may use a service, 663 which objects the client is allowed to access, and the type of 664 access allowed for each. 666 Capability 667 A token that grants the bearer permission to access an object or 668 service. In Kerberos, this might be a ticket whose use is 669 restricted by the contents of the authorization data field, but 670 which lists no network addresses, together with the session key 671 necessary to use the ticket. 673 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 675 Ciphertext 676 The output of an encryption function. Encryption transforms 677 plaintext into ciphertext. 679 Client 680 A process that makes use of a network service on behalf of a user. 681 Note that in some cases a Server may itself be a client of some 682 other server (e.g. a print server may be a client of a file 683 server). 685 Credentials 686 A ticket plus the secret session key necessary to successfully use 687 that ticket in an authentication exchange. 689 Encryption Type (etype) 690 When associated with encrypted data, an encryption type identifies 691 the algorithm used to encrypt the data and is used to select the 692 appropriate algorithm for decrypting the data. Encryption type 693 tags are communicated in other messages to enumerate algorithms 694 that are desired, supported, preferred, or allowed to be used for 695 encryption of data between parties. This preference is combined 696 with local information and policy to select an algorithm to be 697 used. 699 KDC 700 Key Distribution Center, a network service that supplies tickets 701 and temporary session keys; or an instance of that service or the 702 host on which it runs. The KDC services both initial ticket and 703 ticket-granting ticket requests. The initial ticket portion is 704 sometimes referred to as the Authentication Server (or service). 705 The ticket-granting ticket portion is sometimes referred to as the 706 ticket-granting server (or service). 708 Kerberos 709 The name given to the Project Athena's authentication service, the 710 protocol used by that service, or the code used to implement the 711 authentication service. The name is adopted from the three-headed 712 dog which guards Hades. 714 Key Version Number (kvno) 715 A tag associated with encrypted data identifies which key was used 716 for encryption when a long lived key associated with a principal 717 changes over time. It is used during the transition to a new key 718 so that the party decrypting a message can tell whether the data 719 was encrypted using the old or the new key. 721 Plaintext 722 The input to an encryption function or the output of a decryption 724 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 726 function. Decryption transforms ciphertext into plaintext. 728 Principal 729 A named client or server entity that participates in a network 730 communication, with one name that is considered canonical. 732 Principal identifier 733 The canonical name used to uniquely identify each different 734 principal. 736 Seal 737 To encipher a record containing several fields in such a way that 738 the fields cannot be individually replaced without either 739 knowledge of the encryption key or leaving evidence of tampering. 741 Secret key 742 An encryption key shared by a principal and the KDC, distributed 743 outside the bounds of the system, with a long lifetime. In the 744 case of a human user's principal, the secret key MAY be derived 745 from a password. 747 Server 748 A particular Principal which provides a resource to network 749 clients. The server is sometimes referred to as the Application 750 Server. 752 Service 753 A resource provided to network clients; often provided by more 754 than one server (for example, remote file service). 756 Session key 757 A temporary encryption key used between two principals, with a 758 lifetime limited to the duration of a single login "session". 760 Sub-session key 761 A temporary encryption key used between two principals, selected 762 and exchanged by the principals using the session key, and with a 763 lifetime limited to the duration of a single association. 765 Ticket 766 A record that helps a client authenticate itself to a server; it 767 contains the client's identity, a session key, a timestamp, and 768 other information, all sealed using the server's secret key. It 769 only serves to authenticate a client when presented along with a 770 fresh Authenticator. 772 2. Ticket flag uses and requests 773 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 775 Each Kerberos ticket contains a set of flags which are used to 776 indicate attributes of that ticket. Most flags may be requested by a 777 client when the ticket is obtained; some are automatically turned on 778 and off by a Kerberos server as required. The following sections 779 explain what the various flags mean and give examples of reasons to 780 use them. With the exception of the INVALID flag clients MUST ignore 781 ticket flags that are not recognized. KDCs MUST ignore KDC options 782 that are not recognized. Some implementations of RFC 1510 are known 783 to reject unknown KDC options, so clients may need to resend a 784 request without KDC new options absent if the request was rejected 785 when sent with option added since RFC 1510. Since new KDCs will 786 ignore unknown options, clients MUST confirm that the ticket returned 787 by the KDC meets their needs. 789 Note that it is not, in general, possible to determine whether an 790 option was not honored because it was not understood or because it 791 was rejected either through configuration or policy. When adding a 792 new option to the Kerberos protocol, designers should consider 793 whether the distinction is important for their option. In cases where 794 it is, a mechanism for the KDC to return an indication that the 795 option was understood but rejected needs to be provided in the 796 specification of the option. Often in such cases, the mechanism needs 797 to be broad enough to permit an error or reason to be returned. 799 2.1. Initial, pre-authenticated, and hardware authenticated tickets 801 The INITIAL flag indicates that a ticket was issued using the AS 802 protocol, rather than issued based on a ticket-granting ticket. 803 Application servers that want to require the demonstrated knowledge 804 of a client's secret key (e.g. a password-changing program) can 805 insist that this flag be set in any tickets they accept, and thus be 806 assured that the client's key was recently presented to the 807 application client. 809 The PRE-AUTHENT and HW-AUTHENT flags provide additional information 810 about the initial authentication, regardless of whether the current 811 ticket was issued directly (in which case INITIAL will also be set) 812 or issued on the basis of a ticket-granting ticket (in which case the 813 INITIAL flag is clear, but the PRE-AUTHENT and HW-AUTHENT flags are 814 carried forward from the ticket-granting ticket). 816 2.2. Invalid tickets 818 The INVALID flag indicates that a ticket is invalid. Application 819 servers MUST reject tickets which have this flag set. A postdated 820 ticket will be issued in this form. Invalid tickets MUST be validated 821 by the KDC before use, by presenting them to the KDC in a TGS request 822 with the VALIDATE option specified. The KDC will only validate 824 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 826 tickets after their starttime has passed. The validation is required 827 so that postdated tickets which have been stolen before their 828 starttime can be rendered permanently invalid (through a hot-list 829 mechanism) (see section 3.3.3.1). 831 2.3. Renewable tickets 833 Applications may desire to hold tickets which can be valid for long 834 periods of time. However, this can expose their credentials to 835 potential theft for equally long periods, and those stolen 836 credentials would be valid until the expiration time of the 837 ticket(s). Simply using short-lived tickets and obtaining new ones 838 periodically would require the client to have long-term access to its 839 secret key, an even greater risk. Renewable tickets can be used to 840 mitigate the consequences of theft. Renewable tickets have two 841 "expiration times": the first is when the current instance of the 842 ticket expires, and the second is the latest permissible value for an 843 individual expiration time. An application client must periodically 844 (i.e. before it expires) present a renewable ticket to the KDC, with 845 the RENEW option set in the KDC request. The KDC will issue a new 846 ticket with a new session key and a later expiration time. All other 847 fields of the ticket are left unmodified by the renewal process. When 848 the latest permissible expiration time arrives, the ticket expires 849 permanently. At each renewal, the KDC MAY consult a hot-list to 850 determine if the ticket had been reported stolen since its last 851 renewal; it will refuse to renew such stolen tickets, and thus the 852 usable lifetime of stolen tickets is reduced. 854 The RENEWABLE flag in a ticket is normally only interpreted by the 855 ticket-granting service (discussed below in section 3.3). It can 856 usually be ignored by application servers. However, some particularly 857 careful application servers MAY disallow renewable tickets. 859 If a renewable ticket is not renewed by its expiration time, the KDC 860 will not renew the ticket. The RENEWABLE flag is reset by default, 861 but a client MAY request it be set by setting the RENEWABLE option in 862 the KRB_AS_REQ message. If it is set, then the renew-till field in 863 the ticket contains the time after which the ticket may not be 864 renewed. 866 2.4. Postdated tickets 868 Applications may occasionally need to obtain tickets for use much 869 later, e.g. a batch submission system would need tickets to be valid 870 at the time the batch job is serviced. However, it is dangerous to 871 hold valid tickets in a batch queue, since they will be on-line 872 longer and more prone to theft. Postdated tickets provide a way to 873 obtain these tickets from the KDC at job submission time, but to 875 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 877 leave them "dormant" until they are activated and validated by a 878 further request of the KDC. If a ticket theft were reported in the 879 interim, the KDC would refuse to validate the ticket, and the thief 880 would be foiled. 882 The MAY-POSTDATE flag in a ticket is normally only interpreted by the 883 ticket-granting service. It can be ignored by application servers. 884 This flag MUST be set in a ticket-granting ticket in order to issue a 885 postdated ticket based on the presented ticket. It is reset by 886 default; it MAY be requested by a client by setting the ALLOW- 887 POSTDATE option in the KRB_AS_REQ message. This flag does not allow 888 a client to obtain a postdated ticket-granting ticket; postdated 889 ticket-granting tickets can only by obtained by requesting the 890 postdating in the KRB_AS_REQ message. The life (endtime-starttime) of 891 a postdated ticket will be the remaining life of the ticket-granting 892 ticket at the time of the request, unless the RENEWABLE option is 893 also set, in which case it can be the full life (endtime-starttime) 894 of the ticket-granting ticket. The KDC MAY limit how far in the 895 future a ticket may be postdated. 897 The POSTDATED flag indicates that a ticket has been postdated. The 898 application server can check the authtime field in the ticket to see 899 when the original authentication occurred. Some services MAY choose 900 to reject postdated tickets, or they may only accept them within a 901 certain period after the original authentication. When the KDC issues 902 a POSTDATED ticket, it will also be marked as INVALID, so that the 903 application client MUST present the ticket to the KDC to be validated 904 before use. 906 2.5. Proxiable and proxy tickets 908 At times it may be necessary for a principal to allow a service to 909 perform an operation on its behalf. The service must be able to take 910 on the identity of the client, but only for a particular purpose. A 911 principal can allow a service to take on the principal's identity for 912 a particular purpose by granting it a proxy. 914 The process of granting a proxy using the proxy and proxiable flags 915 is used to provide credentials for use with specific services. Though 916 conceptually also a proxy, users wishing to delegate their identity 917 in a form usable for all purpose MUST use the ticket forwarding 918 mechanism described in the next section to forward a ticket-granting 919 ticket. 921 The PROXIABLE flag in a ticket is normally only interpreted by the 922 ticket-granting service. It can be ignored by application servers. 923 When set, this flag tells the ticket-granting server that it is OK to 924 issue a new ticket (but not a ticket-granting ticket) with a 926 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 928 different network address based on this ticket. This flag is set if 929 requested by the client on initial authentication. By default, the 930 client will request that it be set when requesting a ticket-granting 931 ticket, and reset when requesting any other ticket. 933 This flag allows a client to pass a proxy to a server to perform a 934 remote request on its behalf (e.g. a print service client can give 935 the print server a proxy to access the client's files on a particular 936 file server in order to satisfy a print request). 938 In order to complicate the use of stolen credentials, Kerberos 939 tickets are usually valid from only those network addresses 940 specifically included in the ticket[4]. When granting a proxy, the 941 client MUST specify the new network address from which the proxy is 942 to be used, or indicate that the proxy is to be issued for use from 943 any address. 945 The PROXY flag is set in a ticket by the TGS when it issues a proxy 946 ticket. Application servers MAY check this flag and at their option 947 they MAY require additional authentication from the agent presenting 948 the proxy in order to provide an audit trail. 950 2.6. Forwardable tickets 952 Authentication forwarding is an instance of a proxy where the service 953 granted is complete use of the client's identity. An example where it 954 might be used is when a user logs in to a remote system and wants 955 authentication to work from that system as if the login were local. 957 The FORWARDABLE flag in a ticket is normally only interpreted by the 958 ticket-granting service. It can be ignored by application servers. 959 The FORWARDABLE flag has an interpretation similar to that of the 960 PROXIABLE flag, except ticket-granting tickets may also be issued 961 with different network addresses. This flag is reset by default, but 962 users MAY request that it be set by setting the FORWARDABLE option in 963 the AS request when they request their initial ticket-granting 964 ticket. 966 This flag allows for authentication forwarding without requiring the 967 user to enter a password again. If the flag is not set, then 968 authentication forwarding is not permitted, but the same result can 969 still be achieved if the user engages in the AS exchange specifying 970 the requested network addresses and supplies a password. 972 The FORWARDED flag is set by the TGS when a client presents a ticket 973 with the FORWARDABLE flag set and requests a forwarded ticket by 974 specifying the FORWARDED KDC option and supplying a set of addresses 975 for the new ticket. It is also set in all tickets issued based on 977 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 979 tickets with the FORWARDED flag set. Application servers may choose 980 to process FORWARDED tickets differently than non-FORWARDED tickets. 982 If addressless tickets are forwarded from one system to another, 983 clients SHOULD still use this option to obtain a new TGT in order to 984 have different session keys on the different systems. 986 2.7. Transited Policy Checking 988 In Kerberos, the application server is ultimately responsible for 989 accepting or rejecting authentication and SHOULD check that only 990 suitably trusted KDCs are relied upon to authenticate a principal. 991 The transited field in the ticket identifies which realms (and thus 992 which KDCs) were involved in the authentication process and an 993 application server would normally check this field. If any of these 994 are untrusted to authenticate the indicated client principal 995 (probably determined by a realm-based policy), the authentication 996 attempt MUST be rejected. The presence of trusted KDCs in this list 997 does not provide any guarantee; an untrusted KDC may have fabricated 998 the list. 1000 While the end server ultimately decides whether authentication is 1001 valid, the KDC for the end server's realm MAY apply a realm specific 1002 policy for validating the transited field and accepting credentials 1003 for cross-realm authentication. When the KDC applies such checks and 1004 accepts such cross-realm authentication it will set the TRANSITED- 1005 POLICY-CHECKED flag in the service tickets it issues based on the 1006 cross-realm TGT. A client MAY request that the KDCs not check the 1007 transited field by setting the DISABLE-TRANSITED-CHECK flag. KDCs are 1008 encouraged but not required to honor this flag. 1010 Application servers MUST either do the transited-realm checks 1011 themselves, or reject cross-realm tickets without TRANSITED-POLICY- 1012 CHECKED set. 1014 2.8. OK as Delegate 1016 For some applications a client may need to delegate authority to a 1017 server to act on its behalf in contacting other services. This 1018 requires that the client forward credentials to an intermediate 1019 server. The ability for a client to obtain a service ticket to a 1020 server conveys no information to the client about whether the server 1021 should be trusted to accept delegated credentials. The OK-AS- 1022 DELEGATE provides a way for a KDC to communicate local realm policy 1023 to a client regarding whether an intermediate server is trusted to 1024 accept such credentials. 1026 The OK-AS-DELEGATE flag from the copy of the ticket flags in the 1028 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 1030 encrypted part of the KDC reply indicates to the client that the 1031 server (not the client) specified in the ticket has been determined 1032 by policy of the realm to be a suitable recipient of delegation. A 1033 client can use the presence of this flag to help it make a decision 1034 whether to delegate credentials (either grant a proxy or a forwarded 1035 ticket-granting ticket) to this server. Ignore the value of this 1036 flag. When setting this flag, an administrator should consider the 1037 Security and placement of the server on which the service will run, 1038 as well as whether the service requires the use of delegated 1039 credentials. 1041 2.9. Other KDC options 1043 There are three additional options which MAY be set in a client's 1044 request of the KDC. 1046 2.9.1. Renewable-OK 1048 The RENEWABLE-OK option indicates that the client will accept a 1049 renewable ticket if a ticket with the requested life cannot otherwise 1050 be provided. If a ticket with the requested life cannot be provided, 1051 then the KDC MAY issue a renewable ticket with a renew-till equal to 1052 the requested endtime. The value of the renew-till field MAY still be 1053 adjusted by site-determined limits or limits imposed by the 1054 individual principal or server. 1056 2.9.2. ENC-TKT-IN-SKEY 1058 In its basic form the Kerberos protocol supports authentication in a 1059 client-server 1060 setting and is not well suited to authentication in a peer-to-peer 1061 environment because the long term key of the user does not remain on 1062 the workstation after initial login. Authentication of such peers may 1063 be supported by Kerberos in its user-to-user variant. The ENC-TKT-IN- 1064 SKEY option supports user-to-user authentication by allowing the KDC 1065 to issue a service ticket encrypted using the session key from 1066 another ticket-granting ticket issued to another user. The ENC-TKT- 1067 IN-SKEY option is honored only by the ticket-granting service. It 1068 indicates that the ticket to be issued for the end server is to be 1069 encrypted in the session key from the additional second ticket- 1070 granting ticket provided with the request. See section 3.3.3 for 1071 specific details. 1073 2.9.3. Passwordless Hardware Authentication 1075 The OPT-HARDWARE-AUTH option indicates that the client wishes to use 1076 some form of hardware authentication instead of or in addition to the 1077 client's password or other long-lived encryption key. OPT-HARDWARE- 1079 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 1081 AUTH is honored only by the authentication service. If supported and 1082 allowed by policy, the KDC will return an errorcode 1083 KDC_ERR_PREAUTH_REQUIRED and include the required METHOD-DATA to 1084 perform such authentication. 1086 3. Message Exchanges 1088 The following sections describe the interactions between network 1089 clients and servers and the messages involved in those exchanges. 1091 3.1. The Authentication Service Exchange 1093 Summary 1095 Message direction Message type Section 1096 1. Client to Kerberos KRB_AS_REQ 5.4.1 1097 2. Kerberos to client KRB_AS_REP or 5.4.2 1098 KRB_ERROR 5.9.1 1100 The Authentication Service (AS) Exchange between the client and the 1101 Kerberos Authentication Server is initiated by a client when it 1102 wishes to obtain authentication credentials for a given server but 1103 currently holds no credentials. In its basic form, the client's 1104 secret key is used for encryption and decryption. This exchange is 1105 typically used at the initiation of a login session to obtain 1106 credentials for a Ticket-Granting Server which will subsequently be 1107 used to obtain credentials for other servers (see section 3.3) 1108 without requiring further use of the client's secret key. This 1109 exchange is also used to request credentials for services which must 1110 not be mediated through the Ticket-Granting Service, but rather 1111 require a principal's secret key, such as the password-changing 1112 service[5]. This exchange does not by itself provide any assurance of 1113 the identity of the user[6]. 1115 The exchange consists of two messages: KRB_AS_REQ from the client to 1116 Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these 1117 messages are described in sections 5.4.1, 5.4.2, and 5.9.1. 1119 In the request, the client sends (in cleartext) its own identity and 1120 the identity of the server for which it is requesting credentials, 1121 other information about the credentials it is requesting, and a 1122 randomly generated nonce which can be used to detect replays, and to 1123 associate replies with the matching requests. This nonce MUST be 1124 generated randomly by the client and remembered for checking against 1125 the nonce in the expected reply. The response, KRB_AS_REP, contains a 1126 ticket for the client to present to the server, and a session key 1127 that will be shared by the client and the server. The session key 1128 and additional information are encrypted in the client's secret key. 1130 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 1132 The encrypted part of the KRB_AS_REP message also contains the nonce 1133 which MUST be matched with the nonce from the KRB_AS_REQ message. 1135 Without pre-authentication, the authentication server does not know 1136 whether the client is actually the principal named in the request. It 1137 simply sends a reply without knowing or caring whether they are the 1138 same. This is acceptable because nobody but the principal whose 1139 identity was given in the request will be able to use the reply. Its 1140 critical information is encrypted in that principal's key. However, 1141 an attacker can send a KRB_AS_REQ message to get known plaintext in 1142 order to attack the principal's key. Especially if the key is based 1143 on a password, this may create a security exposure. So, the initial 1144 request supports an optional field that can be used to pass 1145 additional information that might be needed for the initial exchange. 1146 This field SHOULD be used for pre-authentication as described in 1147 sections 3.1.1 and 5.2.7. 1149 Various errors can occur; these are indicated by an error response 1150 (KRB_ERROR) instead of the KRB_AS_REP response. The error message is 1151 not encrypted. The KRB_ERROR message contains information which can 1152 be used to associate it with the message to which it replies. The 1153 contents of the KRB_ERROR message are not integrity-protected. As 1154 such, the client cannot detect replays, fabrications or 1155 modifications. A solution to this problem will be included in a 1156 future version of the protocol. 1158 3.1.1. Generation of KRB_AS_REQ message 1160 The client may specify a number of options in the initial request. 1161 Among these options are whether pre-authentication is to be 1162 performed; whether the requested ticket is to be renewable, 1163 proxiable, or forwardable; whether it should be postdated or allow 1164 postdating of derivative tickets; and whether a renewable ticket will 1165 be accepted in lieu of a non-renewable ticket if the requested ticket 1166 expiration date cannot be satisfied by a non-renewable ticket (due to 1167 configuration constraints). 1169 The client prepares the KRB_AS_REQ message and sends it to the KDC. 1171 3.1.2. Receipt of KRB_AS_REQ message 1173 If all goes well, processing the KRB_AS_REQ message will result in 1174 the creation of a ticket for the client to present to the server. The 1175 format for the ticket is described in section 5.3. The contents of 1176 the ticket are determined as follows. 1178 Because Kerberos can run over unreliable transports such as UDP, the 1179 KDC MUST be prepared to retransmit responses in case they are lost. 1181 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 1183 If a KDC receives a request identical to one it has recently 1184 successfully processed, the KDC MUST respond with a KRB_AS_REP 1185 message rather than a replay error. In order to reduce ciphertext 1186 given to a potential attacker, KDCs MAY send the same response 1187 generated when the request was first handled. KDCs MUST obey this 1188 replay behavior even if the actual transport in use is reliable. 1190 3.1.3. Generation of KRB_AS_REP message 1192 The authentication server looks up the client and server principals 1193 named in the KRB_AS_REQ in its database, extracting their respective 1194 keys. If the requested client principal named in the request is not 1195 known because it doesn't exist in the KDC's principal database, then 1196 an error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is returned. 1198 If required, the server pre-authenticates the request, and if the 1199 pre-authentication check fails, an error message with the code 1200 KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is 1201 required, but was not present in the request, an error message with 1202 the code KDC_ERR_PREAUTH_REQUIRED is returned and a METHOD-DATA 1203 object will be stored in the e-data field of the KRB-ERROR message to 1204 specify which pre-authentication mechanisms are acceptable. Usually 1205 this will include PA-ETYPE-INFO and/or PA-ETYPE-INFO2 elements as 1206 described below. If the server cannot accommodate any encryption type 1207 requested by the client, an error message with code 1208 KDC_ERR_ETYPE_NOSUPP is returned. Otherwise the KDC generates a 1209 'random' session key[7]. 1211 When responding to an AS request, if there are multiple encryption 1212 keys registered for a client in the Kerberos database, then the etype 1213 field from the AS request is used by the KDC to select the encryption 1214 method to be used to protect the encrypted part of the KRB_AS_REP 1215 message which is sent to the client. If there is more than one 1216 supported strong encryption type in the etype list, the KDC SHOULD 1217 use the first valid strong etype for which an encryption key is 1218 available. 1220 When the user's key is generated from a password or pass phrase, the 1221 string-to-key function for the particular encryption key type is 1222 used, as specified in [@KCRYPTO]. The salt value and additional 1223 parameters for the string-to-key function have default values 1224 (specified by section 4 and by the encryption mechanism 1225 specification, respectively) that may be overridden by pre- 1226 authentication data (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA- 1227 ETYPE-INFO2, etc). Since the KDC is presumed to store a copy of the 1228 resulting key only, these values should not be changed for password- 1229 based keys except when changing the principal's key. 1231 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 1233 When the AS server is to include pre-authentication data in a KRB- 1234 ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE-INFO, 1235 if the etype field of the client's AS-REQ lists at least one "newer" 1236 encryption type. Otherwise (when the etype field of the client's AS- 1237 REQ does not list any "newer" encryption types) it MUST send both, 1238 PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an entry for each 1239 enctype). A "newer" enctype is any enctype first officially 1240 specified concurrently with or subsequent to the issue of this RFC. 1241 The enctypes DES, 3DES or RC4 and any defined in [RFC1510] are not 1242 newer enctypes. 1244 It is not possible to reliably generate a user's key given a pass 1245 phrase without contacting the KDC, since it will not be known whether 1246 alternate salt or parameter values are required. 1248 The KDC will attempt to assign the type of the random session key 1249 from the list of methods in the etype field. The KDC will select the 1250 appropriate type using the list of methods provided together with 1251 information from the Kerberos database indicating acceptable 1252 encryption methods for the application server. The KDC will not issue 1253 tickets with a weak session key encryption type. 1255 If the requested start time is absent, indicates a time in the past, 1256 or is within the window of acceptable clock skew for the KDC and the 1257 POSTDATE option has not been specified, then the start time of the 1258 ticket is set to the authentication server's current time. If it 1259 indicates a time in the future beyond the acceptable clock skew, but 1260 the POSTDATED option has not been specified then the error 1261 KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the requested start 1262 time is checked against the policy of the local realm (the 1263 administrator might decide to prohibit certain types or ranges of 1264 postdated tickets), and if acceptable, the ticket's start time is set 1265 as requested and the INVALID flag is set in the new ticket. The 1266 postdated ticket MUST be validated before use by presenting it to the 1267 KDC after the start time has been reached. 1269 The expiration time of the ticket will be set to the earlier of the 1270 requested endtime and a time determined by local policy, possibly 1271 determined using realm or principal specific factors. For example, 1272 the expiration time MAY be set to the earliest of the following: 1274 * The expiration time (endtime) requested in the KRB_AS_REQ 1275 message. 1277 * The ticket's start time plus the maximum allowable lifetime 1278 associated with the client principal from the authentication 1279 server's database. 1281 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 1283 * The ticket's start time plus the maximum allowable lifetime 1284 associated with the server principal. 1286 * The ticket's start time plus the maximum lifetime set by the 1287 policy of the local realm. 1289 If the requested expiration time minus the start time (as determined 1290 above) is less than a site-determined minimum lifetime, an error 1291 message with code KDC_ERR_NEVER_VALID is returned. If the requested 1292 expiration time for the ticket exceeds what was determined as above, 1293 and if the 'RENEWABLE-OK' option was requested, then the 'RENEWABLE' 1294 flag is set in the new ticket, and the renew-till value is set as if 1295 the 'RENEWABLE' option were requested (the field and option names are 1296 described fully in section 5.4.1). 1298 If the RENEWABLE option has been requested or if the RENEWABLE-OK 1299 option has been set and a renewable ticket is to be issued, then the 1300 renew-till field MAY be set to the earliest of: 1302 * Its requested value. 1304 * The start time of the ticket plus the minimum of the two 1305 maximum renewable lifetimes associated with the principals' 1306 database entries. 1308 * The start time of the ticket plus the maximum renewable 1309 lifetime set by the policy of the local realm. 1311 The flags field of the new ticket will have the following options set 1312 if they have been requested and if the policy of the local realm 1313 allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. 1314 If the new ticket is postdated (the start time is in the future), its 1315 INVALID flag will also be set. 1317 If all of the above succeed, the server will encrypt the ciphertext 1318 part of the ticket using the encryption key extracted from the server 1319 principal's record in the Kerberos database using the encryption type 1320 associated with the server principal's key (this choice is NOT 1321 affected by the etype field in the request). It then formats a 1322 KRB_AS_REP message (see section 5.4.2), copying the addresses in the 1323 request into the caddr of the response, placing any required pre- 1324 authentication data into the padata of the response, and encrypts the 1325 ciphertext part in the client's key using an acceptable encryption 1326 method requested in the etype field of the request, or in some key 1327 specified by pre-authentication mechanisms being used. 1329 3.1.4. Generation of KRB_ERROR message 1330 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 1332 Several errors can occur, and the Authentication Server responds by 1333 returning an error message, KRB_ERROR, to the client, with the error- 1334 code and e-text fields set to appropriate values. The error message 1335 contents and details are described in Section 5.9.1. 1337 3.1.5. Receipt of KRB_AS_REP message 1339 If the reply message type is KRB_AS_REP, then the client verifies 1340 that the cname and crealm fields in the cleartext portion of the 1341 reply match what it requested. If any padata fields are present, they 1342 may be used to derive the proper secret key to decrypt the message. 1343 The client decrypts the encrypted part of the response using its 1344 secret key, verifies that the nonce in the encrypted part matches the 1345 nonce it supplied in its request (to detect replays). It also 1346 verifies that the sname and srealm in the response match those in the 1347 request (or are otherwise expected values), and that the host address 1348 field is also correct. It then stores the ticket, session key, start 1349 and expiration times, and other information for later use. The last- 1350 req field (and the deprecated key-expiration field) from the 1351 encrypted part of the response MAY be checked to notify the user of 1352 impending key expiration. This enables the client program to suggest 1353 remedial action, such as a password change. 1355 Upon validation of the KRB_AS_REP message (by checking the returned 1356 nonce against that sent in the KRB_AS_REQ message) the client knows 1357 that the current time on the KDC is that read from the authtime field 1358 of the encrypted part of the reply. The client can optionally use 1359 this value for clock synchronization in subsequent messages by 1360 recording with the ticket the difference (offset) between the 1361 authtime value and the local clock. This offset can then be used by 1362 the same user to adjust the time read from the system clock when 1363 generating messages [DGT96]. 1365 This technique MUST be used when adjusting for clock skew instead of 1366 directly changing the system clock because the KDC reply is only 1367 authenticated to the user whose secret key was used, but not to the 1368 system or workstation. If the clock were adjusted, an attacker 1369 colluding with a user logging into a workstation could agree on a 1370 password, resulting in a KDC reply that would be correctly validated 1371 even though it did not originate from a KDC trusted by the 1372 workstation. 1374 Proper decryption of the KRB_AS_REP message is not sufficient for the 1375 host to verify the identity of the user; the user and an attacker 1376 could cooperate to generate a KRB_AS_REP format message which 1377 decrypts properly but is not from the proper KDC. If the host wishes 1378 to verify the identity of the user, it MUST require the user to 1379 present application credentials which can be verified using a 1381 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 1383 securely-stored secret key for the host. If those credentials can be 1384 verified, then the identity of the user can be assured. 1386 3.1.6. Receipt of KRB_ERROR message 1388 If the reply message type is KRB_ERROR, then the client interprets it 1389 as an error and performs whatever application-specific tasks are 1390 necessary to recover. 1392 3.2. The Client/Server Authentication Exchange 1394 Summary 1395 Message direction Message type Section 1396 Client to Application server KRB_AP_REQ 5.5.1 1397 [optional] Application server to client KRB_AP_REP or 5.5.2 1398 KRB_ERROR 5.9.1 1400 The client/server authentication (CS) exchange is used by network 1401 applications to authenticate the client to the server and vice versa. 1402 The client MUST have already acquired credentials for the server 1403 using the AS or TGS exchange. 1405 3.2.1. The KRB_AP_REQ message 1407 The KRB_AP_REQ contains authentication information which SHOULD be 1408 part of the first message in an authenticated transaction. It 1409 contains a ticket, an authenticator, and some additional bookkeeping 1410 information (see section 5.5.1 for the exact format). The ticket by 1411 itself is insufficient to authenticate a client, since tickets are 1412 passed across the network in cleartext[8], so the authenticator is 1413 used to prevent invalid replay of tickets by proving to the server 1414 that the client knows the session key of the ticket and thus is 1415 entitled to use the ticket. The KRB_AP_REQ message is referred to 1416 elsewhere as the 'authentication header.' 1418 3.2.2. Generation of a KRB_AP_REQ message 1420 When a client wishes to initiate authentication to a server, it 1421 obtains (either through a credentials cache, the AS exchange, or the 1422 TGS exchange) a ticket and session key for the desired service. The 1423 client MAY re-use any tickets it holds until they expire. To use a 1424 ticket the client constructs a new Authenticator from the system 1425 time, its name, and optionally an application specific checksum, an 1426 initial sequence number to be used in KRB_SAFE or KRB_PRIV messages, 1427 and/or a session subkey to be used in negotiations for a session key 1428 unique to this particular session. Authenticators MAY NOT be re-used 1429 and will be rejected if replayed to a server[9]. If a sequence number 1430 is to be included, it SHOULD be randomly chosen so that even after 1432 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 1434 many messages have been exchanged it is not likely to collide with 1435 other sequence numbers in use. 1437 The client MAY indicate a requirement of mutual authentication or the 1438 use of a session-key based ticket (for user to user authentication - 1439 see section 3.7) by setting the appropriate flag(s) in the ap-options 1440 field of the message. 1442 The Authenticator is encrypted in the session key and combined with 1443 the ticket to form the KRB_AP_REQ message which is then sent to the 1444 end server along with any additional application-specific 1445 information. 1447 3.2.3. Receipt of KRB_AP_REQ message 1449 Authentication is based on the server's current time of day (clocks 1450 MUST be loosely synchronized), the authenticator, and the ticket. 1451 Several errors are possible. If an error occurs, the server is 1452 expected to reply to the client with a KRB_ERROR message. This 1453 message MAY be encapsulated in the application protocol if its 'raw' 1454 form is not acceptable to the protocol. The format of error messages 1455 is described in section 5.9.1. 1457 The algorithm for verifying authentication information is as follows. 1458 If the message type is not KRB_AP_REQ, the server returns the 1459 KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the Ticket 1460 in the KRB_AP_REQ is not one the server can use (e.g., it indicates 1461 an old key, and the server no longer possesses a copy of the old 1462 key), the KRB_AP_ERR_BADKEYVER error is returned. If the USE-SESSION- 1463 KEY flag is set in the ap-options field, it indicates to the server 1464 that user-to-user authentication is in use, and that the ticket is 1465 encrypted in the session key from the server's ticket-granting ticket 1466 rather than in the server's secret key. See section 3.7 for a more 1467 complete description of the affect of user to user authentication on 1468 all messages in the Kerberos protocol. 1470 Since it is possible for the server to be registered in multiple 1471 realms, with different keys in each, the srealm field in the 1472 unencrypted portion of the ticket in the KRB_AP_REQ is used to 1473 specify which secret key the server should use to decrypt that 1474 ticket. The KRB_AP_ERR_NOKEY error code is returned if the server 1475 doesn't have the proper key to decipher the ticket. 1477 The ticket is decrypted using the version of the server's key 1478 specified by the ticket. If the decryption routines detect a 1479 modification of the ticket (each encryption system MUST provide 1480 safeguards to detect modified ciphertext; see section 6), the 1481 KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that 1483 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 1485 different keys were used to encrypt and decrypt). 1487 The authenticator is decrypted using the session key extracted from 1488 the decrypted ticket. If decryption shows it to have been modified, 1489 the KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of 1490 the client from the ticket are compared against the same fields in 1491 the authenticator. If they don't match, the KRB_AP_ERR_BADMATCH 1492 error is returned; this normally is caused by a client error or 1493 attempted attack. The addresses in the ticket (if any) are then 1494 searched for an address matching the operating-system reported 1495 address of the client. If no match is found or the server insists on 1496 ticket addresses but none are present in the ticket, the 1497 KRB_AP_ERR_BADADDR error is returned. If the local (server) time and 1498 the client time in the authenticator differ by more than the 1499 allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW error is 1500 returned. 1502 Unless the application server provides its own suitable means to 1503 protect against replay (for example, a challenge-response sequence 1504 initiated by the server after authentication, or use of a server- 1505 generated encryption subkey), the server MUST utilize a replay cache 1506 to remember any authenticator presented within the allowable clock 1507 skew. Careful analysis of the application protocol and implementation 1508 is recommended before eliminating this cache. The replay cache will 1509 store at least the server name, along with the client name, time and 1510 microsecond fields from the recently-seen authenticators and if a 1511 matching tuple is found, the KRB_AP_ERR_REPEAT error is returned 1512 [10]. If a server loses track of authenticators presented within the 1513 allowable clock skew, it MUST reject all requests until the clock 1514 skew interval has passed, providing assurance that any lost or 1515 replayed authenticators will fall outside the allowable clock skew 1516 and can no longer be successfully replayed [11]. 1518 Implementation note: If a client generates multiple requests to the 1519 KDC with the same timestamp, including the microsecond field, all but 1520 the first of the requests received will be rejected as replays. This 1521 might happen, for example, if the resolution of the client's clock is 1522 too coarse. Implementations SHOULD ensure that the timestamps are 1523 not reused, possibly by incrementing the microseconds field in the 1524 time stamp when the clock returns the same time for multiple 1525 requests. 1527 If multiple servers (for example, different services on one machine, 1528 or a single service implemented on multiple machines) share a service 1529 principal (a practice we do not recommend in general, but acknowledge 1530 will be used in some cases), they should also share this replay 1531 cache, or the application protocol should be designed so as to 1532 eliminate the need for it. Note that this applies to all of the 1534 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 1536 services, if any of the application protocols does not have replay 1537 protection built in; an authenticator used with such a service could 1538 later be replayed to a different service with the same service 1539 principal but no replay protection, if the former doesn't record the 1540 authenticator information in the common replay cache. 1542 If a sequence number is provided in the authenticator, the server 1543 saves it for later use in processing KRB_SAFE and/or KRB_PRIV 1544 messages. If a subkey is present, the server either saves it for 1545 later use or uses it to help generate its own choice for a subkey to 1546 be returned in a KRB_AP_REP message. 1548 The server computes the age of the ticket: local (server) time minus 1549 the start time inside the Ticket. If the start time is later than the 1550 current time by more than the allowable clock skew or if the INVALID 1551 flag is set in the ticket, the KRB_AP_ERR_TKT_NYV error is returned. 1552 Otherwise, if the current time is later than end time by more than 1553 the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error is 1554 returned. 1556 If all these checks succeed without an error, the server is assured 1557 that the client possesses the credentials of the principal named in 1558 the ticket and thus, the client has been authenticated to the server. 1560 Passing these checks provides only authentication of the named 1561 principal; it does not imply authorization to use the named service. 1562 Applications MUST make a separate authorization decisions based upon 1563 the authenticated name of the user, the requested operation, local 1564 access control information such as that contained in a .k5login or 1565 .k5users file, and possibly a separate distributed authorization 1566 service. 1568 3.2.4. Generation of a KRB_AP_REP message 1570 Typically, a client's request will include both the authentication 1571 information and its initial request in the same message, and the 1572 server need not explicitly reply to the KRB_AP_REQ. However, if 1573 mutual authentication (not only authenticating the client to the 1574 server, but also the server to the client) is being performed, the 1575 KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options 1576 field, and a KRB_AP_REP message is required in response. As with the 1577 error message, this message MAY be encapsulated in the application 1578 protocol if its "raw" form is not acceptable to the application's 1579 protocol. The timestamp and microsecond field used in the reply MUST 1580 be the client's timestamp and microsecond field (as provided in the 1581 authenticator) [12]. If a sequence number is to be included, it 1582 SHOULD be randomly chosen as described above for the authenticator. A 1583 subkey MAY be included if the server desires to negotiate a different 1585 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 1587 subkey. The KRB_AP_REP message is encrypted in the session key 1588 extracted from the ticket. 1590 3.2.5. Receipt of KRB_AP_REP message 1592 If a KRB_AP_REP message is returned, the client uses the session key 1593 from the credentials obtained for the server [13] to decrypt the 1594 message, and verifies that the timestamp and microsecond fields match 1595 those in the Authenticator it sent to the server. If they match, then 1596 the client is assured that the server is genuine. The sequence number 1597 and subkey (if present) are retained for later use. 1599 3.2.6. Using the encryption key 1601 After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and 1602 server share an encryption key which can be used by the application. 1603 In some cases, the use of this session key will be implicit in the 1604 protocol; in others the method of use must be chosen from several 1605 alternatives. The 'true session key' to be used for KRB_PRIV, 1606 KRB_SAFE, or other application-specific uses MAY be chosen by the 1607 application based on the session key from the ticket and subkeys in 1608 the KRB_AP_REP message and the authenticator [14]. To mitigate the 1609 effect of failures in random number generation on the client it is 1610 strongly encouraged that any key derived by an application for 1611 subsequent use include the full key entropy derived from the KDC 1612 generated session key carried in the ticket. We leave the protocol 1613 negotiations of how to use the key (e.g. selecting an encryption or 1614 checksum type) to the application programmer; the Kerberos protocol 1615 does not constrain the implementation options, but an example of how 1616 this might be done follows. 1618 One way that an application may choose to negotiate a key to be used 1619 for subsequent integrity and privacy protection is for the client to 1620 propose a key in the subkey field of the authenticator. The server 1621 can then choose a key using the proposed key from the client as 1622 input, returning the new subkey in the subkey field of the 1623 application reply. This key could then be used for subsequent 1624 communication. 1626 To make this example more concrete, if the communication patterns of 1627 an application dictates the use of encryption modes of operation 1628 incompatible with the encryption system used for the authenticator, 1629 then a key compatible with the required encryption system may be 1630 generated by either the client, the server, or collaboratively by 1631 both and exchanged using the subkey field. This generation might 1632 involve the use of a random number as a pre-key, initially generated 1633 by either party, which could then be encrypted using the session key 1634 from the ticket, and the result exchanged and used for subsequent 1636 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 1638 encryption. By encrypting the pre-key with the session key from the 1639 ticket, randomness from the KDC generated key is assured of being 1640 present in the negotiated key. Application developers must be careful 1641 however, to use a means of introducing this entropy that does not 1642 allow an attacker to learn the session key from the ticket if it 1643 learns the key generated and used for subsequent communication. The 1644 reader should note that this is only an example, and that an analysis 1645 of the particular cryptosystem to be used, must be made before 1646 deciding how to generate values for the subkey fields, and the key to 1647 be used for subsequent communication. 1649 With both the one-way and mutual authentication exchanges, the peers 1650 should take care not to send sensitive information to each other 1651 without proper assurances. In particular, applications that require 1652 privacy or integrity SHOULD use the KRB_AP_REP response from the 1653 server to client to assure both client and server of their peer's 1654 identity. If an application protocol requires privacy of its 1655 messages, it can use the KRB_PRIV message (section 3.5). The KRB_SAFE 1656 message (section 3.4) can be used to assure integrity. 1658 3.3. The Ticket-Granting Service (TGS) Exchange 1660 Summary 1661 Message direction Message type Section 1662 1. Client to Kerberos KRB_TGS_REQ 5.4.1 1663 2. Kerberos to client KRB_TGS_REP or 5.4.2 1664 KRB_ERROR 5.9.1 1666 The TGS exchange between a client and the Kerberos Ticket-Granting 1667 Server is initiated by a client when it wishes to obtain 1668 authentication credentials for a given server (which might be 1669 registered in a remote realm), when it wishes to renew or validate an 1670 existing ticket, or when it wishes to obtain a proxy ticket. In the 1671 first case, the client must already have acquired a ticket for the 1672 Ticket-Granting Service using the AS exchange (the ticket-granting 1673 ticket is usually obtained when a client initially authenticates to 1674 the system, such as when a user logs in). The message format for the 1675 TGS exchange is almost identical to that for the AS exchange. The 1676 primary difference is that encryption and decryption in the TGS 1677 exchange does not take place under the client's key. Instead, the 1678 session key from the ticket-granting ticket or renewable ticket, or 1679 sub-session key from an Authenticator is used. As is the case for all 1680 application servers, expired tickets are not accepted by the TGS, so 1681 once a renewable or ticket-granting ticket expires, the client must 1682 use a separate exchange to obtain valid tickets. 1684 The TGS exchange consists of two messages: A request (KRB_TGS_REQ) 1685 from the client to the Kerberos Ticket-Granting Server, and a reply 1687 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 1689 (KRB_TGS_REP or KRB_ERROR). The KRB_TGS_REQ message includes 1690 information authenticating the client plus a request for credentials. 1691 The authentication information consists of the authentication header 1692 (KRB_AP_REQ) which includes the client's previously obtained ticket- 1693 granting, renewable, or invalid ticket. In the ticket-granting 1694 ticket and proxy cases, the request MAY include one or more of: a 1695 list of network addresses, a collection of typed authorization data 1696 to be sealed in the ticket for authorization use by the application 1697 server, or additional tickets (the use of which are described later). 1698 The TGS reply (KRB_TGS_REP) contains the requested credentials, 1699 encrypted in the session key from the ticket-granting ticket or 1700 renewable ticket, or if present, in the sub-session key from the 1701 Authenticator (part of the authentication header). The KRB_ERROR 1702 message contains an error code and text explaining what went wrong. 1703 The KRB_ERROR message is not encrypted. The KRB_TGS_REP message 1704 contains information which can be used to detect replays, and to 1705 associate it with the message to which it replies. The KRB_ERROR 1706 message also contains information which can be used to associate it 1707 with the message to which it replies. The same comments about 1708 integrity protection of KRB_ERROR messages mentioned in section 3.1 1709 apply to the TGS exchange. 1711 3.3.1. Generation of KRB_TGS_REQ message 1713 Before sending a request to the ticket-granting service, the client 1714 MUST determine in which realm the application server is believed to 1715 be registered [15]. If the client knows the service principal name 1716 and realm and it does not already possess a ticket-granting ticket 1717 for the appropriate realm, then one must be obtained. This is first 1718 attempted by requesting a ticket-granting ticket for the destination 1719 realm from a Kerberos server for which the client possesses a ticket- 1720 granting ticket (using the KRB_TGS_REQ message recursively). The 1721 Kerberos server MAY return a TGT for the desired realm in which case 1722 one can proceed. Alternatively, the Kerberos server MAY return a TGT 1723 for a realm which is 'closer' to the desired realm (further along the 1724 standard hierarchical path between the client's realm and the 1725 requested realm server's realm). It should be noted in this case that 1726 misconfiguration of the Kerberos servers may cause loops in the 1727 resulting authentication path, which the client should be careful to 1728 detect and avoid. 1730 If the Kerberos server returns a TGT for a 'closer' realm other than 1731 the desired realm, the client MAY use local policy configuration to 1732 verify that the authentication path used is an acceptable one. 1733 Alternatively, a client MAY choose its own authentication path, 1734 rather than relying on the Kerberos server to select one. In either 1735 case, any policy or configuration information used to choose or 1736 validate authentication paths, whether by the Kerberos server or 1738 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 1740 client, MUST be obtained from a trusted source. 1742 When a client obtains a ticket-granting ticket that is 'closer' to 1743 the destination realm, the client MAY cache this ticket and reuse it 1744 in future KRB-TGS exchanges with services in the 'closer' realm. 1745 However, if the client were to obtain a ticket-granting ticket for 1746 the 'closer' realm by starting at the initial KDC rather than as part 1747 of obtaining another ticket, then a shorter path to the 'closer' 1748 realm might be used. This shorter path may be desirable because fewer 1749 intermediate KDCs would know the session key of the ticket involved. 1750 For this reason, clients SHOULD evaluate whether they trust the 1751 realms transited in obtaining the 'closer' ticket when making a 1752 decision to use the ticket in future. 1754 Once the client obtains a ticket-granting ticket for the appropriate 1755 realm, it determines which Kerberos servers serve that realm, and 1756 contacts one. The list might be obtained through a configuration file 1757 or network service or it MAY be generated from the name of the realm; 1758 as long as the secret keys exchanged by realms are kept secret, only 1759 denial of service results from using a false Kerberos server. 1761 (This paragraph changed) As in the AS exchange, the client MAY 1762 specify a number of options in the KRB_TGS_REQ message. One of these 1763 options is the ENC-TKT-IN-SKEY option used for user-to-user 1764 authentication. An overview of user to user authentication can be 1765 found in section 3.7. When generating the KRB_TGS_REQ message, this 1766 option indicates that the client is including a ticket-granting 1767 ticket obtained from the application server in the additional tickets 1768 field of the request and that the KDC SHOULD encrypt the ticket for 1769 the application server using the session key from this additional 1770 ticket, instead of using a server key from the principal database. 1772 The client prepares the KRB_TGS_REQ message, providing an 1773 authentication header as an element of the padata field, and 1774 including the same fields as used in the KRB_AS_REQ message along 1775 with several optional fields: the enc-authorizatfion-data field for 1776 application server use and additional tickets required by some 1777 options. 1779 In preparing the authentication header, the client can select a sub- 1780 session key under which the response from the Kerberos server will be 1781 encrypted [16]. If the sub-session key is not specified, the session 1782 key from the ticket-granting ticket will be used. If the enc- 1783 authorization-data is present, it MUST be encrypted in the sub- 1784 session key, if present, from the authenticator portion of the 1785 authentication header, or if not present, using the session key from 1786 the ticket-granting ticket. 1788 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 1790 Once prepared, the message is sent to a Kerberos server for the 1791 destination realm. 1793 3.3.2. Receipt of KRB_TGS_REQ message 1795 The KRB_TGS_REQ message is processed in a manner similar to the 1796 KRB_AS_REQ message, but there are many additional checks to be 1797 performed. First, the Kerberos server MUST determine which server the 1798 accompanying ticket is for and it MUST select the appropriate key to 1799 decrypt it. For a normal KRB_TGS_REQ message, it will be for the 1800 ticket granting service, and the TGS's key will be used. If the TGT 1801 was issued by another realm, then the appropriate inter-realm key 1802 MUST be used. If the accompanying ticket is not a ticket-granting 1803 ticket for the current realm, but is for an application server in the 1804 current realm, the RENEW, VALIDATE, or PROXY options are specified in 1805 the request, and the server for which a ticket is requested is the 1806 server named in the accompanying ticket, then the KDC will decrypt 1807 the ticket in the authentication header using the key of the server 1808 for which it was issued. If no ticket can be found in the padata 1809 field, the KDC_ERR_PADATA_TYPE_NOSUPP error is returned. 1811 Once the accompanying ticket has been decrypted, the user-supplied 1812 checksum in the Authenticator MUST be verified against the contents 1813 of the request, and the message rejected if the checksums do not 1814 match (with an error code of KRB_AP_ERR_MODIFIED) or if the checksum 1815 is not keyed or not collision-proof (with an error code of 1816 KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported, the 1817 KDC_ERR_SUMTYPE_NOSUPP error is returned. If the authorization-data 1818 are present, they are decrypted using the sub-session key from the 1819 Authenticator. 1821 If any of the decryptions indicate failed integrity checks, the 1822 KRB_AP_ERR_BAD_INTEGRITY error is returned. 1824 As discussed in section 3.1.2, the KDC MUST send a valid KRB_TGS_REP 1825 message if it receives a KRB_TGS_REQ message identical to one it has 1826 recently processed. However, if the authenticator is a replay, but 1827 the rest of the request is not identical, then the KDC SHOULD return 1828 KRB_AP_ERR_REPEAT. 1830 3.3.3. Generation of KRB_TGS_REP message 1832 The KRB_TGS_REP message shares its format with the KRB_AS_REP 1833 (KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The 1834 detailed specification is in section 5.4.2. 1836 The response will include a ticket for the requested server or for a 1837 ticket granting server of an intermediate KDC to be contacted to 1839 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 1841 obtain the requested ticket. The Kerberos database is queried to 1842 retrieve the record for the appropriate server (including the key 1843 with which the ticket will be encrypted). If the request is for a 1844 ticket-granting ticket for a remote realm, and if no key is shared 1845 with the requested realm, then the Kerberos server will select the 1846 realm 'closest' to the requested realm with which it does share a 1847 key, and use that realm instead. If the requested server cannot be 1848 found in the TGS database, then a TGT for another trusted realm MAY 1849 be returned instead of a ticket for the service. This TGT is a 1850 referral mechanism to cause the client to retry the request to the 1851 realm of the TGT. These are the only cases where the response for 1852 the KDC will be for a different server than that requested by the 1853 client. 1855 By default, the address field, the client's name and realm, the list 1856 of transited realms, the time of initial authentication, the 1857 expiration time, and the authorization data of the newly-issued 1858 ticket will be copied from the ticket-granting ticket (TGT) or 1859 renewable ticket. If the transited field needs to be updated, but the 1860 transited type is not supported, the KDC_ERR_TRTYPE_NOSUPP error is 1861 returned. 1863 If the request specifies an endtime, then the endtime of the new 1864 ticket is set to the minimum of (a) that request, (b) the endtime 1865 from the TGT, and (c) the starttime of the TGT plus the minimum of 1866 the maximum life for the application server and the maximum life for 1867 the local realm (the maximum life for the requesting principal was 1868 already applied when the TGT was issued). If the new ticket is to be 1869 a renewal, then the endtime above is replaced by the minimum of (a) 1870 the value of the renew_till field of the ticket and (b) the starttime 1871 for the new ticket plus the life (endtime-starttime) of the old 1872 ticket. 1874 If the FORWARDED option has been requested, then the resulting ticket 1875 will contain the addresses specified by the client. This option will 1876 only be honored if the FORWARDABLE flag is set in the TGT. The PROXY 1877 option is similar; the resulting ticket will contain the addresses 1878 specified by the client. It will be honored only if the PROXIABLE 1879 flag in the TGT is set. The PROXY option will not be honored on 1880 requests for additional ticket-granting tickets. 1882 If the requested start time is absent, indicates a time in the past, 1883 or is within the window of acceptable clock skew for the KDC and the 1884 POSTDATE option has not been specified, then the start time of the 1885 ticket is set to the authentication server's current time. If it 1886 indicates a time in the future beyond the acceptable clock skew, but 1887 the POSTDATED option has not been specified or the MAY-POSTDATE flag 1888 is not set in the TGT, then the error KDC_ERR_CANNOT_POSTDATE is 1890 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 1892 returned. Otherwise, if the ticket-granting ticket has the MAY- 1893 POSTDATE flag set, then the resulting ticket will be postdated and 1894 the requested starttime is checked against the policy of the local 1895 realm. If acceptable, the ticket's start time is set as requested, 1896 and the INVALID flag is set. The postdated ticket MUST be validated 1897 before use by presenting it to the KDC after the starttime has been 1898 reached. However, in no case may the starttime, endtime, or renew- 1899 till time of a newly-issued postdated ticket extend beyond the renew- 1900 till time of the ticket-granting ticket. 1902 If the ENC-TKT-IN-SKEY option has been specified and an additional 1903 ticket has been included in the request, it indicates that the client 1904 is using user- to-user authentication to prove its identity to a 1905 server that does not have access to a persistent key. Section 3.7 1906 describes the affect of this option on the entire Kerberos protocol. 1907 When generating the KRB_TGS_REP message, this option in the 1908 KRB_TGS_REQ message tells the KDC to decrypt the additional ticket 1909 using the key for the server to which the additional ticket was 1910 issued and verify that it is a ticket-granting ticket. If the name of 1911 the requested server is missing from the request, the name of the 1912 client in the additional ticket will be used. Otherwise the name of 1913 the requested server will be compared to the name of the client in 1914 the additional ticket and if different, the request will be rejected. 1915 If the request succeeds, the session key from the additional ticket 1916 will be used to encrypt the new ticket that is issued instead of 1917 using the key of the server for which the new ticket will be used. 1919 If the name of the server in the ticket that is presented to the KDC 1920 as part of the authentication header is not that of the ticket- 1921 granting server itself, the server is registered in the realm of the 1922 KDC, and the RENEW option is requested, then the KDC will verify that 1923 the RENEWABLE flag is set in the ticket, that the INVALID flag is not 1924 set in the ticket, and that the renew_till time is still in the 1925 future. If the VALIDATE option is requested, the KDC will check that 1926 the starttime has passed and the INVALID flag is set. If the PROXY 1927 option is requested, then the KDC will check that the PROXIABLE flag 1928 is set in the ticket. If the tests succeed, and the ticket passes the 1929 hotlist check described in the next section, the KDC will issue the 1930 appropriate new ticket. 1932 The ciphertext part of the response in the KRB_TGS_REP message is 1933 encrypted in the sub-session key from the Authenticator, if present, 1934 or the session key from the ticket-granting ticket. It is not 1935 encrypted using the client's secret key. Furthermore, the client's 1936 key's expiration date and the key version number fields are left out 1937 since these values are stored along with the client's database 1938 record, and that record is not needed to satisfy a request based on a 1939 ticket-granting ticket. 1941 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 1943 3.3.3.1. Checking for revoked tickets 1945 Whenever a request is made to the ticket-granting server, the 1946 presented ticket(s) is(are) checked against a hot-list of tickets 1947 which have been canceled. This hot-list might be implemented by 1948 storing a range of issue timestamps for 'suspect tickets'; if a 1949 presented ticket had an authtime in that range, it would be rejected. 1950 In this way, a stolen ticket-granting ticket or renewable ticket 1951 cannot be used to gain additional tickets (renewals or otherwise) 1952 once the theft has been reported to the KDC for the realm in which 1953 the server resides. Any normal ticket obtained before it was reported 1954 stolen will still be valid (because they require no interaction with 1955 the KDC), but only until their normal expiration time. If TGT's have 1956 been issued for cross-realm authentication, use of the cross-realm 1957 TGT will not be affected unless the hot-list is propagated to the 1958 KDCs for the realms for which such cross-realm tickets were issued. 1960 3.3.3.2. Encoding the transited field 1962 If the identity of the server in the TGT that is presented to the KDC 1963 as part of the authentication header is that of the ticket-granting 1964 service, but the TGT was issued from another realm, the KDC will look 1965 up the inter-realm key shared with that realm and use that key to 1966 decrypt the ticket. If the ticket is valid, then the KDC will honor 1967 the request, subject to the constraints outlined above in the section 1968 describing the AS exchange. The realm part of the client's identity 1969 will be taken from the ticket-granting ticket. The name of the realm 1970 that issued the ticket-granting ticket, if it is not the realm of the 1971 client principal, will be added to the transited field of the ticket 1972 to be issued. This is accomplished by reading the transited field 1973 from the ticket-granting ticket (which is treated as an unordered set 1974 of realm names), adding the new realm to the set, then constructing 1975 and writing out its encoded (shorthand) form (this may involve a 1976 rearrangement of the existing encoding). 1978 Note that the ticket-granting service does not add the name of its 1979 own realm. Instead, its responsibility is to add the name of the 1980 previous realm. This prevents a malicious Kerberos server from 1981 intentionally leaving out its own name (it could, however, omit other 1982 realms' names). 1984 The names of neither the local realm nor the principal's realm are to 1985 be included in the transited field. They appear elsewhere in the 1986 ticket and both are known to have taken part in authenticating the 1987 principal. Since the endpoints are not included, both local and 1988 single-hop inter-realm authentication result in a transited field 1989 that is empty. 1991 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 1993 Because the name of each realm transited is added to this field, it 1994 might potentially be very long. To decrease the length of this field, 1995 its contents are encoded. The initially supported encoding is 1996 optimized for the normal case of inter-realm communication: a 1997 hierarchical arrangement of realms using either domain or X.500 style 1998 realm names. This encoding (called DOMAIN-X500-COMPRESS) is now 1999 described. 2001 Realm names in the transited field are separated by a ",". The ",", 2002 "\", trailing "."s, and leading spaces (" ") are special characters, 2003 and if they are part of a realm name, they MUST be quoted in the 2004 transited field by preceding them with a "\". 2006 A realm name ending with a "." is interpreted as being prepended to 2007 the previous realm. For example, we can encode traversal of EDU, 2008 MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as: 2010 "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". 2012 Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, 2013 that they would not be included in this field, and we would have: 2015 "EDU,MIT.,WASHINGTON.EDU" 2017 A realm name beginning with a "/" is interpreted as being appended to 2018 the previous realm. For the purpose of appending, the realm 2019 preceding the first listed realm is considered to be the null realm 2020 (""). If a realm name beginning with a "/" is to stand by itself, 2021 then it SHOULD be preceded by a space (" "). For example, we can 2022 encode traversal of /COM/HP/APOLLO, /COM/HP, /COM, and /COM/DEC as: 2024 "/COM,/HP,/APOLLO, /COM/DEC". 2026 Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, 2027 they would not be included in this field, and we would have: 2029 "/COM,/HP" 2031 A null subfield preceding or following a "," indicates that all 2032 realms between the previous realm and the next realm have been 2033 traversed. For the purpose of interpreting null subfields, the 2034 client's realm is considered to precede those in the transited field, 2035 and the server's realm is considered to follow them. Thus, "," means 2036 that all realms along the path between the client and the server have 2037 been traversed. ",EDU, /COM," means that all realms from the client's 2038 realm up to EDU (in a domain style hierarchy) have been traversed, 2039 and that everything from /COM down to the server's realm in an X.500 2040 style has also been traversed. This could occur if the EDU realm in 2042 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 2044 one hierarchy shares an inter-realm key directly with the /COM realm 2045 in another hierarchy. 2047 3.3.4. Receipt of KRB_TGS_REP message 2049 When the KRB_TGS_REP is received by the client, it is processed in 2050 the same manner as the KRB_AS_REP processing described above. The 2051 primary difference is that the ciphertext part of the response must 2052 be decrypted using the sub-session key from the Authenticator, if it 2053 was specified in the request, or the session key from the ticket- 2054 granting ticket, rather than the client's secret key. The server name 2055 returned in the reply is the true principal name of the service. 2057 3.4. The KRB_SAFE Exchange 2059 The KRB_SAFE message MAY be used by clients requiring the ability to 2060 detect modifications of messages they exchange. It achieves this by 2061 including a keyed collision-proof checksum of the user data and some 2062 control information. The checksum is keyed with an encryption key 2063 (usually the last key negotiated via subkeys, or the session key if 2064 no negotiation has occurred). 2066 3.4.1. Generation of a KRB_SAFE message 2068 When an application wishes to send a KRB_SAFE message, it collects 2069 its data and the appropriate control information and computes a 2070 checksum over them. The checksum algorithm should be the keyed 2071 checksum mandated to be implemented along with the crypto system used 2072 for the sub-session or session key. The checksum is generated using 2073 the sub-session key if present, and the session key. Some 2074 implementations use a different checksum algorithm for the KRB_SAFE 2075 messages but doing so in a interoperable manner is not always 2076 possible. 2078 Implementations SHOULD accept any checksum algorithm they implement 2079 that both have adequate security and that have keys compatible with 2080 the sub-session or session key. Unkeyed or non-collision-proof 2081 checksums are not suitable for this use. 2083 The control information for the KRB_SAFE message includes both a 2084 timestamp and a sequence number. The designer of an application using 2085 the KRB_SAFE message MUST choose at least one of the two mechanisms. 2086 This choice SHOULD be based on the needs of the application protocol. 2088 Sequence numbers are useful when all messages sent will be received 2089 by one's peer. Connection state is presently required to maintain the 2090 session key, so maintaining the next sequence number should not 2091 present an additional problem. 2093 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 2095 If the application protocol is expected to tolerate lost messages 2096 without them being resent, the use of the timestamp is the 2097 appropriate replay detection mechanism. Using timestamps is also the 2098 appropriate mechanism for multi-cast protocols where all of one's 2099 peers share a common sub-session key, but some messages will be sent 2100 to a subset of one's peers. 2102 After computing the checksum, the client then transmits the 2103 information and checksum to the recipient in the message format 2104 specified in section 5.6.1. 2106 3.4.2. Receipt of KRB_SAFE message 2108 When an application receives a KRB_SAFE message, it verifies it as 2109 follows. If any error occurs, an error code is reported for use by 2110 the application. 2112 The message is first checked by verifying that the protocol version 2113 and type fields match the current version and KRB_SAFE, respectively. 2114 A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE 2115 error. The application verifies that the checksum used is a 2116 collision-proof keyed checksum that uses keys compatible with the 2117 sub-session or session key as appropriate (or with the application 2118 key derived from the session or sub-session keys), and if it is not, 2119 a KRB_AP_ERR_INAPP_CKSUM error is generated. The sender's address 2120 MUST be included in the control information; the recipient verifies 2121 that the operating system's report of the sender's address matches 2122 the sender's address in the message, and (if a recipient address is 2123 specified or the recipient requires an address) that one of the 2124 recipient's addresses appears as the recipient's address in the 2125 message. To work with network address translation, senders MAY use 2126 the directional address type specified in section 8.1 for the sender 2127 address and not include recipient addresses. A failed match for 2128 either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp 2129 and usec and/or the sequence number fields are checked. If timestamp 2130 and usec are expected and not present, or they are present but not 2131 current, the KRB_AP_ERR_SKEW error is generated. If the server name, 2132 along with the client name, time and microsecond fields from the 2133 Authenticator match any recently-seen (sent or received) such tuples, 2134 the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence 2135 number is included, or a sequence number is expected but not present, 2136 the KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp 2137 and usec or a sequence number is present, a KRB_AP_ERR_MODIFIED error 2138 is generated. Finally, the checksum is computed over the data and 2139 control information, and if it doesn't match the received checksum, a 2140 KRB_AP_ERR_MODIFIED error is generated. 2142 If all the checks succeed, the application is assured that the 2144 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 2146 message was generated by its peer and was not modified in transit. 2148 3.5. The KRB_PRIV Exchange 2150 The KRB_PRIV message MAY be used by clients requiring confidentiality 2151 and the ability to detect modifications of exchanged messages. It 2152 achieves this by encrypting the messages and adding control 2153 information. 2155 3.5.1. Generation of a KRB_PRIV message 2157 When an application wishes to send a KRB_PRIV message, it collects 2158 its data and the appropriate control information (specified in 2159 section 5.7.1) and encrypts them under an encryption key (usually the 2160 last key negotiated via subkeys, or the session key if no negotiation 2161 has occurred). As part of the control information, the client MUST 2162 choose to use either a timestamp or a sequence number (or both); see 2163 the discussion in section 3.4.1 for guidelines on which to use. After 2164 the user data and control information are encrypted, the client 2165 transmits the ciphertext and some 'envelope' information to the 2166 recipient. 2168 3.5.2. Receipt of KRB_PRIV message 2170 When an application receives a KRB_PRIV message, it verifies it as 2171 follows. If any error occurs, an error code is reported for use by 2172 the application. 2174 The message is first checked by verifying that the protocol version 2175 and type fields match the current version and KRB_PRIV, respectively. 2176 A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE 2177 error. The application then decrypts the ciphertext and processes the 2178 resultant plaintext. If decryption shows the data to have been 2179 modified, a KRB_AP_ERR_BAD_INTEGRITY error is generated. 2181 The sender's address MUST be included in the control information; the 2182 recipient verifies that the operating system's report of the sender's 2183 address matches the sender's address in the message. If a recipient 2184 address is specified or the recipient requires an address then one of 2185 the recipient's addresses MUST also appear as the recipient's address 2186 in the message. Where a sender's or receiver's address might not 2187 otherwise match the address in a message because of network address 2188 translation, an application MAY be written to use addresses of the 2189 directional address type in place of the actual network address. 2191 A failed match for either case generates a KRB_AP_ERR_BADADDR error. 2192 To work with network address translation, implementations MAY use the 2193 directional address type defined in section 7.1 for the sender 2195 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 2197 address and include no recipient address. Then the timestamp and usec 2198 and/or the sequence number fields are checked. If timestamp and usec 2199 are expected and not present, or they are present but not current, 2200 the KRB_AP_ERR_SKEW error is generated. If the server name, along 2201 with the client name, time and microsecond fields from the 2202 Authenticator match any recently-seen such tuples, the 2203 KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence number 2204 is included, or a sequence number is expected but not present, the 2205 KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and 2206 usec or a sequence number is present, a KRB_AP_ERR_MODIFIED error is 2207 generated. 2209 If all the checks succeed, the application can assume the message was 2210 generated by its peer, and was securely transmitted (without 2211 intruders able to see the unencrypted contents). 2213 3.6. The KRB_CRED Exchange 2215 The KRB_CRED message MAY be used by clients requiring the ability to 2216 send Kerberos credentials from one host to another. It achieves this 2217 by sending the tickets together with encrypted data containing the 2218 session keys and other information associated with the tickets. 2220 3.6.1. Generation of a KRB_CRED message 2222 When an application wishes to send a KRB_CRED message it first (using 2223 the KRB_TGS exchange) obtains credentials to be sent to the remote 2224 host. It then constructs a KRB_CRED message using the ticket or 2225 tickets so obtained, placing the session key needed to use each 2226 ticket in the key field of the corresponding KrbCredInfo sequence of 2227 the encrypted part of the KRB_CRED message. 2229 Other information associated with each ticket and obtained during the 2230 KRB_TGS exchange is also placed in the corresponding KrbCredInfo 2231 sequence in the encrypted part of the KRB_CRED message. The current 2232 time and, if specifically required by the application (and 2233 communicated from the recipient to the sender by application specific 2234 means) the nonce, s-address, and r-address fields, are placed in the 2235 encrypted part of the KRB_CRED message which is then encrypted under 2236 an encryption key previously exchanged in the KRB_AP exchange 2237 (usually the last key negotiated via subkeys, or the session key if 2238 no negotiation has occurred). 2240 Implementation note: When constructing a KRB_CRED message for 2241 inclusion in a GSSAPI initial context token, the MIT implementation 2242 of Kerberos will not encrypt the KRB_CRED message if the session key 2243 is a DES or triple DES key. For interoperability with MIT, the 2244 Microsoft implementation will not encrypt the KRB_CRED in a GSSAPI 2246 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 2248 token if it is using a DES session key. Starting at version 1.2.5, 2249 MIT Kerberos can receive and decode either encrypted or unencrypted 2250 KRB_CRED tokens in the GSSAPI exchange. The Heimdal implementation of 2251 Kerberos can also accept either encrypted or unencrypted KRB_CRED 2252 messages. Since the KRB_CRED message in a GSSAPI token is encrypted 2253 in the authenticator, the MIT behavior does not present a security 2254 problem, although it is a violation of the Kerberos specification. 2256 3.6.2. Receipt of KRB_CRED message 2258 When an application receives a KRB_CRED message, it verifies it. If 2259 any error occurs, an error code is reported for use by the 2260 application. The message is verified by checking that the protocol 2261 version and type fields match the current version and KRB_CRED, 2262 respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or 2263 KRB_AP_ERR_MSG_TYPE error. The application then decrypts the 2264 ciphertext and processes the resultant plaintext. If decryption shows 2265 the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is 2266 generated. 2268 If present or required, the recipient MAY verify that the operating 2269 system's report of the sender's address matches the sender's address 2270 in the message, and that one of the recipient's addresses appears as 2271 the recipient's address in the message. The address check does not 2272 provide any added security, since the address if present has already 2273 been checked in the KRB_AP_REQ message and there is not any benefit 2274 to be gained by an attacker in reflecting a KRB_CRED message back to 2275 its originator. Thus, the recipient MAY ignore the address even if 2276 present in order to work better in NAT environments. A failed match 2277 for either case generates a KRB_AP_ERR_BADADDR error. Recipients MAY 2278 skip the address check as the KRB_CRED message cannot generally be 2279 reflected back to the originator. The timestamp and usec fields (and 2280 the nonce field if required) are checked next. If the timestamp and 2281 usec are not present, or they are present but not current, the 2282 KRB_AP_ERR_SKEW error is generated. 2284 If all the checks succeed, the application stores each of the new 2285 tickets in its credentials cache together with the session key and 2286 other information in the corresponding KrbCredInfo sequence from the 2287 encrypted part of the KRB_CRED message. 2289 3.7. User to User Authentication Exchanges 2291 User to User authentication provides a method to perform 2292 authentication when the verifier does not have a access to long term 2293 service key. This might be the case when running a server (for 2294 example a window server) as a user on a workstation. In such cases, 2295 the server may have access to the ticket-granting ticket obtained 2297 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 2299 when the user logged in to the workstation, but because the server is 2300 running as an unprivileged user it might not have access to system 2301 keys. Similar situations may arise when running peer-to-peer 2302 applications. 2304 Summary 2305 Message direction Message type Sections 2306 0. Message from application server Not Specified 2307 1. Client to Kerberos KRB_TGS_REQ 3.3 + 5.4.1 2308 2. Kerberos to client KRB_TGS_REP or 3.3 + 5.4.2 2309 KRB_ERROR 5.9.1 2310 3. Client to Application server KRB_AP_REQ 3.2 + 5.5.1 2312 To address this problem, the Kerberos protocol allows the client to 2313 request that the ticket issued by the KDC be encrypted using a 2314 session key from a ticket-granting ticket issued to the party that 2315 will verify the authentication. This ticket-granting ticket must be 2316 obtained from the verifier by means of an exchange external to the 2317 Kerberos protocol, usually as part of the application protocol. This 2318 message is shown in the summary above as message 0. Note that because 2319 the ticket-granting ticket is encrypted in the KDC's secret key, it 2320 can not be used for authentication without posession of the 2321 corresponding secret key. Furthermore, because the verifier does not 2322 reveal the corresponding secret key, providing a copy of the 2323 verifier's ticket-granting ticket does not allow impersonation of the 2324 verifier. 2326 Message 0 in the table above represents an application specific 2327 negotation between the client and server, at the end of which both 2328 have determined that they will use user to user authentication and 2329 the client has obtained the server's TGT. 2331 Next, the client includes the server's TGT as an additional ticket in 2332 its KRB_TGS_REQ request to the KDC (message 1 in the table above) and 2333 specifyies the ENC-TKT-IN-SKEY option in its request. 2335 If validated according to the instructions in 3.3.3, the application 2336 ticket returned to the client (message 2 in the table above) will be 2337 encrypted using the session key from the additional ticket and the 2338 client will note this when it uses or stores the application ticket. 2340 When contacting the server using a ticket obtained for user to user 2341 authentication (message 3 in the table above), the client MUST 2342 specify the USE-SESSION-KEY flag in the ap-options field. This tells 2343 the application server to use the session key associated with its 2344 ticket-granting ticket to decrypt the server ticket provided in the 2345 application request. 2347 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 2349 4. Encryption and Checksum Specifications 2351 The Kerberos protocols described in this document are designed to 2352 encrypt messages of arbitrary sizes, using stream or block encryption 2353 ciphers. Encryption is used to prove the identities of the network 2354 entities participating in message exchanges. The Key Distribution 2355 Center for each realm is trusted by all principals registered in that 2356 realm to store a secret key in confidence. Proof of knowledge of this 2357 secret key is used to verify the authenticity of a principal. 2359 The KDC uses the principal's secret key (in the AS exchange) or a 2360 shared session key (in the TGS exchange) to encrypt responses to 2361 ticket requests; the ability to obtain the secret key or session key 2362 implies the knowledge of the appropriate keys and the identity of the 2363 KDC. The ability of a principal to decrypt the KDC response and 2364 present a Ticket and a properly formed Authenticator (generated with 2365 the session key from the KDC response) to a service verifies the 2366 identity of the principal; likewise the ability of the service to 2367 extract the session key from the Ticket and prove its knowledge 2368 thereof in a response verifies the identity of the service. 2370 [@KCRYPTO] defines a framework for defining encryption and checksum 2371 mechanisms for use with Kerberos. It also defines several such 2372 mechanisms, and more may be added in future updates to that document. 2374 The string-to-key operation provided by [@KCRYPTO] is used to produce 2375 a long-term key for a principal (generally for a user). The default 2376 salt string, if none is provided via pre-authentication data, is the 2377 concatenation of the principal's realm and name components, in order, 2378 with no separators. Unless otherwise indicated, the default string- 2379 to-key opaque parameter set as defined in [@KCRYPTO] is used. 2381 Encrypted data, keys and checksums are transmitted using the 2382 EncryptedData, EncryptionKey and Checksum data objects defined in 2383 section 5.2.9. The encryption, decryption, and checksum operations 2384 described in this document use the corresponding encryption, 2385 decryption, and get_mic operations described in [@KCRYPTO], with 2386 implicit "specific key" generation using the "key usage" values 2387 specified in the description of each EncryptedData or Checksum object 2388 to vary the key for each operation. Note that in some cases, the 2389 value to be used is dependent on the method of choosing the key or 2390 the context of the message. 2392 Key usages are unsigned 32 bit integers; zero is not permitted. The 2393 key usage values for encrypting or checksumming Kerberos messages are 2394 indicated in section 5 along with the message definitions. Key usage 2395 values 512-1023 are reserved for uses internal to a Kerberos 2396 implementation. (For example, seeding a pseudo-random number 2398 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 2400 generator with a value produced by encrypting something with a 2401 session key and a key usage value not used for any other purpose.) 2402 Key usage values between 1024 and 2047 (inclusive) are reserved for 2403 application use; applications SHOULD use even values for encryption 2404 and odd values for checksums within this range. Key usage values are 2405 also summarized in a table in section 7.5.1. 2407 There might exist other documents which define protocols in terms of 2408 the RFC1510 encryption types or checksum types. Such documents would 2409 not know about key usages. In order that these specifications 2410 continue to be meaningful until they are updated, if not key usage 2411 values are specified then key usages 1024 and 1025 must be used to 2412 derive keys for encryption and checksums, respectively (this does not 2413 apply to protocols that do their own encryption independent of this 2414 framework, directly using the key resulting from the Kerberos 2415 authentication exchange.) New protocols defined in terms of the 2416 Kerberos encryption and checksum types SHOULD use their own key usage 2417 values. 2419 Unless otherwise indicated, no cipher state chaining is done from one 2420 encryption operation to another. 2422 Implementation note: While not recommended, some application 2423 protocols will continue to use the key data directly, even if only in 2424 currently existing protocol specifications. An implementation 2425 intended to support general Kerberos applications may therefore need 2426 to make key data available, as well as the attributes and operations 2427 described in [@KCRYPTO]. One of the more common reasons for directly 2428 performing encryption is direct control over negotiation and 2429 selection of a "sufficiently strong" encryption algorithm (in the 2430 context of a given application). While Kerberos does not directly 2431 provide a facility for negotiating encryption types between the 2432 application client and server, there are approaches for using 2433 Kerberos to facilitate this negotiation - for example, a client may 2434 request only "sufficiently strong" session key types from the KDC and 2435 expect that any type returned by the KDC will be understood and 2436 supported by the application server. 2438 5. Message Specifications 2440 NOTE: The ASN.1 collected here should be identical to the contents of 2441 Appendix A. In case of conflict, the contents of Appendix A shall 2442 take precedence. 2444 The Kerberos protocol is defined here in terms of Abstract Syntax 2445 Notation One (ASN.1) [X680], which provides a syntax for specifying 2446 both the abstract layout of protocol messages as well as their 2447 encodings. Implementors not utilizing an existing ASN.1 compiler or 2449 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 2451 support library are cautioned to thoroughly understand the actual 2452 ASN.1 specification to ensure correct implementation behavior, as 2453 there is more complexity in the notation than is immediately obvious, 2454 and some tutorials and guides to ASN.1 are misleading or erroneous. 2456 Note that in several places, there have been changes here from RFC 2457 1510 that change the abstract types. This is in part to address 2458 widespread assumptions that various implementors have made, in some 2459 cases resulting in unintentional violations of the ASN.1 standard. 2460 These are clearly flagged where they occur. The differences between 2461 the abstract types in RFC 1510 and abstract types in this document 2462 can cause incompatible encodings to be emitted when certain encoding 2463 rules, e.g. the Packed Encoding Rules (PER), are used. This 2464 theoretical incompatibility should not be relevant for Kerberos, 2465 since Kerberos explicitly specifies the use of the Distinguished 2466 Encoding Rules (DER). It might be an issue for protocols wishing to 2467 use Kerberos types with other encoding rules. (This practice is not 2468 recommended.) With very few exceptions (most notably the usages of 2469 BIT STRING), the encodings resulting from using the DER remain 2470 identical between the types defined in RFC 1510 and the types defined 2471 in this document. 2473 The type definitions in this section assume an ASN.1 module 2474 definition of the following form: 2476 KerberosV5Spec2 { 2477 iso(1) identified-organization(3) dod(6) internet(1) 2478 security(5) kerberosV5(2) modules(4) krb5spec2(2) 2479 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 2481 -- rest of definitions here 2483 END 2485 This specifies that the tagging context for the module will be 2486 explicit and non-automatic. 2488 Note that in some other publications [RFC1510] [RFC1964], the "dod" 2489 portion of the object identifier is erroneously specified as having 2490 the value "5". In the case of RFC 1964, use of the "correct" OID 2491 value would result in a change in the wire protocol; therefore, it 2492 remains unchanged for now. 2494 Note that elsewhere in this document, nomenclature for various 2495 message types is inconsistent, but seems to largely follow C language 2496 conventions, including use of underscore (_) characters and all-caps 2497 spelling of names intended to be numeric constants. Also, in some 2498 places, identifiers (especially ones refering to constants) are 2500 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 2502 written in all-caps in order to distinguish them from surrounding 2503 explanatory text. 2505 The ASN.1 notation does not permit underscores in identifiers, so in 2506 actual ASN.1 definitions, underscores are replaced with hyphens (-). 2507 Additionally, structure member names and defined values in ASN.1 MUST 2508 begin with a lowercase letter, while type names MUST begin with an 2509 uppercase letter. 2511 5.1. Specific Compatibility Notes on ASN.1 2513 For compatibility purposes, implementors should heed the following 2514 specific notes regarding the use of ASN.1 in Kerberos. These notes do 2515 not describe deviations from standard usage of ASN.1. The purpose of 2516 these notes is to instead describe some historical quirks and non- 2517 compliance of various implementations, as well as historical 2518 ambiguities, which, while being valid ASN.1, can lead to confusion 2519 during implementation. 2521 5.1.1. ASN.1 Distinguished Encoding Rules 2523 The encoding of Kerberos protocol messages shall obey the 2524 Distinguished Encoding Rules (DER) of ASN.1 as described in [X690]. 2525 Some implementations (believed to be primarly ones derived from DCE 2526 1.1 and earlier) are known to use the more general Basic Encoding 2527 Rules (BER); in particular, these implementations send indefinite 2528 encodings of lengths. Implementations MAY accept such encodings in 2529 the interests of backwards compatibility, though implementors are 2530 warned that decoding fully-general BER is fraught with peril. 2532 5.1.2. Optional Integer Fields 2534 Some implementations do not internally distinguish between an omitted 2535 optional integer value and a transmitted value of zero. The places in 2536 the protocol where this is relevant include various microseconds 2537 fields, nonces, and sequence numbers. Implementations SHOULD treat 2538 omitted optional integer values as having been transmitted with a 2539 value of zero, if the application is expecting this. 2541 5.1.3. Empty SEQUENCE OF Types 2543 There are places in the protocol where a message contains a SEQUENCE 2544 OF type as an optional member. This can result in an encoding that 2545 contains an empty SEQUENCE OF encoding. The Kerberos protocol does 2546 not semantically distinguish between an absent optional SEQUENCE OF 2547 type and a present optional but empty SEQUENCE OF type. 2548 Implementations SHOULD NOT send empty SEQUENCE OF encodings that are 2549 marked OPTIONAL, but SHOULD accept them as being equivalent to an 2551 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 2553 omitted OPTIONAL type. In the ASN.1 syntax describing Kerberos 2554 messages, instances of these problematic optional SEQUENCE OF types 2555 are indicated with a comment. 2557 5.1.4. Unrecognized Tag Numbers 2559 Future revisions to this protocol may include new message types with 2560 different APPLICATION class tag numbers. Such revisions should 2561 protect older implementations by only sending the message types to 2562 parties that are known to understand them, e.g. by means of a flag 2563 bit set by the receiver in a preceding request. In the interest of 2564 robust error handling, implementations SHOULD gracefully handle 2565 receiving a message with an unrecognized tag anyway, and return an 2566 error message if appropriate. 2568 5.1.5. Tag Numbers Greater Than 30 2570 A naive implementation of a DER ASN.1 decoder may experience problems 2571 with ASN.1 tag numbers greater than 30, due to such tag numbers being 2572 encoded using more than one byte. Future revisions of this protocol 2573 may utilize tag numbers greater than 30, and implementations SHOULD 2574 be prepared to gracefully return an error, if appropriate, if they do 2575 not recognize the tag. 2577 5.2. Basic Kerberos Types 2579 This section defines a number of basic types that are potentially 2580 used in multiple Kerberos protocol messages. 2582 5.2.1. KerberosString 2584 The original specification of the Kerberos protocol in RFC 1510 uses 2585 GeneralString in numerous places for human-readable string data. 2586 Historical implementations of Kerberos cannot utilize the full power 2587 of GeneralString. This ASN.1 type requires the use of designation 2588 and invocation escape sequences as specified in ISO-2022/ECMA-35 2589 [ISO-2022/ECMA-35] to switch character sets, and the default 2590 character set that is designated as G0 is the ISO-646/ECMA-6 2591 [ISO-646,ECMA-6] International Reference Version (IRV) (aka U.S. 2592 ASCII), which mostly works. 2594 ISO-2022/ECMA-35 defines four character-set code elements (G0..G3) 2595 and two Control-function code elements (C0..C1). DER prohibits the 2596 designation of character sets as any but the G0 and C0 sets. 2597 Unfortunately, this seems to have the side effect of prohibiting the 2598 use of ISO-8859 (ISO Latin) [ISO-8859] character-sets or any other 2599 character-sets that utilize a 96-character set, since it is 2600 prohibited by ISO-2022/ECMA-35 to designate them as the G0 code 2602 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 2604 element. This side effect is being investigated in the ASN.1 2605 standards community. 2607 In practice, many implementations treat GeneralStrings as if they 2608 were 8-bit strings of whichever character set the implementation 2609 defaults to, without regard for correct usage of character-set 2610 designation escape sequences. The default character set is often 2611 determined by the current user's operating system dependent locale. 2612 At least one major implementation places unescaped UTF-8 encoded 2613 Unicode characters in the GeneralString. This failure to adhere to 2614 the GeneralString specifications results in interoperability issues 2615 when conflicting character encodings are utilized by the Kerberos 2616 clients, services, and KDC. 2618 This unfortunate situation is the result of improper documentation of 2619 the restrictions of the ASN.1 GeneralString type in prior Kerberos 2620 specifications. 2622 The new (post-RFC 1510) type KerberosString, defined below, is a 2623 GeneralString that is constrained to only contain characters in 2624 IA5String 2626 KerberosString ::= GeneralString (IA5String) 2628 US-ASCII control characters should in general not be used in 2629 KerberosString, except for cases such as newlines in lengthy error 2630 messages. Control characters SHOULD NOT be used in principal names or 2631 realm names. 2633 For compatibility, implementations MAY choose to accept GeneralString 2634 values that contain characters other than those permitted by 2635 IA5String, but they should be aware that character set designation 2636 codes will likely be absent, and that the encoding should probably be 2637 treated as locale-specific in almost every way. Implementations MAY 2638 also choose to emit GeneralString values that are beyond those 2639 permitted by IA5String, but should be aware that doing so is 2640 extraordinarily risky from an interoperability perspective. 2642 Some existing implementations use GeneralString to encode unescaped 2643 locale-specific characters. This is a violation of the ASN.1 2644 standard. Most of these implementations encode US-ASCII in the left- 2645 hand half, so as long the implementation transmits only US-ASCII, the 2646 ASN.1 standard is not violated in this regard. As soon as such an 2647 implementation encodes unescaped locale-specific characters with the 2648 high bit set, it violates the ASN.1 standard. 2650 Other implementations have been known to use GeneralString to contain 2651 a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8 2653 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 2655 is a different encoding, not a 94 or 96 character "G" set as defined 2656 by ISO 2022. It is believed that these implementations do not even 2657 use the ISO 2022 escape sequence to change the character encoding. 2658 Even if implementations were to announce the change of encoding by 2659 using that escape sequence, the ASN.1 standard prohibits the use of 2660 any escape sequences other than those used to designate/invoke "G" or 2661 "C" sets allowed by GeneralString. 2663 Future revisions to this protocol will almost certainly allow for a 2664 more interoperable representation of principal names, probably 2665 including UTF8String. 2667 Note that applying a new constraint to a previously unconstrained 2668 type constitutes creation of a new ASN.1 type. In this particular 2669 case, the change does not result in a changed encoding under DER. 2671 5.2.2. Realm and PrincipalName 2673 Realm ::= KerberosString 2675 PrincipalName ::= SEQUENCE { 2676 name-type [0] Int32, 2677 name-string [1] SEQUENCE OF KerberosString 2678 } 2680 Kerberos realm names are encoded as KerberosStrings. Realms shall not 2681 contain a character with the code 0 (the US-ASCII NUL). Most realms 2682 will usually consist of several components separated by periods (.), 2683 in the style of Internet Domain Names, or separated by slashes (/) in 2684 the style of X.500 names. Acceptable forms for realm names are 2685 specified in section 6.1.. A PrincipalName is a typed sequence of 2686 components consisting of the following sub-fields: 2688 name-type 2689 This field specifies the type of name that follows. Pre-defined 2690 values for this field are specified in section 6.2. The name-type 2691 SHOULD be treated as a hint. Ignoring the name type, no two names 2692 can be the same (i.e. at least one of the components, or the 2693 realm, must be different). 2695 name-string 2696 This field encodes a sequence of components that form a name, each 2697 component encoded as a KerberosString. Taken together, a 2698 PrincipalName and a Realm form a principal identifier. Most 2699 PrincipalNames will have only a few components (typically one or 2700 two). 2702 5.2.3. KerberosTime 2703 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 2705 KerberosTime ::= GeneralizedTime -- with no fractional seconds 2707 The timestamps used in Kerberos are encoded as GeneralizedTimes. A 2708 KerberosTime value shall not include any fractional portions of the 2709 seconds. As required by the DER, it further shall not include any 2710 separators, and it shall specify the UTC time zone (Z). Example: The 2711 only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6 2712 November 1985 is 19851106210627Z. 2714 5.2.4. Constrained Integer types 2716 Some integer members of types SHOULD be constrained to values 2717 representable in 32 bits, for compatibility with reasonable 2718 implementation limits. 2720 Int32 ::= INTEGER (-2147483648..2147483647) 2721 -- signed values representable in 32 bits 2723 UInt32 ::= INTEGER (0..4294967295) 2724 -- unsigned 32 bit values 2726 Microseconds ::= INTEGER (0..999999) 2727 -- microseconds 2729 While this results in changes to the abstract types from the RFC 1510 2730 version, the encoding in DER should be unaltered. Historical 2731 implementations were typically limited to 32-bit integer values 2732 anyway, and assigned numbers SHOULD fall in the space of integer 2733 values representable in 32 bits in order to promote interoperability 2734 anyway. 2736 There are several integer fields in messages that are constrained to 2737 fixed values. 2739 pvno 2740 also TKT-VNO or AUTHENTICATOR-VNO, this recurring field is always 2741 the constant integer 5. There is no easy way to make this field 2742 into a useful protocol version number, so its value is fixed. 2744 msg-type 2745 this integer field is usually identical to the application tag 2746 number of the containing message type. 2748 5.2.5. HostAddress and HostAddresses 2750 HostAddress ::= SEQUENCE { 2751 addr-type [0] Int32, 2752 address [1] OCTET STRING 2754 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 2756 } 2758 -- NOTE: HostAddresses is always used as an OPTIONAL field and 2759 -- should not be empty. 2760 HostAddresses -- NOTE: subtly different from rfc1510, 2761 -- but has a value mapping and encodes the same 2762 ::= SEQUENCE OF HostAddress 2764 The host address encodings consists of two fields: 2766 addr-type 2767 This field specifies the type of address that follows. Pre-defined 2768 values for this field are specified in section 7.5.3. 2770 address 2771 This field encodes a single address of type addr-type. 2773 5.2.6. AuthorizationData 2775 -- NOTE: AuthorizationData is always used as an OPTIONAL field and 2776 -- should not be empty. 2777 AuthorizationData ::= SEQUENCE OF SEQUENCE { 2778 ad-type [0] Int32, 2779 ad-data [1] OCTET STRING 2780 } 2782 ad-data 2783 This field contains authorization data to be interpreted according 2784 to the value of the corresponding ad-type field. 2786 ad-type 2787 This field specifies the format for the ad-data subfield. All 2788 negative values are reserved for local use. Non-negative values 2789 are reserved for registered use. 2791 Each sequence of type and data is referred to as an authorization 2792 element. Elements MAY be application specific, however, there is a 2793 common set of recursive elements that should be understood by all 2794 implementations. These elements contain other elements embedded 2795 within them, and the interpretation of the encapsulating element 2796 determines which of the embedded elements must be interpreted, and 2797 which may be ignored. 2799 These common authorization data elements are recursively defined, 2800 meaning the ad-data for these types will itself contain a sequence of 2801 authorization data whose interpretation is affected by the 2802 encapsulating element. Depending on the meaning of the encapsulating 2803 element, the encapsulated elements may be ignored, might be 2805 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 2807 interpreted as issued directly by the KDC, or they might be stored in 2808 a separate plaintext part of the ticket. The types of the 2809 encapsulating elements are specified as part of the Kerberos 2810 specification because the behavior based on these values should be 2811 understood across implementations whereas other elements need only be 2812 understood by the applications which they affect. 2814 Authorization data elements are considered critical if present in a 2815 ticket or authenticator. Unless encapsulated in a known authorization 2816 data element amending the criticality of the elements it contains, if 2817 an unknown authorization data element type is received by a server 2818 either in an AP-REQ or in a ticket contained in an AP-REQ, then 2819 authentication MUST fail. Authorization data is intended to restrict 2820 the use of a ticket. If the service cannot determine whether the 2821 restriction applies to that service then a security weakness may 2822 result if the ticket can be used for that service. Authorization 2823 elements that are optional can be enclosed in AD-IF-RELEVANT element. 2825 In the definitions that follow, the value of the ad-type for the 2826 element will be specified as the least significant part of the 2827 subsection number, and the value of the ad-data will be as shown in 2828 the ASN.1 structure that follows the subsection heading. 2830 contents of ad-data ad-type 2832 DER encoding of AD-IF-RELEVANT 1 2834 DER encoding of AD-KDCIssued 4 2836 DER encoding of AD-AND-OR 5 2838 DER encoding of AD-MANDATORY-FOR-KDC 8 2840 5.2.6.1. IF-RELEVANT 2842 AD-IF-RELEVANT ::= AuthorizationData 2844 AD elements encapsulated within the if-relevant element are intended 2845 for interpretation only by application servers that understand the 2846 particular ad-type of the embedded element. Application servers that 2847 do not understand the type of an element embedded within the if- 2848 relevant element MAY ignore the uninterpretable element. This element 2849 promotes interoperability across implementations which may have local 2850 extensions for authorization. The ad-type for AD-IF-RELEVANT is (1). 2852 5.2.6.2. KDCIssued 2854 AD-KDCIssued ::= SEQUENCE { 2856 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 2858 ad-checksum [0] Checksum, 2859 i-realm [1] Realm OPTIONAL, 2860 i-sname [2] PrincipalName OPTIONAL, 2861 elements [3] AuthorizationData 2862 } 2864 ad-checksum 2865 A checksum over the elements field using a cryptographic checksum 2866 method that is identical to the checksum used to protect the 2867 ticket itself (i.e. using the same hash function and the same 2868 encryption algorithm used to encrypt the ticket) using the key 2869 used to protect the ticket, and a key usage value of 19. 2871 i-realm, i-sname 2872 The name of the issuing principal if different from the KDC 2873 itself. This field would be used when the KDC can verify the 2874 authenticity of elements signed by the issuing principal and it 2875 allows this KDC to notify the application server of the validity 2876 of those elements. 2878 elements 2879 A sequence of authorization data elements issued by the KDC. 2881 The KDC-issued ad-data field is intended to provide a means for 2882 Kerberos principal credentials to embed within themselves privilege 2883 attributes and other mechanisms for positive authorization, 2884 amplifying the privileges of the principal beyond what can be done 2885 using a credentials without such an a-data element. 2887 This can not be provided without this element because the definition 2888 of the authorization-data field allows elements to be added at will 2889 by the bearer of a TGT at the time that they request service tickets 2890 and elements may also be added to a delegated ticket by inclusion in 2891 the authenticator. 2893 For KDC-issued elements this is prevented because the elements are 2894 signed by the KDC by including a checksum encrypted using the 2895 server's key (the same key used to encrypt the ticket - or a key 2896 derived from that key). Elements encapsulated with in the KDC-issued 2897 element will be ignored by the application server if this "signature" 2898 is not present. Further, elements encapsulated within this element 2899 from a ticket-granting ticket MAY be interpreted by the KDC, and used 2900 as a basis according to policy for including new signed elements 2901 within derivative tickets, but they will not be copied to a 2902 derivative ticket directly. If they are copied directly to a 2903 derivative ticket by a KDC that is not aware of this element, the 2904 signature will not be correct for the application ticket elements, 2905 and the field will be ignored by the application server. 2907 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 2909 This element and the elements it encapulates MAY be safely ignored by 2910 applications, application servers, and KDCs that do not implement 2911 this element. 2913 The ad-type for AD-KDC-ISSUED is (4). 2915 5.2.6.3. AND-OR 2917 AD-AND-OR ::= SEQUENCE { 2918 condition-count [0] INTEGER, 2919 elements [1] AuthorizationData 2920 } 2922 When restrictive AD elements are encapsulated within the and-or 2923 element, the and-or element is considered satisfied if and only if at 2924 least the number of encapsulated elements specified in condition- 2925 count are satisifed. Therefore, this element MAY be used to 2926 implement an "or" operation by setting the condition-count field to 2927 1, and it MAY specify an "and" operation by setting the condition 2928 count to the number of embedded elements. Application servers that do 2929 not implement this element MUST reject tickets that contain 2930 authorization data elements of this type. 2932 The ad-type for AD-AND-OR is (5). 2934 5.2.6.4. MANDATORY-FOR-KDC 2936 AD-MANDATORY-FOR-KDC ::= AuthorizationData 2938 AD elements encapsulated within the mandatory-for-kdc element are to 2939 be interpreted by the KDC. KDCs that do not understand the type of an 2940 element embedded within the mandatory-for-kdc element MUST reject the 2941 request. 2943 The ad-type for AD-MANDATORY-FOR-KDC is (8). 2945 5.2.7. PA-DATA 2947 Historically, PA-DATA have been known as "pre-authentication data", 2948 meaning that they were used to augment the initial authentication 2949 with the KDC. Since that time, they have also been used as a typed 2950 hole with which to extend protocol exchanges with the KDC. 2952 PA-DATA ::= SEQUENCE { 2953 -- NOTE: first tag is [1], not [0] 2954 padata-type [1] Int32, 2955 padata-value [2] OCTET STRING -- might be encoded AP-REQ 2957 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 2959 } 2961 padata-type 2962 indicates the way that the padata-value element is to be 2963 interpreted. Negative values of padata-type are reserved for 2964 unregistered use; non-negative values are used for a registered 2965 interpretation of the element type. 2967 padata-value 2968 Usually contains the DER encoding of another type; the padata-type 2969 field identifies which type is encoded here. 2971 padata-type name contents of padata-value 2973 1 pa-tgs-req DER encoding of AP-REQ 2975 2 pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP 2977 3 pa-pw-salt salt (not ASN.1 encoded) 2979 11 pa-etype-info DER encoding of ETYPE-INFO 2981 19 pa-etype-info2 DER encoding of ETYPE-INFO2 2983 This field MAY also contain information needed by certain 2984 extensions to the Kerberos protocol. For example, it might be used 2985 to initially verify the identity of a client before any response 2986 is returned. 2988 The padata field can also contain information needed to help the 2989 KDC or the client select the key needed for generating or 2990 decrypting the response. This form of the padata is useful for 2991 supporting the use of certain token cards with Kerberos. The 2992 details of such extensions are specified in separate documents. 2993 See [Pat92] for additional uses of this field. 2995 5.2.7.1. PA-TGS-REQ 2997 In the case of requests for additional tickets (KRB_TGS_REQ), padata- 2998 value will contain an encoded AP-REQ. The checksum in the 2999 authenticator (which MUST be collision-proof) is to be computed over 3000 the KDC-REQ-BODY encoding. 3002 5.2.7.2. Encrypted Timestamp Pre-authentication 3004 There are pre-authentication types that may be used to pre- 3005 authenticate a client by means of an encrypted timestamp. 3007 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 3009 PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC 3011 PA-ENC-TS-ENC ::= SEQUENCE { 3012 patimestamp [0] KerberosTime -- client's time --, 3013 pausec [1] Microseconds OPTIONAL 3014 } 3016 Patimestamp contains the client's time, and pausec contains the 3017 microseconds, which MAY be omitted if a client will not generate more 3018 than one request per second. The ciphertext (padata-value) consists 3019 of the PA-ENC-TS-ENC encoding, encrypted using the client's secret 3020 key and a key usage value of 1. 3022 This pre-authentication type was not present in RFC 1510, but many 3023 implementations support it. 3025 5.2.7.3. PA-PW-SALT 3027 The padata-value for this pre-authentication type contains the salt 3028 for the string-to-key to be used by the client to obtain the key for 3029 decrypting the encrypted part of an AS-REP message. Unfortunately, 3030 for historical reasons, the character set to be used is unspecified 3031 and probably locale-specific. 3033 This pre-authentication type was not present in RFC 1510, but many 3034 implementations support it. It is necessary in any case where the 3035 salt for the string-to-key algorithm is not the default. 3037 In the trivial example, a zero-length salt string is very commonplace 3038 for realms that have converted their principal databases from 3039 Kerberos 4. 3041 A KDC SHOULD NOT send PA-PW-SALT when issuing a KRB-ERROR message 3042 that requests additional pre-authentication. Implementation note: 3043 some KDC implementations issue an erroneous PA-PW-SALT when issuing a 3044 KRB-ERROR message that requests additional pre-authentication. 3045 Therefore, clients SHOULD ignore a PA-PW-SALT accompanying a KRB- 3046 ERROR message that requests additional pre-authentication. 3048 5.2.7.4. PA-ETYPE-INFO 3050 The ETYPE-INFO pre-authentication type is sent by the KDC in a KRB- 3051 ERROR indicating a requirement for additional pre-authentication. It 3052 is usually used to notify a client of which key to use for the 3053 encryption of an encrypted timestamp for the purposes of sending a 3054 PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an 3055 AS-REP to provide information to the client about which key salt to 3056 use for the string-to-key to be used by the client to obtain the key 3058 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 3060 for decrypting the encrypted part the AS-REP. 3062 ETYPE-INFO-ENTRY ::= SEQUENCE { 3063 etype [0] Int32, 3064 salt [1] OCTET STRING OPTIONAL 3065 } 3067 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY 3069 The salt, like that of PA-PW-SALT, is also completely unspecified 3070 with respect to character set and is probably locale-specific. 3072 If ETYPE-INFO is sent in an AS-REP, there shall be exactly one ETYPE- 3073 INFO-ENTRY, and its etype shall match that of the enc-part in the AS- 3074 REP. 3076 This pre-authentication type was not present in RFC 1510, but many 3077 implementations that support encrypted timestamps for pre- 3078 authentication need to support ETYPE-INFO as well. 3080 5.2.7.5. PA-ETYPE-INFO2 3082 The ETYPE-INFO2 pre-authentication type is sent by the KDC in a KRB- 3083 ERROR indicating a requirement for additional pre-authentication. It 3084 is usually used to notify a client of which key to use for the 3085 encryption of an encrypted timestamp for the purposes of sending a 3086 PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an 3087 AS-REP to provide information to the client about which key salt to 3088 use for the string-to-key to be used by the client to obtain the key 3089 for decrypting the encrypted part the AS-REP. 3091 ETYPE-INFO2-ENTRY ::= SEQUENCE { 3092 etype [0] Int32, 3093 salt [1] KerberosString OPTIONAL, 3094 s2kparams [2] OCTET STRING OPTIONAL 3095 } 3097 ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO-ENTRY 3099 The type of the salt is KerberosString, but existing installations 3100 might have locale-specific characters stored in salt strings, and 3101 implementors MAY choose to handle them. 3103 The interpretation of s2kparams is specified in the cryptosystem 3104 description associated with the etype. Each cryptosystem has a 3105 default interpretation of s2kparams that will hold if that element is 3106 omitted from the encoding of ETYPE-INFO2-ENTRY. 3108 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 3110 If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one 3111 ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part in 3112 the AS-REP. 3114 The preferred ordering of pre-authentication data that modify client 3115 key selection is: ETYPE-INFO2, followed by ETYPE-INFO, followed by 3116 PW-SALT. A KDC shall send all of these pre-authentication data that 3117 it supports, in the preferred ordering, when issuing an AS-REP or 3118 when issuing a KRB-ERROR requesting additional pre-authentication. 3120 The ETYPE-INFO2 pre-authentication type was not present in RFC 1510. 3122 5.2.8. KerberosFlags 3124 For several message types, a specific constrained bit string type, 3125 KerberosFlags, is used. 3127 KerberosFlags ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits 3128 -- shall be sent, but no fewer than 32 3130 Compatibility note: the following paragraphs describe a change from 3131 the RFC1510 description of bit strings that would result in 3132 incompatility in the case of an implementation that strictly 3133 conformed to ASN.1 DER and RFC1510. 3135 ASN.1 bit strings have multiple uses. The simplest use of a bit 3136 string is to contain a vector of bits, with no particular meaning 3137 attached to individual bits. This vector of bits is not necessarily a 3138 multiple of eight bits long. The use in Kerberos of a bit string as 3139 a compact boolean vector wherein each element has a distinct meaning 3140 poses some problems. The natural notation for a compact boolean 3141 vector is the ASN.1 "NamedBit" notation, and the DER require that 3142 encodings of a bit string using "NamedBit" notation exclude any 3143 trailing zero bits. This truncation is easy to neglect, especially 3144 given C language implementations that naturally choose to store 3145 boolean vectors as 32 bit integers. 3147 For example, if the notation for KDCOptions were to include the 3148 "NamedBit" notation, as in RFC 1510, and a KDCOptions value to be 3149 encoded had only the "forwardable" (bit number one) bit set, the DER 3150 encoding MUST include only two bits: the first reserved bit 3151 ("reserved", bit number zero, value zero) and the one-valued bit (bit 3152 number one) for "forwardable". 3154 Most existing implementations of Kerberos unconditionally send 32 3155 bits on the wire when encoding bit strings used as boolean vectors. 3156 This behavior violates the ASN.1 syntax used for flag values in RFC 3157 1510, but occurs on such a widely installed base that the protocol 3159 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 3161 description is being modified to accomodate it. 3163 Consequently, this document removes the "NamedBit" notations for 3164 individual bits, relegating them to comments. The size constraint on 3165 the KerberosFlags type requires that at least 32 bits be encoded at 3166 all times, though a lenient implementation MAY choose to accept fewer 3167 than 32 bits and to treat the missing bits as set to zero. 3169 Currently, no uses of KerberosFlags specify more than 32 bits worth 3170 of flags, although future revisions of this document may do so. When 3171 more than 32 bits are to be transmitted in a KerberosFlags value, 3172 future revisions to this document will likely specify that the 3173 smallest number of bits needed to encode the highest-numbered one- 3174 valued bit should be sent. This is somewhat similar to the DER 3175 encoding of a bit string that is declared with the "NamedBit" 3176 notation. 3178 5.2.9. Cryptosystem-related Types 3180 Many Kerberos protocol messages contain an EncryptedData as a 3181 container for arbitrary encrypted data, which is often the encrypted 3182 encoding of another data type. Fields within EncryptedData assist the 3183 recipient in selecting a key with which to decrypt the enclosed data. 3185 EncryptedData ::= SEQUENCE { 3186 etype [0] Int32 -- EncryptionType --, 3187 kvno [1] UInt32 OPTIONAL, 3188 cipher [2] OCTET STRING -- ciphertext 3189 } 3191 etype 3192 This field identifies which encryption algorithm was used to 3193 encipher the cipher. 3195 kvno 3196 This field contains the version number of the key under which data 3197 is encrypted. It is only present in messages encrypted under long 3198 lasting keys, such as principals' secret keys. 3200 cipher 3201 This field contains the enciphered text, encoded as an OCTET 3202 STRING. (Note that the encryption mechanisms defined in 3203 [@KCRYPTO] MUST incorporate integrity protection as well, so no 3204 additional checksum is required.) 3206 The EncryptionKey type is the means by which cryptographic keys used 3207 for encryption are transfered. 3209 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 3211 EncryptionKey ::= SEQUENCE { 3212 keytype [0] Int32 -- actually encryption type --, 3213 keyvalue [1] OCTET STRING 3214 } 3216 keytype 3217 This field specifies the encryption type of the encryption key 3218 that follows in the keyvalue field. While its name is "keytype", 3219 it actually specifies an encryption type. Previously, multiple 3220 cryptosystems that performed encryption differently but were 3221 capable of using keys with the same characteristics were permitted 3222 to share an assigned number to designate the type of key; this 3223 usage is now deprecated. 3225 keyvalue 3226 This field contains the key itself, encoded as an octet string. 3228 Messages containing cleartext data to be authenticated will usually 3229 do so by using a member of type Checksum. Most instances of Checksum 3230 use a keyed hash, though exceptions will be noted. 3232 Checksum ::= SEQUENCE { 3233 cksumtype [0] Int32, 3234 checksum [1] OCTET STRING 3235 } 3237 cksumtype 3238 This field indicates the algorithm used to generate the 3239 accompanying checksum. 3241 checksum 3242 This field contains the checksum itself, encoded as an octet 3243 string. 3245 See section 4 for a brief description of the use of encryption and 3246 checksums in Kerberos. 3248 5.3. Tickets 3250 This section describes the format and encryption parameters for 3251 tickets and authenticators. When a ticket or authenticator is 3252 included in a protocol message it is treated as an opaque object. A 3253 ticket is a record that helps a client authenticate to a service. A 3254 Ticket contains the following information: 3256 Ticket ::= [APPLICATION 1] SEQUENCE { 3257 tkt-vno [0] INTEGER (5), 3258 realm [1] Realm, 3260 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 3262 sname [2] PrincipalName, 3263 enc-part [3] EncryptedData -- EncTicketPart 3264 } 3266 -- Encrypted part of ticket 3267 EncTicketPart ::= [APPLICATION 3] SEQUENCE { 3268 flags [0] TicketFlags, 3269 key [1] EncryptionKey, 3270 crealm [2] Realm, 3271 cname [3] PrincipalName, 3272 transited [4] TransitedEncoding, 3273 authtime [5] KerberosTime, 3274 starttime [6] KerberosTime OPTIONAL, 3275 endtime [7] KerberosTime, 3276 renew-till [8] KerberosTime OPTIONAL, 3277 caddr [9] HostAddresses OPTIONAL, 3278 authorization-data [10] AuthorizationData OPTIONAL 3279 } 3281 -- encoded Transited field 3282 TransitedEncoding ::= SEQUENCE { 3283 tr-type [0] Int32 -- must be registered --, 3284 contents [1] OCTET STRING 3285 } 3287 TicketFlags ::= KerberosFlags 3288 -- reserved(0), 3289 -- forwardable(1), 3290 -- forwarded(2), 3291 -- proxiable(3), 3292 -- proxy(4), 3293 -- may-postdate(5), 3294 -- postdated(6), 3295 -- invalid(7), 3296 -- renewable(8), 3297 -- initial(9), 3298 -- pre-authent(10), 3299 -- hw-authent(11), 3300 -- the following are new since 1510 3301 -- transited-policy-checked(12), 3302 -- ok-as-delegate(13) 3304 tkt-vno 3305 This field specifies the version number for the ticket format. 3306 This document describes version number 5. 3308 realm 3309 This field specifies the realm that issued a ticket. It also 3311 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 3313 serves to identify the realm part of the server's principal 3314 identifier. Since a Kerberos server can only issue tickets for 3315 servers within its realm, the two will always be identical. 3317 sname 3318 This field specifies all components of the name part of the 3319 server's identity, including those parts that identify a specific 3320 instance of a service. 3322 enc-part 3323 This field holds the encrypted encoding of the EncTicketPart 3324 sequence. It is encrypted in the key shared by Kerberos and the 3325 end server (the server's secret key), using a key usage value of 3326 2. 3328 flags 3329 This field indicates which of various options were used or 3330 requested when the ticket was issued. The meanings of the flags 3331 are: 3333 Bit(s) Name Description 3335 0 reserved Reserved for future expansion of this 3336 field. 3338 The FORWARDABLE flag is normally only 3339 interpreted by the TGS, and can be 3340 ignored by end servers. When set, this 3341 1 forwardable flag tells the ticket-granting server 3342 that it is OK to issue a new 3343 ticket-granting ticket with a 3344 different network address based on the 3345 presented ticket. 3347 When set, this flag indicates that the 3348 ticket has either been forwarded or 3349 2 forwarded was issued based on authentication 3350 involving a forwarded ticket-granting 3351 ticket. 3353 The PROXIABLE flag is normally only 3354 interpreted by the TGS, and can be 3355 ignored by end servers. The PROXIABLE 3356 flag has an interpretation identical 3357 3 proxiable to that of the FORWARDABLE flag, 3358 except that the PROXIABLE flag tells 3359 the ticket-granting server that only 3360 non-ticket-granting tickets may be 3362 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 3364 issued with different network 3365 addresses. 3367 4 proxy When set, this flag indicates that a 3368 ticket is a proxy. 3370 The MAY-POSTDATE flag is normally only 3371 interpreted by the TGS, and can be 3372 5 may-postdate ignored by end servers. This flag 3373 tells the ticket-granting server that 3374 a post-dated ticket MAY be issued 3375 based on this ticket-granting ticket. 3377 This flag indicates that this ticket 3378 has been postdated. The end-service 3379 6 postdated can check the authtime field to see 3380 when the original authentication 3381 occurred. 3383 This flag indicates that a ticket is 3384 invalid, and it must be validated by 3385 7 invalid the KDC before use. Application 3386 servers must reject tickets which have 3387 this flag set. 3389 The RENEWABLE flag is normally only 3390 interpreted by the TGS, and can 3391 usually be ignored by end servers 3392 8 renewable (some particularly careful servers MAY 3393 disallow renewable tickets). A 3394 renewable ticket can be used to obtain 3395 a replacement ticket that expires at a 3396 later date. 3398 This flag indicates that this ticket 3399 9 initial was issued using the AS protocol, and 3400 not issued based on a ticket-granting 3401 ticket. 3403 This flag indicates that during 3404 initial authentication, the client was 3405 authenticated by the KDC before a 3406 10 pre-authent ticket was issued. The strength of the 3407 pre-authentication method is not 3408 indicated, but is acceptable to the 3409 KDC. 3411 This flag indicates that the protocol 3413 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 3415 employed for initial authentication 3416 required the use of hardware expected 3417 11 hw-authent to be possessed solely by the named 3418 client. The hardware authentication 3419 method is selected by the KDC and the 3420 strength of the method is not 3421 indicated. 3423 This flag indicates that the KDC for 3424 the realm has checked the transited 3425 field against a realm defined policy 3426 for trusted certifiers. If this flag 3427 is reset (0), then the application 3428 server must check the transited field 3429 itself, and if unable to do so it must 3430 reject the authentication. If the flag 3431 12 transited- is set (1) then the application server 3432 policy-checked MAY skip its own validation of the 3433 transited field, relying on the 3434 validation performed by the KDC. At 3435 its option the application server MAY 3436 still apply its own validation based 3437 on a separate policy for acceptance. 3439 This flag is new since RFC 1510. 3441 This flag indicates that the server 3442 (not the client) specified in the 3443 ticket has been determined by policy 3444 of the realm to be a suitable 3445 recipient of delegation. A client can 3446 use the presence of this flag to help 3447 it make a decision whether to delegate 3448 credentials (either grant a proxy or a 3449 forwarded ticket-granting ticket) to 3450 13 ok-as-delegate this server. The client is free to 3451 ignore the value of this flag. When 3452 setting this flag, an administrator 3453 should consider the Security and 3454 placement of the server on which the 3455 service will run, as well as whether 3456 the service requires the use of 3457 delegated credentials. 3459 This flag is new since RFC 1510. 3461 14-31 reserved Reserved for future use. 3463 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 3465 key 3466 This field exists in the ticket and the KDC response and is used 3467 to pass the session key from Kerberos to the application server 3468 and the client. 3470 crealm 3471 This field contains the name of the realm in which the client is 3472 registered and in which initial authentication took place. 3474 cname 3475 This field contains the name part of the client's principal 3476 identifier. 3478 transited 3479 This field lists the names of the Kerberos realms that took part 3480 in authenticating the user to whom this ticket was issued. It does 3481 not specify the order in which the realms were transited. See 3482 section 3.3.3.2 for details on how this field encodes the 3483 traversed realms. When the names of CA's are to be embedded in 3484 the transited field (as specified for some extensions to the 3485 protocol), the X.500 names of the CA's SHOULD be mapped into items 3486 in the transited field using the mapping defined by RFC2253. 3488 authtime 3489 This field indicates the time of initial authentication for the 3490 named principal. It is the time of issue for the original ticket 3491 on which this ticket is based. It is included in the ticket to 3492 provide additional information to the end service, and to provide 3493 the necessary information for implementation of a `hot list' 3494 service at the KDC. An end service that is particularly paranoid 3495 could refuse to accept tickets for which the initial 3496 authentication occurred "too far" in the past. This field is also 3497 returned as part of the response from the KDC. When returned as 3498 part of the response to initial authentication (KRB_AS_REP), this 3499 is the current time on the Kerberos server. It is NOT recommended 3500 that this time value be used to adjust the workstation's clock 3501 since the workstation cannot reliably determine that such a 3502 KRB_AS_REP actually came from the proper KDC in a timely manner. 3504 starttime 3506 This field in the ticket specifies the time after which the ticket 3507 is valid. Together with endtime, this field specifies the life of 3508 the ticket. If the starttime field is absent from the ticket, then 3509 the authtime field SHOULD be used in its place to determine the 3510 life of the ticket. 3512 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 3514 endtime 3515 This field contains the time after which the ticket will not be 3516 honored (its expiration time). Note that individual services MAY 3517 place their own limits on the life of a ticket and MAY reject 3518 tickets which have not yet expired. As such, this is really an 3519 upper bound on the expiration time for the ticket. 3521 renew-till 3522 This field is only present in tickets that have the RENEWABLE flag 3523 set in the flags field. It indicates the maximum endtime that may 3524 be included in a renewal. It can be thought of as the absolute 3525 expiration time for the ticket, including all renewals. 3527 caddr 3528 This field in a ticket contains zero (if omitted) or more (if 3529 present) host addresses. These are the addresses from which the 3530 ticket can be used. If there are no addresses, the ticket can be 3531 used from any location. The decision by the KDC to issue or by the 3532 end server to accept addressless tickets is a policy decision and 3533 is left to the Kerberos and end-service administrators; they MAY 3534 refuse to issue or accept such tickets. Because of the wide 3535 deployment of network address translation, it is recommended that 3536 policy allow the issue and acceptance of such tickets. 3538 Network addresses are included in the ticket to make it harder for 3539 an attacker to use stolen credentials. Because the session key is 3540 not sent over the network in cleartext, credentials can't be 3541 stolen simply by listening to the network; an attacker has to gain 3542 access to the session key (perhaps through operating system 3543 security breaches or a careless user's unattended session) to make 3544 use of stolen tickets. 3546 It is important to note that the network address from which a 3547 connection is received cannot be reliably determined. Even if it 3548 could be, an attacker who has compromised the client's workstation 3549 could use the credentials from there. Including the network 3550 addresses only makes it more difficult, not impossible, for an 3551 attacker to walk off with stolen credentials and then use them 3552 from a "safe" location. 3554 authorization-data 3555 The authorization-data field is used to pass authorization data 3556 from the principal on whose behalf a ticket was issued to the 3557 application service. If no authorization data is included, this 3558 field will be left out. Experience has shown that the name of this 3559 field is confusing, and that a better name for this field would be 3560 restrictions. Unfortunately, it is not possible to change the name 3561 of this field at this time. 3563 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 3565 This field contains restrictions on any authority obtained on the 3566 basis of authentication using the ticket. It is possible for any 3567 principal in posession of credentials to add entries to the 3568 authorization data field since these entries further restrict what 3569 can be done with the ticket. Such additions can be made by 3570 specifying the additional entries when a new ticket is obtained 3571 during the TGS exchange, or they MAY be added during chained 3572 delegation using the authorization data field of the 3573 authenticator. 3575 Because entries may be added to this field by the holder of 3576 credentials, except when an entry is separately authenticated by 3577 encapsulation in the KDC-issued element, it is not allowable for 3578 the presence of an entry in the authorization data field of a 3579 ticket to amplify the privileges one would obtain from using a 3580 ticket. 3582 The data in this field may be specific to the end service; the 3583 field will contain the names of service specific objects, and the 3584 rights to those objects. The format for this field is described in 3585 section 5.2.6. Although Kerberos is not concerned with the format 3586 of the contents of the sub-fields, it does carry type information 3587 (ad-type). 3589 By using the authorization_data field, a principal is able to 3590 issue a proxy that is valid for a specific purpose. For example, a 3591 client wishing to print a file can obtain a file server proxy to 3592 be passed to the print server. By specifying the name of the file 3593 in the authorization_data field, the file server knows that the 3594 print server can only use the client's rights when accessing the 3595 particular file to be printed. 3597 A separate service providing authorization or certifying group 3598 membership may be built using the authorization-data field. In 3599 this case, the entity granting authorization (not the authorized 3600 entity), may obtain a ticket in its own name (e.g. the ticket is 3601 issued in the name of a privilege server), and this entity adds 3602 restrictions on its own authority and delegates the restricted 3603 authority through a proxy to the client. The client would then 3604 present this authorization credential to the application server 3605 separately from the authentication exchange. Alternatively, such 3606 authorization credentials MAY be embedded in the ticket 3607 authenticating the authorized entity, when the authorization is 3608 separately authenticated using the KDC-issued authorization data 3609 element (see 5.2.6.2). 3611 Similarly, if one specifies the authorization-data field of a 3612 proxy and leaves the host addresses blank, the resulting ticket 3614 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 3616 and session key can be treated as a capability. See [Neu93] for 3617 some suggested uses of this field. 3619 The authorization-data field is optional and does not have to be 3620 included in a ticket. 3622 5.4. Specifications for the AS and TGS exchanges 3624 This section specifies the format of the messages used in the 3625 exchange between the client and the Kerberos server. The format of 3626 possible error messages appears in section 5.9.1. 3628 5.4.1. KRB_KDC_REQ definition 3630 The KRB_KDC_REQ message has no application tag number of its own. 3631 Instead, it is incorporated into one of KRB_AS_REQ or KRB_TGS_REQ, 3632 which each have an application tag, depending on whether the request 3633 is for an initial ticket or an additional ticket. In either case, the 3634 message is sent from the client to the KDC to request credentials for 3635 a service. 3637 The message fields are: 3639 AS-REQ ::= [APPLICATION 10] KDC-REQ 3641 TGS-REQ ::= [APPLICATION 12] KDC-REQ 3643 KDC-REQ ::= SEQUENCE { 3644 -- NOTE: first tag is [1], not [0] 3645 pvno [1] INTEGER (5) , 3646 msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --), 3647 padata [3] SEQUENCE OF PA-DATA OPTIONAL 3648 -- NOTE: not empty --, 3649 req-body [4] KDC-REQ-BODY 3650 } 3652 KDC-REQ-BODY ::= SEQUENCE { 3653 kdc-options [0] KDCOptions, 3654 cname [1] PrincipalName OPTIONAL 3655 -- Used only in AS-REQ --, 3656 realm [2] Realm 3657 -- Server's realm 3658 -- Also client's in AS-REQ --, 3659 sname [3] PrincipalName OPTIONAL, 3660 from [4] KerberosTime OPTIONAL, 3661 till [5] KerberosTime, 3662 rtime [6] KerberosTime OPTIONAL, 3663 nonce [7] UInt32, 3665 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 3667 etype [8] SEQUENCE OF Int32 -- EncryptionType 3668 -- in preference order --, 3669 addresses [9] HostAddresses OPTIONAL, 3670 enc-authorization-data [10] EncryptedData -- AuthorizationData --, 3671 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 3672 -- NOTE: not empty 3673 } 3675 KDCOptions ::= KerberosFlags 3676 -- reserved(0), 3677 -- forwardable(1), 3678 -- forwarded(2), 3679 -- proxiable(3), 3680 -- proxy(4), 3681 -- allow-postdate(5), 3682 -- postdated(6), 3683 -- unused7(7), 3684 -- renewable(8), 3685 -- unused9(9), 3686 -- unused10(10), 3687 -- opt-hardware-auth(11), 3688 -- unused12(12), 3689 -- unused13(13), 3690 -- 15 is reserved for canonicalize 3691 -- unused15(15), 3692 -- 26 was unused in 1510 3693 -- disable-transited-check(26), 3694 -- 3695 -- renewable-ok(27), 3696 -- enc-tkt-in-skey(28), 3697 -- renew(30), 3698 -- validate(31) 3700 The fields in this message are: 3702 pvno 3703 This field is included in each message, and specifies the protocol 3704 version number. This document specifies protocol version 5. 3706 msg-type 3707 This field indicates the type of a protocol message. It will 3708 almost always be the same as the application identifier associated 3709 with a message. It is included to make the identifier more readily 3710 accessible to the application. For the KDC-REQ message, this type 3711 will be KRB_AS_REQ or KRB_TGS_REQ. 3713 padata 3714 Contains pre-authentication data. Requests for additional tickets 3716 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 3718 (KRB_TGS_REQ) MUST contain a padata of PA-TGS-REQ. 3720 The padata (pre-authentication data) field contains a sequence of 3721 authentication information which may be needed before credentials 3722 can be issued or decrypted. 3724 req-body 3725 This field is a placeholder delimiting the extent of the remaining 3726 fields. If a checksum is to be calculated over the request, it is 3727 calculated over an encoding of the KDC-REQ-BODY sequence which is 3728 enclosed within the req-body field. 3730 kdc-options 3731 This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to 3732 the KDC and indicates the flags that the client wants set on the 3733 tickets as well as other information that is to modify the 3734 behavior of the KDC. Where appropriate, the name of an option may 3735 be the same as the flag that is set by that option. Although in 3736 most case, the bit in the options field will be the same as that 3737 in the flags field, this is not guaranteed, so it is not 3738 acceptable to simply copy the options field to the flags field. 3739 There are various checks that must be made before honoring an 3740 option anyway. 3742 The kdc_options field is a bit-field, where the selected options 3743 are indicated by the bit being set (1), and the unselected options 3744 and reserved fields being reset (0). The encoding of the bits is 3745 specified in section 5.2. The options are described in more detail 3746 above in section 2. The meanings of the options are: 3748 Bits Name Description 3750 0 RESERVED Reserved for future expansion of 3751 this field. 3753 The FORWARDABLE option indicates 3754 that the ticket to be issued is to 3755 have its forwardable flag set. It 3756 1 FORWARDABLE may only be set on the initial 3757 request, or in a subsequent request 3758 if the ticket-granting ticket on 3759 which it is based is also 3760 forwardable. 3762 The FORWARDED option is only 3763 specified in a request to the 3764 ticket-granting server and will only 3765 be honored if the ticket-granting 3767 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 3769 ticket in the request has its 3770 2 FORWARDED FORWARDABLE bit set. This option 3771 indicates that this is a request for 3772 forwarding. The address(es) of the 3773 host from which the resulting ticket 3774 is to be valid are included in the 3775 addresses field of the request. 3777 The PROXIABLE option indicates that 3778 the ticket to be issued is to have 3779 its proxiable flag set. It may only 3780 3 PROXIABLE be set on the initial request, or in 3781 a subsequent request if the 3782 ticket-granting ticket on which it 3783 is based is also proxiable. 3785 The PROXY option indicates that this 3786 is a request for a proxy. This 3787 option will only be honored if the 3788 ticket-granting ticket in the 3789 4 PROXY request has its PROXIABLE bit set. 3790 The address(es) of the host from 3791 which the resulting ticket is to be 3792 valid are included in the addresses 3793 field of the request. 3795 The ALLOW-POSTDATE option indicates 3796 that the ticket to be issued is to 3797 have its MAY-POSTDATE flag set. It 3798 5 ALLOW-POSTDATE may only be set on the initial 3799 request, or in a subsequent request 3800 if the ticket-granting ticket on 3801 which it is based also has its 3802 MAY-POSTDATE flag set. 3804 The POSTDATED option indicates that 3805 this is a request for a postdated 3806 ticket. This option will only be 3807 honored if the ticket-granting 3808 ticket on which it is based has its 3809 6 POSTDATED MAY-POSTDATE flag set. The resulting 3810 ticket will also have its INVALID 3811 flag set, and that flag may be reset 3812 by a subsequent request to the KDC 3813 after the starttime in the ticket 3814 has been reached. 3816 7 RESERVED This option is presently unused. 3818 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 3820 The RENEWABLE option indicates that 3821 the ticket to be issued is to have 3822 its RENEWABLE flag set. It may only 3823 be set on the initial request, or 3824 when the ticket-granting ticket on 3825 8 RENEWABLE which the request is based is also 3826 renewable. If this option is 3827 requested, then the rtime field in 3828 the request contains the desired 3829 absolute expiration time for the 3830 ticket. 3832 9 RESERVED Reserved for PK-Cross 3834 10 RESERVED Reserved for future use. 3836 11 RESERVED Reserved for opt-hardware-auth. 3838 12-25 RESERVED Reserved for future use. 3840 By default the KDC will check the 3841 transited field of a 3842 ticket-granting-ticket against the 3843 policy of the local realm before it 3844 will issue derivative tickets based 3845 on the ticket-granting ticket. If 3846 this flag is set in the request, 3847 checking of the transited field is 3848 disabled. Tickets issued without the 3849 26 DISABLE-TRANSITED-CHECK performance of this check will be 3850 noted by the reset (0) value of the 3851 TRANSITED-POLICY-CHECKED flag, 3852 indicating to the application server 3853 that the tranisted field must be 3854 checked locally. KDCs are 3855 encouraged but not required to honor 3856 the DISABLE-TRANSITED-CHECK option. 3858 This flag is new since RFC 1510 3860 The RENEWABLE-OK option indicates 3861 that a renewable ticket will be 3862 acceptable if a ticket with the 3863 requested life cannot otherwise be 3864 provided. If a ticket with the 3865 requested life cannot be provided, 3866 27 RENEWABLE-OK then a renewable ticket may be 3867 issued with a renew-till equal to 3869 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 3871 the requested endtime. The value 3872 of the renew-till field may still be 3873 limited by local limits, or limits 3874 selected by the individual principal 3875 or server. 3877 This option is used only by the 3878 ticket-granting service. The 3879 ENC-TKT-IN-SKEY option indicates 3880 28 ENC-TKT-IN-SKEY that the ticket for the end server 3881 is to be encrypted in the session 3882 key from the additional 3883 ticket-granting ticket provided. 3885 29 RESERVED Reserved for future use. 3887 This option is used only by the 3888 ticket-granting service. The RENEW 3889 option indicates that the present 3890 request is for a renewal. The ticket 3891 provided is encrypted in the secret 3892 key for the server on which it is 3893 30 RENEW valid. This option will only be 3894 honored if the ticket to be renewed 3895 has its RENEWABLE flag set and if 3896 the time in its renew-till field has 3897 not passed. The ticket to be renewed 3898 is passed in the padata field as 3899 part of the authentication header. 3901 This option is used only by the 3902 ticket-granting service. The 3903 VALIDATE option indicates that the 3904 request is to validate a postdated 3905 ticket. It will only be honored if 3906 the ticket presented is postdated, 3907 presently has its INVALID flag set, 3908 31 VALIDATE and would be otherwise usable at 3909 this time. A ticket cannot be 3910 validated before its starttime. The 3911 ticket presented for validation is 3912 encrypted in the key of the server 3913 for which it is valid and is passed 3914 in the padata field as part of the 3915 authentication header. 3916 cname and sname 3917 These fields are the same as those described for the ticket in 3918 section 5.3. The sname may only be absent when the ENC-TKT-IN-SKEY 3920 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 3922 option is specified. If absent, the name of the server is taken 3923 from the name of the client in the ticket passed as additional- 3924 tickets. 3926 enc-authorization-data 3927 The enc-authorization-data, if present (and it can only be present 3928 in the TGS_REQ form), is an encoding of the desired authorization- 3929 data encrypted under the sub-session key if present in the 3930 Authenticator, or alternatively from the session key in the 3931 ticket-granting ticket (both the Authenticator and ticket-granting 3932 ticket come from the padata field in the KRB_TGS_REQ). The key 3933 usage value used when encrypting is 5 if a sub-session key is 3934 used, or 4 if the session key is used. 3936 realm 3937 This field specifies the realm part of the server's principal 3938 identifier. In the AS exchange, this is also the realm part of the 3939 client's principal identifier. 3941 from 3942 This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket 3943 requests when the requested ticket is to be postdated. It 3944 specifies the desired start time for the requested ticket. If this 3945 field is omitted then the KDC SHOULD use the current time instead. 3947 till 3948 This field contains the expiration date requested by the client in 3949 a ticket request. It is not optional, but if the requested endtime 3950 is "19700101000000Z", the requested ticket is to have the maximum 3951 endtime permitted according to KDC policy. Implementation note: 3952 This special timestamp corresponds to a UNIX time_t value of zero 3953 on most systems. 3955 rtime 3956 This field is the requested renew-till time sent from a client to 3957 the KDC in a ticket request. It is optional. 3959 nonce 3960 This field is part of the KDC request and response. It is intended 3961 to hold a random number generated by the client. If the same 3962 number is included in the encrypted response from the KDC, it 3963 provides evidence that the response is fresh and has not been 3964 replayed by an attacker. Nonces MUST NEVER be reused. 3966 etype 3967 This field specifies the desired encryption algorithm to be used 3968 in the response. 3970 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 3972 addresses 3973 This field is included in the initial request for tickets, and 3974 optionally included in requests for additional tickets from the 3975 ticket-granting server. It specifies the addresses from which the 3976 requested ticket is to be valid. Normally it includes the 3977 addresses for the client's host. If a proxy is requested, this 3978 field will contain other addresses. The contents of this field are 3979 usually copied by the KDC into the caddr field of the resulting 3980 ticket. 3982 additional-tickets 3983 Additional tickets MAY be optionally included in a request to the 3984 ticket-granting server. If the ENC-TKT-IN-SKEY option has been 3985 specified, then the session key from the additional ticket will be 3986 used in place of the server's key to encrypt the new ticket. When 3987 the ENC-TKT-IN-SKEY option is used for user-to-user 3988 authentication, this addional ticket MAY be a TGT issued by the 3989 local realm or an inter-realm TGT issued for the current KDC's 3990 realm by a remote KDC. If more than one option which requires 3991 additional tickets has been specified, then the additional tickets 3992 are used in the order specified by the ordering of the options 3993 bits (see kdc-options, above). 3995 The application tag number will be either ten (10) or twelve (12) 3996 depending on whether the request is for an initial ticket (AS-REQ) or 3997 for an additional ticket (TGS-REQ). 3999 The optional fields (addresses, authorization-data and additional- 4000 tickets) are only included if necessary to perform the operation 4001 specified in the kdc-options field. 4003 It should be noted that in KRB_TGS_REQ, the protocol version number 4004 appears twice and two different message types appear: the KRB_TGS_REQ 4005 message contains these fields as does the authentication header 4006 (KRB_AP_REQ) that is passed in the padata field. 4008 5.4.2. KRB_KDC_REP definition 4010 The KRB_KDC_REP message format is used for the reply from the KDC for 4011 either an initial (AS) request or a subsequent (TGS) request. There 4012 is no message type for KRB_KDC_REP. Instead, the type will be either 4013 KRB_AS_REP or KRB_TGS_REP. The key used to encrypt the ciphertext 4014 part of the reply depends on the message type. For KRB_AS_REP, the 4015 ciphertext is encrypted in the client's secret key, and the client's 4016 key version number is included in the key version number for the 4017 encrypted data. For KRB_TGS_REP, the ciphertext is encrypted in the 4018 sub-session key from the Authenticator, or if absent, the session key 4019 from the ticket-granting ticket used in the request. In that case, 4021 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 4023 no version number will be present in the EncryptedData sequence. 4025 The KRB_KDC_REP message contains the following fields: 4027 AS-REP ::= [APPLICATION 11] KDC-REP 4029 TGS-REP ::= [APPLICATION 13] KDC-REP 4031 KDC-REP ::= SEQUENCE { 4032 pvno [0] INTEGER (5), 4033 msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --), 4034 padata [2] SEQUENCE OF PA-DATA OPTIONAL 4035 -- NOTE: not empty --, 4036 crealm [3] Realm, 4037 cname [4] PrincipalName, 4038 ticket [5] Ticket, 4039 enc-part [6] EncryptedData 4040 -- EncASRepPart or EncTGSRepPart, 4041 -- as appropriate 4042 } 4044 EncASRepPart ::= [APPLICATION 25] EncKDCRepPart 4046 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 4048 EncKDCRepPart ::= SEQUENCE { 4049 key [0] EncryptionKey, 4050 last-req [1] LastReq, 4051 nonce [2] UInt32, 4052 key-expiration [3] KerberosTime OPTIONAL, 4053 flags [4] TicketFlags, 4054 authtime [5] KerberosTime, 4055 starttime [6] KerberosTime OPTIONAL, 4056 endtime [7] KerberosTime, 4057 renew-till [8] KerberosTime OPTIONAL, 4058 srealm [9] Realm, 4059 sname [10] PrincipalName, 4060 caddr [11] HostAddresses OPTIONAL 4061 } 4063 LastReq ::= SEQUENCE OF SEQUENCE { 4064 lr-type [0] Int32, 4065 lr-value [1] KerberosTime 4066 } 4068 pvno and msg-type 4069 These fields are described above in section 5.4.1. msg-type is 4070 either KRB_AS_REP or KRB_TGS_REP. 4072 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 4074 padata 4075 This field is described in detail in section 5.4.1. One possible 4076 use for this field is to encode an alternate "salt" string to be 4077 used with a string-to-key algorithm. This ability is useful to 4078 ease transitions if a realm name needs to change (e.g. when a 4079 company is acquired); in such a case all existing password-derived 4080 entries in the KDC database would be flagged as needing a special 4081 salt string until the next password change. 4083 crealm, cname, srealm and sname 4084 These fields are the same as those described for the ticket in 4085 section 5.3. 4087 ticket 4088 The newly-issued ticket, from section 5.3. 4090 enc-part 4091 This field is a place holder for the ciphertext and related 4092 information that forms the encrypted part of a message. The 4093 description of the encrypted part of the message follows each 4094 appearance of this field. 4096 The key usage value for encrypting this field is 3 in an AS-REP 4097 message, using the client's long-term key or another key selected 4098 via pre-authentication mechanisms. In a TGS-REP message, the key 4099 usage value is 8 if the TGS session key is used, or 9 if a TGS 4100 authenticator subkey is used. 4102 Compatibility note: Some implementations unconditionally send an 4103 encrypted EncTGSRepPart (application tag number 26) in this field 4104 regardless of whether the reply is a AS-REP or a TGS-REP. In the 4105 interests of compatibility, implementors MAY relax the check on 4106 the tag number of the decrypted ENC-PART. 4108 key 4109 This field is the same as described for the ticket in section 5.3. 4111 last-req 4112 This field is returned by the KDC and specifies the time(s) of the 4113 last request by a principal. Depending on what information is 4114 available, this might be the last time that a request for a 4115 ticket-granting ticket was made, or the last time that a request 4116 based on a ticket-granting ticket was successful. It also might 4117 cover all servers for a realm, or just the particular server. Some 4118 implementations MAY display this information to the user to aid in 4119 discovering unauthorized use of one's identity. It is similar in 4120 spirit to the last login time displayed when logging into 4121 timesharing systems. 4123 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 4125 lr-type 4126 This field indicates how the following lr-value field is to be 4127 interpreted. Negative values indicate that the information 4128 pertains only to the responding server. Non-negative values 4129 pertain to all servers for the realm. 4131 If the lr-type field is zero (0), then no information is 4132 conveyed by the lr-value subfield. If the absolute value of the 4133 lr-type field is one (1), then the lr-value subfield is the 4134 time of last initial request for a TGT. If it is two (2), then 4135 the lr-value subfield is the time of last initial request. If 4136 it is three (3), then the lr-value subfield is the time of 4137 issue for the newest ticket-granting ticket used. If it is four 4138 (4), then the lr-value subfield is the time of the last 4139 renewal. If it is five (5), then the lr-value subfield is the 4140 time of last request (of any type). If it is (6), then the lr- 4141 value subfield is the time when the password will expire. If 4142 it is (7), then the lr-value subfield is the time when the 4143 account will expire. 4145 lr-value 4146 This field contains the time of the last request. The time MUST 4147 be interpreted according to the contents of the accompanying 4148 lr-type subfield. 4150 nonce 4151 This field is described above in section 5.4.1. 4153 key-expiration 4154 The key-expiration field is part of the response from the KDC and 4155 specifies the time that the client's secret key is due to expire. 4156 The expiration might be the result of password aging or an account 4157 expiration. If present, it SHOULD be set to the earliest of the 4158 user's key expiration and account expiration. The use of this 4159 field is deprecated and the last-req field SHOULD be used to 4160 convey this information instead. This field will usually be left 4161 out of the TGS reply since the response to the TGS request is 4162 encrypted in a session key and no client information need be 4163 retrieved from the KDC database. It is up to the application 4164 client (usually the login program) to take appropriate action 4165 (such as notifying the user) if the expiration time is imminent. 4167 flags, authtime, starttime, endtime, renew-till and caddr 4168 These fields are duplicates of those found in the encrypted 4169 portion of the attached ticket (see section 5.3), provided so the 4170 client MAY verify they match the intended request and to assist in 4171 proper ticket caching. If the message is of type KRB_TGS_REP, the 4172 caddr field will only be filled in if the request was for a proxy 4174 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 4176 or forwarded ticket, or if the user is substituting a subset of 4177 the addresses from the ticket-granting ticket. If the client- 4178 requested addresses are not present or not used, then the 4179 addresses contained in the ticket will be the same as those 4180 included in the ticket-granting ticket. 4182 5.5. Client/Server (CS) message specifications 4184 This section specifies the format of the messages used for the 4185 authentication of the client to the application server. 4187 5.5.1. KRB_AP_REQ definition 4189 The KRB_AP_REQ message contains the Kerberos protocol version number, 4190 the message type KRB_AP_REQ, an options field to indicate any options 4191 in use, and the ticket and authenticator themselves. The KRB_AP_REQ 4192 message is often referred to as the 'authentication header'. 4194 AP-REQ ::= [APPLICATION 14] SEQUENCE { 4195 pvno [0] INTEGER (5), 4196 msg-type [1] INTEGER (14), 4197 ap-options [2] APOptions, 4198 ticket [3] Ticket, 4199 authenticator [4] EncryptedData -- Authenticator 4200 } 4202 APOptions ::= KerberosFlags 4203 -- reserved(0), 4204 -- use-session-key(1), 4205 -- mutual-required(2) 4207 pvno and msg-type 4208 These fields are described above in section 5.4.1. msg-type is 4209 KRB_AP_REQ. 4211 ap-options 4212 This field appears in the application request (KRB_AP_REQ) and 4213 affects the way the request is processed. It is a bit-field, where 4214 the selected options are indicated by the bit being set (1), and 4215 the unselected options and reserved fields being reset (0). The 4216 encoding of the bits is specified in section 5.2. The meanings of 4217 the options are: 4219 Bit(s) Name Description 4221 0 reserved Reserved for future expansion of this field. 4223 The USE-SESSION-KEY option indicates that the 4225 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 4227 ticket the client is presenting to a server 4228 1 use-session-key is encrypted in the session key from the 4229 server's ticket-granting ticket. When this 4230 option is not specified, the ticket is 4231 encrypted in the server's secret key. 4233 The MUTUAL-REQUIRED option tells the server 4234 2 mutual-required that the client requires mutual 4235 authentication, and that it must respond with 4236 a KRB_AP_REP message. 4238 3-31 reserved Reserved for future use. 4240 ticket 4241 This field is a ticket authenticating the client to the server. 4243 authenticator 4244 This contains the encrypted authenticator, which includes the 4245 client's choice of a subkey. 4247 The encrypted authenticator is included in the AP-REQ; it certifies 4248 to a server that the sender has recent knowledge of the encryption 4249 key in the accompanying ticket, to help the server detect replays. It 4250 also assists in the selection of a "true session key" to use with the 4251 particular session. The DER encoding of the following is encrypted 4252 in the ticket's session key, with a key usage value of 11 in normal 4253 application exchanges, or 7 when used as the PA-TGS-REQ PA-DATA field 4254 of a TGS-REQ exchange (see section 5.4.1): 4256 -- Unencrypted authenticator 4257 Authenticator ::= [APPLICATION 2] SEQUENCE { 4258 authenticator-vno [0] INTEGER (5), 4259 crealm [1] Realm, 4260 cname [2] PrincipalName, 4261 cksum [3] Checksum OPTIONAL, 4262 cusec [4] Microseconds, 4263 ctime [5] KerberosTime, 4264 subkey [6] EncryptionKey OPTIONAL, 4265 seq-number [7] UInt32 OPTIONAL, 4266 authorization-data [8] AuthorizationData OPTIONAL 4267 } 4269 authenticator-vno 4270 This field specifies the version number for the format of the 4271 authenticator. This document specifies version 5. 4273 crealm and cname 4274 These fields are the same as those described for the ticket in 4276 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 4278 section 5.3. 4280 cksum 4281 This field contains a checksum of the application data that 4282 accompanies the KRB_AP_REQ, computed using a key usage value of 10 4283 in normal application exchanges, or 6 when used in the TGS-REQ PA- 4284 TGS-REQ AP-DATA field. 4286 cusec 4287 This field contains the microsecond part of the client's 4288 timestamp. Its value (before encryption) ranges from 0 to 999999. 4289 It often appears along with ctime. The two fields are used 4290 together to specify a reasonably accurate timestamp. 4292 ctime 4293 This field contains the current time on the client's host. 4295 subkey 4296 This field contains the client's choice for an encryption key 4297 which is to be used to protect this specific application session. 4298 Unless an application specifies otherwise, if this field is left 4299 out the session key from the ticket will be used. 4301 seq-number 4302 This optional field includes the initial sequence number to be 4303 used by the KRB_PRIV or KRB_SAFE messages when sequence numbers 4304 are used to detect replays (It may also be used by application 4305 specific messages). When included in the authenticator this field 4306 specifies the initial sequence number for messages from the client 4307 to the server. When included in the AP-REP message, the initial 4308 sequence number is that for messages from the server to the 4309 client. When used in KRB_PRIV or KRB_SAFE messages, it is 4310 incremented by one after each message is sent. Sequence numbers 4311 fall in the range of 0 through 2^32 - 1 and wrap to zero following 4312 the value 2^32 - 1. 4314 For sequence numbers to adequately support the detection of 4315 replays they SHOULD be non-repeating, even across connection 4316 boundaries. The initial sequence number SHOULD be random and 4317 uniformly distributed across the full space of possible sequence 4318 numbers, so that it cannot be guessed by an attacker and so that 4319 it and the successive sequence numbers do not repeat other 4320 sequences. 4322 Implmentation note: historically, some implementations transmit 4323 signed twos-complement numbers for sequence numbers. In the 4324 interests of compatibility, implementations MAY accept the 4325 equivalent negative number where a positive number greater than 4327 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 4329 2^31 - 1 is expected. 4331 Implementation note: as noted before, some implementations omit 4332 the optional sequence number when its value would be zero. 4333 Implementations MAY accept an omitted sequence number when 4334 expecting a value of zero, and SHOULD NOT transmit an 4335 Authenticator with a initial sequence number of zero. 4337 authorization-data 4338 This field is the same as described for the ticket in section 5.3. 4339 It is optional and will only appear when additional restrictions 4340 are to be placed on the use of a ticket, beyond those carried in 4341 the ticket itself. 4343 5.5.2. KRB_AP_REP definition 4345 The KRB_AP_REP message contains the Kerberos protocol version number, 4346 the message type, and an encrypted time-stamp. The message is sent in 4347 response to an application request (KRB_AP_REQ) where the mutual 4348 authentication option has been selected in the ap-options field. 4350 AP-REP ::= [APPLICATION 15] SEQUENCE { 4351 pvno [0] INTEGER (5), 4352 msg-type [1] INTEGER (15), 4353 enc-part [2] EncryptedData -- EncAPRepPart 4354 } 4356 EncAPRepPart ::= [APPLICATION 27] SEQUENCE { 4357 ctime [0] KerberosTime, 4358 cusec [1] Microseconds, 4359 subkey [2] EncryptionKey OPTIONAL, 4360 seq-number [3] UInt32 OPTIONAL 4361 } 4363 The encoded EncAPRepPart is encrypted in the shared session key of 4364 the ticket. The optional subkey field can be used in an application- 4365 arranged negotiation to choose a per association session key. 4367 pvno and msg-type 4368 These fields are described above in section 5.4.1. msg-type is 4369 KRB_AP_REP. 4371 enc-part 4372 This field is described above in section 5.4.2. It is computed 4373 with a key usage value of 12. 4375 ctime 4376 This field contains the current time on the client's host. 4378 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 4380 cusec 4381 This field contains the microsecond part of the client's 4382 timestamp. 4384 subkey 4385 This field contains an encryption key which is to be used to 4386 protect this specific application session. See section 3.2.6 for 4387 specifics on how this field is used to negotiate a key. Unless an 4388 application specifies otherwise, if this field is left out, the 4389 sub-session key from the authenticator, or if also left out, the 4390 session key from the ticket will be used. 4392 seq-number 4393 This field is described above in section 5.3.2. 4395 5.5.3. Error message reply 4397 If an error occurs while processing the application request, the 4398 KRB_ERROR message will be sent in response. See section 5.9.1 for the 4399 format of the error message. The cname and crealm fields MAY be left 4400 out if the server cannot determine their appropriate values from the 4401 corresponding KRB_AP_REQ message. If the authenticator was 4402 decipherable, the ctime and cusec fields will contain the values from 4403 it. 4405 5.6. KRB_SAFE message specification 4407 This section specifies the format of a message that can be used by 4408 either side (client or server) of an application to send a tamper- 4409 proof message to its peer. It presumes that a session key has 4410 previously been exchanged (for example, by using the 4411 KRB_AP_REQ/KRB_AP_REP messages). 4413 5.6.1. KRB_SAFE definition 4415 The KRB_SAFE message contains user data along with a collision-proof 4416 checksum keyed with the last encryption key negotiated via subkeys, 4417 or the session key if no negotiation has occurred. The message fields 4418 are: 4420 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 4421 pvno [0] INTEGER (5), 4422 msg-type [1] INTEGER (20), 4423 safe-body [2] KRB-SAFE-BODY, 4424 cksum [3] Checksum 4425 } 4427 KRB-SAFE-BODY ::= SEQUENCE { 4429 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 4431 user-data [0] OCTET STRING, 4432 timestamp [1] KerberosTime OPTIONAL, 4433 usec [2] Microseconds OPTIONAL, 4434 seq-number [3] UInt32 OPTIONAL, 4435 s-address [4] HostAddress, 4436 r-address [5] HostAddress OPTIONAL 4437 } 4439 pvno and msg-type 4440 These fields are described above in section 5.4.1. msg-type is 4441 KRB_SAFE. 4443 safe-body 4444 This field is a placeholder for the body of the KRB-SAFE message. 4446 cksum 4447 This field contains the checksum of the application data, computed 4448 with a key usage value of 15. 4450 The checksum is computed over the encoding of the KRB-SAFE 4451 sequence. First, the cksum is set to a type zero, zero-length 4452 value and the checksum is computed over the encoding of the KRB- 4453 SAFE sequence, then the checksum is set to the result of that 4454 computation, and finally the KRB-SAFE sequence is encoded again. 4455 This method, while different than the one specified in RFC 1510, 4456 corresponds to existing practice. 4458 user-data 4459 This field is part of the KRB_SAFE and KRB_PRIV messages and 4460 contain the application specific data that is being passed from 4461 the sender to the recipient. 4463 timestamp 4464 This field is part of the KRB_SAFE and KRB_PRIV messages. Its 4465 contents are the current time as known by the sender of the 4466 message. By checking the timestamp, the recipient of the message 4467 is able to make sure that it was recently generated, and is not a 4468 replay. 4470 usec 4471 This field is part of the KRB_SAFE and KRB_PRIV headers. It 4472 contains the microsecond part of the timestamp. 4474 seq-number 4475 This field is described above in section 5.3.2. 4477 s-address 4478 Sender's address. 4480 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 4482 This field specifies the address in use by the sender of the 4483 message. It MAY be omitted if not required by the application 4484 protocol. 4486 r-address 4487 This field specifies the address in use by the recipient of the 4488 message. It MAY be omitted for some uses (such as broadcast 4489 protocols), but the recipient MAY arbitrarily reject such 4490 messages. This field, along with s-address, can be used to help 4491 detect messages which have been incorrectly or maliciously 4492 delivered to the wrong recipient. 4494 5.7. KRB_PRIV message specification 4496 This section specifies the format of a message that can be used by 4497 either side (client or server) of an application to securely and 4498 privately send a message to its peer. It presumes that a session key 4499 has previously been exchanged (for example, by using the 4500 KRB_AP_REQ/KRB_AP_REP messages). 4502 5.7.1. KRB_PRIV definition 4504 The KRB_PRIV message contains user data encrypted in the Session Key. 4505 The message fields are: 4507 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 4508 pvno [0] INTEGER (5), 4509 msg-type [1] INTEGER (21), 4510 -- NOTE: there is no [2] tag 4511 enc-part [3] EncryptedData -- EncKrbPrivPart 4512 } 4514 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 4515 user-data [0] OCTET STRING, 4516 timestamp [1] KerberosTime OPTIONAL, 4517 usec [2] Microseconds OPTIONAL, 4518 seq-number [3] UInt32 OPTIONAL, 4519 s-address [4] HostAddress -- sender's addr --, 4520 r-address [5] HostAddress OPTIONAL -- recip's addr 4521 } 4523 pvno and msg-type 4524 These fields are described above in section 5.4.1. msg-type is 4525 KRB_PRIV. 4527 enc-part 4528 This field holds an encoding of the EncKrbPrivPart sequence 4529 encrypted under the session key, with a key usage value of 13. 4531 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 4533 This encrypted encoding is used for the enc-part field of the KRB- 4534 PRIV message. 4536 user-data, timestamp, usec, s-address and r-address 4537 These fields are described above in section 5.6.1. 4539 seq-number 4540 This field is described above in section 5.3.2. 4542 5.8. KRB_CRED message specification 4544 This section specifies the format of a message that can be used to 4545 send Kerberos credentials from one principal to another. It is 4546 presented here to encourage a common mechanism to be used by 4547 applications when forwarding tickets or providing proxies to 4548 subordinate servers. It presumes that a session key has already been 4549 exchanged perhaps by using the KRB_AP_REQ/KRB_AP_REP messages. 4551 5.8.1. KRB_CRED definition 4553 The KRB_CRED message contains a sequence of tickets to be sent and 4554 information needed to use the tickets, including the session key from 4555 each. The information needed to use the tickets is encrypted under 4556 an encryption key previously exchanged or transferred alongside the 4557 KRB_CRED message. The message fields are: 4559 KRB-CRED ::= [APPLICATION 22] SEQUENCE { 4560 pvno [0] INTEGER (5), 4561 msg-type [1] INTEGER (22), 4562 tickets [2] SEQUENCE OF Ticket, 4563 enc-part [3] EncryptedData -- EncKrbCredPart 4564 } 4566 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 4567 ticket-info [0] SEQUENCE OF KrbCredInfo, 4568 nonce [1] UInt32 OPTIONAL, 4569 timestamp [2] KerberosTime OPTIONAL, 4570 usec [3] Microseconds OPTIONAL, 4571 s-address [4] HostAddress OPTIONAL, 4572 r-address [5] HostAddress OPTIONAL 4573 } 4575 KrbCredInfo ::= SEQUENCE { 4576 key [0] EncryptionKey, 4577 prealm [1] Realm OPTIONAL, 4578 pname [2] PrincipalName OPTIONAL, 4579 flags [3] TicketFlags OPTIONAL, 4580 authtime [4] KerberosTime OPTIONAL, 4582 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 4584 starttime [5] KerberosTime OPTIONAL, 4585 endtime [6] KerberosTime OPTIONAL, 4586 renew-till [7] KerberosTime OPTIONAL, 4587 srealm [8] Realm OPTIONAL, 4588 sname [9] PrincipalName OPTIONAL, 4589 caddr [10] HostAddresses OPTIONAL 4590 } 4592 pvno and msg-type 4593 These fields are described above in section 5.4.1. msg-type is 4594 KRB_CRED. 4596 tickets 4597 These are the tickets obtained from the KDC specifically for use 4598 by the intended recipient. Successive tickets are paired with the 4599 corresponding KrbCredInfo sequence from the enc-part of the KRB- 4600 CRED message. 4602 enc-part 4603 This field holds an encoding of the EncKrbCredPart sequence 4604 encrypted under the session key shared between the sender and the 4605 intended recipient, with a key usage value of 14. This encrypted 4606 encoding is used for the enc-part field of the KRB-CRED message. 4608 Implementation note: implementations of certain applications, most 4609 notably certain implementations of the Kerberos GSS-API mechanism, 4610 do not separately encrypt the contents of the EncKrbCredPart of 4611 the KRB-CRED message when sending it. In the case of those GSS- 4612 API mechanisms, this is not a security vulnerability, as the 4613 entire KRB-CRED message is itself embedded in an encrypted 4614 message. 4616 nonce 4617 If practical, an application MAY require the inclusion of a nonce 4618 generated by the recipient of the message. If the same value is 4619 included as the nonce in the message, it provides evidence that 4620 the message is fresh and has not been replayed by an attacker. A 4621 nonce MUST NEVER be reused; it SHOULD be generated randomly by the 4622 recipient of the message and provided to the sender of the message 4623 in an application specific manner. 4625 timestamp and usec 4626 These fields specify the time that the KRB-CRED message was 4627 generated. The time is used to provide assurance that the message 4628 is fresh. 4630 s-address and r-address 4631 These fields are described above in section 5.6.1. They are used 4633 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 4635 optionally to provide additional assurance of the integrity of the 4636 KRB-CRED message. 4638 key 4639 This field exists in the corresponding ticket passed by the KRB- 4640 CRED message and is used to pass the session key from the sender 4641 to the intended recipient. The field's encoding is described in 4642 section 5.2.9. 4644 The following fields are optional. If present, they can be associated 4645 with the credentials in the remote ticket file. If left out, then it 4646 is assumed that the recipient of the credentials already knows their 4647 value. 4649 prealm and pname 4650 The name and realm of the delegated principal identity. 4652 flags, authtime, starttime, endtime, renew-till, srealm, sname, and 4653 caddr 4654 These fields contain the values of the corresponding fields from 4655 the ticket found in the ticket field. Descriptions of the fields 4656 are identical to the descriptions in the KDC-REP message. 4658 5.9. Error message specification 4660 This section specifies the format for the KRB_ERROR message. The 4661 fields included in the message are intended to return as much 4662 information as possible about an error. It is not expected that all 4663 the information required by the fields will be available for all 4664 types of errors. If the appropriate information is not available when 4665 the message is composed, the corresponding field will be left out of 4666 the message. 4668 Note that since the KRB_ERROR message is not integrity protected, it 4669 is quite possible for an intruder to synthesize or modify such a 4670 message. In particular, this means that the client SHOULD NOT use any 4671 fields in this message for security-critical purposes, such as 4672 setting a system clock or generating a fresh authenticator. The 4673 message can be useful, however, for advising a user on the reason for 4674 some failure. 4676 5.9.1. KRB_ERROR definition 4678 The KRB_ERROR message consists of the following fields: 4680 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 4681 pvno [0] INTEGER (5), 4682 msg-type [1] INTEGER (30), 4684 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 4686 ctime [2] KerberosTime OPTIONAL, 4687 cusec [3] Microseconds OPTIONAL, 4688 stime [4] KerberosTime, 4689 susec [5] Microseconds, 4690 error-code [6] Int32, 4691 crealm [7] Realm OPTIONAL, 4692 cname [8] PrincipalName OPTIONAL, 4693 realm [9] Realm -- service realm --, 4694 sname [10] PrincipalName -- service name --, 4695 e-text [11] KerberosString OPTIONAL, 4696 e-data [12] OCTET STRING OPTIONAL 4697 } 4699 pvno and msg-type 4700 These fields are described above in section 5.4.1. +A msg-type is 4701 KRB_ERROR. 4703 ctime 4704 This field is described above in section 5.4.1. 4706 cusec 4707 This field is described above in section 5.5.2. 4709 stime 4710 This field contains the current time on the server. It is of type 4711 KerberosTime. 4713 susec 4714 This field contains the microsecond part of the server's 4715 timestamp. Its value ranges from 0 to 999999. It appears along 4716 with stime. The two fields are used in conjunction to specify a 4717 reasonably accurate timestamp. 4719 error-code 4720 This field contains the error code returned by Kerberos or the 4721 server when a request fails. To interpret the value of this field 4722 see the list of error codes in section 7.5.9. Implementations are 4723 encouraged to provide for national language support in the display 4724 of error messages. 4726 crealm, cname, srealm and sname 4727 These fields are described above in section 5.3. 4729 e-text 4730 This field contains additional text to help explain the error code 4731 associated with the failed request (for example, it might include 4732 a principal name which was unknown). 4734 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 4736 e-data 4737 This field contains additional data about the error for use by the 4738 application to help it recover from or handle the error. If the 4739 errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will 4740 contain an encoding of a sequence of padata fields, each 4741 corresponding to an acceptable pre-authentication method and 4742 optionally containing data for the method: 4744 METHOD-DATA ::= SEQUENCE OF PA-DATA 4746 For error codes defined in this document other than 4747 KDC_ERR_PREAUTH_REQUIRED, the format and contents of the e-data field 4748 are implementation-defined. Similarly, for future error codes, the 4749 format and contents of the e-data field are implementation-defined 4750 unless specified. Whether defined by the implementation or in a 4751 future document, the e-data field MAY take the form of TYPED-DATA: 4753 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 4754 data-type [0] INTEGER, 4755 data-value [1] OCTET STRING OPTIONAL 4756 } 4758 5.10. Application Tag Numbers 4760 The following table lists the application class tag numbers used by 4761 various data types defined in this section. 4763 Tag Number(s) Type Name Comments 4765 0 unused 4767 1 Ticket PDU 4769 2 Authenticator non-PDU 4771 3 EncTicketPart non-PDU 4773 4-9 unused 4775 10 AS-REQ PDU 4777 11 AS-REP PDU 4779 12 TGS-REQ PDU 4781 13 TGS-REP PDU 4783 14 AP-REQ PDU 4785 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 4787 15 AP-REP PDU 4789 16 RESERVED16 TGT-REQ (for user-to-user) 4791 17 RESERVED17 TGT-REP (for user-to-user) 4793 18-19 unused 4795 20 KRB-SAFE PDU 4797 21 KRB-PRIV PDU 4799 22 KRB-CRED PDU 4801 23-24 unused 4803 25 EncASRepPart non-PDU 4805 26 EncTGSRepPart non-PDU 4807 27 EncApRepPart non-PDU 4809 28 EncKrbPrivPart non-PDU 4811 29 EncKrbCredPart non-PDU 4813 30 KRB-ERROR PDU 4815 The ASN.1 types marked as "PDU" (Protocol Data Unit) in the above are 4816 the only ASN.1 types intended as top-level types of the Kerberos 4817 protcol, and are the only types that may be used as elements in 4818 another protocol that makes use of Kerberos. 4820 6. Naming Constraints 4822 6.1. Realm Names 4824 Although realm names are encoded as GeneralStrings and although a 4825 realm can technically select any name it chooses, interoperability 4826 across realm boundaries requires agreement on how realm names are to 4827 be assigned, and what information they imply. 4829 To enforce these conventions, each realm MUST conform to the 4830 conventions itself, and it MUST require that any realms with which 4831 inter-realm keys are shared also conform to the conventions and 4832 require the same from its neighbors. 4834 Kerberos realm names are case sensitive. Realm names that differ only 4836 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 4838 in the case of the characters are not equivalent. There are presently 4839 three styles of realm names: domain, X500, and other. Examples of 4840 each style follow: 4842 domain: ATHENA.MIT.EDU 4843 X500: C=US/O=OSF 4844 other: NAMETYPE:rest/of.name=without-restrictions 4846 Domain syle realm names MUST look like domain names: they consist of 4847 components separated by periods (.) and they contain neither colons 4848 (:) nor slashes (/). Though domain names themselves are case 4849 insensitive, in order for realms to match, the case must match as 4850 well. When establishing a new realm name based on an internet domain 4851 name it is recommended by convention that the characters be converted 4852 to upper case. 4854 X.500 names contain an equal (=) and cannot contain a colon (:) 4855 before the equal. The realm names for X.500 names will be string 4856 representations of the names with components separated by slashes. 4857 Leading and trailing slashes will not be included. Note that the 4858 slash separator is consistent with Kerberos implementations based on 4859 RFC1510, but it is different from the separator recommended in 4860 RFC2253. 4862 Names that fall into the other category MUST begin with a prefix that 4863 contains no equal (=) or period (.) and the prefix MUST be followed 4864 by a colon (:) and the rest of the name. All prefixes must be 4865 assigned before they may be used. Presently none are assigned. 4867 The reserved category includes strings which do not fall into the 4868 first three categories. All names in this category are reserved. It 4869 is unlikely that names will be assigned to this category unless there 4870 is a very strong argument for not using the 'other' category. 4872 These rules guarantee that there will be no conflicts between the 4873 various name styles. The following additional constraints apply to 4874 the assignment of realm names in the domain and X.500 categories: the 4875 name of a realm for the domain or X.500 formats must either be used 4876 by the organization owning (to whom it was assigned) an Internet 4877 domain name or X.500 name, or in the case that no such names are 4878 registered, authority to use a realm name MAY be derived from the 4879 authority of the parent realm. For example, if there is no domain 4880 name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can 4881 authorize the creation of a realm with that name. 4883 This is acceptable because the organization to which the parent is 4884 assigned is presumably the organization authorized to assign names to 4885 its children in the X.500 and domain name systems as well. If the 4887 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 4889 parent assigns a realm name without also registering it in the domain 4890 name or X.500 hierarchy, it is the parent's responsibility to make 4891 sure that there will not in the future exist a name identical to the 4892 realm name of the child unless it is assigned to the same entity as 4893 the realm name. 4895 6.2. Principal Names 4897 As was the case for realm names, conventions are needed to ensure 4898 that all agree on what information is implied by a principal name. 4899 The name-type field that is part of the principal name indicates the 4900 kind of information implied by the name. The name-type SHOULD be 4901 treated only as a hint to interpreting the meaning of a name. It is 4902 not significant when checking for equivalence. Principal names that 4903 differ only in the name-type identify the same principal. The name 4904 type does not partition the name space. Ignoring the name type, no 4905 two names can be the same (i.e. at least one of the components, or 4906 the realm, MUST be different). The following name types are defined: 4908 name-type value meaning 4910 name types 4912 NT-UNKNOWN 0 Name type not known 4913 NT-PRINCIPAL 1 Just the name of the principal as in DCE, or for users 4914 NT-SRV-INST 2 Service and other unique instance (krbtgt) 4915 NT-SRV-HST 3 Service with host name as instance (telnet, rcommands) 4916 NT-SRV-XHST 4 Service with host as remaining components 4917 NT-UID 5 Unique ID 4918 NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] 4919 NT-SMTP-NAME 7 Name in form of SMTP email name (e.g. user@foo.com) 4920 NT-ENTERPRISE 10 Enterprise name - may be mapped to principal name 4922 When a name implies no information other than its uniqueness at a 4923 particular time the name type PRINCIPAL SHOULD be used. The principal 4924 name type SHOULD be used for users, and it might also be used for a 4925 unique server. If the name is a unique machine generated ID that is 4926 guaranteed never to be reassigned then the name type of UID SHOULD be 4927 used (note that it is generally a bad idea to reassign names of any 4928 type since stale entries might remain in access control lists). 4930 If the first component of a name identifies a service and the 4931 remaining components identify an instance of the service in a server 4932 specified manner, then the name type of SRV-INST SHOULD be used. An 4933 example of this name type is the Kerberos ticket-granting service 4934 whose name has a first component of krbtgt and a second component 4935 identifying the realm for which the ticket is valid. 4937 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 4939 If the first component of a name identifies a service and there is a 4940 single component following the service name identifying the instance 4941 as the host on which the server is running, then the name type SRV- 4942 HST SHOULD be used. This type is typically used for Internet services 4943 such as telnet and the Berkeley R commands. If the separate 4944 components of the host name appear as successive components following 4945 the name of the service, then the name type SRV-XHST SHOULD be used. 4946 This type might be used to identify servers on hosts with X.500 names 4947 where the slash (/) might otherwise be ambiguous. 4949 A name type of NT-X500-PRINCIPAL SHOULD be used when a name from an 4950 X.509 certificate is translated into a Kerberos name. The encoding of 4951 the X.509 name as a Kerberos principal shall conform to the encoding 4952 rules specified in RFC 2253. 4954 A name type of SMTP allows a name to be of a form that resembles a 4955 SMTP email name. This name, including an "@" and a domain name, is 4956 used as the one component of the principal name. 4958 A name type of UNKNOWN SHOULD be used when the form of the name is 4959 not known. When comparing names, a name of type UNKNOWN will match 4960 principals authenticated with names of any type. A principal 4961 authenticated with a name of type UNKNOWN, however, will only match 4962 other names of type UNKNOWN. 4964 Names of any type with an initial component of 'krbtgt' are reserved 4965 for the Kerberos ticket granting service. See section 7.5.8 for the 4966 form of such names. 4968 6.2.1. Name of server principals 4970 The principal identifier for a server on a host will generally be 4971 composed of two parts: (1) the realm of the KDC with which the server 4972 is registered, and (2) a two-component name of type NT-SRV-HST if the 4973 host name is an Internet domain name or a multi-component name of 4974 type NT-SRV-XHST if the name of the host is of a form such as X.500 4975 that allows slash (/) separators. The first component of the two- or 4976 multi-component name will identify the service and the latter 4977 components will identify the host. Where the name of the host is not 4978 case sensitive (for example, with Internet domain names) the name of 4979 the host MUST be lower case. If specified by the application protocol 4980 for services such as telnet and the Berkeley R commands which run 4981 with system privileges, the first component MAY be the string 'host' 4982 instead of a service specific identifier. When a host has an official 4983 name and one or more aliases and the official name can be reliably 4984 determined, the official name of the host SHOULD be used when 4985 constructing the name of the server principal. 4987 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 4989 7. Constants and other defined values 4991 7.1. Host address types 4993 All negative values for the host address type are reserved for local 4994 use. All non-negative values are reserved for officially assigned 4995 type fields and interpretations. 4997 Internet (IPv4) Addresses 4999 Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded 5000 in MSB order. The IPv4 loopback address SHOULD NOT appear in a 5001 Kerberos packet. The type of IPv4 addresses is two (2). 5003 Internet (IPv6) Addresses 5005 IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities, 5006 encoded in MSB order. The type of IPv6 addresses is twenty-four 5007 (24). The following addresses MUST NOT appear in any Kerberos 5008 packet: 5010 * the Unspecified Address 5011 * the Loopback Address 5012 * Link-Local addresses 5014 IPv4-mapped IPv6 addresses MUST be represented as addresses of 5015 type 2. 5017 DECnet Phase IV addresses 5019 DECnet Phase IV addresses are 16-bit addresses, encoded in LSB 5020 order. The type of DECnet Phase IV addresses is twelve (12). 5022 Netbios addresses 5024 Netbios addresses are 16-octet addresses typically composed of 1 5025 to 15 alphanumeric characters and padded with the US-ASCII SPC 5026 character (code 32). The 16th octet MUST be the US-ASCII NUL 5027 character (code 0). The type of Netbios addresses is twenty (20). 5029 Directional Addresses 5031 In many environments, including the sender address in KRB_SAFE and 5032 KRB_PRIV messages is undesirable because the addresses may be 5033 changed in transport by network address translators. However, if 5034 these addresses are removed, the messages may be subject to a 5035 reflection attack in which a message is reflected back to its 5036 originator. The directional address type provides a way to avoid 5038 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 5040 transport addresses and reflection attacks. Directional addresses 5041 are encoded as four byte unsigned integers in network byte order. 5042 If the message is originated by the party sending the original 5043 KRB_AP_REQ message, then an address of 0 SHOULD be used. If the 5044 message is originated by the party to whom that KRB_AP_REQ was 5045 sent, then the address 1 SHOULD be used. Applications involving 5046 multiple parties can specify the use of other addresses. 5048 Directional addresses MUST only be used for the sender address 5049 field in the KRB_SAFE or KRB_PRIV messages. They MUST NOT be used 5050 as a ticket address or in a KRB_AP_REQ message. This address type 5051 SHOULD only be used in situations where the sending party knows 5052 that the receiving party supports the address type. This generally 5053 means that directional addresses may only be used when the 5054 application protocol requires their support. Directional addresses 5055 are type (3). 5057 7.2. KDC messaging - IP Transports 5059 Kerberos defines two IP transport mechanisms for communication 5060 between clients and servers: UDP/IP and TCP/IP. 5062 7.2.1. UDP/IP transport 5064 Kerberos servers (KDCs) supporting IP transports MUST accept UDP 5065 requests and SHOULD listen for such requests on port 88 (decimal) 5066 unless specifically configured to listen on an alternative UDP port. 5067 Alternate ports MAY be used when running multiple KDCs for multiple 5068 realms on the same host. 5070 Kerberos clients supporting IP transports SHOULD support the sending 5071 of UDP requests. Clients SHOULD use KDC discovery [7.2.3] to identify 5072 the IP address and port to which they will send their request. 5074 When contacting a KDC for a KRB_KDC_REQ request using UDP/IP 5075 transport, the client shall send a UDP datagram containing only an 5076 encoding of the request to the KDC. The KDC will respond with a reply 5077 datagram containing only an encoding of the reply message (either a 5078 KRB_ERROR or a KRB_KDC_REP) to the sending port at the sender's IP 5079 address. The response to a request made through UDP/IP transport MUST 5080 also use UDP/IP transport. If the response can not be handled using 5081 UDP (for example because it is too large), the KDC MUST return 5082 KRB_ERR_RESPONSE_TOO_BIG, forcing the client to retry the request 5083 using the TCP transport. 5085 7.2.2. TCP/IP transport 5087 Kerberos servers (KDCs) supporting IP transports MUST accept TCP 5089 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 5091 requests and SHOULD listen for such requests on port 88 (decimal) 5092 unless specifically configured to listen on an alternate TCP port. 5093 Alternate ports MAY be used when running multiple KDCs for multiple 5094 realms on the same host. 5096 Clients MUST support the sending of TCP requests, but MAY choose to 5097 intially try a request using the UDP transport. Clients SHOULD use 5098 KDC discovery [7.2.3] to identify the IP address and port to which 5099 they will send their request. 5101 Implementation note: Some extensions to the Kerberos protocol will 5102 not succeed if any client or KDC not supporting the TCP transport is 5103 involved. Implementations of RFC 1510 were not required to support 5104 TCP/IP transports. 5106 When the KRB_KDC_REQ message is sent to the KDC over a TCP stream, 5107 the response (KRB_KDC_REP or KRB_ERROR message) MUST be returned to 5108 the client on the same TCP stream that was established for the 5109 request. The KDC MAY close the TCP stream after sending a response, 5110 but MAY leave the stream open for a reasonable period of time if it 5111 expects a followup. Care must be taken in managing TCP/IP connections 5112 on the KDC to prevent denial of service attacks based on the number 5113 of open TCP/IP connections. 5115 The client MUST be prepared to have the stream closed by the KDC at 5116 anytime after the receipt of a response. A stream closure SHOULD NOT 5117 be treated as a fatal error. Instead, if multiple exchanges are 5118 required (e.g., certain forms of pre-authentication) the client may 5119 need to establish a new connection when it is ready to send 5120 subsequent messages. A client MAY close the stream after receiving a 5121 response, and SHOULD close the stream if it does not expect to send 5122 followup messages. 5124 A client MAY send multiple requests before receiving responses, 5125 though it must be prepared to handle the connection being closed 5126 after the first response. 5128 Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR) 5129 sent over the TCP stream is preceded by the length of the request as 5130 4 octets in network byte order. The high bit of the length is 5131 reserved for future expansion and MUST currently be set to zero. 5133 If multiple requests are sent over a single TCP connection, and the 5134 KDC sends multiple responses, the KDC is not required to send the 5135 responses in the order of the corresponding requests. This may permit 5136 some implementations to send each response as soon as it is ready 5137 even if earlier requests are still being processed (for example, 5138 waiting for a response from an external device or database). 5140 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 5142 7.2.3. KDC Discovery on IP Networks 5144 Kerberos client implementations MUST provide a means for the client 5145 to determine the location of the Kerberos Key Distribution Centers 5146 (KDCs). Traditionally, Kerberos implementations have stored such 5147 configuration information in a file on each client machine. 5148 Experience has shown this method of storing configuration information 5149 presents problems with out-of-date information and scaling problems, 5150 especially when using cross-realm authentication. This section 5151 describes a method for using the Domain Name System [RFC 1035] for 5152 storing KDC location information. 5154 7.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names 5156 In Kerberos, realm names are case sensitive. While it is strongly 5157 encouraged that all realm names be all upper case this recommendation 5158 has not been adopted by all sites. Some sites use all lower case 5159 names and other use mixed case. DNS on the other hand is case 5160 insensitive for queries. Since "MYREALM", "myrealm", and "MyRealm" 5161 are all different it is necessary that only one of the possible 5162 combinations of upper and lower case characters be used. This 5163 restriction may be lifted in the future as the DNS naming scheme is 5164 expanded to support non-US-ASCII names. 5166 7.2.3.2. Specifying KDC Location information with DNS SRV records 5168 KDC location information is to be stored using the DNS SRV RR [RFC 5169 2052]. The format of this RR is as follows: 5171 Service.Proto.Realm TTL Class SRV Priority Weight Port Target 5173 The Service name for Kerberos is always "_kerberos". 5175 The Proto can be one of "_udp", "_tcp". If these SRV records are to 5176 be used, both "_udp" and "_tcp" records MUST be specified for all KDC 5177 deployments. 5179 The Realm is the Kerberos realm that this record corresponds to. 5181 TTL, Class, SRV, Priority, Weight, and Target have the standard 5182 meaning as defined in RFC 2052. 5184 As per RFC 2052 the Port number used for "_udp" and "_tcp" SRV 5185 records SHOULD be the value assigned to "kerberos" by the Internet 5186 Assigned Number Authority: 88 (decimal) unless the KDC is configured 5187 to listen on an alternate TCP port. 5189 Implementation note: Many existing client implementations do not 5191 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 5193 support KDC Discovery and are configured to send requests to the IANA 5194 assigned port (88 decimal), so it is strongly recommended that KDCs 5195 be configured to listen on that port. 5197 7.2.3.3. KDC Discovery for Domain Style Realm Names on IP Networks 5199 These are DNS records for a Kerberos realm EXAMPLE.COM. It has two 5200 Kerberos servers, kdc1.example.com and kdc2.example.com. Queries 5201 should be directed to kdc1.example.com first as per the specified 5202 priority. Weights are not used in these sample records. 5204 _kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. 5205 _kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. 5206 _kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. 5207 _kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. 5209 7.3. Name of the TGS 5211 The principal identifier of the ticket-granting service shall be 5212 composed of three parts: (1) the realm of the KDC issuing the TGS 5213 ticket (2) a two-part name of type NT-SRV-INST, with the first part 5214 "krbtgt" and the second part the name of the realm which will accept 5215 the ticket-granting ticket. For example, a ticket-granting ticket 5216 issued by the ATHENA.MIT.EDU realm to be used to get tickets from the 5217 ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU" 5218 (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting 5219 ticket issued by the ATHENA.MIT.EDU realm to be used to get tickets 5220 from the MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" 5221 (realm), ("krbtgt", "MIT.EDU") (name). 5223 7.4. OID arc for KerberosV5 5225 This OID MAY be used to identify Kerberos protocol messages 5226 encapsulated in other protocols. It also designates the OID arc for 5227 KerberosV5-related OIDs assigned by future IETF action. 5228 Implementation note:: RFC 1510 had an incorrect value (5) for "dod" 5229 in its OID. 5231 id-krb5 OBJECT IDENTIFIER ::= { 5232 iso(1) identified-organization(3) dod(6) internet(1) 5233 security(5) kerberosV5(2) 5234 } 5236 Assignment of OIDs beneath the id-krb5 arc must be obtained by 5237 contacting krb5-oid-registrar@mit.edu. 5239 7.5. Protocol constants and associated values 5240 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 5242 The following tables list constants used in the protocol and define 5243 their meanings. Ranges are specified in the "specification" section 5244 that limit the values of constants for which values are defined here. 5245 This allows implementations to make assumptions about the maximum 5246 values that will be received for these constants. Implementation 5247 receiving values outside the range specified in the "specification" 5248 section MAY reject the request, but they MUST recover cleanly. 5250 7.5.1. Key usage numbers 5252 The encryption and checksum specifications in [@KCRYPTO] require as 5253 input a "key usage number", to alter the encryption key used in any 5254 specific message, to make certain types of cryptographic attack more 5255 difficult. These are the key usage values assigned in this document: 5257 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted 5258 with the client key (section 5.2.7.2) 5259 2. AS-REP Ticket and TGS-REP Ticket (includes TGS session 5260 key or application session key), encrypted with the 5261 service key (section 5.3) 5262 3. AS-REP encrypted part (includes TGS session key or 5263 application session key), encrypted with the client key 5264 (section 5.4.2) 5265 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with 5266 the TGS session key (section 5.4.1) 5267 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with 5268 the TGS authenticator subkey (section 5.4.1) 5269 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, 5270 keyed with the TGS session key (sections 5.5.1) 5271 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator 5272 (includes TGS authenticator subkey), encrypted with the 5273 TGS session key (section 5.5.1) 5274 8. TGS-REP encrypted part (includes application session 5275 key), encrypted with the TGS session key (section 5276 5.4.2) 5277 9. TGS-REP encrypted part (includes application session 5278 key), encrypted with the TGS authenticator subkey 5279 (section 5.4.2) 5280 10. AP-REQ Authenticator cksum, keyed with the application 5281 session key (section 5.5.1) 5282 11. AP-REQ Authenticator (includes application 5283 authenticator subkey), encrypted with the application 5284 session key (section 5.5.1) 5285 12. AP-REP encrypted part (includes application session 5286 subkey), encrypted with the application session key 5287 (section 5.5.2) 5288 13. KRB-PRIV encrypted part, encrypted with a key chosen by 5289 the application (section 5.7.1) 5291 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 5293 14. KRB-CRED encrypted part, encrypted with a key chosen by 5294 the application (section 5.8.1) 5295 15. KRB-SAFE cksum, keyed with a key chosen by the 5296 application (section 5.6.1) 5297 19. AD-KDC-ISSUED checksum (ad-checksum in 5.2.6.4) 5298 22-24. Reserved for use in GSSAPI mechanisms derived from RFC 5299 1964. (raeburn/MIT) 5300 16-18,20-21,25-511. Reserved for future use in Kerberos and related 5301 protocols. 5302 512-1023. Reserved for uses internal to a Kerberos 5303 implementation. 5304 1024. Encryption for application use in protocols that 5305 do not specify key usage values 5306 1025. Checksums for application use in protocols that 5307 do not specify key usage values 5308 1026-2047. Reserved for application use. 5310 7.5.2. PreAuthentication Data Types 5312 padata and data types padata-type value comment 5314 PA-TGS-REQ 1 5315 PA-ENC-TIMESTAMP 2 5316 PA-PW-SALT 3 5317 [reserved] 4 5318 PA-ENC-UNIX-TIME 5 (deprecated) 5319 PA-SANDIA-SECUREID 6 5320 PA-SESAME 7 5321 PA-OSF-DCE 8 5322 PA-CYBERSAFE-SECUREID 9 5323 PA-AFS3-SALT 10 5324 PA-ETYPE-INFO 11 5325 PA-SAM-CHALLENGE 12 (sam/otp) 5326 PA-SAM-RESPONSE 13 (sam/otp) 5327 PA-PK-AS-REQ 14 (pkinit) 5328 PA-PK-AS-REP 15 (pkinit) 5329 PA-ETYPE-INFO2 19 (replaces pa-etype-info) 5330 PA-USE-SPECIFIED-KVNO 20 5331 PA-SAM-REDIRECT 21 (sam/otp) 5332 PA-GET-FROM-TYPED-DATA 22 (embedded in typed data) 5333 TD-PADATA 22 (embeds padata) 5334 PA-SAM-ETYPE-INFO 23 (sam/otp) 5335 PA-ALT-PRINC 24 (crawdad@fnal.gov) 5336 PA-SAM-CHALLENGE2 30 (kenh@pobox.com) 5337 PA-SAM-RESPONSE2 31 (kenh@pobox.com) 5338 PA-EXTRA-TGT 41 Reserved extra TGT 5339 TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS 5341 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 5343 TD-KRB-PRINCIPAL 102 PrincipalName 5344 TD-KRB-REALM 103 Realm 5345 TD-TRUSTED-CERTIFIERS 104 from PKINIT 5346 TD-CERTIFICATE-INDEX 105 from PKINIT 5347 TD-APP-DEFINED-ERROR 106 application specific 5348 TD-REQ-NONCE 107 INTEGER 5349 TD-REQ-SEQ 108 INTEGER 5350 PA-PAC-REQUEST 128 (jbrezak@exchange.microsoft.com) 5352 7.5.3. Address Types 5354 Address type value 5356 IPv4 2 5357 Directional 3 5358 ChaosNet 5 5359 XNS 6 5360 ISO 7 5361 DECNET Phase IV 12 5362 AppleTalk DDP 16 5363 NetBios 20 5364 IPv6 24 5366 7.5.4. Authorization Data Types 5368 authorization data type ad-type value 5369 AD-IF-RELEVANT 1 5370 AD-INTENDED-FOR-SERVER 2 5371 AD-INTENDED-FOR-APPLICATION-CLASS 3 5372 AD-KDC-ISSUED 4 5373 AD-AND-OR 5 5374 AD-MANDATORY-TICKET-EXTENSIONS 6 5375 AD-IN-TICKET-EXTENSIONS 7 5376 AD-MANDATORY-FOR-KDC 8 5377 reserved values 9-63 5378 OSF-DCE 64 5379 SESAME 65 5380 AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com) 5381 AD-WIN2K-PAC 128 (jbrezak@exchange.microsoft.com) 5383 7.5.5. Transited Encoding Types 5385 transited encoding type tr-type value 5386 DOMAIN-X500-COMPRESS 1 5387 reserved values all others 5389 7.5.6. Protocol Version Number 5390 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 5392 Label Value Meaning or MIT code 5394 pvno 5 current Kerberos protocol version number 5396 7.5.7. Kerberos Message Types 5398 message types 5400 KRB_AS_REQ 10 Request for initial authentication 5401 KRB_AS_REP 11 Response to KRB_AS_REQ request 5402 KRB_TGS_REQ 12 Request for authentication based on TGT 5403 KRB_TGS_REP 13 Response to KRB_TGS_REQ request 5404 KRB_AP_REQ 14 application request to server 5405 KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL 5406 KRB_RESERVED16 16 Reserved for user-to-user krb_tgt_request 5407 KRB_RESERVED17 17 Reserved for user-to-user krb_tgt_reply 5408 KRB_SAFE 20 Safe (checksummed) application message 5409 KRB_PRIV 21 Private (encrypted) application message 5410 KRB_CRED 22 Private (encrypted) message to forward credentials 5411 KRB_ERROR 30 Error response 5413 7.5.8. Name Types 5415 name types 5417 KRB_NT_UNKNOWN 0 Name type not known 5418 KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users 5419 KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) 5420 KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands) 5421 KRB_NT_SRV_XHST 4 Service with host as remaining components 5422 KRB_NT_UID 5 Unique ID 5423 KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] 5424 KRB_NT_SMTP_NAME 7 Name in form of SMTP email name (e.g. user@foo.com) 5425 KRB_NT_ENTERPRISE 10 Enterprise name - may be mapped to principal name 5427 7.5.9. Error Codes 5429 error codes 5431 KDC_ERR_NONE 0 No error 5432 KDC_ERR_NAME_EXP 1 Client's entry in database has expired 5433 KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired 5434 KDC_ERR_BAD_PVNO 3 Requested protocol version number 5435 not supported 5436 KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key 5437 KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key 5438 KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database 5439 KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database 5441 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 5443 KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database 5444 KDC_ERR_NULL_KEY 9 The client or server has a null key 5445 KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating 5446 KDC_ERR_NEVER_VALID 11 Requested start time is later than end time 5447 KDC_ERR_POLICY 12 KDC policy rejects request 5448 KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option 5449 KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type 5450 KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type 5451 KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type 5452 KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type 5453 KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked 5454 KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked 5455 KDC_ERR_TGT_REVOKED 20 TGT has been revoked 5456 KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later 5457 KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later 5458 KDC_ERR_KEY_EXPIRED 23 Password has expired 5459 - change password to reset 5460 KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid 5461 KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired 5462 KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match 5463 KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user only 5464 KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path 5465 KDC_ERR_SVC_UNAVAILABLE 29 A service is not available 5466 KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed 5467 KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired 5468 KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid 5469 KRB_AP_ERR_REPEAT 34 Request is a replay 5470 KRB_AP_ERR_NOT_US 35 The ticket isn't for us 5471 KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match 5472 KRB_AP_ERR_SKEW 37 Clock skew too great 5473 KRB_AP_ERR_BADADDR 38 Incorrect net address 5474 KRB_AP_ERR_BADVERSION 39 Protocol version mismatch 5475 KRB_AP_ERR_MSG_TYPE 40 Invalid msg type 5476 KRB_AP_ERR_MODIFIED 41 Message stream modified 5477 KRB_AP_ERR_BADORDER 42 Message out of order 5478 KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available 5479 KRB_AP_ERR_NOKEY 45 Service key not available 5480 KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed 5481 KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction 5482 KRB_AP_ERR_METHOD 48 Alternative authentication method required 5483 KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message 5484 KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message 5485 KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path 5486 KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP, retry with TCP 5487 KRB_ERR_GENERIC 60 Generic error (description in e-text) 5488 KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation 5489 KDC_ERROR_CLIENT_NOT_TRUSTED 62 Reserved for PKINIT 5490 KDC_ERROR_KDC_NOT_TRUSTED 63 Reserved for PKINIT 5492 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 5494 KDC_ERROR_INVALID_SIG 64 Reserved for PKINIT 5495 KDC_ERR_KEY_TOO_WEAK 65 Reserved for PKINIT 5496 KDC_ERR_CERTIFICATE_MISMATCH 66 Reserved for PKINIT 5497 KRB_AP_ERR_NO_TGT 67 No TGT available to validate USER-TO-USER 5498 KDC_ERR_WRONG_REALM 68 USER-TO-USER TGT issued different KDC 5499 KRB_AP_ERR_USER_TO_USER_REQUIRED 69 Ticket must be for USER-TO-USER 5500 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 Reserved for PKINIT 5501 KDC_ERR_INVALID_CERTIFICATE 71 Reserved for PKINIT 5502 KDC_ERR_REVOKED_CERTIFICATE 72 Reserved for PKINIT 5503 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 Reserved for PKINIT 5504 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 Reserved for PKINIT 5505 KDC_ERR_CLIENT_NAME_MISMATCH 75 Reserved for PKINIT 5506 KDC_ERR_KDC_NAME_MISMATCH 76 Reserved for PKINIT 5508 8. Interoperability requirements 5510 Version 5 of the Kerberos protocol supports a myriad of options. 5511 Among these are multiple encryption and checksum types, alternative 5512 encoding schemes for the transited field, optional mechanisms for 5513 pre-authentication, the handling of tickets with no addresses, 5514 options for mutual authentication, user to user authentication, 5515 support for proxies, forwarding, postdating, and renewing tickets, 5516 the format of realm names, and the handling of authorization data. 5518 In order to ensure the interoperability of realms, it is necessary to 5519 define a minimal configuration which must be supported by all 5520 implementations. This minimal configuration is subject to change as 5521 technology does. For example, if at some later date it is discovered 5522 that one of the required encryption or checksum algorithms is not 5523 secure, it will be replaced. 5525 8.1. Specification 2 5527 This section defines the second specification of these options. 5528 Implementations which are configured in this way can be said to 5529 support Kerberos Version 5 Specification 2 (5.2). Specification 1 5530 (deprecated) may be found in RFC1510. 5532 Transport 5534 TCP/IP and UDP/IP transport MUST be supported by clients and KDCs 5535 claiming conformance to specification 2. 5537 Encryption and checksum methods 5539 The following encryption and checksum mechanisms MUST be 5540 supported. 5542 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 5544 Encryption: AES256-CTS-HMAC-SHA1-96 5545 Checksums: HMAC-SHA1-96-AES256 5547 Implementations SHOULD support other mechanisms as well, but the 5548 additional mechanisms may only be used when communicating with 5549 principals known to also support them. The mechanisms that SHOULD 5550 be supported are: 5552 Encryption: DES-CBC-MD5, DES3-CBC-SHA1-KD 5553 Checksums: DES-MD5, HMAC-SHA1-DES3-KD 5555 Implementations MAY support other mechanisms as well, but the 5556 additional mechanisms may only be used when communicating with 5557 principals known to also support them. 5559 Implementation note: earlier implementations of Kerberos generate 5560 messages using the CRC-32, RSA-MD5 checksum methods. For 5561 interoperability with these earlier releases implementors MAY 5562 consider supporting these checksum methods but should carefully 5563 analyze the security impplications to limit the situations within 5564 which these methods are accepted. 5566 Realm Names 5568 All implementations MUST understand hierarchical realms in both 5569 the Internet Domain and the X.500 style. When a ticket-granting 5570 ticket for an unknown realm is requested, the KDC MUST be able to 5571 determine the names of the intermediate realms between the KDCs 5572 realm and the requested realm. 5574 Transited field encoding 5576 DOMAIN-X500-COMPRESS (described in section 3.3.3.2) MUST be 5577 supported. Alternative encodings MAY be supported, but they may 5578 be used only when that encoding is supported by ALL intermediate 5579 realms. 5581 Pre-authentication methods 5583 The TGS-REQ method MUST be supported. The TGS-REQ method is not 5584 used on the initial request. The PA-ENC-TIMESTAMP method MUST be 5585 supported by clients but whether it is enabled by default MAY be 5586 determined on a realm by realm basis. If not used in the initial 5587 request and the error KDC_ERR_PREAUTH_REQUIRED is returned 5588 specifying PA-ENC-TIMESTAMP as an acceptable method, the client 5589 SHOULD retry the initial request using the PA-ENC-TIMESTAMP pre- 5590 authentication method. Servers need not support the PA-ENC- 5591 TIMESTAMP method, but if not supported the server SHOULD ignore 5593 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 5595 the presence of PA-ENC-TIMESTAMP pre-authentication in a request. 5597 The ETYPE-INFO2 method MUST be supported; this method is used to 5598 communicate the set of supported encryption types, and 5599 corresponding salt and string to key paramters. The ETYPE-INFO 5600 method SHOULD be supported for interoperability with older 5601 implementation. 5603 Mutual authentication 5605 Mutual authentication (via the KRB_AP_REP message) MUST be 5606 supported. 5608 Ticket addresses and flags 5610 All KDCs MUST pass through tickets that carry no addresses (i.e. 5611 if a TGT contains no addresses, the KDC will return derivative 5612 tickets). Implementations SHOULD default to requesting 5613 addressless tickets as this significantly increases 5614 interoperability with network address translation. In some cases 5615 realms or application servers MAY require that tickets have an 5616 address. 5618 Implementations SHOULD accept directional address type for the 5619 KRB_SAFE and KRB_PRIV message and SHOULD include directional 5620 addresses in these messages when other address types are not 5621 available. 5623 Proxies and forwarded tickets MUST be supported. Individual realms 5624 and application servers can set their own policy on when such 5625 tickets will be accepted. 5627 All implementations MUST recognize renewable and postdated 5628 tickets, but need not actually implement them. If these options 5629 are not supported, the starttime and endtime in the ticket shall 5630 specify a ticket's entire useful life. When a postdated ticket is 5631 decoded by a server, all implementations shall make the presence 5632 of the postdated flag visible to the calling server. 5634 User-to-user authentication 5636 Support for user to user authentication (via the ENC-TKT-IN-SKEY 5637 KDC option) MUST be provided by implementations, but individual 5638 realms MAY decide as a matter of policy to reject such requests on 5639 a per-principal or realm-wide basis. 5641 Authorization data 5643 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 5645 Implementations MUST pass all authorization data subfields from 5646 ticket-granting tickets to any derivative tickets unless directed 5647 to suppress a subfield as part of the definition of that 5648 registered subfield type (it is never incorrect to pass on a 5649 subfield, and no registered subfield types presently specify 5650 suppression at the KDC). 5652 Implementations MUST make the contents of any authorization data 5653 subfields available to the server when a ticket is used. 5654 Implementations are not required to allow clients to specify the 5655 contents of the authorization data fields. 5657 Constant ranges 5659 All protocol constants are constrained to 32 bit (signed) values 5660 unless further constrained by the protocol definition. This limit 5661 is provided to allow implementations to make assumptions about the 5662 maximum values that will be received for these constants. 5663 Implementation receiving values outside this range MAY reject the 5664 request, but they MUST recover cleanly. 5666 8.2. Recommended KDC values 5668 Following is a list of recommended values for a KDC configuration. 5670 minimum lifetime 5 minutes 5671 maximum renewable lifetime 1 week 5672 maximum ticket lifetime 1 day 5673 acceptable clock skew 5 minutes 5674 empty addresses Allowed. 5675 proxiable, etc. Allowed. 5677 9. IANA considerations 5679 Section 7 of this document specifies protocol constants and other 5680 defined values required for the interoperability of multiple 5681 implementations. Until otherwise specified in a subsequent RFC, 5682 allocations of additional protocol constants and other defined values 5683 required for extensions to the Kerberos protocol will be administered 5684 by the Kerberos Working Group. 5686 10. Security Considerations 5688 As an authentication service, Kerberos provides a means of verifying 5689 the identity of principals on a network. Kerberos does not, by 5690 itself, provide authorization. Applications should not accept the 5691 issuance of a service ticket by the Kerberos server as granting 5692 authority to use the service, since such applications may become 5694 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 5696 vulnerable to the bypass of this authorization check in an 5697 environment if they inter-operate with other KDCs or where other 5698 options for application authentication are provided. 5700 Denial of service attacks are not solved with Kerberos. There are 5701 places in the protocols where an intruder can prevent an application 5702 from participating in the proper authentication steps. Because 5703 authentication is a required step for the use of many services, 5704 successful denial of service attacks on a Kerberos server might 5705 result in the denial of other network services that rely on Kerberos 5706 for authentication. Kerberos is vulnerable to many kinds of denial of 5707 service attacks: denial of service attacks on the network which would 5708 prevent clients from contacting the KDC; denial of service attacks on 5709 the domain name system which could prevent a client from finding the 5710 IP address of the Kerberos server; and denial of service attack by 5711 overloading the Kerberos KDC itself with repeated requests. 5713 Interoperability conflicts caused by incompatible character-set usage 5714 (see 5.2.1) can result in denial of service for clients that utilize 5715 character-sets in Kerberos strings other than those stored in the KDC 5716 database. 5718 Authentication servers maintain a database of principals (i.e., users 5719 and servers) and their secret keys. The security of the 5720 authentication server machines is critical. The breach of security of 5721 an authentication server will compromise the security of all servers 5722 that rely upon the compromised KDC, and will compromise the 5723 authentication of any principals registered in the realm of the 5724 compromised KDC. 5726 Principals must keep their secret keys secret. If an intruder somehow 5727 steals a principal's key, it will be able to masquerade as that 5728 principal or impersonate any server to the legitimate principal. 5730 Password guessing attacks are not solved by Kerberos. If a user 5731 chooses a poor password, it is possible for an attacker to 5732 successfully mount an off-line dictionary attack by repeatedly 5733 attempting to decrypt, with successive entries from a dictionary, 5734 messages obtained which are encrypted under a key derived from the 5735 user's password. 5737 Unless pre-authentication options are required by the policy of a 5738 realm, the KDC will not know whether a request for authentication 5739 succeeds. An attacker can request a reply with credentials for any 5740 principal. These credentials will likely not be of much use to the 5741 attacker unless it knows the client's secret key, but the 5742 availability of the response encrypted in the client's secret key 5743 provides the attacker with ciphertext that may be used to mount brute 5745 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 5747 force or dictionary attacks to decrypt the credentials, by guessing 5748 the user's password. For this reason it is strongly encouraged that 5749 Kerberos realms require the use of pre-authentication. Even with pre- 5750 authentication, attackers may try brute force or dictionary attacks 5751 against credentials that are observed by eavesdropping on the 5752 network. 5754 Because a client can request a ticket for any server principal and 5755 can attempt a brute force or dictionary attack against the server 5756 principal's key using that ticket, it is strongly encouraged that 5757 keys be randomly generated (rather than generated from passwords) for 5758 any principals that are usable as the target principal for a 5759 KRB_TGS_REQ or KRB_AS_REQ messages. 5761 Each host on the network must have a clock which is loosely 5762 synchronized to the time of the other hosts; this synchronization is 5763 used to reduce the bookkeeping needs of application servers when they 5764 do replay detection. The degree of "looseness" can be configured on a 5765 per-server basis, but is typically on the order of 5 minutes. If the 5766 clocks are synchronized over the network, the clock synchronization 5767 protocol must itself be secured from network attackers. 5769 Principal identifiers must not recycled on a short-term basis. A 5770 typical mode of access control will use access control lists (ACLs) 5771 to grant permissions to particular principals. If a stale ACL entry 5772 remains for a deleted principal and the principal identifier is 5773 reused, the new principal will inherit rights specified in the stale 5774 ACL entry. By not reusing principal identifiers, the danger of 5775 inadvertent access is removed. 5777 Proper decryption of an KRB_AS_REP message from the KDC is not 5778 sufficient for the host to verify the identity of the user; the user 5779 and an attacker could cooperate to generate a KRB_AS_REP format 5780 message which decrypts properly but is not from the proper KDC. To 5781 authenticate a user logging on to a local system, the credentials 5782 obtained in the AS exchange may first be used in a TGS exchange to 5783 obtain credentials for a local server. Those credentials must then be 5784 verified by a local server through successful completion of the 5785 Client/Server exchange. 5787 Kerberos credentials contain clear-text information identifying the 5788 principals to which they apply. If privacy of this information is 5789 needed, this exchange should itself be encapsulated in a protocol 5790 providing for confidentiality on the exchange of these credentials. 5792 Applications must take care to protect communications subsequent to 5793 authentication either by using the KRB_PRIV or KRB_SAFE messages as 5794 appropriate, or by applying their own confidentiality or integrity 5796 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 5798 mechanisms on such communications. Completion of the KRB_AP_REQ and 5799 KRB_AP_REP exchange without subsequent use of confidentiality and 5800 integrity mechanisms provides only for authentication of the parties 5801 to the communication and not confidentiality and integrity of the 5802 subsequent communication. Application applying confidentiality and 5803 protections mechanisms other than KRB_PRIV and KRB_SAFE must make 5804 sure that the authentication step is appropriately linked with the 5805 protected communication channel that is established by the 5806 application. 5808 Unless the application server provides its own suitable means to 5809 protect against replay (for example, a challenge-response sequence 5810 initiated by the server after authentication, or use of a server- 5811 generated encryption subkey), the server must utilize a replay cache 5812 to remember any authenticator presented within the allowable clock 5813 skew. All services sharing a key need to use the same replay cache. 5814 If separate replay caches are used, then and authenticator used with 5815 one such service could later be replayed to a different service with 5816 the same service principal. 5818 If a server loses track of authenticators presented within the 5819 allowable clock skew, it must reject all requests until the clock 5820 skew interval has passed, providing assurance that any lost or 5821 replayed authenticators will fall outside the allowable clock skew 5822 and can no longer be successfully replayed. 5824 Implementations of Kerberos should not use untrusted directory 5825 servers to determine the realm of a host. To allow such would allow 5826 the compromise of the directory server to enable an attacker to 5827 direct the client to accept authentication with the wrong principal 5828 (i.e. one with a similar name, but in a realm with which the 5829 legitimate host was not registered). 5831 Implementations of Kerberos must not use DNS to canonicalize the host 5832 components of service principal names. To allow such canonicalization 5833 would allow a compromise of the DNS to result in a client obtaining 5834 credentials and correctly authenticating to the wrong principal. 5835 Though the client will know who it is communicating with, it will not 5836 be the principal with which it intended to communicate. 5838 If the Kerberos server returns a TGT for a 'closer' realm other than 5839 the desired realm, the client may use local policy configuration to 5840 verify that the authentication path used is an acceptable one. 5841 Alternatively, a client may choose its own authentication path, 5842 rather than relying on the Kerberos server to select one. In either 5843 case, any policy or configuration information used to choose or 5844 validate authentication paths, whether by the Kerberos server or 5845 client, must be obtained from a trusted source. 5847 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 5849 The Kerberos protocol in its basic form does not provide perfect 5850 forward secrecy for communications. If traffic has been recorded by 5851 an eavesdropper, then messages encrypted using the KRB_PRIV message, 5852 or messages encrypted using application specific encryption under 5853 keys exchanged using Kerberos can be decrypted if any of the user's, 5854 application server's, or KDC's key is subsequently discovered. This 5855 is because the session key use to encrypt such messages is 5856 transmitted over the network encrypted in the key of the application 5857 server, and also encrypted under the session key from the user's 5858 ticket-granting ticket when returned to the user in the KRB_TGS_REP 5859 message. The session key from the ticket-granting ticket was sent to 5860 the user in the KRB_AS_REP message encrypted in the user's secret 5861 key, and embedded in the ticket-granting ticket, which was encrypted 5862 in the key of the KDC. Application requiring perfect forward secrecy 5863 must exchange keys through mechanisms that provide such assurance, 5864 but may use Kerberos for authentication of the encrypted channel 5865 established through such other means. 5867 11. Author's Addresses 5869 Clifford Neuman 5870 Information Sciences Institute 5871 University of Southern California 5872 4676 Admiralty Way 5873 Marina del Rey, CA 90292, USA 5874 Email: bcn@isi.edu 5876 Tom Yu 5877 Massachusetts Institute of Technology 5878 77 Massachusetts Avenue 5879 Cambridge, MA 02139, USA 5880 Email: tlyu@mit.edu 5882 Sam Hartman 5883 Massachusetts Institute of Technology 5884 77 Massachusetts Avenue 5885 Cambridge, MA 02139, USA 5886 Email: hartmans@mit.edu 5888 Kenneth Raeburn 5889 Massachusetts Institute of Technology 5890 77 Massachusetts Avenue 5891 Cambridge, MA 02139, USA 5892 Email: raeburn@MIT.EDU 5894 12. Acknowledgements 5895 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 5897 This document is a revision to RFC1510 which was co-authored with 5898 John Kohl. The specification of the Kerberos protocol described in 5899 this document is the result of many years of effort. Over this 5900 period many individuals have contributed to the definition of the 5901 protocol and to the writing of the specification. Unfortunately it is 5902 not possible to list all contributors as authors of this document, 5903 though there are many not listed who are authors in spirit, because 5904 they contributed text for parts of some sections, because they 5905 contributed to the design of parts of the protocol, or because they 5906 contributed significantly to the discussion of the protocol in the 5907 IETF common authentication technology (CAT) and Kerberos working 5908 groups. 5910 Among those contributing to the development and specification of 5911 Kerberos were Jeffrey Altman, John Brezak, Marc Colan, Johan 5912 Danielsson, Don Davis, Doug Engert, Dan Geer, Paul Hill, John Kohl, 5913 Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John Linn, 5914 Ari Medvinsky, Sasha Medvinsky, Steve Miller, Jon Rochlis, Jerome 5915 Saltzer, Jeffrey Schiller, Jennifer Steiner, Ralph Swick, Mike Swift, 5916 Jonathan Trostle, Theodore Ts'o, Brian Tung, Jacques Vidrine, Assar 5917 Westerlund, and Nicolas Williams. Many other members of MIT Project 5918 Athena, the MIT networking group, and the Kerberos and CAT working 5919 groups of the IETF contributed but are not listed. 5921 13. REFERENCES 5923 [@KRYPTO] 5924 RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg- 5925 crypto. 5927 [@AES] 5928 RFC-Editor: To be replaced by RFC number for draft-raeburn0krb- 5929 rijndael-krb. 5931 [DGT96] 5932 Don Davis, Daniel Geer, and Theodore Ts'0, "Kerberos With Clocks 5933 Adrift: History, Protocols, and Implementation", USENIX Computing 5934 Systems 9:1 (Januart 1996). 5936 [DS81] 5937 Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key 5938 Distribution Protocols," Communications of the ACM, Vol. 24(8), 5939 pp. 533-536 (August 1981). 5941 [ISO-646/ECMA-6] 5942 7-bit Coded Character Set 5944 [ISO-2022/ECMA-35] 5946 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 5948 Character Code Structure and Extension Techniques 5950 [ISO-4873/ECMA-43] 5951 8-bit Coded Character Set Structure and Rules 5953 [KNT94] 5955 John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The 5956 Evolution of the Kerberos Authentication System". In Distributed 5957 Open Systems, pages 78-94. IEEE Computer Society Press, 1994. 5959 [MNSS87] 5960 S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer, 5961 Section E.2.1: Kerberos Authentication and Authorization System, 5962 M.I.T. Project Athena, Cambridge, Massachusetts (December 21, 5963 1987). 5965 [Neu93] 5966 B. Clifford Neuman, "Proxy-Based Authorization and Accounting for 5967 Distributed Systems," in Proceedings of the 13th International 5968 Conference on Distributed Computing Systems, Pittsburgh, PA (May, 5969 1993). 5971 [NS78] 5972 Roger M. Needham and Michael D. Schroeder, "Using Encryption for 5973 Authentication in Large Networks of Computers," Communications of 5974 the ACM, Vol. 21(12), pp. 993-999 (December, 1978). 5976 [NT94] 5977 B. Clifford Neuman and Theodore Y. Ts'o, "An Authentication 5978 Service for Computer Networks," IEEE Communications Magazine, Vol. 5979 32(9), pp. 33-38 (September 1994). 5981 [Pat92]. 5982 J. Pato, Using Pre-Authentication to Avoid Password Guessing 5983 Attacks, Open Software Foundation DCE Request for Comments 26 5984 (December 1992). 5986 [RFC1035] 5987 P.V. Mockapetris, RFC1035: "Domain Names - Implementations and 5988 Specification," November 1, 1987, Obsoletes - RFC973, RFC882, 5989 RFC883. Updated by RFC1101, RFC1183, RFC1348, RFCRFC1876, RFC1982, 5990 RFC1995, RFC1996, RFC2065, RFC2136, RFC2137, RFC2181, RFC2308, 5991 RFC2535, RFC2845, and RFC3425. Status: Standard. 5993 [RFC1510] 5994 J. Kohl and B. C. Neuman, RFC1510: "The Kerberos Network 5995 Authentication Service (v5)," September 1993, Status: Proposed 5997 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 5999 Standard. 6001 [RFC2026] 6002 S. Bradner, RFC2026: "The Internet Standard Process - Revision 6003 3," October 1996, Obsoletes - RFC 1602, Status: Best Current 6004 Practice. 6006 [RFC2052] 6007 A. Gulbrandsen and P. Vixie, RFC2052: "A DNS RR for Specifying the 6008 Location of Services (DNS SRV)," October 1996, Obseleted by 6009 RFC2782, Status: Experimental 6011 [RFC2253] 6012 M. Wahl, S. Killie, and T. Howes, RFC2253: "Lightweight Directory 6013 Access Protocol (v3): UTF-8 String Representation or Distinguished 6014 Names," December 1997, Obsoletes - RFC1779, Updated by RFC3377, 6015 Status: Proposed Standard. 6017 [RFC2273] 6018 D. Levi, P. Meyer, and B. Stewart, RFC2273: "SNMPv3 Applications," 6019 January 1998, Obsoletes - RFC2263, Obsoleted by RFC2573, Status: 6020 Proposed Standard. 6022 [RFC2373] 6023 R. Hinden, S. Deering, RFC2373: "IP Version 6 Addressing 6024 Architecture," July 1998, Status: Proposed Standard. 6026 [SNS88] 6027 J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Kerberos: An 6028 Authentication Service for Open Network Systems," pp. 191-202 in 6029 Usenix Conference Proceedings, Dallas, Texas (February, 1988). 6031 [X680] 6032 Abstract Syntax Notation One (ASN.1): Specification of Basic 6033 Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC 6034 International Standard 8824-1:1998. 6036 [X690] 6037 ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), 6038 Canonical Encoding Rules (CER) and Distinguished Encoding Rules 6039 (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International 6040 Standard 8825-1:1998. 6042 A. ASN.1 module 6044 KerberosV5Spec2 { 6045 iso(1) identified-organization(3) dod(6) internet(1) 6046 security(5) kerberosV5(2) modules(4) krb5spec2(2) 6048 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 6050 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 6052 -- OID arc for KerberosV5 6053 -- 6054 -- This OID may be used to identify Kerberos protocol messages 6055 -- encapsulated in other protocols. 6056 -- 6057 -- This OID also designates the OID arc for KerberosV5-related OIDs. 6058 -- 6059 -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its OID. 6060 id-krb5 OBJECT IDENTIFIER ::= { 6061 iso(1) identified-organization(3) dod(6) internet(1) 6062 security(5) kerberosV5(2) 6063 } 6065 Int32 ::= INTEGER (-2147483648..2147483647) 6066 -- signed values representable in 32 bits 6068 UInt32 ::= INTEGER (0..4294967295) 6069 -- unsigned 32 bit values 6071 Microseconds ::= INTEGER (0..999999) 6072 -- microseconds 6074 KerberosString ::= GeneralString (IA5String) 6076 Realm ::= KerberosString 6078 PrincipalName ::= SEQUENCE { 6079 name-type [0] Int32, 6080 name-string [1] SEQUENCE OF KerberosString 6081 } 6083 KerberosTime ::= GeneralizedTime -- with no fractional seconds 6085 HostAddress ::= SEQUENCE { 6086 addr-type [0] Int32, 6087 address [1] OCTET STRING 6088 } 6090 -- NOTE: HostAddresses is always used as an OPTIONAL field and 6091 -- should not be empty. 6092 HostAddresses -- NOTE: subtly different from rfc1510, 6093 -- but has a value mapping and encodes the same 6094 ::= SEQUENCE OF HostAddress 6096 -- NOTE: AuthorizationData is always used as an OPTIONAL field and 6097 -- should not be empty. 6099 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 6101 AuthorizationData ::= SEQUENCE OF SEQUENCE { 6102 ad-type [0] Int32, 6103 ad-data [1] OCTET STRING 6104 } 6106 PA-DATA ::= SEQUENCE { 6107 -- NOTE: first tag is [1], not [0] 6108 padata-type [1] Int32, 6109 padata-value [2] OCTET STRING -- might be encoded AP-REQ 6110 } 6112 KerberosFlags ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits 6113 -- shall be sent, but no fewer than 32 6115 EncryptedData ::= SEQUENCE { 6116 etype [0] Int32 -- EncryptionType --, 6117 kvno [1] UInt32 OPTIONAL, 6118 cipher [2] OCTET STRING -- ciphertext 6119 } 6121 EncryptionKey ::= SEQUENCE { 6122 keytype [0] Int32 -- actually encryption type --, 6123 keyvalue [1] OCTET STRING 6124 } 6126 Checksum ::= SEQUENCE { 6127 cksumtype [0] Int32, 6128 checksum [1] OCTET STRING 6129 } 6131 Ticket ::= [APPLICATION 1] SEQUENCE { 6132 tkt-vno [0] INTEGER (5), 6133 realm [1] Realm, 6134 sname [2] PrincipalName, 6135 enc-part [3] EncryptedData -- EncTicketPart 6136 } 6138 -- Encrypted part of ticket 6139 EncTicketPart ::= [APPLICATION 3] SEQUENCE { 6140 flags [0] TicketFlags, 6141 key [1] EncryptionKey, 6142 crealm [2] Realm, 6143 cname [3] PrincipalName, 6144 transited [4] TransitedEncoding, 6145 authtime [5] KerberosTime, 6146 starttime [6] KerberosTime OPTIONAL, 6147 endtime [7] KerberosTime, 6148 renew-till [8] KerberosTime OPTIONAL, 6150 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 6152 caddr [9] HostAddresses OPTIONAL, 6153 authorization-data [10] AuthorizationData OPTIONAL 6154 } 6156 -- encoded Transited field 6157 TransitedEncoding ::= SEQUENCE { 6158 tr-type [0] Int32 -- must be registered --, 6159 contents [1] OCTET STRING 6160 } 6162 TicketFlags ::= KerberosFlags 6163 -- reserved(0), 6164 -- forwardable(1), 6165 -- forwarded(2), 6166 -- proxiable(3), 6167 -- proxy(4), 6168 -- may-postdate(5), 6169 -- postdated(6), 6170 -- invalid(7), 6171 -- renewable(8), 6172 -- initial(9), 6173 -- pre-authent(10), 6174 -- hw-authent(11), 6175 -- the following are new since 1510 6176 -- transited-policy-checked(12), 6177 -- ok-as-delegate(13) 6179 AS-REQ ::= [APPLICATION 10] KDC-REQ 6181 TGS-REQ ::= [APPLICATION 12] KDC-REQ 6183 KDC-REQ ::= SEQUENCE { 6184 -- NOTE: first tag is [1], not [0] 6185 pvno [1] INTEGER (5) , 6186 msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --), 6187 padata [3] SEQUENCE OF PA-DATA OPTIONAL 6188 -- NOTE: not empty --, 6189 req-body [4] KDC-REQ-BODY 6190 } 6192 KDC-REQ-BODY ::= SEQUENCE { 6193 kdc-options [0] KDCOptions, 6194 cname [1] PrincipalName OPTIONAL 6195 -- Used only in AS-REQ --, 6196 realm [2] Realm 6197 -- Server's realm 6198 -- Also client's in AS-REQ --, 6199 sname [3] PrincipalName OPTIONAL, 6201 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 6203 from [4] KerberosTime OPTIONAL, 6204 till [5] KerberosTime, 6205 rtime [6] KerberosTime OPTIONAL, 6206 nonce [7] UInt32, 6207 etype [8] SEQUENCE OF Int32 -- EncryptionType 6208 -- in preference order --, 6209 addresses [9] HostAddresses OPTIONAL, 6210 enc-authorization-data [10] EncryptedData -- AuthorizationData --, 6211 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 6212 -- NOTE: not empty 6213 } 6215 KDCOptions ::= KerberosFlags 6216 -- reserved(0), 6217 -- forwardable(1), 6218 -- forwarded(2), 6219 -- proxiable(3), 6220 -- proxy(4), 6221 -- allow-postdate(5), 6222 -- postdated(6), 6223 -- unused7(7), 6224 -- renewable(8), 6225 -- unused9(9), 6226 -- unused10(10), 6227 -- opt-hardware-auth(11), 6228 -- unused12(12), 6229 -- unused13(13), 6230 -- 15 is reserved for canonicalize 6231 -- unused15(15), 6232 -- 26 was unused in 1510 6233 -- disable-transited-check(26), 6234 -- 6235 -- renewable-ok(27), 6236 -- enc-tkt-in-skey(28), 6237 -- renew(30), 6238 -- validate(31) 6240 AS-REP ::= [APPLICATION 11] KDC-REP 6242 TGS-REP ::= [APPLICATION 13] KDC-REP 6244 KDC-REP ::= SEQUENCE { 6245 pvno [0] INTEGER (5), 6246 msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --), 6247 padata [2] SEQUENCE OF PA-DATA OPTIONAL 6248 -- NOTE: not empty --, 6249 crealm [3] Realm, 6250 cname [4] PrincipalName, 6252 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 6254 ticket [5] Ticket, 6255 enc-part [6] EncryptedData 6256 -- EncASRepPart or EncTGSRepPart, 6257 -- as appropriate 6258 } 6260 EncASRepPart ::= [APPLICATION 25] EncKDCRepPart 6262 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 6264 EncKDCRepPart ::= SEQUENCE { 6265 key [0] EncryptionKey, 6266 last-req [1] LastReq, 6267 nonce [2] UInt32, 6268 key-expiration [3] KerberosTime OPTIONAL, 6269 flags [4] TicketFlags, 6270 authtime [5] KerberosTime, 6271 starttime [6] KerberosTime OPTIONAL, 6272 endtime [7] KerberosTime, 6273 renew-till [8] KerberosTime OPTIONAL, 6274 srealm [9] Realm, 6275 sname [10] PrincipalName, 6276 caddr [11] HostAddresses OPTIONAL 6277 } 6279 LastReq ::= SEQUENCE OF SEQUENCE { 6280 lr-type [0] Int32, 6281 lr-value [1] KerberosTime 6282 } 6284 AP-REQ ::= [APPLICATION 14] SEQUENCE { 6285 pvno [0] INTEGER (5), 6286 msg-type [1] INTEGER (14), 6287 ap-options [2] APOptions, 6288 ticket [3] Ticket, 6289 authenticator [4] EncryptedData -- Authenticator 6290 } 6292 APOptions ::= KerberosFlags 6293 -- reserved(0), 6294 -- use-session-key(1), 6295 -- mutual-required(2) 6297 -- Unencrypted authenticator 6298 Authenticator ::= [APPLICATION 2] SEQUENCE { 6299 authenticator-vno [0] INTEGER (5), 6300 crealm [1] Realm, 6301 cname [2] PrincipalName, 6303 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 6305 cksum [3] Checksum OPTIONAL, 6306 cusec [4] Microseconds, 6307 ctime [5] KerberosTime, 6308 subkey [6] EncryptionKey OPTIONAL, 6309 seq-number [7] UInt32 OPTIONAL, 6310 authorization-data [8] AuthorizationData OPTIONAL 6311 } 6313 AP-REP ::= [APPLICATION 15] SEQUENCE { 6314 pvno [0] INTEGER (5), 6315 msg-type [1] INTEGER (15), 6316 enc-part [2] EncryptedData -- EncAPRepPart 6317 } 6319 EncAPRepPart ::= [APPLICATION 27] SEQUENCE { 6320 ctime [0] KerberosTime, 6321 cusec [1] Microseconds, 6322 subkey [2] EncryptionKey OPTIONAL, 6323 seq-number [3] UInt32 OPTIONAL 6324 } 6326 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 6327 pvno [0] INTEGER (5), 6328 msg-type [1] INTEGER (20), 6329 safe-body [2] KRB-SAFE-BODY, 6330 cksum [3] Checksum 6331 } 6333 KRB-SAFE-BODY ::= SEQUENCE { 6334 user-data [0] OCTET STRING, 6335 timestamp [1] KerberosTime OPTIONAL, 6336 usec [2] Microseconds OPTIONAL, 6337 seq-number [3] UInt32 OPTIONAL, 6338 s-address [4] HostAddress, 6339 r-address [5] HostAddress OPTIONAL 6340 } 6342 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 6343 pvno [0] INTEGER (5), 6344 msg-type [1] INTEGER (21), 6345 -- NOTE: there is no [2] tag 6346 enc-part [3] EncryptedData -- EncKrbPrivPart 6347 } 6349 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 6350 user-data [0] OCTET STRING, 6351 timestamp [1] KerberosTime OPTIONAL, 6352 usec [2] Microseconds OPTIONAL, 6354 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 6356 seq-number [3] UInt32 OPTIONAL, 6357 s-address [4] HostAddress -- sender's addr --, 6358 r-address [5] HostAddress OPTIONAL -- recip's addr 6359 } 6361 KRB-CRED ::= [APPLICATION 22] SEQUENCE { 6362 pvno [0] INTEGER (5), 6363 msg-type [1] INTEGER (22), 6364 tickets [2] SEQUENCE OF Ticket, 6365 enc-part [3] EncryptedData -- EncKrbCredPart 6366 } 6368 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 6369 ticket-info [0] SEQUENCE OF KrbCredInfo, 6370 nonce [1] UInt32 OPTIONAL, 6371 timestamp [2] KerberosTime OPTIONAL, 6372 usec [3] Microseconds OPTIONAL, 6373 s-address [4] HostAddress OPTIONAL, 6374 r-address [5] HostAddress OPTIONAL 6375 } 6377 KrbCredInfo ::= SEQUENCE { 6378 key [0] EncryptionKey, 6379 prealm [1] Realm OPTIONAL, 6380 pname [2] PrincipalName OPTIONAL, 6381 flags [3] TicketFlags OPTIONAL, 6382 authtime [4] KerberosTime OPTIONAL, 6383 starttime [5] KerberosTime OPTIONAL, 6384 endtime [6] KerberosTime OPTIONAL, 6385 renew-till [7] KerberosTime OPTIONAL, 6386 srealm [8] Realm OPTIONAL, 6387 sname [9] PrincipalName OPTIONAL, 6388 caddr [10] HostAddresses OPTIONAL 6389 } 6391 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 6392 pvno [0] INTEGER (5), 6393 msg-type [1] INTEGER (30), 6394 ctime [2] KerberosTime OPTIONAL, 6395 cusec [3] Microseconds OPTIONAL, 6396 stime [4] KerberosTime, 6397 susec [5] Microseconds, 6398 error-code [6] Int32, 6399 crealm [7] Realm OPTIONAL, 6400 cname [8] PrincipalName OPTIONAL, 6401 realm [9] Realm -- service realm --, 6402 sname [10] PrincipalName -- service name --, 6403 e-text [11] KerberosString OPTIONAL, 6405 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 6407 e-data [12] OCTET STRING OPTIONAL 6408 } 6410 METHOD-DATA ::= SEQUENCE OF PA-DATA 6412 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 6413 data-type [0] INTEGER, 6414 data-value [1] OCTET STRING OPTIONAL 6415 } 6417 -- preauth stuff follows 6419 PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC 6421 PA-ENC-TS-ENC ::= SEQUENCE { 6422 patimestamp [0] KerberosTime -- client's time --, 6423 pausec [1] Microseconds OPTIONAL 6424 } 6426 ETYPE-INFO-ENTRY ::= SEQUENCE { 6427 etype [0] Int32, 6428 salt [1] OCTET STRING OPTIONAL 6429 } 6431 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY 6433 ETYPE-INFO2-ENTRY ::= SEQUENCE { 6434 etype [0] Int32, 6435 salt [1] KerberosString OPTIONAL, 6436 s2kparams [2] OCTET STRING OPTIONAL 6437 } 6439 ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO-ENTRY 6441 AD-IF-RELEVANT ::= AuthorizationData 6443 AD-KDCIssued ::= SEQUENCE { 6444 ad-checksum [0] Checksum, 6445 i-realm [1] Realm OPTIONAL, 6446 i-sname [2] PrincipalName OPTIONAL, 6447 elements [3] AuthorizationData 6448 } 6450 AD-AND-OR ::= SEQUENCE { 6451 condition-count [0] INTEGER, 6452 elements [1] AuthorizationData 6453 } 6455 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 6457 AD-MANDATORY-FOR-KDC ::= AuthorizationData 6459 END 6461 B. Changes since RFC-1510 6463 This document replaces RFC-1510 and clarifies specification of items 6464 that were not completely specified. Where changes to recommended 6465 implementation choices were made, or where new options were added, 6466 those changes are described within the document and listed in this 6467 section. More significantly, "Specification 2" in section 8 changes 6468 the required encryption and checksum methods to bring them in line 6469 with the best current practices and to deprecate methods that are no 6470 longer considered sufficiently strong. 6472 Discussion was added to section 1 regarding the ability to rely on 6473 the KDC to check the transited field, and on the inclusion of a flag 6474 in a ticket indicating that this check has occurred. This is a new 6475 capability not present in RFC1510. Pre-existing implementations may 6476 ignore or not set this flag without negative security implications. 6478 The definition of the secret key says that in the case of a user the 6479 key may be derived from a password. In 1510, it said that the key was 6480 derived from the password. This change was made to accommodate 6481 situations where the user key might be stored on a smart-card, or 6482 otherwise obtained independent of a password. 6484 The introduction mentions the use of public key cryptography for 6485 initial authentication in Kerberos by reference. RFC1510 did not 6486 include such a reference. 6488 Section 1.2 was added to explain that while Kerberos provides 6489 authentication of a named principal, it is still the responsibility 6490 of the application to ensure that the authenticated name is the 6491 entity with which the application wishes to communicate. 6493 Discussion of extensibility has been added to the introduction. 6495 Discussion of how extensibility affects ticket flags and KDC options 6496 was added to the introduction of section 2. No changes were made to 6497 existing options and flags specified in RFC1510, though some of the 6498 sections in the specification were renumbered, and text was revised 6499 to make the description and intent of existing options clearer, 6500 especially with respect to the ENC-TKT-IN-SKEY option (now section 6501 2.9.2) which is used for user-to-user authentication. The new option 6502 and ticket flag transited policy checking (section 2.7) was added. 6504 A warning regarding generation of session keys for application use 6506 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 6508 was added to section 3, urging the inclusion of key entropy from the 6509 KDC generated session key in the ticket. An example regarding use of 6510 the sub-session key was added to section 3.2.6. Descriptions of the 6511 pa-etype-info, pa-etype-info2, and pa-pw-salt pre-authentication data 6512 items were added. The recommendation for use of pre-authentication 6513 was changed from "may" to "should" and a note was added regarding 6514 known plaintext attacks. 6516 In RFC 1510, section 4 described the database in the KDC. This 6517 discussion was not necessary for interoperability and unnecessarily 6518 constrained implementation. The old section 4 was removed. 6520 The current section 4 was formerly section 6 on encryption and 6521 checksum specifications. The major part of this section was brought 6522 up to date to support new encryption methods, and move to a separate 6523 document. Those few remaining aspects of the encryption and checksum 6524 specification specific to Kerberos are now specified in section 4. 6526 Significant changes were made to the layout of section 5 to clarify 6527 the correct behavior for optional fields. Many of these changes were 6528 made necessary because of improper ASN.1 description in the original 6529 Kerberos specification which left the correct behavior 6530 underspecified. Additionally, the wording in this section was 6531 tightened wherever possible to ensure that implementations conforming 6532 to this specification will be extensible with the addition of new 6533 fields in future specifications. 6535 Text was added describing time_t=0 issues in the ASN.1. Text was also 6536 added, clarifying issues with implementations treating omitted 6537 optional integers as zero. Text was added clarifying behavior for 6538 optional SEQUENCE or SEQUENCE OF that may be empty. Discussion was 6539 added regarding sequence numbers and behavior of some 6540 implementations, including "zero" behavior and negative numbers. A 6541 compatibility note was added regarding the unconditional sending of 6542 EncTGSRepPart regardless of the enclosing reply type. Minor changes 6543 were made to the description of the HostAddresses type. Integer types 6544 were constrained. KerberosString was defined as a (significantly) 6545 constrained GeneralString. KerberosFlags was defined to reflect 6546 existing implementation behavior that departs from the definition in 6547 RFC 1510. The transited-policy-checked(12) and the ok-as-delegate(13) 6548 ticket flags were added. The disable-transited-check(26) KDC option 6549 was added. 6551 Descriptions of commonly implemented PA-DATA were added to section 5. 6552 The description of KRB-SAFE has been updated to note the existing 6553 implementation behavior of double-encoding. 6555 There were two definitions of METHOD-DATA in RFC 1510. The second 6557 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 6559 one, intended for use with KRB_AP_ERR_METHOD was removed leaving the 6560 SEQUENCE OF PA-DATA definition. 6562 Section 7, naming constraints, from RFC1510 was moved to section 6. 6564 Words were added describing the convention that domain based realm 6565 names for newly created realms should be specified as upper case. 6566 This recommendation does not make lower case realm names illegal. 6567 Words were added highlighting that the slash separated components in 6568 the X500 style of realm names is consistent with existing RFC1510 6569 based implementations, but that it conflicts with the general 6570 recommendation of X.500 name representation specified in RFC2253. 6572 Section 8, network transport, constants and defined values, from 6573 RFC1510 was moved to section 7. Since RFC1510, the definition of the 6574 TCP transport for Kerberos messages was added, and the encryption and 6575 checksum number assignments have been moved into a separate document. 6577 "Specification 2" in section 8 of the current document changes the 6578 required encryption and checksum methods to bring them in line with 6579 the best current practices and to deprecate methods that are no 6580 longer considered sufficiently strong. 6582 Two new sections, on IANA considerations and security considerations 6583 were added. 6585 The pseudo-code has been removed from the appendix. The pseudo-code 6586 was sometimes misinterpreted to limit implementation choices and in 6587 RFC 1510, it was not always consistent with the words in the 6588 specification. Effort was made to clear up any ambiguities in the 6589 specification, rather than to rely on the pseudo-code. 6591 An appendix was added containing the complete ASN.1 module drawn from 6592 the discussion in section 5 of the current document. 6594 An appendix was added defining those authorization data elements that 6595 must be understood by all Kerberos implementations. 6597 END NOTES 6599 [TM] Project Athena, Athena, and Kerberos are trademarks of the 6600 Massachusetts Institute of Technology (MIT). No commercial use of 6601 these trademarks may be made without prior written permission of MIT. 6603 [1] Note, however, that many applications use Kerberos' functions 6604 only upon the initiation of a stream-based network connection. Unless 6605 an application subsequently provides integrity protection for the 6606 data stream, the identity verification applies only to the initiation 6608 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 6610 of the connection, and does not guarantee that subsequent messages on 6611 the connection originate from the same principal. 6613 [2] Secret and private are often used interchangeably in the 6614 literature. In our usage, it takes two (or more) to share a secret, 6615 thus a shared DES key is a secret key. Something is only private when 6616 no one but its owner knows it. Thus, in public key cryptosystems, one 6617 has a public and a private key. 6619 [3] Of course, with appropriate permission the client could arrange 6620 registration of a separately-named principal in a remote realm, and 6621 engage in normal exchanges with that realm's services. However, for 6622 even small numbers of clients this becomes cumbersome, and more 6623 automatic methods as described here are necessary. 6625 [4] Though it is permissible to request or issue tickets with no 6626 network addresses specified. 6628 [5] The password-changing request must not be honored unless the 6629 requester can provide the old password (the user's current secret 6630 key). Otherwise, it would be possible for someone to walk up to an 6631 unattended session and change another user's password. 6633 [6] To authenticate a user logging on to a local system, the 6634 credentials obtained in the AS exchange may first be used in a TGS 6635 exchange to obtain credentials for a local server. Those credentials 6636 must then be verified by a local server through successful completion 6637 of the Client/Server exchange. 6639 [7] "Random" means that, among other things, it should be impossible 6640 to guess the next session key based on knowledge of past session 6641 keys. This can only be achieved in a pseudo-random number generator 6642 if it is based on cryptographic principles. It is more desirable to 6643 use a truly random number generator, such as one based on 6644 measurements of random physical phenomena. 6646 [8] Tickets contain both an encrypted and unencrypted portion, so 6647 cleartext here refers to the entire unit, which can be copied from 6648 one message and replayed in another without any cryptographic skill. 6650 [9] Note that this can make applications based on unreliable 6651 transports difficult to code correctly. If the transport might 6652 deliver duplicated messages, either a new authenticator must be 6653 generated for each retry, or the application server must match 6654 requests and replies and replay the first reply in response to a 6655 detected duplicate. 6657 [10] Note also that the rejection here is restricted to 6659 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT 6661 authenticators from the same principal to the same server. Other 6662 client principals communicating with the same server principal should 6663 not be have their authenticators rejected if the time and microsecond 6664 fields happen to match some other client's authenticator. 6666 [11] If this is not done, an attacker could subvert the 6667 authentication by recording the ticket and authenticator sent over 6668 the network to a server and replaying them following an event that 6669 caused the server to lose track of recently seen authenticators. 6671 [12] In the Kerberos version 4 protocol, the timestamp in the reply 6672 was the client's timestamp plus one. This is not necessary in version 6673 5 because version 5 messages are formatted in such a way that it is 6674 not possible to create the reply by judicious message surgery (even 6675 in encrypted form) without knowledge of the appropriate encryption 6676 keys. 6678 [13] Note that for encrypting the KRB_AP_REP message, the sub-session 6679 key is not used, even if present in the Authenticator. 6681 [14] Implementations of the protocol may provide routines to choose 6682 subkeys based on session keys and random numbers and to generate a 6683 negotiated key to be returned in the KRB_AP_REP message. 6685 [15]This can be accomplished in several ways. It might be known 6686 beforehand (since the realm is part of the principal identifier), it 6687 might be stored in a nameserver, or it might be obtained from a 6688 configuration file. If the realm to be used is obtained from a 6689 nameserver, there is a danger of being spoofed if the nameservice 6690 providing the realm name is not authenticated. This might result in 6691 the use of a realm which has been compromised, and would result in an 6692 attacker's ability to compromise the authentication of the 6693 application server to the client. 6695 [16] If the client selects a sub-session key, care must be taken to 6696 ensure the randomness of the selected sub-session key. One approach 6697 would be to generate a random number and XOR it with the session key 6698 from the ticket-granting ticket.