idnits 2.17.1 draft-ietf-krb-wg-kerberos-clarifications-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 6125. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 6136. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 6143. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 6149. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 3) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 252 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([DS81], [MNSS87], [NT94], [NS78], [SNS88], [KNT94]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 7 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 4776 has weird spacing: '...ticator non-P...' == Line 4778 has weird spacing: '...ketPart non-P...' == Line 4809 has weird spacing: '...RepPart non-...' == Line 4811 has weird spacing: '...RepPart non-P...' == Line 4813 has weird spacing: '...RepPart non-...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 29, 2004) is 7242 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: 'RFC1964' is mentioned on line 2509, but not defined == Missing Reference: 'ISO-646' is mentioned on line 2618, but not defined == Missing Reference: 'ECMA-6' is mentioned on line 2618, but not defined == Missing Reference: 'ISO-8859' is mentioned on line 2625, but not defined -- Looks like a reference, but probably isn't: '0' on line 6553 -- Looks like a reference, but probably isn't: '1' on line 6554 -- Looks like a reference, but probably isn't: '2' on line 6546 -- Looks like a reference, but probably isn't: '3' on line 6547 == Missing Reference: 'APPLICATION 1' is mentioned on line 6238, but not defined == Missing Reference: 'APPLICATION 3' is mentioned on line 6246, but not defined -- Looks like a reference, but probably isn't: '4' on line 6497 -- Looks like a reference, but probably isn't: '5' on line 6498 -- Looks like a reference, but probably isn't: '6' on line 6499 -- Looks like a reference, but probably isn't: '7' on line 6500 -- Looks like a reference, but probably isn't: '8' on line 6503 -- Looks like a reference, but probably isn't: '9' on line 6504 -- Looks like a reference, but probably isn't: '10' on line 6505 == Missing Reference: 'APPLICATION 10' is mentioned on line 6285, but not defined == Missing Reference: 'APPLICATION 12' is mentioned on line 6287, but not defined -- Looks like a reference, but probably isn't: '11' on line 6506 == Missing Reference: 'APPLICATION 11' is mentioned on line 6346, but not defined == Missing Reference: 'APPLICATION 13' is mentioned on line 6348, but not defined == Missing Reference: 'APPLICATION 25' is mentioned on line 6365, but not defined == Missing Reference: 'APPLICATION 26' is mentioned on line 6367, but not defined == Missing Reference: 'APPLICATION 14' is mentioned on line 6389, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 6404, but not defined == Missing Reference: 'APPLICATION 15' is mentioned on line 6416, but not defined == Missing Reference: 'APPLICATION 27' is mentioned on line 6422, but not defined == Missing Reference: 'APPLICATION 20' is mentioned on line 6429, but not defined == Missing Reference: 'APPLICATION 21' is mentioned on line 6445, but not defined == Missing Reference: 'APPLICATION 28' is mentioned on line 6453, but not defined == Missing Reference: 'APPLICATION 22' is mentioned on line 6462, but not defined == Missing Reference: 'APPLICATION 29' is mentioned on line 6469, but not defined == Missing Reference: 'APPLICATION 30' is mentioned on line 6492, but not defined -- Looks like a reference, but probably isn't: '12' on line 6507 == Missing Reference: 'RFC 2253' is mentioned on line 5425, 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 == Missing Reference: 'RFC 2434' is mentioned on line 5684, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Unused Reference: 'RFC1035' is defined on line 6000, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 6009, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 6014, but no explicit reference was found in the text == Unused Reference: 'RFC2782' is defined on line 6018, but no explicit reference was found in the text == Unused Reference: 'RFC2253' is defined on line 6022, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 6099, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-krb-wg-kerberos-clarifications-06 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3377 (ref. 'RFC2253') (Obsoleted by RFC 4510) ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' == Outdated reference: A later version (-07) exists of draft-ietf-krb-wg-kerberos-clarifications-06 -- Duplicate reference: draft-ietf-krb-wg-kerberos-clarifications, mentioned in 'DS81', was also mentioned in 'RFC1035'. -- Obsolete informational reference (is this intentional?): RFC 1510 (Obsoleted by RFC 4120, RFC 6649) -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) == Outdated reference: A later version (-07) exists of draft-ietf-krb-wg-kerberos-clarifications-06 -- Duplicate reference: draft-ietf-krb-wg-kerberos-clarifications, mentioned in 'RFC2026', was also mentioned in 'DS81'. Summary: 15 errors (**), 0 flaws (~~), 45 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Clifford Neuman 3 Obsoletes: 1510 USC-ISI 4 Tom Yu 5 Sam Hartman 6 Ken Raeburn 7 MIT 8 June 29, 2004 9 Expires 29 December, 2004 11 The Kerberos Network Authentication Service (V5) 12 draft-ietf-krb-wg-kerberos-clarifications-06.txt 14 STATUS OF THIS MEMO 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC 2026. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 To learn the current status of any Internet-Draft, please check the 34 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 35 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 36 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 38 The distribution of this memo is unlimited. It is filed as draft- 39 ietf-krb-wg-kerberos-clarifications-06.txt, and expires 29 December 40 2004. Please send comments to: ietf-krb-wg@anl.gov 42 ABSTRACT 44 This document provides an overview and specification of Version 5 of 45 the Kerberos protocol, and obsoletes RFC1510 to clarify aspects of 46 the protocol and its intended use that require more detailed or 47 clearer explanation than was provided in RFC1510. This document is 48 intended to provide a detailed description of the protocol, suitable 49 for implementation, together with descriptions of the appropriate use 50 of protocol messages and fields within those messages. 52 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 54 OVERVIEW 56 This document describes the concepts and model upon which the 57 Kerberos network authentication system is based. It also specifies 58 Version 5 of the Kerberos protocol. The motivations, goals, 59 assumptions, and rationale behind most design decisions are treated 60 cursorily; they are more fully described in a paper available in IEEE 61 communications [NT94] and earlier in the Kerberos portion of the 62 Athena Technical Plan [MNSS87]. 64 This document is not intended to describe Kerberos to the end user, 65 system administrator, or application developer. Higher level papers 66 describing Version 5 of the Kerberos system [NT94] and documenting 67 version 4 [SNS88], are available elsewhere. 69 BACKGROUND 71 The Kerberos model is based in part on Needham and Schroeder's 72 trusted third-party authentication protocol [NS78] and on 73 modifications suggested by Denning and Sacco [DS81]. The original 74 design and implementation of Kerberos Versions 1 through 4 was the 75 work of two former Project Athena staff members, Steve Miller of 76 Digital Equipment Corporation and Clifford Neuman (now at the 77 Information Sciences Institute of the University of Southern 78 California), along with Jerome Saltzer, Technical Director of Project 79 Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other 80 members of Project Athena have also contributed to the work on 81 Kerberos. 83 Version 5 of the Kerberos protocol (described in this document) has 84 evolved from Version 4 based on new requirements and desires for 85 features not available in Version 4. The design of Version 5 of the 86 Kerberos protocol was led by Clifford Neuman and John Kohl with much 87 input from the community. The development of the MIT reference 88 implementation was led at MIT by John Kohl and Theodore Ts'o, with 89 help and contributed code from many others. Since RFC1510 was issued, 90 extensions and revisions to the protocol have been proposed by many 91 individuals. Some of these proposals are reflected in this document. 92 Where such changes involved significant effort, the document cites 93 the contribution of the proposer. 95 Reference implementations of both version 4 and version 5 of Kerberos 96 are publicly available and commercial implementations have been 97 developed and are widely used. Details on the differences between 98 Kerberos Versions 4 and 5 can be found in [KNT94]. 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119. 104 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 106 Table of Contents 108 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 6 109 1.1. Cross-realm operation . . . . . . . . . . . . . . . . . . . . . 8 110 1.2. Choosing a principal with which to communicate . . . . . . . . 9 111 1.3. Authorization . . . . . . . . . . . . . . . . . . . . . . . . . 10 112 1.4. Extending Kerberos Without Breaking Interoperability . . . . . 11 113 1.4.1. Compatibility with RFC 1510 . . . . . . . . . . . . . . . . . 11 114 1.4.2. Sending Extensible Messages . . . . . . . . . . . . . . . . . 12 115 1.5. Environmental assumptions . . . . . . . . . . . . . . . . . . . 12 116 1.6. Glossary of terms . . . . . . . . . . . . . . . . . . . . . . . 13 117 2. Ticket flag uses and requests . . . . . . . . . . . . . . . . . . 16 118 2.1. Initial, pre-authenticated, and hardware authenticated 119 tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 120 2.2. Invalid tickets . . . . . . . . . . . . . . . . . . . . . . . . 17 121 2.3. Renewable tickets . . . . . . . . . . . . . . . . . . . . . . . 17 122 2.4. Postdated tickets . . . . . . . . . . . . . . . . . . . . . . . 18 123 2.5. Proxiable and proxy tickets . . . . . . . . . . . . . . . . . . 19 124 2.6. Forwardable tickets . . . . . . . . . . . . . . . . . . . . . . 19 125 2.7. Transited Policy Checking . . . . . . . . . . . . . . . . . . . 20 126 2.8. OK as Delegate . . . . . . . . . . . . . . . . . . . . . . . . 21 127 2.9. Other KDC options . . . . . . . . . . . . . . . . . . . . . . . 21 128 2.9.1. Renewable-OK . . . . . . . . . . . . . . . . . . . . . . . . 21 129 2.9.2. ENC-TKT-IN-SKEY . . . . . . . . . . . . . . . . . . . . . . . 22 130 2.9.3. Passwordless Hardware Authentication . . . . . . . . . . . . 22 131 3. Message Exchanges . . . . . . . . . . . . . . . . . . . . . . . . 22 132 3.1. The Authentication Service Exchange . . . . . . . . . . . . . . 22 133 3.1.1. Generation of KRB_AS_REQ message . . . . . . . . . . . . . . 24 134 3.1.2. Receipt of KRB_AS_REQ message . . . . . . . . . . . . . . . . 24 135 3.1.3. Generation of KRB_AS_REP message . . . . . . . . . . . . . . 24 136 3.1.4. Generation of KRB_ERROR message . . . . . . . . . . . . . . . 27 137 3.1.5. Receipt of KRB_AS_REP message . . . . . . . . . . . . . . . . 27 138 3.1.6. Receipt of KRB_ERROR message . . . . . . . . . . . . . . . . 28 139 3.2. The Client/Server Authentication Exchange . . . . . . . . . . . 28 140 3.2.1. The KRB_AP_REQ message . . . . . . . . . . . . . . . . . . . 29 141 3.2.2. Generation of a KRB_AP_REQ message . . . . . . . . . . . . . 29 142 3.2.3. Receipt of KRB_AP_REQ message . . . . . . . . . . . . . . . . 30 143 3.2.4. Generation of a KRB_AP_REP message . . . . . . . . . . . . . 32 144 3.2.5. Receipt of KRB_AP_REP message . . . . . . . . . . . . . . . . 33 145 3.2.6. Using the encryption key . . . . . . . . . . . . . . . . . . 33 146 3.3. The Ticket-Granting Service (TGS) Exchange . . . . . . . . . . 34 147 3.3.1. Generation of KRB_TGS_REQ message . . . . . . . . . . . . . . 35 148 3.3.2. Receipt of KRB_TGS_REQ message . . . . . . . . . . . . . . . 37 149 3.3.3. Generation of KRB_TGS_REP message . . . . . . . . . . . . . . 38 150 3.3.3.1. Checking for revoked tickets . . . . . . . . . . . . . . . 40 151 3.3.3.2. Encoding the transited field . . . . . . . . . . . . . . . 40 152 3.3.4. Receipt of KRB_TGS_REP message . . . . . . . . . . . . . . . 42 153 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 155 3.4. The KRB_SAFE Exchange . . . . . . . . . . . . . . . . . . . . . 42 156 3.4.1. Generation of a KRB_SAFE message . . . . . . . . . . . . . . 42 157 3.4.2. Receipt of KRB_SAFE message . . . . . . . . . . . . . . . . . 43 158 3.5. The KRB_PRIV Exchange . . . . . . . . . . . . . . . . . . . . . 44 159 3.5.1. Generation of a KRB_PRIV message . . . . . . . . . . . . . . 44 160 3.5.2. Receipt of KRB_PRIV message . . . . . . . . . . . . . . . . . 44 161 3.6. The KRB_CRED Exchange . . . . . . . . . . . . . . . . . . . . . 45 162 3.6.1. Generation of a KRB_CRED message . . . . . . . . . . . . . . 45 163 3.6.2. Receipt of KRB_CRED message . . . . . . . . . . . . . . . . . 46 164 3.7. User-to-User Authentication Exchanges . . . . . . . . . . . . . 47 165 4. Encryption and Checksum Specifications . . . . . . . . . . . . . 48 166 5. Message Specifications . . . . . . . . . . . . . . . . . . . . . 50 167 5.1. Specific Compatibility Notes on ASN.1 . . . . . . . . . . . . . 51 168 5.1.1. ASN.1 Distinguished Encoding Rules . . . . . . . . . . . . . 51 169 5.1.2. Optional Integer Fields . . . . . . . . . . . . . . . . . . . 51 170 5.1.3. Empty SEQUENCE OF Types . . . . . . . . . . . . . . . . . . . 52 171 5.1.4. Unrecognized Tag Numbers . . . . . . . . . . . . . . . . . . 52 172 5.1.5. Tag Numbers Greater Than 30 . . . . . . . . . . . . . . . . . 52 173 5.2. Basic Kerberos Types . . . . . . . . . . . . . . . . . . . . . 52 174 5.2.1. KerberosString . . . . . . . . . . . . . . . . . . . . . . . 53 175 5.2.2. Realm and PrincipalName . . . . . . . . . . . . . . . . . . . 54 176 5.2.3. KerberosTime . . . . . . . . . . . . . . . . . . . . . . . . 55 177 5.2.4. Constrained Integer types . . . . . . . . . . . . . . . . . . 55 178 5.2.5. HostAddress and HostAddresses . . . . . . . . . . . . . . . . 56 179 5.2.6. AuthorizationData . . . . . . . . . . . . . . . . . . . . . . 56 180 5.2.6.1. IF-RELEVANT . . . . . . . . . . . . . . . . . . . . . . . . 58 181 5.2.6.2. KDCIssued . . . . . . . . . . . . . . . . . . . . . . . . . 58 182 5.2.6.3. AND-OR . . . . . . . . . . . . . . . . . . . . . . . . . . 59 183 5.2.6.4. MANDATORY-FOR-KDC . . . . . . . . . . . . . . . . . . . . . 59 184 5.2.7. PA-DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 185 5.2.7.1. PA-TGS-REQ . . . . . . . . . . . . . . . . . . . . . . . . 61 186 5.2.7.2. Encrypted Timestamp Pre-authentication . . . . . . . . . . 61 187 5.2.7.3. PA-PW-SALT . . . . . . . . . . . . . . . . . . . . . . . . 61 188 5.2.7.4. PA-ETYPE-INFO . . . . . . . . . . . . . . . . . . . . . . . 62 189 5.2.7.5. PA-ETYPE-INFO2 . . . . . . . . . . . . . . . . . . . . . . 62 190 5.2.8. KerberosFlags . . . . . . . . . . . . . . . . . . . . . . . . 63 191 5.2.9. Cryptosystem-related Types . . . . . . . . . . . . . . . . . 64 192 5.3. Tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 193 5.4. Specifications for the AS and TGS exchanges . . . . . . . . . . 73 194 5.4.1. KRB_KDC_REQ definition . . . . . . . . . . . . . . . . . . . 73 195 5.4.2. KRB_KDC_REP definition . . . . . . . . . . . . . . . . . . . 81 196 5.5. Client/Server (CS) message specifications . . . . . . . . . . . 84 197 5.5.1. KRB_AP_REQ definition . . . . . . . . . . . . . . . . . . . . 84 198 5.5.2. KRB_AP_REP definition . . . . . . . . . . . . . . . . . . . . 87 199 5.5.3. Error message reply . . . . . . . . . . . . . . . . . . . . . 88 200 5.6. KRB_SAFE message specification . . . . . . . . . . . . . . . . 89 201 5.6.1. KRB_SAFE definition . . . . . . . . . . . . . . . . . . . . . 89 202 5.7. KRB_PRIV message specification . . . . . . . . . . . . . . . . 90 203 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 205 5.7.1. KRB_PRIV definition . . . . . . . . . . . . . . . . . . . . . 91 206 5.8. KRB_CRED message specification . . . . . . . . . . . . . . . . 91 207 5.8.1. KRB_CRED definition . . . . . . . . . . . . . . . . . . . . . 91 208 5.9. Error message specification . . . . . . . . . . . . . . . . . . 94 209 5.9.1. KRB_ERROR definition . . . . . . . . . . . . . . . . . . . . 94 210 5.10. Application Tag Numbers . . . . . . . . . . . . . . . . . . . 96 211 6. Naming Constraints . . . . . . . . . . . . . . . . . . . . . . . 97 212 6.1. Realm Names . . . . . . . . . . . . . . . . . . . . . . . . . . 97 213 6.2. Principal Names . . . . . . . . . . . . . . . . . . . . . . . . 98 214 6.2.1. Name of server principals . . . . . . . . . . . . . . . . . . 100 215 7. Constants and other defined values . . . . . . . . . . . . . . . 100 216 7.1. Host address types . . . . . . . . . . . . . . . . . . . . . . 100 217 7.2. KDC messaging - IP Transports . . . . . . . . . . . . . . . . . 101 218 7.2.1. UDP/IP transport . . . . . . . . . . . . . . . . . . . . . . 102 219 7.2.2. TCP/IP transport . . . . . . . . . . . . . . . . . . . . . . 102 220 7.2.3. KDC Discovery on IP Networks . . . . . . . . . . . . . . . . 103 221 7.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names . . . . 103 222 7.2.3.2. Specifying KDC Location information with DNS SRV 223 records . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 224 7.2.3.3. KDC Discovery for Domain Style Realm Names on IP 225 Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 226 7.3. Name of the TGS . . . . . . . . . . . . . . . . . . . . . . . . 105 227 7.4. OID arc for KerberosV5 . . . . . . . . . . . . . . . . . . . . 105 228 7.5. Protocol constants and associated values . . . . . . . . . . . 105 229 7.5.1. Key usage numbers . . . . . . . . . . . . . . . . . . . . . . 105 230 7.5.2. PreAuthentication Data Types . . . . . . . . . . . . . . . . 107 231 7.5.3. Address Types . . . . . . . . . . . . . . . . . . . . . . . . 108 232 7.5.4. Authorization Data Types . . . . . . . . . . . . . . . . . . 108 233 7.5.5. Transited Encoding Types . . . . . . . . . . . . . . . . . . 108 234 7.5.6. Protocol Version Number . . . . . . . . . . . . . . . . . . . 108 235 7.5.7. Kerberos Message Types . . . . . . . . . . . . . . . . . . . 108 236 7.5.8. Name Types . . . . . . . . . . . . . . . . . . . . . . . . . 109 237 7.5.9. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 109 238 8. Interoperability requirements . . . . . . . . . . . . . . . . . . 111 239 8.1. Specification 2 . . . . . . . . . . . . . . . . . . . . . . . . 111 240 8.2. Recommended KDC values . . . . . . . . . . . . . . . . . . . . 114 241 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . . . 114 242 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 115 243 11. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 119 244 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 120 245 13. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 246 13.1 NORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . . 120 247 13.2 INFORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . 121 248 14. Copyright Statement . . . . . . . . . . . . . . . . . . . . . . 123 249 15. Intellectual Property . . . . . . . . . . . . . . . . . . . . . 123 250 A. ASN.1 module . . . . . . . . . . . . . . . . . . . . . . . . . . 124 251 B. Changes since RFC-1510 . . . . . . . . . . . . . . . . . . . . . 132 252 END NOTES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 253 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 255 1. Introduction 257 Kerberos provides a means of verifying the identities of principals, 258 (e.g. a workstation user or a network server) on an open 259 (unprotected) network. This is accomplished without relying on 260 assertions by the host operating system, without basing trust on host 261 addresses, without requiring physical security of all the hosts on 262 the network, and under the assumption that packets traveling along 263 the network can be read, modified, and inserted at will. Kerberos 264 performs authentication under these conditions as a trusted third- 265 party authentication service by using conventional (shared secret 266 key) cryptography. Extensions to Kerberos (outside the scope of this 267 document) can provide for the use of public key cryptography during 268 certain phases of the authentication protocol [@RFCE: if PKINIT 269 advances concurrently include reference to the RFC here]. Such 270 extensions support Kerberos authentication for users registered with 271 public key certification authorities and provide certain benefits of 272 public key cryptography in situations where they are needed. 274 The basic Kerberos authentication process proceeds as follows: A 275 client sends a request to the authentication server (AS) requesting 276 "credentials" for a given server. The AS responds with these 277 credentials, encrypted in the client's key. The credentials consist 278 of a "ticket" for the server and a temporary encryption key (often 279 called a "session key"). The client transmits the ticket (which 280 contains the client's identity and a copy of the session key, all 281 encrypted in the server's key) to the server. The session key (now 282 shared by the client and server) is used to authenticate the client, 283 and may optionally be used to authenticate the server. It may also be 284 used to encrypt further communication between the two parties or to 285 exchange a separate sub-session key to be used to encrypt further 286 communication. Note that many applications use Kerberos' functions 287 only upon the initiation of a stream-based network connection. Unless 288 an application performs encryption or integrity protection for the 289 data stream, the identity verification applies only to the initiation 290 of the connection, and does not guarantee that subsequent messages on 291 the connection originate from the same principal. 293 Implementation of the basic protocol consists of one or more 294 authentication servers running on physically secure hosts. The 295 authentication servers maintain a database of principals (i.e., users 296 and servers) and their secret keys. Code libraries provide encryption 297 and implement the Kerberos protocol. In order to add authentication 298 to its transactions, a typical network application adds calls to the 299 Kerberos library directly or through the Generic Security Services 300 Application Programming Interface, GSSAPI, described in separate 301 document [ref to GSSAPI RFC]. These calls result in the transmission 302 of the necessary messages to achieve authentication. 304 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 306 The Kerberos protocol consists of several sub-protocols (or 307 exchanges). There are two basic methods by which a client can ask a 308 Kerberos server for credentials. In the first approach, the client 309 sends a cleartext request for a ticket for the desired server to the 310 AS. The reply is sent encrypted in the client's secret key. Usually 311 this request is for a ticket-granting ticket (TGT) which can later be 312 used with the ticket-granting server (TGS). In the second method, 313 the client sends a request to the TGS. The client uses the TGT to 314 authenticate itself to the TGS in the same manner as if it were 315 contacting any other application server that requires Kerberos 316 authentication. The reply is encrypted in the session key from the 317 TGT. Though the protocol specification describes the AS and the TGS 318 as separate servers, they are implemented in practice as different 319 protocol entry points within a single Kerberos server. 321 Once obtained, credentials may be used to verify the identity of the 322 principals in a transaction, to ensure the integrity of messages 323 exchanged between them, or to preserve privacy of the messages. The 324 application is free to choose whatever protection may be necessary. 326 To verify the identities of the principals in a transaction, the 327 client transmits the ticket to the application server. Since the 328 ticket is sent "in the clear" (parts of it are encrypted, but this 329 encryption doesn't thwart replay) and might be intercepted and reused 330 by an attacker, additional information is sent to prove that the 331 message originated with the principal to whom the ticket was issued. 332 This information (called the authenticator) is encrypted in the 333 session key, and includes a timestamp. The timestamp proves that the 334 message was recently generated and is not a replay. Encrypting the 335 authenticator in the session key proves that it was generated by a 336 party possessing the session key. Since no one except the requesting 337 principal and the server know the session key (it is never sent over 338 the network in the clear) this guarantees the identity of the client. 340 The integrity of the messages exchanged between principals can also 341 be guaranteed using the session key (passed in the ticket and 342 contained in the credentials). This approach provides detection of 343 both replay attacks and message stream modification attacks. It is 344 accomplished by generating and transmitting a collision-proof 345 checksum (elsewhere called a hash or digest function) of the client's 346 message, keyed with the session key. Privacy and integrity of the 347 messages exchanged between principals can be secured by encrypting 348 the data to be passed using the session key contained in the ticket 349 or the sub-session key found in the authenticator. 351 The authentication exchanges mentioned above require read-only access 352 to the Kerberos database. Sometimes, however, the entries in the 353 database must be modified, such as when adding new principals or 354 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 356 changing a principal's key. This is done using a protocol between a 357 client and a third Kerberos server, the Kerberos Administration 358 Server (KADM). There is also a protocol for maintaining multiple 359 copies of the Kerberos database. Neither of these protocols are 360 described in this document. 362 1.1. Cross-realm operation 364 The Kerberos protocol is designed to operate across organizational 365 boundaries. A client in one organization can be authenticated to a 366 server in another. Each organization wishing to run a Kerberos server 367 establishes its own "realm". The name of the realm in which a client 368 is registered is part of the client's name, and can be used by the 369 end-service to decide whether to honor a request. 371 By establishing "inter-realm" keys, the administrators of two realms 372 can allow a client authenticated in the local realm to prove its 373 identity to servers in other realms. The exchange of inter-realm keys 374 (a separate key may be used for each direction) registers the ticket- 375 granting service of each realm as a principal in the other realm. A 376 client is then able to obtain a ticket-granting ticket for the remote 377 realm's ticket-granting service from its local realm. When that 378 ticket-granting ticket is used, the remote ticket-granting service 379 uses the inter-realm key (which usually differs from its own normal 380 TGS key) to decrypt the ticket-granting ticket, and is thus certain 381 that it was issued by the client's own TGS. Tickets issued by the 382 remote ticket-granting service will indicate to the end-service that 383 the client was authenticated from another realm. 385 WIthout cross-realm operation, and with appropriate permission the 386 client can arrange registration of a separately-named principal in a 387 remote realm, and engage in normal exchanges with that realm's 388 services. However, for even small numbers of clients this becomes 389 cumbersome, and more automatic methods as described here are 390 necessary. 392 A realm is said to communicate with another realm if the two realms 393 share an inter-realm key, or if the local realm shares an inter-realm 394 key with an intermediate realm that communicates with the remote 395 realm. An authentication path is the sequence of intermediate realms 396 that are transited in communicating from one realm to another. 398 Realms may be organized hierarchically. Each realm shares a key with 399 its parent and a different key with each child. If an inter-realm key 400 is not directly shared by two realms, the hierarchical organization 401 allows an authentication path to be easily constructed. If a 402 hierarchical organization is not used, it may be necessary to consult 403 a database in order to construct an authentication path between 404 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 406 realms. 408 Although realms are typically hierarchical, intermediate realms may 409 be bypassed to achieve cross-realm authentication through alternate 410 authentication paths (these might be established to make 411 communication between two realms more efficient). It is important for 412 the end-service to know which realms were transited when deciding how 413 much faith to place in the authentication process. To facilitate this 414 decision, a field in each ticket contains the names of the realms 415 that were involved in authenticating the client. 417 The application server is ultimately responsible for accepting or 418 rejecting authentication and SHOULD check the transited field. The 419 application server may choose to rely on the KDC for the application 420 server's realm to check the transited field. The application server's 421 KDC will set the TRANSITED-POLICY-CHECKED flag in this case. The KDCs 422 for intermediate realms may also check the transited field as they 423 issue ticket-granting tickets for other realms, but they are 424 encouraged not to do so. A client may request that the KDCs not check 425 the transited field by setting the DISABLE-TRANSITED-CHECK flag. KDCs 426 SHOULD honor this flag. 428 1.2. Choosing a principal with which to communicate 430 The Kerberos protocol provides the means for verifying (subject to 431 the assumptions in 1.5) that the entity with which one communicates 432 is the same entity that was registered with the KDC using the claimed 433 identity (principal name). It is still necessary to determine whether 434 that identity corresponds to the entity with which one intends to 435 communicate. 437 When appropriate data has been exchanged in advance, this 438 determination may be performed syntactically by the application based 439 on the application protocol specification, information provided by 440 the user, and configuration files. For example, the server principal 441 name (including realm) for a telnet server might be derived from the 442 user specified host name (from the telnet command line), the "host/" 443 prefix specified in the application protocol specification, and a 444 mapping to a Kerberos realm derived syntactically from the domain 445 part of the specified hostname and information from the local 446 Kerberos realms database. 448 One can also rely on trusted third parties to make this 449 determination, but only when the data obtained from the third party 450 is suitably integrity protected while resident on the third party 451 server and when transmitted. Thus, for example, one should not rely 452 on an unprotected domain name system record to map a host alias to 453 the primary name of a server, accepting the primary name as the party 454 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 456 one intends to contact, since an attacker can modify the mapping and 457 impersonate the party with which one intended to communicate. 459 Implementations of Kerberos and protocols based on Kerberos MUST NOT 460 use insecure DNS queries to canonicalize the hostname components of 461 the service principal names (i.e. MUST NOT use insecure DNS queries 462 to map one name to another to determine the host part of the 463 principal name with which one is to communicate). In an environment 464 without secure name service, application authors MAY append a 465 statically configured domain name to unqualified hostnames before 466 passing the name to the security mechanisms, but should do no more 467 than that. Secure name service facilities, if available, might be 468 trusted for hostname canonicalization, but such canonicalization by 469 the client SHOULD NOT be required by KDC implementations. 471 Implementation note: Many current implementations do some degree of 472 canonicalization of the provided service name, often using DNS even 473 though it creates security problems. However there is no consistency 474 among implementations about whether the service name is case folded 475 to lower case or whether reverse resolution is used. To maximize 476 interoperability and security, applications SHOULD provide security 477 mechanisms with names which result from folding the user-entered name 478 to lower case, without performing any other modifications or 479 canonicalization. 481 1.3. Authorization 483 As an authentication service, Kerberos provides a means of verifying 484 the identity of principals on a network. Authentication is usually 485 useful primarily as a first step in the process of authorization, 486 determining whether a client may use a service, which objects the 487 client is allowed to access, and the type of access allowed for each. 488 Kerberos does not, by itself, provide authorization. Possession of a 489 client ticket for a service provides only for authentication of the 490 client to that service, and in the absence of a separate 491 authorization procedure, it should not be considered by an 492 application as authorizing the use of that service. 494 Such separate authorization methods MAY be implemented as application 495 specific access control functions and may utilize files on the 496 application server, or on separately issued authorization credentials 497 such as those based on proxies [Neu93], or on other authorization 498 services. Separately authenticated authorization credentials MAY be 499 embedded in a ticket's authorization data when encapsulated by the 500 KDC-issued authorization data element. 502 Applications should not accept the mere issuance of a service ticket 503 by the Kerberos server (even by a modified Kerberos server) as 504 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 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 are provided. 511 1.4. Extending Kerberos Without Breaking Interoperability 513 As the deployed base of Kerberos implementations grows, extending 514 Kerberos becomes more important. Unfortunately some extensions to the 515 existing Kerberos protocol create interoperability issues because of 516 uncertainty regarding the treatment of certain extensibility options 517 by some implementations. This section includes guidelines that will 518 enable future implementations to maintain interoperability. 520 Kerberos provides a general mechanism for protocol extensibility. 521 Some protocol messages contain typed holes -- sub-messages that 522 contain an octet-string along with an integer that defines how to 523 interpret the octet-string. The integer types are registered 524 centrally, but can be used both for vendor extensions and for 525 extensions standardized through the IETF. 527 In this document, the word "extension" means an extension by defining 528 a new type to insert into an existing typed hole in a protocol 529 message. It does not mean extension by addition of new fields to 530 ASN.1 types, unless explicitly indicated otherwise in the text. 532 1.4.1. Compatibility with RFC 1510 534 It is important to note that existing Kerberos message formats can 535 not be readily extended by adding fields to the ASN.1 types. Sending 536 additional fields often results in the entire message being discarded 537 without an error indication. Future versions of this specification 538 will provide guidelines to ensure that ASN.1 fields can be added 539 without creating an interoperability problem. 541 In the meantime, all new or modified implementations of Kerberos that 542 receive an unknown message extension SHOULD preserve the encoding of 543 the extension but otherwise ignore the presence of the extension. 544 Recipients MUST NOT decline a request simply because an extension is 545 present. 547 There is one exception to this rule. If an unknown authorization data 548 element type is received by a server other than the ticket granting 549 service either in an AP-REQ or in a ticket contained in an AP-REQ, 550 then authentication MUST fail. One of the primary uses of 551 authorization data is to restrict the use of the ticket. If the 552 service cannot determine whether the restriction applies to that 553 service then a security weakness may result if the ticket can be used 554 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 556 for that service. Authorization elements that are optional SHOULD be 557 enclosed in the AD-IF-RELEVANT element. 559 The ticket granting service MUST ignore but propagate to derivative 560 tickets any unknown authorization data types, unless those data types 561 are embedded in a MANDATORY-FOR-KDC element, in which case the 562 request will be rejected. This behavior is appropriate because 563 requiring that the ticket granting service understand unknown 564 authorization data types would require that KDC software be upgraded 565 to understand new application-level restrictions before applications 566 used these restrictions, decreasing the utility of authorization data 567 as a mechanism for restricting the use of tickets. No security 568 problem is created because services to which the tickets are issued 569 will verify the authorization data. 571 Implementation note: Many RFC 1510 implementations ignore unknown 572 authorization data elements. Depending on these implementations to 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 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 606 are places in the protocols where an intruder can prevent an 607 application from participating in the proper authentication steps. 608 Detection and solution of such attacks (some of which can appear 609 to be not-uncommon "normal" failure modes for the system) is 610 usually best left to the human administrators and users. 612 * Principals MUST keep their secret keys secret. If an intruder 613 somehow steals a principal's key, it will be able to masquerade as 614 that principal or impersonate any server to the legitimate 615 principal. 617 * "Password guessing" attacks are not solved by Kerberos. If a user 618 chooses a poor password, it is possible for an attacker to 619 successfully mount an offline dictionary attack by repeatedly 620 attempting to decrypt, with successive entries from a dictionary, 621 messages obtained which are encrypted under a key derived from the 622 user's password. 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 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 656 process when communicating from one realm to another. 658 Authenticator 659 A record containing information that can be shown to have been 660 recently generated using the session key known only by the client 661 and server. 663 Authorization 664 The process of determining whether a client may use a service, 665 which objects the client is allowed to access, and the type of 666 access allowed for each. 668 Capability 669 A token that grants the bearer permission to access an object or 670 service. In Kerberos, this might be a ticket whose use is 671 restricted by the contents of the authorization data field, but 672 which lists no network addresses, together with the session key 673 necessary to use the ticket. 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 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 706 sometimes referred to as the Authentication Server (or service). 707 The ticket-granting ticket portion is sometimes referred to as the 708 ticket-granting server (or service). 710 Kerberos 711 The name given to the Project Athena's authentication service, the 712 protocol used by that service, or the code used to implement the 713 authentication service. The name is adopted from the three-headed 714 dog which guards Hades. 716 Key Version Number (kvno) 717 A tag associated with encrypted data identifies which key was used 718 for encryption when a long lived key associated with a principal 719 changes over time. It is used during the transition to a new key 720 so that the party decrypting a message can tell whether the data 721 was encrypted using the old or the new key. 723 Plaintext 724 The input to an encryption function or the output of a decryption 725 function. Decryption transforms ciphertext into plaintext. 727 Principal 728 A named client or server entity that participates in a network 729 communication, with one name that is considered canonical. 731 Principal identifier 732 The canonical name used to uniquely identify each different 733 principal. 735 Seal 736 To encipher a record containing several fields in such a way that 737 the fields cannot be individually replaced without either 738 knowledge of the encryption key or leaving evidence of tampering. 740 Secret key 741 An encryption key shared by a principal and the KDC, distributed 742 outside the bounds of the system, with a long lifetime. In the 743 case of a human user's principal, the secret key MAY be derived 744 from a password. 746 Server 747 A particular Principal which provides a resource to network 748 clients. The server is sometimes referred to as the Application 749 Server. 751 Service 752 A resource provided to network clients; often provided by more 753 than one server (for example, remote file service). 755 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 757 Session key 758 A temporary encryption key used between two principals, with a 759 lifetime limited to the duration of a single login "session". In 760 the Kerberos system, a session key is generated by the KDC. The 761 session key is distinct from the sub-session key, described next.. 763 Sub-session key 764 A temporary encryption key used between two principals, selected 765 and exchanged by the principals using the session key, and with a 766 lifetime limited to the duration of a single association. The sub- 767 session key is also referred to as the subkey. 769 Ticket 770 A record that helps a client authenticate itself to a server; it 771 contains the client's identity, a session key, a timestamp, and 772 other information, all sealed using the server's secret key. It 773 only serves to authenticate a client when presented along with a 774 fresh Authenticator. 776 2. Ticket flag uses and requests 778 Each Kerberos ticket contains a set of flags which are used to 779 indicate attributes of that ticket. Most flags may be requested by a 780 client when the ticket is obtained; some are automatically turned on 781 and off by a Kerberos server as required. The following sections 782 explain what the various flags mean and give examples of reasons to 783 use them. With the exception of the INVALID flag clients MUST ignore 784 ticket flags that are not recognized. KDCs MUST ignore KDC options 785 that are not recognized. Some implementations of RFC 1510 are known 786 to reject unknown KDC options, so clients may need to resend a 787 request without new KDC options if the request was rejected when sent 788 with options added since RFC 1510. Since new KDCs will ignore unknown 789 options, clients MUST confirm that the ticket returned by the KDC 790 meets their needs. 792 Note that it is not, in general, possible to determine whether an 793 option was not honored because it was not understood or because it 794 was rejected either through configuration or policy. When adding a 795 new option to the Kerberos protocol, designers should consider 796 whether the distinction is important for their option. In cases where 797 it is, a mechanism for the KDC to return an indication that the 798 option was understood but rejected needs to be provided in the 799 specification of the option. Often in such cases, the mechanism needs 800 to be broad enough to permit an error or reason to be returned. 802 2.1. Initial, pre-authenticated, and hardware authenticated tickets 803 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 805 The INITIAL flag indicates that a ticket was issued using the AS 806 protocol, rather than issued based on a ticket-granting ticket. 807 Application servers that want to require the demonstrated knowledge 808 of a client's secret key (e.g. a password-changing program) can 809 insist that this flag be set in any tickets they accept, and thus be 810 assured that the client's key was recently presented to the 811 application client. 813 The PRE-AUTHENT and HW-AUTHENT flags provide additional information 814 about the initial authentication, regardless of whether the current 815 ticket was issued directly (in which case INITIAL will also be set) 816 or issued on the basis of a ticket-granting ticket (in which case the 817 INITIAL flag is clear, but the PRE-AUTHENT and HW-AUTHENT flags are 818 carried forward from the ticket-granting ticket). 820 2.2. Invalid tickets 822 The INVALID flag indicates that a ticket is invalid. Application 823 servers MUST reject tickets which have this flag set. A postdated 824 ticket will be issued in this form. Invalid tickets MUST be validated 825 by the KDC before use, by presenting them to the KDC in a TGS request 826 with the VALIDATE option specified. The KDC will only validate 827 tickets after their starttime has passed. The validation is required 828 so that postdated tickets which have been stolen before their 829 starttime can be rendered permanently invalid (through a hot-list 830 mechanism) (see section 3.3.3.1). 832 2.3. Renewable tickets 834 Applications may desire to hold tickets which can be valid for long 835 periods of time. However, this can expose their credentials to 836 potential theft for equally long periods, and those stolen 837 credentials would be valid until the expiration time of the 838 ticket(s). Simply using short-lived tickets and obtaining new ones 839 periodically would require the client to have long-term access to its 840 secret key, an even greater risk. Renewable tickets can be used to 841 mitigate the consequences of theft. Renewable tickets have two 842 "expiration times": the first is when the current instance of the 843 ticket expires, and the second is the latest permissible value for an 844 individual expiration time. An application client must periodically 845 (i.e. before it expires) present a renewable ticket to the KDC, with 846 the RENEW option set in the KDC request. The KDC will issue a new 847 ticket with a new session key and a later expiration time. All other 848 fields of the ticket are left unmodified by the renewal process. When 849 the latest permissible expiration time arrives, the ticket expires 850 permanently. At each renewal, the KDC MAY consult a hot-list to 851 determine if the ticket had been reported stolen since its last 852 renewal; it will refuse to renew such stolen tickets, and thus the 853 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 855 usable lifetime of stolen tickets is reduced. 857 The RENEWABLE flag in a ticket is normally only interpreted by the 858 ticket-granting service (discussed below in section 3.3). It can 859 usually be ignored by application servers. However, some particularly 860 careful application servers MAY disallow renewable tickets. 862 If a renewable ticket is not renewed by its expiration time, the KDC 863 will not renew the ticket. The RENEWABLE flag is reset by default, 864 but a client MAY request it be set by setting the RENEWABLE option in 865 the KRB_AS_REQ message. If it is set, then the renew-till field in 866 the ticket contains the time after which the ticket may not be 867 renewed. 869 2.4. Postdated tickets 871 Applications may occasionally need to obtain tickets for use much 872 later, e.g. a batch submission system would need tickets to be valid 873 at the time the batch job is serviced. However, it is dangerous to 874 hold valid tickets in a batch queue, since they will be on-line 875 longer and more prone to theft. Postdated tickets provide a way to 876 obtain these tickets from the KDC at job submission time, but to 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 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 905 application client MUST present the ticket to the KDC to be validated 906 before use. 908 2.5. Proxiable and proxy tickets 910 At times it may be necessary for a principal to allow a service to 911 perform an operation on its behalf. The service must be able to take 912 on the identity of the client, but only for a particular purpose. A 913 principal can allow a service to take on the principal's identity for 914 a particular purpose by granting it a proxy. 916 The process of granting a proxy using the proxy and proxiable flags 917 is used to provide credentials for use with specific services. Though 918 conceptually also a proxy, users wishing to delegate their identity 919 in a form usable for all purpose MUST use the ticket forwarding 920 mechanism described in the next section to forward a ticket-granting 921 ticket. 923 The PROXIABLE flag in a ticket is normally only interpreted by the 924 ticket-granting service. It can be ignored by application servers. 925 When set, this flag tells the ticket-granting server that it is OK to 926 issue a new ticket (but not a ticket-granting ticket) with a 927 different network address based on this ticket. This flag is set if 928 requested by the client on initial authentication. By default, the 929 client will request that it be set when requesting a ticket-granting 930 ticket, and reset when requesting any other ticket. 932 This flag allows a client to pass a proxy to a server to perform a 933 remote request on its behalf (e.g. a print service client can give 934 the print server a proxy to access the client's files on a particular 935 file server in order to satisfy a print request). 937 In order to complicate the use of stolen credentials, Kerberos 938 tickets are often valid from only those network addresses 939 specifically included in the ticket, but it is permissible as a 940 policy option to allow requests and issue tickets with no network 941 addresses specified. When granting a proxy, the client MUST specify 942 the new network address from which the proxy is to be used, or 943 indicate that the proxy is to be issued for use from 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 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 955 that is granted is complete use of the client's identity. An example 956 where it might be used is when a user logs in to a remote system and 957 wants authentication to work from that system as if the login were 958 local. 960 The FORWARDABLE flag in a ticket is normally only interpreted by the 961 ticket-granting service. It can be ignored by application servers. 962 The FORWARDABLE flag has an interpretation similar to that of the 963 PROXIABLE flag, except ticket-granting tickets may also be issued 964 with different network addresses. This flag is reset by default, but 965 users MAY request that it be set by setting the FORWARDABLE option in 966 the AS request when they request their initial ticket-granting 967 ticket. 969 This flag allows for authentication forwarding without requiring the 970 user to enter a password again. If the flag is not set, then 971 authentication forwarding is not permitted, but the same result can 972 still be achieved if the user engages in the AS exchange specifying 973 the requested network addresses and supplies a password. 975 The FORWARDED flag is set by the TGS when a client presents a ticket 976 with the FORWARDABLE flag set and requests a forwarded ticket by 977 specifying the FORWARDED KDC option and supplying a set of addresses 978 for the new ticket. It is also set in all tickets issued based on 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 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 1005 for cross-realm authentication. When the KDC applies such checks and 1006 accepts such cross-realm authentication it will set the TRANSITED- 1007 POLICY-CHECKED flag in the service tickets it issues based on the 1008 cross-realm TGT. A client MAY request that the KDCs not check the 1009 transited field by setting the DISABLE-TRANSITED-CHECK flag. KDCs are 1010 encouraged but not required to honor this flag. 1012 Application servers MUST either do the transited-realm checks 1013 themselves, or reject cross-realm tickets without TRANSITED-POLICY- 1014 CHECKED set. 1016 2.8. OK as Delegate 1018 For some applications a client may need to delegate authority to a 1019 server to act on its behalf in contacting other services. This 1020 requires that the client forward credentials to an intermediate 1021 server. The ability for a client to obtain a service ticket to a 1022 server conveys no information to the client about whether the server 1023 should be trusted to accept delegated credentials. The OK-AS- 1024 DELEGATE provides a way for a KDC to communicate local realm policy 1025 to a client regarding whether an intermediate server is trusted to 1026 accept such credentials. 1028 The copy of the ticket flags in the encrypted part of the KDC reply 1029 may have the OK-AS-DELEGATE flag set to indicates to the client that 1030 the server specified in the ticket has been determined by policy of 1031 the realm to be a suitable recipient of delegation. A client can use 1032 the presence of this flag to help it make a decision whether to 1033 delegate credentials (either grant a proxy or a forwarded ticket- 1034 granting ticket) to this server. It is acceptable to ignore the 1035 value of this flag. When setting this flag, an administrator should 1036 consider the security and placement of the server on which the 1037 service will run, as well as whether the service requires the use of 1038 delegated credentials. 1040 2.9. Other KDC options 1042 There are three additional options which MAY be set in a client's 1043 request of the KDC. 1045 2.9.1. Renewable-OK 1047 The RENEWABLE-OK option indicates that the client will accept a 1048 renewable ticket if a ticket with the requested life cannot otherwise 1049 be provided. If a ticket with the requested life cannot be provided, 1050 then the KDC MAY issue a renewable ticket with a renew-till equal to 1051 the requested endtime. The value of the renew-till field MAY still be 1052 adjusted by site-determined limits or limits imposed by the 1053 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 1055 individual principal or server. 1057 2.9.2. ENC-TKT-IN-SKEY 1059 In its basic form the Kerberos protocol supports authentication in a 1060 client-server 1061 setting and is not well suited to authentication in a peer-to-peer 1062 environment because the long term key of the user does not remain on 1063 the workstation after initial login. Authentication of such peers may 1064 be supported by Kerberos in its user-to-user variant. The ENC-TKT-IN- 1065 SKEY option supports user-to-user authentication by allowing the KDC 1066 to issue a service ticket encrypted using the session key from 1067 another ticket-granting ticket issued to another user. The ENC-TKT- 1068 IN-SKEY option is honored only by the ticket-granting service. It 1069 indicates that the ticket to be issued for the end server is to be 1070 encrypted in the session key from the additional second ticket- 1071 granting ticket provided with the request. See section 3.3.3 for 1072 specific details. 1074 2.9.3. Passwordless Hardware Authentication 1076 The OPT-HARDWARE-AUTH option indicates that the client wishes to use 1077 some form of hardware authentication instead of or in addition to the 1078 client's password or other long-lived encryption key. OPT-HARDWARE- 1079 AUTH is honored only by the authentication service. If supported and 1080 allowed by policy, the KDC will return an errorcode 1081 KDC_ERR_PREAUTH_REQUIRED and include the required METHOD-DATA to 1082 perform such authentication. 1084 3. Message Exchanges 1086 The following sections describe the interactions between network 1087 clients and servers and the messages involved in those exchanges. 1089 3.1. The Authentication Service Exchange 1091 Summary 1093 Message direction Message type Section 1094 1. Client to Kerberos KRB_AS_REQ 5.4.1 1095 2. Kerberos to client KRB_AS_REP or 5.4.2 1096 KRB_ERROR 5.9.1 1098 the Kerberos Authentication Server is initiated by a client when it 1099 wishes to obtain authentication credentials for a given server but 1100 currently holds no credentials. In its basic form, the client's 1101 secret key is used for encryption and decryption. This exchange is 1102 typically used at the initiation of a login session to obtain 1103 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 1105 credentials for a Ticket-Granting Server which will subsequently be 1106 used to obtain credentials for other servers (see section 3.3) 1107 without requiring further use of the client's secret key. This 1108 exchange is also used to request credentials for services which must 1109 not be mediated through the Ticket-Granting Service, but rather 1110 require a principal's secret key, such as the password-changing 1111 service for which the request must not be honored unless the 1112 requester can provide the users old password (preventing someone from 1113 walking up to an unattended session and changing another user's 1114 password). 1116 This exchange does not by itself provide any assurance of the 1117 identity of the user. To authenticate a user logging on to a local 1118 system, the credentials obtained in the AS exchange may first be used 1119 in a TGS exchange to obtain credentials for a local server. Those 1120 credentials must then be verified by a local server through 1121 successful completion of the Client/Server exchange. 1123 The AS exchange consists of two messages: KRB_AS_REQ from the client 1124 to Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for 1125 these messages are described in sections 5.4.1, 5.4.2, and 5.9.1. 1127 In the request, the client sends (in cleartext) its own identity and 1128 the identity of the server for which it is requesting credentials, 1129 other information about the credentials it is requesting, and a 1130 randomly generated nonce which can be used to detect replays, and to 1131 associate replies with the matching requests. This nonce MUST be 1132 generated randomly by the client and remembered for checking against 1133 the nonce in the expected reply. The response, KRB_AS_REP, contains a 1134 ticket for the client to present to the server, and a session key 1135 that will be shared by the client and the server. The session key 1136 and additional information are encrypted in the client's secret key. 1137 The encrypted part of the KRB_AS_REP message also contains the nonce 1138 which MUST be matched with the nonce from the KRB_AS_REQ message. 1140 Without pre-authentication, the authentication server does not know 1141 whether the client is actually the principal named in the request. It 1142 simply sends a reply without knowing or caring whether they are the 1143 same. This is acceptable because nobody but the principal whose 1144 identity was given in the request will be able to use the reply. Its 1145 critical information is encrypted in that principal's key. However, 1146 an attacker can send a KRB_AS_REQ message to get known plaintext in 1147 order to attack the principal's key. Especially if the key is based 1148 on a password, this may create a security exposure. So, the initial 1149 request supports an optional field that can be used to pass 1150 additional information that might be needed for the initial exchange. 1151 This field SHOULD be used for pre-authentication as described in 1152 sections 3.1.1 and 5.2.7. 1154 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 1156 Various errors can occur; these are indicated by an error response 1157 (KRB_ERROR) instead of the KRB_AS_REP response. The error message is 1158 not encrypted. The KRB_ERROR message contains information which can 1159 be used to associate it with the message to which it replies. The 1160 contents of the KRB_ERROR message are not integrity-protected. As 1161 such, the client cannot detect replays, fabrications or 1162 modifications. A solution to this problem will be included in a 1163 future version of the protocol. 1165 3.1.1. Generation of KRB_AS_REQ message 1167 The client may specify a number of options in the initial request. 1168 Among these options are whether pre-authentication is to be 1169 performed; whether the requested ticket is to be renewable, 1170 proxiable, or forwardable; whether it should be postdated or allow 1171 postdating of derivative tickets; and whether a renewable ticket will 1172 be accepted in lieu of a non-renewable ticket if the requested ticket 1173 expiration date cannot be satisfied by a non-renewable ticket (due to 1174 configuration constraints). 1176 The client prepares the KRB_AS_REQ message and sends it to the KDC. 1178 3.1.2. Receipt of KRB_AS_REQ message 1180 If all goes well, processing the KRB_AS_REQ message will result in 1181 the creation of a ticket for the client to present to the server. The 1182 format for the ticket is described in section 5.3. 1184 Because Kerberos can run over unreliable transports such as UDP, the 1185 KDC MUST be prepared to retransmit responses in case they are lost. 1186 If a KDC receives a request identical to one it has recently 1187 successfully processed, the KDC MUST respond with a KRB_AS_REP 1188 message rather than a replay error. In order to reduce ciphertext 1189 given to a potential attacker, KDCs MAY send the same response 1190 generated when the request was first handled. KDCs MUST obey this 1191 replay behavior even if the actual transport in use is reliable. 1193 3.1.3. Generation of KRB_AS_REP message 1195 The authentication server looks up the client and server principals 1196 named in the KRB_AS_REQ in its database, extracting their respective 1197 keys. If the requested client principal named in the request is not 1198 known because it doesn't exist in the KDC's principal database, then 1199 an error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is returned. 1201 If required, the server pre-authenticates the request, and if the 1202 pre-authentication check fails, an error message with the code 1203 KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is 1204 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 1206 required, but was not present in the request, an error message with 1207 the code KDC_ERR_PREAUTH_REQUIRED is returned and a METHOD-DATA 1208 object will be stored in the e-data field of the KRB-ERROR message to 1209 specify which pre-authentication mechanisms are acceptable. Usually 1210 this will include PA-ETYPE-INFO and/or PA-ETYPE-INFO2 elements as 1211 described below. If the server cannot accommodate any encryption type 1212 requested by the client, an error message with code 1213 KDC_ERR_ETYPE_NOSUPP is returned. Otherwise the KDC generates a 1214 'random' session key, meaning that, among other things, it should be 1215 impossible to guess the next session key based on knowledge of past 1216 session keys. This can only be achieved in a pseudo-random number 1217 generator if it is based on cryptographic principles. It is more 1218 desirable to use a truly random number generator, such as one based 1219 on measurements of random physical phenomena. See [RFC1750] for an 1220 in depth discussion of randomness. 1222 When responding to an AS request, if there are multiple encryption 1223 keys registered for a client in the Kerberos database, then the etype 1224 field from the AS request is used by the KDC to select the encryption 1225 method to be used to protect the encrypted part of the KRB_AS_REP 1226 message which is sent to the client. If there is more than one 1227 supported strong encryption type in the etype list, the KDC SHOULD 1228 use the first valid strong etype for which an encryption key is 1229 available. 1231 When the user's key is generated from a password or pass phrase, the 1232 string-to-key function for the particular encryption key type is 1233 used, as specified in [@KCRYPTO]. The salt value and additional 1234 parameters for the string-to-key function have default values 1235 (specified by section 4 and by the encryption mechanism 1236 specification, respectively) that may be overridden by pre- 1237 authentication data (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA- 1238 ETYPE-INFO2, etc). Since the KDC is presumed to store a copy of the 1239 resulting key only, these values should not be changed for password- 1240 based keys except when changing the principal's key. 1242 When the AS server is to include pre-authentication data in a KRB- 1243 ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE-INFO, 1244 if the etype field of the client's AS-REQ lists at least one "newer" 1245 encryption type. Otherwise (when the etype field of the client's AS- 1246 REQ does not list any "newer" encryption types) it MUST send both, 1247 PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an entry for each 1248 enctype). A "newer" enctype is any enctype first officially 1249 specified concurrently with or subsequent to the issue of this RFC. 1250 The enctypes DES, 3DES or RC4 and any defined in [RFC1510] are not 1251 "newer" enctypes. 1253 It is not possible to reliably generate a user's key given a pass 1254 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 1256 phrase without contacting the KDC, since it will not be known whether 1257 alternate salt or parameter values are required. 1259 The KDC will attempt to assign the type of the random session key 1260 from the list of methods in the etype field. The KDC will select the 1261 appropriate type using the list of methods provided together with 1262 information from the Kerberos database indicating acceptable 1263 encryption methods for the application server. The KDC will not issue 1264 tickets with a weak session key encryption type. 1266 If the requested start time is absent, indicates a time in the past, 1267 or is within the window of acceptable clock skew for the KDC and the 1268 POSTDATE option has not been specified, then the start time of the 1269 ticket is set to the authentication server's current time. If it 1270 indicates a time in the future beyond the acceptable clock skew, but 1271 the POSTDATED option has not been specified then the error 1272 KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the requested start 1273 time is checked against the policy of the local realm (the 1274 administrator might decide to prohibit certain types or ranges of 1275 postdated tickets), and if acceptable, the ticket's start time is set 1276 as requested and the INVALID flag is set in the new ticket. The 1277 postdated ticket MUST be validated before use by presenting it to the 1278 KDC after the start time has been reached. 1280 The expiration time of the ticket will be set to the earlier of the 1281 requested endtime and a time determined by local policy, possibly 1282 determined using realm or principal specific factors. For example, 1283 the expiration time MAY be set to the earliest of the following: 1285 * The expiration time (endtime) requested in the KRB_AS_REQ 1286 message. 1288 * The ticket's start time plus the maximum allowable lifetime 1289 associated with the client principal from the authentication 1290 server's database. 1292 * The ticket's start time plus the maximum allowable lifetime 1293 associated with the server principal. 1295 * The ticket's start time plus the maximum lifetime set by the 1296 policy of the local realm. 1298 If the requested expiration time minus the start time (as determined 1299 above) is less than a site-determined minimum lifetime, an error 1300 message with code KDC_ERR_NEVER_VALID is returned. If the requested 1301 expiration time for the ticket exceeds what was determined as above, 1302 and if the 'RENEWABLE-OK' option was requested, then the 'RENEWABLE' 1303 flag is set in the new ticket, and the renew-till value is set as if 1304 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 1306 the 'RENEWABLE' option were requested (the field and option names are 1307 described fully in section 5.4.1). 1309 If the RENEWABLE option has been requested or if the RENEWABLE-OK 1310 option has been set and a renewable ticket is to be issued, then the 1311 renew-till field MAY be set to the earliest of: 1313 * Its requested value. 1315 * The start time of the ticket plus the minimum of the two 1316 maximum renewable lifetimes associated with the principals' 1317 database entries. 1319 * The start time of the ticket plus the maximum renewable 1320 lifetime set by the policy of the local realm. 1322 The flags field of the new ticket will have the following options set 1323 if they have been requested and if the policy of the local realm 1324 allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. 1325 If the new ticket is postdated (the start time is in the future), its 1326 INVALID flag will also be set. 1328 If all of the above succeed, the server will encrypt the ciphertext 1329 part of the ticket using the encryption key extracted from the server 1330 principal's record in the Kerberos database using the encryption type 1331 associated with the server principal's key (this choice is NOT 1332 affected by the etype field in the request). It then formats a 1333 KRB_AS_REP message (see section 5.4.2), copying the addresses in the 1334 request into the caddr of the response, placing any required pre- 1335 authentication data into the padata of the response, and encrypts the 1336 ciphertext part in the client's key using an acceptable encryption 1337 method requested in the etype field of the request, or in some key 1338 specified by pre-authentication mechanisms being used. 1340 3.1.4. Generation of KRB_ERROR message 1342 Several errors can occur, and the Authentication Server responds by 1343 returning an error message, KRB_ERROR, to the client, with the error- 1344 code and e-text fields set to appropriate values. The error message 1345 contents and details are described in Section 5.9.1. 1347 3.1.5. Receipt of KRB_AS_REP message 1349 If the reply message type is KRB_AS_REP, then the client verifies 1350 that the cname and crealm fields in the cleartext portion of the 1351 reply match what it requested. If any padata fields are present, they 1352 may be used to derive the proper secret key to decrypt the message. 1353 The client decrypts the encrypted part of the response using its 1354 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 1356 secret key, verifies that the nonce in the encrypted part matches the 1357 nonce it supplied in its request (to detect replays). It also 1358 verifies that the sname and srealm in the response match those in the 1359 request (or are otherwise expected values), and that the host address 1360 field is also correct. It then stores the ticket, session key, start 1361 and expiration times, and other information for later use. The last- 1362 req field (and the deprecated key-expiration field) from the 1363 encrypted part of the response MAY be checked to notify the user of 1364 impending key expiration. This enables the client program to suggest 1365 remedial action, such as a password change. 1367 Upon validation of the KRB_AS_REP message (by checking the returned 1368 nonce against that sent in the KRB_AS_REQ message) the client knows 1369 that the current time on the KDC is that read from the authtime field 1370 of the encrypted part of the reply. The client can optionally use 1371 this value for clock synchronization in subsequent messages by 1372 recording with the ticket the difference (offset) between the 1373 authtime value and the local clock. This offset can then be used by 1374 the same user to adjust the time read from the system clock when 1375 generating messages [DGT96]. 1377 This technique MUST be used when adjusting for clock skew instead of 1378 directly changing the system clock because the KDC reply is only 1379 authenticated to the user whose secret key was used, but not to the 1380 system or workstation. If the clock were adjusted, an attacker 1381 colluding with a user logging into a workstation could agree on a 1382 password, resulting in a KDC reply that would be correctly validated 1383 even though it did not originate from a KDC trusted by the 1384 workstation. 1386 Proper decryption of the KRB_AS_REP message is not sufficient for the 1387 host to verify the identity of the user; the user and an attacker 1388 could cooperate to generate a KRB_AS_REP format message which 1389 decrypts properly but is not from the proper KDC. If the host wishes 1390 to verify the identity of the user, it MUST require the user to 1391 present application credentials which can be verified using a 1392 securely-stored secret key for the host. If those credentials can be 1393 verified, then the identity of the user can be assured. 1395 3.1.6. Receipt of KRB_ERROR message 1397 If the reply message type is KRB_ERROR, then the client interprets it 1398 as an error and performs whatever application-specific tasks are 1399 necessary to recover. 1401 3.2. The Client/Server Authentication Exchange 1403 Summary 1404 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 1406 Message direction Message type Section 1407 Client to Application server KRB_AP_REQ 5.5.1 1408 [optional] Application server to client KRB_AP_REP or 5.5.2 1409 KRB_ERROR 5.9.1 1411 The client/server authentication (CS) exchange is used by network 1412 applications to authenticate the client to the server and vice versa. 1413 The client MUST have already acquired credentials for the server 1414 using the AS or TGS exchange. 1416 3.2.1. The KRB_AP_REQ message 1418 The KRB_AP_REQ contains authentication information which SHOULD be 1419 part of the first message in an authenticated transaction. It 1420 contains a ticket, an authenticator, and some additional bookkeeping 1421 information (see section 5.5.1 for the exact format). The ticket by 1422 itself is insufficient to authenticate a client, since tickets are 1423 passed across the network in cleartext (tickets contain both an 1424 encrypted and unencrypted portion, so cleartext here refers to the 1425 entire unit, which can be copied from one message and replayed in 1426 another without any cryptographic skill), so the authenticator is 1427 used to prevent invalid replay of tickets by proving to the server 1428 that the client knows the session key of the ticket and thus is 1429 entitled to use the ticket. The KRB_AP_REQ message is referred to 1430 elsewhere as the 'authentication header.' 1432 3.2.2. Generation of a KRB_AP_REQ message 1434 When a client wishes to initiate authentication to a server, it 1435 obtains (either through a credentials cache, the AS exchange, or the 1436 TGS exchange) a ticket and session key for the desired service. The 1437 client MAY re-use any tickets it holds until they expire. To use a 1438 ticket the client constructs a new Authenticator from the system 1439 time, its name, and optionally an application specific checksum, an 1440 initial sequence number to be used in KRB_SAFE or KRB_PRIV messages, 1441 and/or a session subkey to be used in negotiations for a session key 1442 unique to this particular session. Authenticators MUST NOT be re- 1443 used and SHOULD be rejected if replayed to a server. Note that this 1444 can make applications based on unreliable transports difficult to 1445 code correctly. If the transport might deliver duplicated messages, 1446 either a new authenticator must be generated for each retry, or the 1447 application server must match requests and replies and replay the 1448 first reply in response to a detected duplicate. 1450 If a sequence number is to be included, it SHOULD be randomly chosen 1451 so that even after many messages have been exchanged it is not likely 1452 to collide with other sequence numbers in use. 1454 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 1456 The client MAY indicate a requirement of mutual authentication or the 1457 use of a session-key based ticket (for user-to-user authentication - 1458 see section 3.7) by setting the appropriate flag(s) in the ap-options 1459 field of the message. 1461 The Authenticator is encrypted in the session key and combined with 1462 the ticket to form the KRB_AP_REQ message which is then sent to the 1463 end server along with any additional application-specific 1464 information. 1466 3.2.3. Receipt of KRB_AP_REQ message 1468 Authentication is based on the server's current time of day (clocks 1469 MUST be loosely synchronized), the authenticator, and the ticket. 1470 Several errors are possible. If an error occurs, the server is 1471 expected to reply to the client with a KRB_ERROR message. This 1472 message MAY be encapsulated in the application protocol if its raw 1473 form is not acceptable to the protocol. The format of error messages 1474 is described in section 5.9.1. 1476 The algorithm for verifying authentication information is as follows. 1477 If the message type is not KRB_AP_REQ, the server returns the 1478 KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the Ticket 1479 in the KRB_AP_REQ is not one the server can use (e.g., it indicates 1480 an old key, and the server no longer possesses a copy of the old 1481 key), the KRB_AP_ERR_BADKEYVER error is returned. If the USE-SESSION- 1482 KEY flag is set in the ap-options field, it indicates to the server 1483 that user-to-user authentication is in use, and that the ticket is 1484 encrypted in the session key from the server's ticket-granting ticket 1485 rather than in the server's secret key. See section 3.7 for a more 1486 complete description of the effect of user-to-user authentication on 1487 all messages in the Kerberos protocol. 1489 Since it is possible for the server to be registered in multiple 1490 realms, with different keys in each, the srealm field in the 1491 unencrypted portion of the ticket in the KRB_AP_REQ is used to 1492 specify which secret key the server should use to decrypt that 1493 ticket. The KRB_AP_ERR_NOKEY error code is returned if the server 1494 doesn't have the proper key to decipher the ticket. 1496 The ticket is decrypted using the version of the server's key 1497 specified by the ticket. If the decryption routines detect a 1498 modification of the ticket (each encryption system MUST provide 1499 safeguards to detect modified ciphertext), the 1500 KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that 1501 different keys were used to encrypt and decrypt). 1503 The authenticator is decrypted using the session key extracted from 1504 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 1506 the decrypted ticket. If decryption shows it to have been modified, 1507 the KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of 1508 the client from the ticket are compared against the same fields in 1509 the authenticator. If they don't match, the KRB_AP_ERR_BADMATCH 1510 error is returned; this normally is caused by a client error or 1511 attempted attack. The addresses in the ticket (if any) are then 1512 searched for an address matching the operating-system reported 1513 address of the client. If no match is found or the server insists on 1514 ticket addresses but none are present in the ticket, the 1515 KRB_AP_ERR_BADADDR error is returned. If the local (server) time and 1516 the client time in the authenticator differ by more than the 1517 allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW error is 1518 returned. 1520 Unless the application server provides its own suitable means to 1521 protect against replay (for example, a challenge-response sequence 1522 initiated by the server after authentication, or use of a server- 1523 generated encryption subkey), the server MUST utilize a replay cache 1524 to remember any authenticator presented within the allowable clock 1525 skew. Careful analysis of the application protocol and implementation 1526 is recommended before eliminating this cache. The replay cache will 1527 store at least the server name, along with the client name, time and 1528 microsecond fields from the recently-seen authenticators and if a 1529 matching tuple is found, the KRB_AP_ERR_REPEAT error is returned. 1530 Note that the rejection here is restricted to authenticators from the 1531 same principal to the same server. Other client principals 1532 communicating with the same server principal should not have their 1533 authenticators rejected if the time and microsecond fields happen to 1534 match some other client's authenticator. 1536 If a server loses track of authenticators presented within the 1537 allowable clock skew, it MUST reject all requests until the clock 1538 skew interval has passed, providing assurance that any lost or 1539 replayed authenticators will fall outside the allowable clock skew 1540 and can no longer be successfully replayed. If this were not done, 1541 an attacker could subvert the authentication by recording the ticket 1542 and authenticator sent over the network to a server and replaying 1543 them following an event that caused the server to lose track of 1544 recently seen authenticators. 1546 Implementation note: If a client generates multiple requests to the 1547 KDC with the same timestamp, including the microsecond field, all but 1548 the first of the requests received will be rejected as replays. This 1549 might happen, for example, if the resolution of the client's clock is 1550 too coarse. Client implementations SHOULD ensure that the timestamps 1551 are not reused, possibly by incrementing the microseconds field in 1552 the time stamp when the clock returns the same time for multiple 1553 requests. 1555 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 1557 If multiple servers (for example, different services on one machine, 1558 or a single service implemented on multiple machines) share a service 1559 principal (a practice we do not recommend in general, but acknowledge 1560 will be used in some cases), they MUST either share this replay 1561 cache, or the application protocol MUST be designed so as to 1562 eliminate the need for it. Note that this applies to all of the 1563 services, if any of the application protocols does not have replay 1564 protection built in; an authenticator used with such a service could 1565 later be replayed to a different service with the same service 1566 principal but no replay protection, if the former doesn't record the 1567 authenticator information in the common replay cache. 1569 If a sequence number is provided in the authenticator, the server 1570 saves it for later use in processing KRB_SAFE and/or KRB_PRIV 1571 messages. If a subkey is present, the server either saves it for 1572 later use or uses it to help generate its own choice for a subkey to 1573 be returned in a KRB_AP_REP message. 1575 The server computes the age of the ticket: local (server) time minus 1576 the start time inside the Ticket. If the start time is later than the 1577 current time by more than the allowable clock skew or if the INVALID 1578 flag is set in the ticket, the KRB_AP_ERR_TKT_NYV error is returned. 1579 Otherwise, if the current time is later than end time by more than 1580 the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error is 1581 returned. 1583 If all these checks succeed without an error, the server is assured 1584 that the client possesses the credentials of the principal named in 1585 the ticket and thus, the client has been authenticated to the server. 1587 Passing these checks provides only authentication of the named 1588 principal; it does not imply authorization to use the named service. 1589 Applications MUST make a separate authorization decision based upon 1590 the authenticated name of the user, the requested operation, local 1591 access control information such as that contained in a .k5login or 1592 .k5users file, and possibly a separate distributed authorization 1593 service. 1595 3.2.4. Generation of a KRB_AP_REP message 1597 Typically, a client's request will include both the authentication 1598 information and its initial request in the same message, and the 1599 server need not explicitly reply to the KRB_AP_REQ. However, if 1600 mutual authentication (not only authenticating the client to the 1601 server, but also the server to the client) is being performed, the 1602 KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options 1603 field, and a KRB_AP_REP message is required in response. As with the 1604 error message, this message MAY be encapsulated in the application 1605 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 1607 protocol if its "raw" form is not acceptable to the application's 1608 protocol. The timestamp and microsecond field used in the reply MUST 1609 be the client's timestamp and microsecond field (as provided in the 1610 authenticator). If a sequence number is to be included, it SHOULD be 1611 randomly chosen as described above for the authenticator. A subkey 1612 MAY be included if the server desires to negotiate a different 1613 subkey. The KRB_AP_REP message is encrypted in the session key 1614 extracted from the ticket. 1616 Note that in the Kerberos version 4 protocol, the timestamp in the 1617 reply was the client's timestamp plus one. This is not necessary in 1618 version 5 because version 5 messages are formatted in such a way that 1619 it is not possible to create the reply by judicious message surgery 1620 (even in encrypted form) without knowledge of the appropriate 1621 encryption keys. 1623 3.2.5. Receipt of KRB_AP_REP message 1625 If a KRB_AP_REP message is returned, the client uses the session key 1626 from the credentials obtained for the server to decrypt the message 1627 (Note that for encrypting the KRB_AP_REP message, the sub-session key 1628 is not used, even if present in the Authenticator), and verifies that 1629 the timestamp and microsecond fields match those in the Authenticator 1630 it sent to the server. If they match, then the client is assured that 1631 the server is genuine. The sequence number and subkey (if present) 1632 are retained for later use. 1634 3.2.6. Using the encryption key 1636 After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and 1637 server share an encryption key which can be used by the application. 1638 In some cases, the use of this session key will be implicit in the 1639 protocol; in others the method of use must be chosen from several 1640 alternatives. The actual encryption key to be used for KRB_PRIV, 1641 KRB_SAFE, or other application-specific uses MAY be chosen by the 1642 application based on the session key from the ticket and subkeys in 1643 the KRB_AP_REP message and the authenticator. Implementations of the 1644 protocol MAY provide routines to choose subkeys based on session keys 1645 and random numbers and to generate a negotiated key to be returned in 1646 the KRB_AP_REP message. 1648 To mitigate the effect of failures in random number generation on the 1649 client it is strongly encouraged that any key derived by an 1650 application for subsequent use include the full key entropy derived 1651 from the KDC generated session key carried in the ticket. We leave 1652 the protocol negotiations of how to use the key (e.g. selecting an 1653 encryption or checksum type) to the application programmer; the 1654 Kerberos protocol does not constrain the implementation options, but 1655 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 1657 an example of how this might be done follows. 1659 One way that an application may choose to negotiate a key to be used 1660 for subsequent integrity and privacy protection is for the client to 1661 propose a key in the subkey field of the authenticator. The server 1662 can then choose a key using the proposed key from the client as 1663 input, returning the new subkey in the subkey field of the 1664 application reply. This key could then be used for subsequent 1665 communication. 1667 With both the one-way and mutual authentication exchanges, the peers 1668 should take care not to send sensitive information to each other 1669 without proper assurances. In particular, applications that require 1670 privacy or integrity SHOULD use the KRB_AP_REP response from the 1671 server to client to assure both client and server of their peer's 1672 identity. If an application protocol requires privacy of its 1673 messages, it can use the KRB_PRIV message (section 3.5). The KRB_SAFE 1674 message (section 3.4) can be used to assure integrity. 1676 3.3. The Ticket-Granting Service (TGS) Exchange 1678 Summary 1679 Message direction Message type Section 1680 1. Client to Kerberos KRB_TGS_REQ 5.4.1 1681 2. Kerberos to client KRB_TGS_REP or 5.4.2 1682 KRB_ERROR 5.9.1 1684 The TGS exchange between a client and the Kerberos Ticket-Granting 1685 Server is initiated by a client when it wishes to obtain 1686 authentication credentials for a given server (which might be 1687 registered in a remote realm), when it wishes to renew or validate an 1688 existing ticket, or when it wishes to obtain a proxy ticket. In the 1689 first case, the client must already have acquired a ticket for the 1690 Ticket-Granting Service using the AS exchange (the ticket-granting 1691 ticket is usually obtained when a client initially authenticates to 1692 the system, such as when a user logs in). The message format for the 1693 TGS exchange is almost identical to that for the AS exchange. The 1694 primary difference is that encryption and decryption in the TGS 1695 exchange does not take place under the client's key. Instead, the 1696 session key from the ticket-granting ticket or renewable ticket, or 1697 sub-session key from an Authenticator is used. As is the case for all 1698 application servers, expired tickets are not accepted by the TGS, so 1699 once a renewable or ticket-granting ticket expires, the client must 1700 use a separate exchange to obtain valid tickets. 1702 The TGS exchange consists of two messages: A request (KRB_TGS_REQ) 1703 from the client to the Kerberos Ticket-Granting Server, and a reply 1704 (KRB_TGS_REP or KRB_ERROR). The KRB_TGS_REQ message includes 1705 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 1707 information authenticating the client plus a request for credentials. 1708 The authentication information consists of the authentication header 1709 (KRB_AP_REQ) which includes the client's previously obtained ticket- 1710 granting, renewable, or invalid ticket. In the ticket-granting 1711 ticket and proxy cases, the request MAY include one or more of: a 1712 list of network addresses, a collection of typed authorization data 1713 to be sealed in the ticket for authorization use by the application 1714 server, or additional tickets (the use of which are described later). 1715 The TGS reply (KRB_TGS_REP) contains the requested credentials, 1716 encrypted in the session key from the ticket-granting ticket or 1717 renewable ticket, or if present, in the sub-session key from the 1718 Authenticator (part of the authentication header). The KRB_ERROR 1719 message contains an error code and text explaining what went wrong. 1720 The KRB_ERROR message is not encrypted. The KRB_TGS_REP message 1721 contains information which can be used to detect replays, and to 1722 associate it with the message to which it replies. The KRB_ERROR 1723 message also contains information which can be used to associate it 1724 with the message to which it replies. The same comments about 1725 integrity protection of KRB_ERROR messages mentioned in section 3.1 1726 apply to the TGS exchange. 1728 3.3.1. Generation of KRB_TGS_REQ message 1730 Before sending a request to the ticket-granting service, the client 1731 MUST determine in which realm the application server is believed to 1732 be registered. This can be accomplished in several ways. It might be 1733 known beforehand (since the realm is part of the principal 1734 identifier), it might be stored in a nameserver, or it might be 1735 obtained from a configuration file. If the realm to be used is 1736 obtained from a nameserver, there is a danger of being spoofed if the 1737 nameservice providing the realm name is not authenticated. This 1738 might result in the use of a realm which has been compromised, and 1739 would result in an attacker's ability to compromise the 1740 authentication of the application server to the client. 1742 If the client knows the service principal name and realm and it does 1743 not already possess a ticket-granting ticket for the appropriate 1744 realm, then one must be obtained. This is first attempted by 1745 requesting a ticket-granting ticket for the destination realm from a 1746 Kerberos server for which the client possesses a ticket-granting 1747 ticket (using the KRB_TGS_REQ message recursively). The Kerberos 1748 server MAY return a TGT for the desired realm in which case one can 1749 proceed. Alternatively, the Kerberos server MAY return a TGT for a 1750 realm which is 'closer' to the desired realm (further along the 1751 standard hierarchical path between the client's realm and the 1752 requested realm server's realm). It should be noted in this case that 1753 misconfiguration of the Kerberos servers may cause loops in the 1754 resulting authentication path, which the client should be careful to 1755 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 1757 detect and avoid. 1759 If the Kerberos server returns a TGT for a 'closer' realm other than 1760 the desired realm, the client MAY use local policy configuration to 1761 verify that the authentication path used is an acceptable one. 1762 Alternatively, a client MAY choose its own authentication path, 1763 rather than relying on the Kerberos server to select one. In either 1764 case, any policy or configuration information used to choose or 1765 validate authentication paths, whether by the Kerberos server or 1766 client, MUST be obtained from a trusted source. 1768 When a client obtains a ticket-granting ticket that is 'closer' to 1769 the destination realm, the client MAY cache this ticket and reuse it 1770 in future KRB-TGS exchanges with services in the 'closer' realm. 1771 However, if the client were to obtain a ticket-granting ticket for 1772 the 'closer' realm by starting at the initial KDC rather than as part 1773 of obtaining another ticket, then a shorter path to the 'closer' 1774 realm might be used. This shorter path may be desirable because fewer 1775 intermediate KDCs would know the session key of the ticket involved. 1776 For this reason, clients SHOULD evaluate whether they trust the 1777 realms transited in obtaining the 'closer' ticket when making a 1778 decision to use the ticket in future. 1780 Once the client obtains a ticket-granting ticket for the appropriate 1781 realm, it determines which Kerberos servers serve that realm, and 1782 contacts one. The list might be obtained through a configuration file 1783 or network service or it MAY be generated from the name of the realm; 1784 as long as the secret keys exchanged by realms are kept secret, only 1785 denial of service results from using a false Kerberos server. 1787 As in the AS exchange, the client MAY specify a number of options in 1788 the KRB_TGS_REQ message. One of these options is the ENC-TKT-IN-SKEY 1789 option used for user-to-user authentication. An overview of user-to- 1790 user authentication can be found in section 3.7. When generating the 1791 KRB_TGS_REQ message, this option indicates that the client is 1792 including a ticket-granting ticket obtained from the application 1793 server in the additional tickets field of the request and that the 1794 KDC SHOULD encrypt the ticket for the application server using the 1795 session key from this additional ticket, instead of using a server 1796 key from the principal database. 1798 The client prepares the KRB_TGS_REQ message, providing an 1799 authentication header as an element of the padata field, and 1800 including the same fields as used in the KRB_AS_REQ message along 1801 with several optional fields: the enc-authorizatfion-data field for 1802 application server use and additional tickets required by some 1803 options. 1805 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 1807 In preparing the authentication header, the client can select a sub- 1808 session key under which the response from the Kerberos server will be 1809 encrypted. If the client selects a sub-session key, care must be 1810 taken to ensure the randomness of the selected sub-session key. One 1811 approach would be to generate a random number and XOR it with the 1812 session key from the ticket-granting ticket. 1814 If the sub-session key is not specified, the session key from the 1815 ticket-granting ticket will be used. If the enc-authorization-data is 1816 present, it MUST be encrypted in the sub-session key, if present, 1817 from the authenticator portion of the authentication header, or if 1818 not present, using the session key from the ticket-granting ticket. 1820 Once prepared, the message is sent to a Kerberos server for the 1821 destination realm. 1823 3.3.2. Receipt of KRB_TGS_REQ message 1825 The KRB_TGS_REQ message is processed in a manner similar to the 1826 KRB_AS_REQ message, but there are many additional checks to be 1827 performed. First, the Kerberos server MUST determine which server the 1828 accompanying ticket is for and it MUST select the appropriate key to 1829 decrypt it. For a normal KRB_TGS_REQ message, it will be for the 1830 ticket granting service, and the TGS's key will be used. If the TGT 1831 was issued by another realm, then the appropriate inter-realm key 1832 MUST be used. If the accompanying ticket is not a ticket-granting 1833 ticket for the current realm, but is for an application server in the 1834 current realm, the RENEW, VALIDATE, or PROXY options are specified in 1835 the request, and the server for which a ticket is requested is the 1836 server named in the accompanying ticket, then the KDC will decrypt 1837 the ticket in the authentication header using the key of the server 1838 for which it was issued. If no ticket can be found in the padata 1839 field, the KDC_ERR_PADATA_TYPE_NOSUPP error is returned. 1841 Once the accompanying ticket has been decrypted, the user-supplied 1842 checksum in the Authenticator MUST be verified against the contents 1843 of the request, and the message rejected if the checksums do not 1844 match (with an error code of KRB_AP_ERR_MODIFIED) or if the checksum 1845 is not collision-proof (with an error code of 1846 KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported, the 1847 KDC_ERR_SUMTYPE_NOSUPP error is returned. If the authorization-data 1848 are present, they are decrypted using the sub-session key from the 1849 Authenticator. 1851 If any of the decryptions indicate failed integrity checks, the 1852 KRB_AP_ERR_BAD_INTEGRITY error is returned. 1854 As discussed in section 3.1.2, the KDC MUST send a valid KRB_TGS_REP 1855 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 1857 message if it receives a KRB_TGS_REQ message identical to one it has 1858 recently processed. However, if the authenticator is a replay, but 1859 the rest of the request is not identical, then the KDC SHOULD return 1860 KRB_AP_ERR_REPEAT. 1862 3.3.3. Generation of KRB_TGS_REP message 1864 The KRB_TGS_REP message shares its format with the KRB_AS_REP 1865 (KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The 1866 detailed specification is in section 5.4.2. 1868 The response will include a ticket for the requested server or for a 1869 ticket granting server of an intermediate KDC to be contacted to 1870 obtain the requested ticket. The Kerberos database is queried to 1871 retrieve the record for the appropriate server (including the key 1872 with which the ticket will be encrypted). If the request is for a 1873 ticket-granting ticket for a remote realm, and if no key is shared 1874 with the requested realm, then the Kerberos server will select the 1875 realm 'closest' to the requested realm with which it does share a 1876 key, and use that realm instead. This is the only case where the 1877 response for the KDC will be for a different server than that 1878 requested by the client. 1880 By default, the address field, the client's name and realm, the list 1881 of transited realms, the time of initial authentication, the 1882 expiration time, and the authorization data of the newly-issued 1883 ticket will be copied from the ticket-granting ticket (TGT) or 1884 renewable ticket. If the transited field needs to be updated, but the 1885 transited type is not supported, the KDC_ERR_TRTYPE_NOSUPP error is 1886 returned. 1888 If the request specifies an endtime, then the endtime of the new 1889 ticket is set to the minimum of (a) that request, (b) the endtime 1890 from the TGT, and (c) the starttime of the TGT plus the minimum of 1891 the maximum life for the application server and the maximum life for 1892 the local realm (the maximum life for the requesting principal was 1893 already applied when the TGT was issued). If the new ticket is to be 1894 a renewal, then the endtime above is replaced by the minimum of (a) 1895 the value of the renew_till field of the ticket and (b) the starttime 1896 for the new ticket plus the life (endtime-starttime) of the old 1897 ticket. 1899 If the FORWARDED option has been requested, then the resulting ticket 1900 will contain the addresses specified by the client. This option will 1901 only be honored if the FORWARDABLE flag is set in the TGT. The PROXY 1902 option is similar; the resulting ticket will contain the addresses 1903 specified by the client. It will be honored only if the PROXIABLE 1904 flag in the TGT is set. The PROXY option will not be honored on 1905 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 1907 requests for additional ticket-granting tickets. 1909 If the requested start time is absent, indicates a time in the past, 1910 or is within the window of acceptable clock skew for the KDC and the 1911 POSTDATE option has not been specified, then the start time of the 1912 ticket is set to the authentication server's current time. If it 1913 indicates a time in the future beyond the acceptable clock skew, but 1914 the POSTDATED option has not been specified or the MAY-POSTDATE flag 1915 is not set in the TGT, then the error KDC_ERR_CANNOT_POSTDATE is 1916 returned. Otherwise, if the ticket-granting ticket has the MAY- 1917 POSTDATE flag set, then the resulting ticket will be postdated and 1918 the requested starttime is checked against the policy of the local 1919 realm. If acceptable, the ticket's start time is set as requested, 1920 and the INVALID flag is set. The postdated ticket MUST be validated 1921 before use by presenting it to the KDC after the starttime has been 1922 reached. However, in no case may the starttime, endtime, or renew- 1923 till time of a newly-issued postdated ticket extend beyond the renew- 1924 till time of the ticket-granting ticket. 1926 If the ENC-TKT-IN-SKEY option has been specified and an additional 1927 ticket has been included in the request, it indicates that the client 1928 is using user- to-user authentication to prove its identity to a 1929 server that does not have access to a persistent key. Section 3.7 1930 describes the affect of this option on the entire Kerberos protocol. 1931 When generating the KRB_TGS_REP message, this option in the 1932 KRB_TGS_REQ message tells the KDC to decrypt the additional ticket 1933 using the key for the server to which the additional ticket was 1934 issued and verify that it is a ticket-granting ticket. If the name of 1935 the requested server is missing from the request, the name of the 1936 client in the additional ticket will be used. Otherwise the name of 1937 the requested server will be compared to the name of the client in 1938 the additional ticket and if different, the request will be rejected. 1939 If the request succeeds, the session key from the additional ticket 1940 will be used to encrypt the new ticket that is issued instead of 1941 using the key of the server for which the new ticket will be used. 1943 If the name of the server in the ticket that is presented to the KDC 1944 as part of the authentication header is not that of the ticket- 1945 granting server itself, the server is registered in the realm of the 1946 KDC, and the RENEW option is requested, then the KDC will verify that 1947 the RENEWABLE flag is set in the ticket, that the INVALID flag is not 1948 set in the ticket, and that the renew_till time is still in the 1949 future. If the VALIDATE option is requested, the KDC will check that 1950 the starttime has passed and the INVALID flag is set. If the PROXY 1951 option is requested, then the KDC will check that the PROXIABLE flag 1952 is set in the ticket. If the tests succeed, and the ticket passes the 1953 hotlist check described in the next section, the KDC will issue the 1954 appropriate new ticket. 1956 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 1958 The ciphertext part of the response in the KRB_TGS_REP message is 1959 encrypted in the sub-session key from the Authenticator, if present, 1960 or the session key from the ticket-granting ticket. It is not 1961 encrypted using the client's secret key. Furthermore, the client's 1962 key's expiration date and the key version number fields are left out 1963 since these values are stored along with the client's database 1964 record, and that record is not needed to satisfy a request based on a 1965 ticket-granting ticket. 1967 3.3.3.1. Checking for revoked tickets 1969 Whenever a request is made to the ticket-granting server, the 1970 presented ticket(s) is(are) checked against a hot-list of tickets 1971 which have been canceled. This hot-list might be implemented by 1972 storing a range of issue timestamps for 'suspect tickets'; if a 1973 presented ticket had an authtime in that range, it would be rejected. 1974 In this way, a stolen ticket-granting ticket or renewable ticket 1975 cannot be used to gain additional tickets (renewals or otherwise) 1976 once the theft has been reported to the KDC for the realm in which 1977 the server resides. Any normal ticket obtained before it was reported 1978 stolen will still be valid (because they require no interaction with 1979 the KDC), but only until their normal expiration time. If TGT's have 1980 been issued for cross-realm authentication, use of the cross-realm 1981 TGT will not be affected unless the hot-list is propagated to the 1982 KDCs for the realms for which such cross-realm tickets were issued. 1984 3.3.3.2. Encoding the transited field 1986 If the identity of the server in the TGT that is presented to the KDC 1987 as part of the authentication header is that of the ticket-granting 1988 service, but the TGT was issued from another realm, the KDC will look 1989 up the inter-realm key shared with that realm and use that key to 1990 decrypt the ticket. If the ticket is valid, then the KDC will honor 1991 the request, subject to the constraints outlined above in the section 1992 describing the AS exchange. The realm part of the client's identity 1993 will be taken from the ticket-granting ticket. The name of the realm 1994 that issued the ticket-granting ticket, if it is not the realm of the 1995 client principal, will be added to the transited field of the ticket 1996 to be issued. This is accomplished by reading the transited field 1997 from the ticket-granting ticket (which is treated as an unordered set 1998 of realm names), adding the new realm to the set, then constructing 1999 and writing out its encoded (shorthand) form (this may involve a 2000 rearrangement of the existing encoding). 2002 Note that the ticket-granting service does not add the name of its 2003 own realm. Instead, its responsibility is to add the name of the 2004 previous realm. This prevents a malicious Kerberos server from 2005 intentionally leaving out its own name (it could, however, omit other 2006 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 2008 realms' names). 2010 The names of neither the local realm nor the principal's realm are to 2011 be included in the transited field. They appear elsewhere in the 2012 ticket and both are known to have taken part in authenticating the 2013 principal. Since the endpoints are not included, both local and 2014 single-hop inter-realm authentication result in a transited field 2015 that is empty. 2017 Because the name of each realm transited is added to this field, it 2018 might potentially be very long. To decrease the length of this field, 2019 its contents are encoded. The initially supported encoding is 2020 optimized for the normal case of inter-realm communication: a 2021 hierarchical arrangement of realms using either domain or X.500 style 2022 realm names. This encoding (called DOMAIN-X500-COMPRESS) is now 2023 described. 2025 Realm names in the transited field are separated by a ",". The ",", 2026 "\", trailing "."s, and leading spaces (" ") are special characters, 2027 and if they are part of a realm name, they MUST be quoted in the 2028 transited field by preceding them with a "\". 2030 A realm name ending with a "." is interpreted as being prepended to 2031 the previous realm. For example, we can encode traversal of EDU, 2032 MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as: 2034 "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.". 2036 Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, 2037 that they would not be included in this field, and we would have: 2039 "EDU,MIT.,WASHINGTON.EDU" 2041 A realm name beginning with a "/" is interpreted as being appended to 2042 the previous realm. For the purpose of appending, the realm 2043 preceding the first listed realm is considered to be the null realm 2044 (""). If a realm name beginning with a "/" is to stand by itself, 2045 then it SHOULD be preceded by a space (" "). For example, we can 2046 encode traversal of /COM/HP/APOLLO, /COM/HP, /COM, and /COM/DEC as: 2048 "/COM,/HP,/APOLLO, /COM/DEC". 2050 Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, 2051 they would not be included in this field, and we would have: 2053 "/COM,/HP" 2055 A null subfield preceding or following a "," indicates that all 2056 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 2058 realms between the previous realm and the next realm have been 2059 traversed. For the purpose of interpreting null subfields, the 2060 client's realm is considered to precede those in the transited field, 2061 and the server's realm is considered to follow them. Thus, "," means 2062 that all realms along the path between the client and the server have 2063 been traversed. ",EDU, /COM," means that all realms from the client's 2064 realm up to EDU (in a domain style hierarchy) have been traversed, 2065 and that everything from /COM down to the server's realm in an X.500 2066 style has also been traversed. This could occur if the EDU realm in 2067 one hierarchy shares an inter-realm key directly with the /COM realm 2068 in another hierarchy. 2070 3.3.4. Receipt of KRB_TGS_REP message 2072 When the KRB_TGS_REP is received by the client, it is processed in 2073 the same manner as the KRB_AS_REP processing described above. The 2074 primary difference is that the ciphertext part of the response must 2075 be decrypted using the sub-session key from the Authenticator, if it 2076 was specified in the request, or the session key from the ticket- 2077 granting ticket, rather than the client's secret key. The server name 2078 returned in the reply is the true principal name of the service. 2080 3.4. The KRB_SAFE Exchange 2082 The KRB_SAFE message MAY be used by clients requiring the ability to 2083 detect modifications of messages they exchange. It achieves this by 2084 including a keyed collision-proof checksum of the user data and some 2085 control information. The checksum is keyed with an encryption key 2086 (usually the last key negotiated via subkeys, or the session key if 2087 no negotiation has occurred). 2089 3.4.1. Generation of a KRB_SAFE message 2091 When an application wishes to send a KRB_SAFE message, it collects 2092 its data and the appropriate control information and computes a 2093 checksum over them. The checksum algorithm should be the keyed 2094 checksum mandated to be implemented along with the crypto system used 2095 for the sub-session or session key. The checksum is generated using 2096 the sub-session key if present or the session key. Some 2097 implementations use a different checksum algorithm for the KRB_SAFE 2098 messages but doing so in a interoperable manner is not always 2099 possible. 2101 The control information for the KRB_SAFE message includes both a 2102 timestamp and a sequence number. The designer of an application using 2103 the KRB_SAFE message MUST choose at least one of the two mechanisms. 2104 This choice SHOULD be based on the needs of the application protocol. 2106 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 2108 Sequence numbers are useful when all messages sent will be received 2109 by one's peer. Connection state is presently required to maintain the 2110 session key, so maintaining the next sequence number should not 2111 present an additional problem. 2113 If the application protocol is expected to tolerate lost messages 2114 without them being resent, the use of the timestamp is the 2115 appropriate replay detection mechanism. Using timestamps is also the 2116 appropriate mechanism for multi-cast protocols where all of one's 2117 peers share a common sub-session key, but some messages will be sent 2118 to a subset of one's peers. 2120 After computing the checksum, the client then transmits the 2121 information and checksum to the recipient in the message format 2122 specified in section 5.6.1. 2124 3.4.2. Receipt of KRB_SAFE message 2126 When an application receives a KRB_SAFE message, it verifies it as 2127 follows. If any error occurs, an error code is reported for use by 2128 the application. 2130 The message is first checked by verifying that the protocol version 2131 and type fields match the current version and KRB_SAFE, respectively. 2132 A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE 2133 error. The application verifies that the checksum used is a 2134 collision-proof keyed checksum that uses keys compatible with the 2135 sub-session or session key as appropriate (or with the application 2136 key derived from the session or sub-session keys), and if it is not, 2137 a KRB_AP_ERR_INAPP_CKSUM error is generated. The sender's address 2138 MUST be included in the control information; the recipient verifies 2139 that the operating system's report of the sender's address matches 2140 the sender's address in the message, and (if a recipient address is 2141 specified or the recipient requires an address) that one of the 2142 recipient's addresses appears as the recipient's address in the 2143 message. To work with network address translation, senders MAY use 2144 the directional address type specified in section 8.1 for the sender 2145 address and not include recipient addresses. A failed match for 2146 either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp 2147 and usec and/or the sequence number fields are checked. If timestamp 2148 and usec are expected and not present, or they are present but not 2149 current, the KRB_AP_ERR_SKEW error is generated. Timestamps are not 2150 required to be strictly ordered; they are only required to be in the 2151 skew window. If the server name, along with the client name, time 2152 and microsecond fields from the Authenticator match any recently-seen 2153 (sent or received) such tuples, the KRB_AP_ERR_REPEAT error is 2154 generated. If an incorrect sequence number is included, or a sequence 2155 number is expected but not present, the KRB_AP_ERR_BADORDER error is 2156 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 2158 generated. If neither a time-stamp and usec or a sequence number is 2159 present, a KRB_AP_ERR_MODIFIED error is generated. Finally, the 2160 checksum is computed over the data and control information, and if it 2161 doesn't match the received checksum, a KRB_AP_ERR_MODIFIED error is 2162 generated. 2164 If all the checks succeed, the application is assured that the 2165 message was generated by its peer and was not modified in transit. 2167 Implementations SHOULD accept any checksum algorithm they implement 2168 that both have adequate security and that have keys compatible with 2169 the sub-session or session key. Unkeyed or non-collision-proof 2170 checksums are not suitable for this use. 2172 3.5. The KRB_PRIV Exchange 2174 The KRB_PRIV message MAY be used by clients requiring confidentiality 2175 and the ability to detect modifications of exchanged messages. It 2176 achieves this by encrypting the messages and adding control 2177 information. 2179 3.5.1. Generation of a KRB_PRIV message 2181 When an application wishes to send a KRB_PRIV message, it collects 2182 its data and the appropriate control information (specified in 2183 section 5.7.1) and encrypts them under an encryption key (usually the 2184 last key negotiated via subkeys, or the session key if no negotiation 2185 has occurred). As part of the control information, the client MUST 2186 choose to use either a timestamp or a sequence number (or both); see 2187 the discussion in section 3.4.1 for guidelines on which to use. After 2188 the user data and control information are encrypted, the client 2189 transmits the ciphertext and some 'envelope' information to the 2190 recipient. 2192 3.5.2. Receipt of KRB_PRIV message 2194 When an application receives a KRB_PRIV message, it verifies it as 2195 follows. If any error occurs, an error code is reported for use by 2196 the application. 2198 The message is first checked by verifying that the protocol version 2199 and type fields match the current version and KRB_PRIV, respectively. 2200 A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE 2201 error. The application then decrypts the ciphertext and processes the 2202 resultant plaintext. If decryption shows the data to have been 2203 modified, a KRB_AP_ERR_BAD_INTEGRITY error is generated. 2205 The sender's address MUST be included in the control information; the 2206 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 2208 recipient verifies that the operating system's report of the sender's 2209 address matches the sender's address in the message. If a recipient 2210 address is specified or the recipient requires an address then one of 2211 the recipient's addresses MUST also appear as the recipient's address 2212 in the message. Where a sender's or receiver's address might not 2213 otherwise match the address in a message because of network address 2214 translation, an application MAY be written to use addresses of the 2215 directional address type in place of the actual network address. 2217 A failed match for either case generates a KRB_AP_ERR_BADADDR error. 2218 To work with network address translation, implementations MAY use the 2219 directional address type defined in section 7.1 for the sender 2220 address and include no recipient address. 2222 Then the timestamp and usec and/or the sequence number fields are 2223 checked. If timestamp and usec are expected and not present, or they 2224 are present but not current, the KRB_AP_ERR_SKEW error is generated. 2225 If the server name, along with the client name, time and microsecond 2226 fields from the Authenticator match any recently-seen such tuples, 2227 the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence 2228 number is included, or a sequence number is expected but not present, 2229 the KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp 2230 and usec or a sequence number is present, a KRB_AP_ERR_MODIFIED error 2231 is generated. 2233 If all the checks succeed, the application can assume the message was 2234 generated by its peer, and was securely transmitted (without 2235 intruders able to see the unencrypted contents). 2237 3.6. The KRB_CRED Exchange 2239 The KRB_CRED message MAY be used by clients requiring the ability to 2240 send Kerberos credentials from one host to another. It achieves this 2241 by sending the tickets together with encrypted data containing the 2242 session keys and other information associated with the tickets. 2244 3.6.1. Generation of a KRB_CRED message 2246 When an application wishes to send a KRB_CRED message it first (using 2247 the KRB_TGS exchange) obtains credentials to be sent to the remote 2248 host. It then constructs a KRB_CRED message using the ticket or 2249 tickets so obtained, placing the session key needed to use each 2250 ticket in the key field of the corresponding KrbCredInfo sequence of 2251 the encrypted part of the KRB_CRED message. 2253 Other information associated with each ticket and obtained during the 2254 KRB_TGS exchange is also placed in the corresponding KrbCredInfo 2255 sequence in the encrypted part of the KRB_CRED message. The current 2256 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 2258 time and, if specifically required by the application the nonce, s- 2259 address, and r-address fields, are placed in the encrypted part of 2260 the KRB_CRED message which is then encrypted under an encryption key 2261 previously exchanged in the KRB_AP exchange (usually the last key 2262 negotiated via subkeys, or the session key if no negotiation has 2263 occurred). 2265 Implementation note: When constructing a KRB_CRED message for 2266 inclusion in a GSSAPI initial context token, the MIT implementation 2267 of Kerberos will not encrypt the KRB_CRED message if the session key 2268 is a DES or triple DES key. For interoperability with MIT, the 2269 Microsoft implementation will not encrypt the KRB_CRED in a GSSAPI 2270 token if it is using a DES session key. Starting at version 1.2.5, 2271 MIT Kerberos can receive and decode either encrypted or unencrypted 2272 KRB_CRED tokens in the GSSAPI exchange. The Heimdal implementation of 2273 Kerberos can also accept either encrypted or unencrypted KRB_CRED 2274 messages. Since the KRB_CRED message in a GSSAPI token is encrypted 2275 in the authenticator, the MIT behavior does not present a security 2276 problem, although it is a violation of the Kerberos specification. 2278 3.6.2. Receipt of KRB_CRED message 2280 When an application receives a KRB_CRED message, it verifies it. If 2281 any error occurs, an error code is reported for use by the 2282 application. The message is verified by checking that the protocol 2283 version and type fields match the current version and KRB_CRED, 2284 respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or 2285 KRB_AP_ERR_MSG_TYPE error. The application then decrypts the 2286 ciphertext and processes the resultant plaintext. If decryption shows 2287 the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is 2288 generated. 2290 If present or required, the recipient MAY verify that the operating 2291 system's report of the sender's address matches the sender's address 2292 in the message, and that one of the recipient's addresses appears as 2293 the recipient's address in the message. The address check does not 2294 provide any added security, since the address if present has already 2295 been checked in the KRB_AP_REQ message and there is not any benefit 2296 to be gained by an attacker in reflecting a KRB_CRED message back to 2297 its originator. Thus, the recipient MAY ignore the address even if 2298 present in order to work better in NAT environments. A failed match 2299 for either case generates a KRB_AP_ERR_BADADDR error. Recipients MAY 2300 skip the address check as the KRB_CRED message cannot generally be 2301 reflected back to the originator. The timestamp and usec fields (and 2302 the nonce field if required) are checked next. If the timestamp and 2303 usec are not present, or they are present but not current, the 2304 KRB_AP_ERR_SKEW error is generated. 2306 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 2308 If all the checks succeed, the application stores each of the new 2309 tickets in its credentials cache together with the session key and 2310 other information in the corresponding KrbCredInfo sequence from the 2311 encrypted part of the KRB_CRED message. 2313 3.7. User-to-User Authentication Exchanges 2315 User-to-User authentication provides a method to perform 2316 authentication when the verifier does not have a access to long term 2317 service key. This might be the case when running a server (for 2318 example a window server) as a user on a workstation. In such cases, 2319 the server may have access to the ticket-granting ticket obtained 2320 when the user logged in to the workstation, but because the server is 2321 running as an unprivileged user it might not have access to system 2322 keys. Similar situations may arise when running peer-to-peer 2323 applications. 2325 Summary 2326 Message direction Message type Sections 2327 0. Message from application server Not Specified 2328 1. Client to Kerberos KRB_TGS_REQ 3.3 + 5.4.1 2329 2. Kerberos to client KRB_TGS_REP or 3.3 + 5.4.2 2330 KRB_ERROR 5.9.1 2331 3. Client to Application server KRB_AP_REQ 3.2 + 5.5.1 2333 To address this problem, the Kerberos protocol allows the client to 2334 request that the ticket issued by the KDC be encrypted using a 2335 session key from a ticket-granting ticket issued to the party that 2336 will verify the authentication. This ticket-granting ticket must be 2337 obtained from the verifier by means of an exchange external to the 2338 Kerberos protocol, usually as part of the application protocol. This 2339 message is shown in the summary above as message 0. Note that because 2340 the ticket-granting ticket is encrypted in the KDC's secret key, it 2341 can not be used for authentication without possession of the 2342 corresponding secret key. Furthermore, because the verifier does not 2343 reveal the corresponding secret key, providing a copy of the 2344 verifier's ticket-granting ticket does not allow impersonation of the 2345 verifier. 2347 Message 0 in the table above represents an application specific 2348 negotiation between the client and server, at the end of which both 2349 have determined that they will use user-to-user authentication and 2350 the client has obtained the server's TGT. 2352 Next, the client includes the server's TGT as an additional ticket in 2353 its KRB_TGS_REQ request to the KDC (message 1 in the table above) and 2354 specifies the ENC-TKT-IN-SKEY option in its request. 2356 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 2358 If validated according to the instructions in 3.3.3, the application 2359 ticket returned to the client (message 2 in the table above) will be 2360 encrypted using the session key from the additional ticket and the 2361 client will note this when it uses or stores the application ticket. 2363 When contacting the server using a ticket obtained for user-to-user 2364 authentication (message 3 in the table above), the client MUST 2365 specify the USE-SESSION-KEY flag in the ap-options field. This tells 2366 the application server to use the session key associated with its 2367 ticket-granting ticket to decrypt the server ticket provided in the 2368 application request. 2370 4. Encryption and Checksum Specifications 2372 The Kerberos protocols described in this document are designed to 2373 encrypt messages of arbitrary sizes, using stream or block encryption 2374 ciphers. Encryption is used to prove the identities of the network 2375 entities participating in message exchanges. The Key Distribution 2376 Center for each realm is trusted by all principals registered in that 2377 realm to store a secret key in confidence. Proof of knowledge of this 2378 secret key is used to verify the authenticity of a principal. 2380 The KDC uses the principal's secret key (in the AS exchange) or a 2381 shared session key (in the TGS exchange) to encrypt responses to 2382 ticket requests; the ability to obtain the secret key or session key 2383 implies the knowledge of the appropriate keys and the identity of the 2384 KDC. The ability of a principal to decrypt the KDC response and 2385 present a Ticket and a properly formed Authenticator (generated with 2386 the session key from the KDC response) to a service verifies the 2387 identity of the principal; likewise the ability of the service to 2388 extract the session key from the Ticket and prove its knowledge 2389 thereof in a response verifies the identity of the service. 2391 [@KCRYPTO] defines a framework for defining encryption and checksum 2392 mechanisms for use with Kerberos. It also defines several such 2393 mechanisms, and more may be added in future updates to that document. 2395 The string-to-key operation provided by [@KCRYPTO] is used to produce 2396 a long-term key for a principal (generally for a user). The default 2397 salt string, if none is provided via pre-authentication data, is the 2398 concatenation of the principal's realm and name components, in order, 2399 with no separators. Unless otherwise indicated, the default string- 2400 to-key opaque parameter set as defined in [@KCRYPTO] is used. 2402 Encrypted data, keys and checksums are transmitted using the 2403 EncryptedData, EncryptionKey and Checksum data objects defined in 2404 section 5.2.9. The encryption, decryption, and checksum operations 2405 described in this document use the corresponding encryption, 2406 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 2408 decryption, and get_mic operations described in [@KCRYPTO], with 2409 implicit "specific key" generation using the "key usage" values 2410 specified in the description of each EncryptedData or Checksum object 2411 to vary the key for each operation. Note that in some cases, the 2412 value to be used is dependent on the method of choosing the key or 2413 the context of the message. 2415 Key usages are unsigned 32 bit integers; zero is not permitted. The 2416 key usage values for encrypting or checksumming Kerberos messages are 2417 indicated in section 5 along with the message definitions. Key usage 2418 values 512-1023 are reserved for uses internal to a Kerberos 2419 implementation. (For example, seeding a pseudo-random number 2420 generator with a value produced by encrypting something with a 2421 session key and a key usage value not used for any other purpose.) 2422 Key usage values between 1024 and 2047 (inclusive) are reserved for 2423 application use; applications SHOULD use even values for encryption 2424 and odd values for checksums within this range. Key usage values are 2425 also summarized in a table in section 7.5.1. 2427 There might exist other documents which define protocols in terms of 2428 the RFC1510 encryption types or checksum types. Such documents would 2429 not know about key usages. In order that these specifications 2430 continue to be meaningful until they are updated, if no key usage 2431 values are specified then key usages 1024 and 1025 must be used to 2432 derive keys for encryption and checksums, respectively (this does not 2433 apply to protocols that do their own encryption independent of this 2434 framework, directly using the key resulting from the Kerberos 2435 authentication exchange.) New protocols defined in terms of the 2436 Kerberos encryption and checksum types SHOULD use their own key usage 2437 values. 2439 Unless otherwise indicated, no cipher state chaining is done from one 2440 encryption operation to another. 2442 Implementation note: While not recommended, some application 2443 protocols will continue to use the key data directly, even if only in 2444 currently existing protocol specifications. An implementation 2445 intended to support general Kerberos applications may therefore need 2446 to make key data available, as well as the attributes and operations 2447 described in [@KCRYPTO]. One of the more common reasons for directly 2448 performing encryption is direct control over negotiation and 2449 selection of a "sufficiently strong" encryption algorithm (in the 2450 context of a given application). While Kerberos does not directly 2451 provide a facility for negotiating encryption types between the 2452 application client and server, there are approaches for using 2453 Kerberos to facilitate this negotiation - for example, a client may 2454 request only "sufficiently strong" session key types from the KDC and 2455 expect that any type returned by the KDC will be understood and 2456 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 2458 supported by the application server. 2460 5. Message Specifications 2462 NOTE: The ASN.1 collected here should be identical to the contents of 2463 Appendix A. In case of conflict, the contents of Appendix A shall 2464 take precedence. 2466 The Kerberos protocol is defined here in terms of Abstract Syntax 2467 Notation One (ASN.1) [X680], which provides a syntax for specifying 2468 both the abstract layout of protocol messages as well as their 2469 encodings. Implementors not utilizing an existing ASN.1 compiler or 2470 support library are cautioned to thoroughly understand the actual 2471 ASN.1 specification to ensure correct implementation behavior, as 2472 there is more complexity in the notation than is immediately obvious, 2473 and some tutorials and guides to ASN.1 are misleading or erroneous. 2475 Note that in several places, there have been changes here from RFC 2476 1510 that change the abstract types. This is in part to address 2477 widespread assumptions that various implementors have made, in some 2478 cases resulting in unintentional violations of the ASN.1 standard. 2479 These are clearly flagged where they occur. The differences between 2480 the abstract types in RFC 1510 and abstract types in this document 2481 can cause incompatible encodings to be emitted when certain encoding 2482 rules, e.g. the Packed Encoding Rules (PER), are used. This 2483 theoretical incompatibility should not be relevant for Kerberos, 2484 since Kerberos explicitly specifies the use of the Distinguished 2485 Encoding Rules (DER). It might be an issue for protocols wishing to 2486 use Kerberos types with other encoding rules. (This practice is not 2487 recommended.) With very few exceptions (most notably the usages of 2488 BIT STRING), the encodings resulting from using the DER remain 2489 identical between the types defined in RFC 1510 and the types defined 2490 in this document. 2492 The type definitions in this section assume an ASN.1 module 2493 definition of the following form: 2495 KerberosV5Spec2 { 2496 iso(1) identified-organization(3) dod(6) internet(1) 2497 security(5) kerberosV5(2) modules(4) krb5spec2(2) 2498 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 2500 -- rest of definitions here 2502 END 2504 This specifies that the tagging context for the module will be 2505 explicit and non-automatic. 2507 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 2509 Note that in some other publications [RFC1510] [RFC1964], the "dod" 2510 portion of the object identifier is erroneously specified as having 2511 the value "5". In the case of RFC 1964, use of the "correct" OID 2512 value would result in a change in the wire protocol; therefore, it 2513 remains unchanged for now. 2515 Note that elsewhere in this document, nomenclature for various 2516 message types is inconsistent, but largely follows C language 2517 conventions, including use of underscore (_) characters and all-caps 2518 spelling of names intended to be numeric constants. Also, in some 2519 places, identifiers (especially ones referring to constants) are 2520 written in all-caps in order to distinguish them from surrounding 2521 explanatory text. 2523 The ASN.1 notation does not permit underscores in identifiers, so in 2524 actual ASN.1 definitions, underscores are replaced with hyphens (-). 2525 Additionally, structure member names and defined values in ASN.1 MUST 2526 begin with a lowercase letter, while type names MUST begin with an 2527 uppercase letter. 2529 5.1. Specific Compatibility Notes on ASN.1 2531 For compatibility purposes, implementors should heed the following 2532 specific notes regarding the use of ASN.1 in Kerberos. These notes do 2533 not describe deviations from standard usage of ASN.1. The purpose of 2534 these notes is to instead describe some historical quirks and non- 2535 compliance of various implementations, as well as historical 2536 ambiguities, which, while being valid ASN.1, can lead to confusion 2537 during implementation. 2539 5.1.1. ASN.1 Distinguished Encoding Rules 2541 The encoding of Kerberos protocol messages shall obey the 2542 Distinguished Encoding Rules (DER) of ASN.1 as described in [X690]. 2543 Some implementations (believed to be primarily ones derived from DCE 2544 1.1 and earlier) are known to use the more general Basic Encoding 2545 Rules (BER); in particular, these implementations send indefinite 2546 encodings of lengths. Implementations MAY accept such encodings in 2547 the interests of backwards compatibility, though implementors are 2548 warned that decoding fully-general BER is fraught with peril. 2550 5.1.2. Optional Integer Fields 2552 Some implementations do not internally distinguish between an omitted 2553 optional integer value and a transmitted value of zero. The places in 2554 the protocol where this is relevant include various microseconds 2555 fields, nonces, and sequence numbers. Implementations SHOULD treat 2556 omitted optional integer values as having been transmitted with a 2557 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 2559 value of zero, if the application is expecting this. 2561 5.1.3. Empty SEQUENCE OF Types 2563 There are places in the protocol where a message contains a SEQUENCE 2564 OF type as an optional member. This can result in an encoding that 2565 contains an empty SEQUENCE OF encoding. The Kerberos protocol does 2566 not semantically distinguish between an absent optional SEQUENCE OF 2567 type and a present optional but empty SEQUENCE OF type. 2568 Implementations SHOULD NOT send empty SEQUENCE OF encodings that are 2569 marked OPTIONAL, but SHOULD accept them as being equivalent to an 2570 omitted OPTIONAL type. In the ASN.1 syntax describing Kerberos 2571 messages, instances of these problematic optional SEQUENCE OF types 2572 are indicated with a comment. 2574 5.1.4. Unrecognized Tag Numbers 2576 Future revisions to this protocol may include new message types with 2577 different APPLICATION class tag numbers. Such revisions should 2578 protect older implementations by only sending the message types to 2579 parties that are known to understand them, e.g. by means of a flag 2580 bit set by the receiver in a preceding request. In the interest of 2581 robust error handling, implementations SHOULD gracefully handle 2582 receiving a message with an unrecognized tag anyway, and return an 2583 error message if appropriate. 2585 In particular, KDCs SHOULD return KRB_AP_ERR_MSG_TYPE if the 2586 incorrect tag is sent over a TCP transport. The KDCs SHOULD NOT 2587 respond to messages received with an unknown tag over UDP transport 2588 in order to avoid denial of service attacks. For non-KDC 2589 applications, the Kerberos implementation typically indicates an 2590 error to the application which takes appropriate steps based on the 2591 application protocol. 2593 5.1.5. Tag Numbers Greater Than 30 2595 A naive implementation of a DER ASN.1 decoder may experience problems 2596 with ASN.1 tag numbers greater than 30, due to such tag numbers being 2597 encoded using more than one byte. Future revisions of this protocol 2598 may utilize tag numbers greater than 30, and implementations SHOULD 2599 be prepared to gracefully return an error, if appropriate, if they do 2600 not recognize the tag. 2602 5.2. Basic Kerberos Types 2604 This section defines a number of basic types that are potentially 2605 used in multiple Kerberos protocol messages. 2607 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 2609 5.2.1. KerberosString 2611 The original specification of the Kerberos protocol in RFC 1510 uses 2612 GeneralString in numerous places for human-readable string data. 2613 Historical implementations of Kerberos cannot utilize the full power 2614 of GeneralString. This ASN.1 type requires the use of designation 2615 and invocation escape sequences as specified in ISO-2022/ECMA-35 2616 [ISO-2022/ECMA-35] to switch character sets, and the default 2617 character set that is designated as G0 is the ISO-646/ECMA-6 2618 [ISO-646,ECMA-6] International Reference Version (IRV) (aka U.S. 2619 ASCII), which mostly works. 2621 ISO-2022/ECMA-35 defines four character-set code elements (G0..G3) 2622 and two Control-function code elements (C0..C1). DER prohibits the 2623 designation of character sets as any but the G0 and C0 sets. 2624 Unfortunately, this seems to have the side effect of prohibiting the 2625 use of ISO-8859 (ISO Latin) [ISO-8859] character-sets or any other 2626 character-sets that utilize a 96-character set, since it is 2627 prohibited by ISO-2022/ECMA-35 to designate them as the G0 code 2628 element. This side effect is being investigated in the ASN.1 2629 standards community. 2631 In practice, many implementations treat GeneralStrings as if they 2632 were 8-bit strings of whichever character set the implementation 2633 defaults to, without regard for correct usage of character-set 2634 designation escape sequences. The default character set is often 2635 determined by the current user's operating system dependent locale. 2636 At least one major implementation places unescaped UTF-8 encoded 2637 Unicode characters in the GeneralString. This failure to adhere to 2638 the GeneralString specifications results in interoperability issues 2639 when conflicting character encodings are utilized by the Kerberos 2640 clients, services, and KDC. 2642 This unfortunate situation is the result of improper documentation of 2643 the restrictions of the ASN.1 GeneralString type in prior Kerberos 2644 specifications. 2646 The new (post-RFC 1510) type KerberosString, defined below, is a 2647 GeneralString that is constrained to only contain characters in 2648 IA5String 2650 KerberosString ::= GeneralString (IA5String) 2652 In general, US-ASCII control characters should not be used in 2653 KerberosString. Control characters SHOULD NOT be used in principal 2654 names or realm names. 2656 For compatibility, implementations MAY choose to accept GeneralString 2657 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 2659 values that contain characters other than those permitted by 2660 IA5String, but they should be aware that character set designation 2661 codes will likely be absent, and that the encoding should probably be 2662 treated as locale-specific in almost every way. Implementations MAY 2663 also choose to emit GeneralString values that are beyond those 2664 permitted by IA5String, but should be aware that doing so is 2665 extraordinarily risky from an interoperability perspective. 2667 Some existing implementations use GeneralString to encode unescaped 2668 locale-specific characters. This is a violation of the ASN.1 2669 standard. Most of these implementations encode US-ASCII in the left- 2670 hand half, so as long the implementation transmits only US-ASCII, the 2671 ASN.1 standard is not violated in this regard. As soon as such an 2672 implementation encodes unescaped locale-specific characters with the 2673 high bit set, it violates the ASN.1 standard. 2675 Other implementations have been known to use GeneralString to contain 2676 a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8 2677 is a different encoding, not a 94 or 96 character "G" set as defined 2678 by ISO 2022. It is believed that these implementations do not even 2679 use the ISO 2022 escape sequence to change the character encoding. 2680 Even if implementations were to announce the change of encoding by 2681 using that escape sequence, the ASN.1 standard prohibits the use of 2682 any escape sequences other than those used to designate/invoke "G" or 2683 "C" sets allowed by GeneralString. 2685 Future revisions to this protocol will almost certainly allow for a 2686 more interoperable representation of principal names, probably 2687 including UTF8String. 2689 Note that applying a new constraint to a previously unconstrained 2690 type constitutes creation of a new ASN.1 type. In this particular 2691 case, the change does not result in a changed encoding under DER. 2693 5.2.2. Realm and PrincipalName 2695 Realm ::= KerberosString 2697 PrincipalName ::= SEQUENCE { 2698 name-type [0] Int32, 2699 name-string [1] SEQUENCE OF KerberosString 2700 } 2702 Kerberos realm names are encoded as KerberosStrings. Realms shall not 2703 contain a character with the code 0 (the US-ASCII NUL). Most realms 2704 will usually consist of several components separated by periods (.), 2705 in the style of Internet Domain Names, or separated by slashes (/) in 2706 the style of X.500 names. Acceptable forms for realm names are 2707 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 2709 specified in section 6.1.. A PrincipalName is a typed sequence of 2710 components consisting of the following sub-fields: 2712 name-type 2713 This field specifies the type of name that follows. Pre-defined 2714 values for this field are specified in section 6.2. The name-type 2715 SHOULD be treated as a hint. Ignoring the name type, no two names 2716 can be the same (i.e. at least one of the components, or the 2717 realm, must be different). 2719 name-string 2720 This field encodes a sequence of components that form a name, each 2721 component encoded as a KerberosString. Taken together, a 2722 PrincipalName and a Realm form a principal identifier. Most 2723 PrincipalNames will have only a few components (typically one or 2724 two). 2726 5.2.3. KerberosTime 2728 KerberosTime ::= GeneralizedTime -- with no fractional seconds 2730 The timestamps used in Kerberos are encoded as GeneralizedTimes. A 2731 KerberosTime value shall not include any fractional portions of the 2732 seconds. As required by the DER, it further shall not include any 2733 separators, and it shall specify the UTC time zone (Z). Example: The 2734 only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6 2735 November 1985 is 19851106210627Z. 2737 5.2.4. Constrained Integer types 2739 Some integer members of types SHOULD be constrained to values 2740 representable in 32 bits, for compatibility with reasonable 2741 implementation limits. 2743 Int32 ::= INTEGER (-2147483648..2147483647) 2744 -- signed values representable in 32 bits 2746 UInt32 ::= INTEGER (0..4294967295) 2747 -- unsigned 32 bit values 2749 Microseconds ::= INTEGER (0..999999) 2750 -- microseconds 2752 While this results in changes to the abstract types from the RFC 1510 2753 version, the encoding in DER should be unaltered. Historical 2754 implementations were typically limited to 32-bit integer values 2755 anyway, and assigned numbers SHOULD fall in the space of integer 2756 values representable in 32 bits in order to promote interoperability 2757 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 2759 anyway. 2761 There are several integer fields in messages that are constrained to 2762 fixed values. 2764 pvno 2765 also TKT-VNO or AUTHENTICATOR-VNO, this recurring field is always 2766 the constant integer 5. There is no easy way to make this field 2767 into a useful protocol version number, so its value is fixed. 2769 msg-type 2770 this integer field is usually identical to the application tag 2771 number of the containing message type. 2773 5.2.5. HostAddress and HostAddresses 2775 HostAddress ::= SEQUENCE { 2776 addr-type [0] Int32, 2777 address [1] OCTET STRING 2778 } 2780 -- NOTE: HostAddresses is always used as an OPTIONAL field and 2781 -- should not be empty. 2782 HostAddresses -- NOTE: subtly different from rfc1510, 2783 -- but has a value mapping and encodes the same 2784 ::= SEQUENCE OF HostAddress 2786 The host address encodings consists of two fields: 2788 addr-type 2789 This field specifies the type of address that follows. Pre-defined 2790 values for this field are specified in section 7.5.3. 2792 address 2793 This field encodes a single address of type addr-type. 2795 5.2.6. AuthorizationData 2797 -- NOTE: AuthorizationData is always used as an OPTIONAL field and 2798 -- should not be empty. 2799 AuthorizationData ::= SEQUENCE OF SEQUENCE { 2800 ad-type [0] Int32, 2801 ad-data [1] OCTET STRING 2802 } 2804 ad-data 2805 This field contains authorization data to be interpreted according 2806 to the value of the corresponding ad-type field. 2808 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 2810 ad-type 2811 This field specifies the format for the ad-data subfield. All 2812 negative values are reserved for local use. Non-negative values 2813 are reserved for registered use. 2815 Each sequence of type and data is referred to as an authorization 2816 element. Elements MAY be application specific, however, there is a 2817 common set of recursive elements that should be understood by all 2818 implementations. These elements contain other elements embedded 2819 within them, and the interpretation of the encapsulating element 2820 determines which of the embedded elements must be interpreted, and 2821 which may be ignored. 2823 These common authorization data elements are recursively defined, 2824 meaning the ad-data for these types will itself contain a sequence of 2825 authorization data whose interpretation is affected by the 2826 encapsulating element. Depending on the meaning of the encapsulating 2827 element, the encapsulated elements may be ignored, might be 2828 interpreted as issued directly by the KDC, or they might be stored in 2829 a separate plaintext part of the ticket. The types of the 2830 encapsulating elements are specified as part of the Kerberos 2831 specification because the behavior based on these values should be 2832 understood across implementations whereas other elements need only be 2833 understood by the applications which they affect. 2835 Authorization data elements are considered critical if present in a 2836 ticket or authenticator. Unless encapsulated in a known authorization 2837 data element amending the criticality of the elements it contains, if 2838 an unknown authorization data element type is received by a server 2839 either in an AP-REQ or in a ticket contained in an AP-REQ, then 2840 authentication MUST fail. Authorization data is intended to restrict 2841 the use of a ticket. If the service cannot determine whether the 2842 restriction applies to that service then a security weakness may 2843 result if the ticket can be used for that service. Authorization 2844 elements that are optional can be enclosed in AD-IF-RELEVANT element. 2846 In the definitions that follow, the value of the ad-type for the 2847 element will be specified as the least significant part of the 2848 subsection number, and the value of the ad-data will be as shown in 2849 the ASN.1 structure that follows the subsection heading. 2851 contents of ad-data ad-type 2853 DER encoding of AD-IF-RELEVANT 1 2855 DER encoding of AD-KDCIssued 4 2857 DER encoding of AD-AND-OR 5 2858 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 2860 DER encoding of AD-MANDATORY-FOR-KDC 8 2862 5.2.6.1. IF-RELEVANT 2864 AD-IF-RELEVANT ::= AuthorizationData 2866 AD elements encapsulated within the if-relevant element are intended 2867 for interpretation only by application servers that understand the 2868 particular ad-type of the embedded element. Application servers that 2869 do not understand the type of an element embedded within the if- 2870 relevant element MAY ignore the uninterpretable element. This element 2871 promotes interoperability across implementations which may have local 2872 extensions for authorization. The ad-type for AD-IF-RELEVANT is (1). 2874 5.2.6.2. KDCIssued 2876 AD-KDCIssued ::= SEQUENCE { 2877 ad-checksum [0] Checksum, 2878 i-realm [1] Realm OPTIONAL, 2879 i-sname [2] PrincipalName OPTIONAL, 2880 elements [3] AuthorizationData 2881 } 2883 ad-checksum 2884 A cryptographic checksum computed over the DER encoding of the 2885 AuthorizationData in the "elements" field, keyed with the session 2886 key. Its checksumtype is the mandatory checksum type for the 2887 encryption type of the session key, and its key usage value is 19. 2889 i-realm, i-sname 2890 The name of the issuing principal if different from the KDC 2891 itself. This field would be used when the KDC can verify the 2892 authenticity of elements signed by the issuing principal and it 2893 allows this KDC to notify the application server of the validity 2894 of those elements. 2896 elements 2897 A sequence of authorization data elements issued by the KDC. 2899 The KDC-issued ad-data field is intended to provide a means for 2900 Kerberos principal credentials to embed within themselves privilege 2901 attributes and other mechanisms for positive authorization, 2902 amplifying the privileges of the principal beyond what can be done 2903 using a credentials without such an a-data element. 2905 This can not be provided without this element because the definition 2906 of the authorization-data field allows elements to be added at will 2907 by the bearer of a TGT at the time that they request service tickets 2908 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 2910 and elements may also be added to a delegated ticket by inclusion in 2911 the authenticator. 2913 For KDC-issued elements this is prevented because the elements are 2914 signed by the KDC by including a checksum encrypted using the 2915 server's key (the same key used to encrypt the ticket - or a key 2916 derived from that key). Elements encapsulated with in the KDC-issued 2917 element MUST be ignored by the application server if this 2918 "signature" is not present. Further, elements encapsulated within 2919 this element from a ticket-granting ticket MAY be interpreted by the 2920 KDC, and used as a basis according to policy for including new signed 2921 elements within derivative tickets, but they will not be copied to a 2922 derivative ticket directly. If they are copied directly to a 2923 derivative ticket by a KDC that is not aware of this element, the 2924 signature will not be correct for the application ticket elements, 2925 and the field will be ignored by the application server. 2927 This element and the elements it encapsulates MAY be safely ignored 2928 by applications, application servers, and KDCs that do not implement 2929 this element. 2931 The ad-type for AD-KDC-ISSUED is (4). 2933 5.2.6.3. AND-OR 2935 AD-AND-OR ::= SEQUENCE { 2936 condition-count [0] INTEGER, 2937 elements [1] AuthorizationData 2938 } 2940 When restrictive AD elements are encapsulated within the and-or 2941 element, the and-or element is considered satisfied if and only if at 2942 least the number of encapsulated elements specified in condition- 2943 count are satisfied. Therefore, this element MAY be used to 2944 implement an "or" operation by setting the condition-count field to 2945 1, and it MAY specify an "and" operation by setting the condition 2946 count to the number of embedded elements. Application servers that do 2947 not implement this element MUST reject tickets that contain 2948 authorization data elements of this type. 2950 The ad-type for AD-AND-OR is (5). 2952 5.2.6.4. MANDATORY-FOR-KDC 2954 AD-MANDATORY-FOR-KDC ::= AuthorizationData 2956 AD elements encapsulated within the mandatory-for-kdc element are to 2957 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 2959 be interpreted by the KDC. KDCs that do not understand the type of an 2960 element embedded within the mandatory-for-kdc element MUST reject the 2961 request. 2963 The ad-type for AD-MANDATORY-FOR-KDC is (8). 2965 5.2.7. PA-DATA 2967 Historically, PA-DATA have been known as "pre-authentication data", 2968 meaning that they were used to augment the initial authentication 2969 with the KDC. Since that time, they have also been used as a typed 2970 hole with which to extend protocol exchanges with the KDC. 2972 PA-DATA ::= SEQUENCE { 2973 -- NOTE: first tag is [1], not [0] 2974 padata-type [1] Int32, 2975 padata-value [2] OCTET STRING -- might be encoded AP-REQ 2976 } 2978 padata-type 2979 indicates the way that the padata-value element is to be 2980 interpreted. Negative values of padata-type are reserved for 2981 unregistered use; non-negative values are used for a registered 2982 interpretation of the element type. 2984 padata-value 2985 Usually contains the DER encoding of another type; the padata-type 2986 field identifies which type is encoded here. 2988 padata-type name contents of padata-value 2990 1 pa-tgs-req DER encoding of AP-REQ 2992 2 pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP 2994 3 pa-pw-salt salt (not ASN.1 encoded) 2996 11 pa-etype-info DER encoding of ETYPE-INFO 2998 19 pa-etype-info2 DER encoding of ETYPE-INFO2 3000 This field MAY also contain information needed by certain 3001 extensions to the Kerberos protocol. For example, it might be used 3002 to initially verify the identity of a client before any response 3003 is returned. 3005 The padata field can also contain information needed to help the 3006 KDC or the client select the key needed for generating or 3007 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 3009 decrypting the response. This form of the padata is useful for 3010 supporting the use of certain token cards with Kerberos. The 3011 details of such extensions are specified in separate documents. 3012 See [Pat92] for additional uses of this field. 3014 5.2.7.1. PA-TGS-REQ 3016 In the case of requests for additional tickets (KRB_TGS_REQ), padata- 3017 value will contain an encoded AP-REQ. The checksum in the 3018 authenticator (which MUST be collision-proof) is to be computed over 3019 the KDC-REQ-BODY encoding. 3021 5.2.7.2. Encrypted Timestamp Pre-authentication 3023 There are pre-authentication types that may be used to pre- 3024 authenticate a client by means of an encrypted timestamp. 3026 PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC 3028 PA-ENC-TS-ENC ::= SEQUENCE { 3029 patimestamp [0] KerberosTime -- client's time --, 3030 pausec [1] Microseconds OPTIONAL 3031 } 3033 Patimestamp contains the client's time, and pausec contains the 3034 microseconds, which MAY be omitted if a client will not generate more 3035 than one request per second. The ciphertext (padata-value) consists 3036 of the PA-ENC-TS-ENC encoding, encrypted using the client's secret 3037 key and a key usage value of 1. 3039 This pre-authentication type was not present in RFC 1510, but many 3040 implementations support it. 3042 5.2.7.3. PA-PW-SALT 3044 The padata-value for this pre-authentication type contains the salt 3045 for the string-to-key to be used by the client to obtain the key for 3046 decrypting the encrypted part of an AS-REP message. Unfortunately, 3047 for historical reasons, the character set to be used is unspecified 3048 and probably locale-specific. 3050 This pre-authentication type was not present in RFC 1510, but many 3051 implementations support it. It is necessary in any case where the 3052 salt for the string-to-key algorithm is not the default. 3054 In the trivial example, a zero-length salt string is very commonplace 3055 for realms that have converted their principal databases from 3056 Kerberos 4. 3058 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 3060 A KDC SHOULD NOT send PA-PW-SALT when issuing a KRB-ERROR message 3061 that requests additional pre-authentication. Implementation note: 3062 some KDC implementations issue an erroneous PA-PW-SALT when issuing a 3063 KRB-ERROR message that requests additional pre-authentication. 3064 Therefore, clients SHOULD ignore a PA-PW-SALT accompanying a KRB- 3065 ERROR message that requests additional pre-authentication. As noted 3066 in section 3.1.3, a KDC MUST NOT send PA-PW-SALT when the client's 3067 AS-REQ includes at least one "newer" etype. 3069 5.2.7.4. PA-ETYPE-INFO 3071 The ETYPE-INFO pre-authentication type is sent by the KDC in a KRB- 3072 ERROR indicating a requirement for additional pre-authentication. It 3073 is usually used to notify a client of which key to use for the 3074 encryption of an encrypted timestamp for the purposes of sending a 3075 PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an 3076 AS-REP to provide information to the client about which key salt to 3077 use for the string-to-key to be used by the client to obtain the key 3078 for decrypting the encrypted part the AS-REP. 3080 ETYPE-INFO-ENTRY ::= SEQUENCE { 3081 etype [0] Int32, 3082 salt [1] OCTET STRING OPTIONAL 3083 } 3085 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY 3087 The salt, like that of PA-PW-SALT, is also completely unspecified 3088 with respect to character set and is probably locale-specific. 3090 If ETYPE-INFO is sent in an AS-REP, there shall be exactly one ETYPE- 3091 INFO-ENTRY, and its etype shall match that of the enc-part in the AS- 3092 REP. 3094 This pre-authentication type was not present in RFC 1510, but many 3095 implementations that support encrypted timestamps for pre- 3096 authentication need to support ETYPE-INFO as well. As noted in 3097 section 3.1.3, a KDC MUST NOT send PA-ETYPE-INFO when the client's 3098 AS-REQ includes at least one "newer" etype. 3100 5.2.7.5. PA-ETYPE-INFO2 3102 The ETYPE-INFO2 pre-authentication type is sent by the KDC in a KRB- 3103 ERROR indicating a requirement for additional pre-authentication. It 3104 is usually used to notify a client of which key to use for the 3105 encryption of an encrypted timestamp for the purposes of sending a 3106 PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an 3107 AS-REP to provide information to the client about which key salt to 3108 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 3110 use for the string-to-key to be used by the client to obtain the key 3111 for decrypting the encrypted part the AS-REP. 3113 ETYPE-INFO2-ENTRY ::= SEQUENCE { 3114 etype [0] Int32, 3115 salt [1] KerberosString OPTIONAL, 3116 s2kparams [2] OCTET STRING OPTIONAL 3117 } 3119 ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY 3121 The type of the salt is KerberosString, but existing installations 3122 might have locale-specific characters stored in salt strings, and 3123 implementors MAY choose to handle them. 3125 The interpretation of s2kparams is specified in the cryptosystem 3126 description associated with the etype. Each cryptosystem has a 3127 default interpretation of s2kparams that will hold if that element is 3128 omitted from the encoding of ETYPE-INFO2-ENTRY. 3130 If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one 3131 ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part in 3132 the AS-REP. 3134 The preferred ordering of the "hint" pre-authentication data that 3135 affect client key selection is: ETYPE-INFO2, followed by ETYPE-INFO, 3136 followed by PW-SALT. As noted in section 3.1.3, a KDC MUST NOT send 3137 ETYPE-INFO or PW-SALT when the client's AS-REQ includes at least one 3138 "newer" etype. 3140 The ETYPE-INFO2 pre-authentication type was not present in RFC 1510. 3142 5.2.8. KerberosFlags 3144 For several message types, a specific constrained bit string type, 3145 KerberosFlags, is used. 3147 KerberosFlags ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits 3148 -- shall be sent, but no fewer than 32 3150 Compatibility note: the following paragraphs describe a change from 3151 the RFC1510 description of bit strings that would result in 3152 incompatility in the case of an implementation that strictly 3153 conformed to ASN.1 DER and RFC1510. 3155 ASN.1 bit strings have multiple uses. The simplest use of a bit 3156 string is to contain a vector of bits, with no particular meaning 3157 attached to individual bits. This vector of bits is not necessarily a 3158 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 3160 multiple of eight bits long. The use in Kerberos of a bit string as 3161 a compact boolean vector wherein each element has a distinct meaning 3162 poses some problems. The natural notation for a compact boolean 3163 vector is the ASN.1 "NamedBit" notation, and the DER require that 3164 encodings of a bit string using "NamedBit" notation exclude any 3165 trailing zero bits. This truncation is easy to neglect, especially 3166 given C language implementations that naturally choose to store 3167 boolean vectors as 32 bit integers. 3169 For example, if the notation for KDCOptions were to include the 3170 "NamedBit" notation, as in RFC 1510, and a KDCOptions value to be 3171 encoded had only the "forwardable" (bit number one) bit set, the DER 3172 encoding MUST include only two bits: the first reserved bit 3173 ("reserved", bit number zero, value zero) and the one-valued bit (bit 3174 number one) for "forwardable". 3176 Most existing implementations of Kerberos unconditionally send 32 3177 bits on the wire when encoding bit strings used as boolean vectors. 3178 This behavior violates the ASN.1 syntax used for flag values in RFC 3179 1510, but occurs on such a widely installed base that the protocol 3180 description is being modified to accommodate it. 3182 Consequently, this document removes the "NamedBit" notations for 3183 individual bits, relegating them to comments. The size constraint on 3184 the KerberosFlags type requires that at least 32 bits be encoded at 3185 all times, though a lenient implementation MAY choose to accept fewer 3186 than 32 bits and to treat the missing bits as set to zero. 3188 Currently, no uses of KerberosFlags specify more than 32 bits worth 3189 of flags, although future revisions of this document may do so. When 3190 more than 32 bits are to be transmitted in a KerberosFlags value, 3191 future revisions to this document will likely specify that the 3192 smallest number of bits needed to encode the highest-numbered one- 3193 valued bit should be sent. This is somewhat similar to the DER 3194 encoding of a bit string that is declared with the "NamedBit" 3195 notation. 3197 5.2.9. Cryptosystem-related Types 3199 Many Kerberos protocol messages contain an EncryptedData as a 3200 container for arbitrary encrypted data, which is often the encrypted 3201 encoding of another data type. Fields within EncryptedData assist the 3202 recipient in selecting a key with which to decrypt the enclosed data. 3204 EncryptedData ::= SEQUENCE { 3205 etype [0] Int32 -- EncryptionType --, 3206 kvno [1] UInt32 OPTIONAL, 3207 cipher [2] OCTET STRING -- ciphertext 3208 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 3210 } 3212 etype 3213 This field identifies which encryption algorithm was used to 3214 encipher the cipher. 3216 kvno 3217 This field contains the version number of the key under which data 3218 is encrypted. It is only present in messages encrypted under long 3219 lasting keys, such as principals' secret keys. 3221 cipher 3222 This field contains the enciphered text, encoded as an OCTET 3223 STRING. (Note that the encryption mechanisms defined in 3224 [@KCRYPTO] MUST incorporate integrity protection as well, so no 3225 additional checksum is required.) 3227 The EncryptionKey type is the means by which cryptographic keys used 3228 for encryption are transferred. 3230 EncryptionKey ::= SEQUENCE { 3231 keytype [0] Int32 -- actually encryption type --, 3232 keyvalue [1] OCTET STRING 3233 } 3235 keytype 3236 This field specifies the encryption type of the encryption key 3237 that follows in the keyvalue field. While its name is "keytype", 3238 it actually specifies an encryption type. Previously, multiple 3239 cryptosystems that performed encryption differently but were 3240 capable of using keys with the same characteristics were permitted 3241 to share an assigned number to designate the type of key; this 3242 usage is now deprecated. 3244 keyvalue 3245 This field contains the key itself, encoded as an octet string. 3247 Messages containing cleartext data to be authenticated will usually 3248 do so by using a member of type Checksum. Most instances of Checksum 3249 use a keyed hash, though exceptions will be noted. 3251 Checksum ::= SEQUENCE { 3252 cksumtype [0] Int32, 3253 checksum [1] OCTET STRING 3254 } 3256 cksumtype 3257 This field indicates the algorithm used to generate the 3258 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 3260 accompanying checksum. 3262 checksum 3263 This field contains the checksum itself, encoded as an octet 3264 string. 3266 See section 4 for a brief description of the use of encryption and 3267 checksums in Kerberos. 3269 5.3. Tickets 3271 This section describes the format and encryption parameters for 3272 tickets and authenticators. When a ticket or authenticator is 3273 included in a protocol message it is treated as an opaque object. A 3274 ticket is a record that helps a client authenticate to a service. A 3275 Ticket contains the following information: 3277 Ticket ::= [APPLICATION 1] SEQUENCE { 3278 tkt-vno [0] INTEGER (5), 3279 realm [1] Realm, 3280 sname [2] PrincipalName, 3281 enc-part [3] EncryptedData -- EncTicketPart 3282 } 3284 -- Encrypted part of ticket 3285 EncTicketPart ::= [APPLICATION 3] SEQUENCE { 3286 flags [0] TicketFlags, 3287 key [1] EncryptionKey, 3288 crealm [2] Realm, 3289 cname [3] PrincipalName, 3290 transited [4] TransitedEncoding, 3291 authtime [5] KerberosTime, 3292 starttime [6] KerberosTime OPTIONAL, 3293 endtime [7] KerberosTime, 3294 renew-till [8] KerberosTime OPTIONAL, 3295 caddr [9] HostAddresses OPTIONAL, 3296 authorization-data [10] AuthorizationData OPTIONAL 3297 } 3299 -- encoded Transited field 3300 TransitedEncoding ::= SEQUENCE { 3301 tr-type [0] Int32 -- must be registered --, 3302 contents [1] OCTET STRING 3303 } 3305 TicketFlags ::= KerberosFlags 3306 -- reserved(0), 3307 -- forwardable(1), 3308 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 3310 -- forwarded(2), 3311 -- proxiable(3), 3312 -- proxy(4), 3313 -- may-postdate(5), 3314 -- postdated(6), 3315 -- invalid(7), 3316 -- renewable(8), 3317 -- initial(9), 3318 -- pre-authent(10), 3319 -- hw-authent(11), 3320 -- the following are new since 1510 3321 -- transited-policy-checked(12), 3322 -- ok-as-delegate(13) 3324 tkt-vno 3325 This field specifies the version number for the ticket format. 3326 This document describes version number 5. 3328 realm 3329 This field specifies the realm that issued a ticket. It also 3330 serves to identify the realm part of the server's principal 3331 identifier. Since a Kerberos server can only issue tickets for 3332 servers within its realm, the two will always be identical. 3334 sname 3335 This field specifies all components of the name part of the 3336 server's identity, including those parts that identify a specific 3337 instance of a service. 3339 enc-part 3340 This field holds the encrypted encoding of the EncTicketPart 3341 sequence. It is encrypted in the key shared by Kerberos and the 3342 end server (the server's secret key), using a key usage value of 3343 2. 3345 flags 3346 This field indicates which of various options were used or 3347 requested when the ticket was issued. The meanings of the flags 3348 are: 3350 Bit(s) Name Description 3352 0 reserved Reserved for future expansion of this 3353 field. 3355 The FORWARDABLE flag is normally only 3356 interpreted by the TGS, and can be 3357 ignored by end servers. When set, this 3358 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 3360 1 forwardable flag tells the ticket-granting server 3361 that it is OK to issue a new 3362 ticket-granting ticket with a 3363 different network address based on the 3364 presented ticket. 3366 When set, this flag indicates that the 3367 ticket has either been forwarded or 3368 2 forwarded was issued based on authentication 3369 involving a forwarded ticket-granting 3370 ticket. 3372 The PROXIABLE flag is normally only 3373 interpreted by the TGS, and can be 3374 ignored by end servers. The PROXIABLE 3375 flag has an interpretation identical 3376 3 proxiable to that of the FORWARDABLE flag, 3377 except that the PROXIABLE flag tells 3378 the ticket-granting server that only 3379 non-ticket-granting tickets may be 3380 issued with different network 3381 addresses. 3383 4 proxy When set, this flag indicates that a 3384 ticket is a proxy. 3386 The MAY-POSTDATE flag is normally only 3387 interpreted by the TGS, and can be 3388 5 may-postdate ignored by end servers. This flag 3389 tells the ticket-granting server that 3390 a post-dated ticket MAY be issued 3391 based on this ticket-granting ticket. 3393 This flag indicates that this ticket 3394 has been postdated. The end-service 3395 6 postdated can check the authtime field to see 3396 when the original authentication 3397 occurred. 3399 This flag indicates that a ticket is 3400 invalid, and it must be validated by 3401 7 invalid the KDC before use. Application 3402 servers must reject tickets which have 3403 this flag set. 3405 The RENEWABLE flag is normally only 3406 interpreted by the TGS, and can 3407 usually be ignored by end servers 3408 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 3410 8 renewable (some particularly careful servers MAY 3411 disallow renewable tickets). A 3412 renewable ticket can be used to obtain 3413 a replacement ticket that expires at a 3414 later date. 3416 This flag indicates that this ticket 3417 9 initial was issued using the AS protocol, and 3418 not issued based on a ticket-granting 3419 ticket. 3421 This flag indicates that during 3422 initial authentication, the client was 3423 authenticated by the KDC before a 3424 10 pre-authent ticket was issued. The strength of the 3425 pre-authentication method is not 3426 indicated, but is acceptable to the 3427 KDC. 3429 This flag indicates that the protocol 3430 employed for initial authentication 3431 required the use of hardware expected 3432 11 hw-authent to be possessed solely by the named 3433 client. The hardware authentication 3434 method is selected by the KDC and the 3435 strength of the method is not 3436 indicated. 3438 This flag indicates that the KDC for 3439 the realm has checked the transited 3440 field against a realm defined policy 3441 for trusted certifiers. If this flag 3442 is reset (0), then the application 3443 server must check the transited field 3444 itself, and if unable to do so it must 3445 reject the authentication. If the flag 3446 12 transited- is set (1) then the application server 3447 policy-checked MAY skip its own validation of the 3448 transited field, relying on the 3449 validation performed by the KDC. At 3450 its option the application server MAY 3451 still apply its own validation based 3452 on a separate policy for acceptance. 3454 This flag is new since RFC 1510. 3456 This flag indicates that the server 3457 (not the client) specified in the 3458 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 3460 ticket has been determined by policy 3461 of the realm to be a suitable 3462 recipient of delegation. A client can 3463 use the presence of this flag to help 3464 it make a decision whether to delegate 3465 credentials (either grant a proxy or a 3466 forwarded ticket-granting ticket) to 3467 13 ok-as-delegate this server. The client is free to 3468 ignore the value of this flag. When 3469 setting this flag, an administrator 3470 should consider the Security and 3471 placement of the server on which the 3472 service will run, as well as whether 3473 the service requires the use of 3474 delegated credentials. 3476 This flag is new since RFC 1510. 3478 14-31 reserved Reserved for future use. 3480 key 3481 This field exists in the ticket and the KDC response and is used 3482 to pass the session key from Kerberos to the application server 3483 and the client. 3485 crealm 3486 This field contains the name of the realm in which the client is 3487 registered and in which initial authentication took place. 3489 cname 3490 This field contains the name part of the client's principal 3491 identifier. 3493 transited 3494 This field lists the names of the Kerberos realms that took part 3495 in authenticating the user to whom this ticket was issued. It does 3496 not specify the order in which the realms were transited. See 3497 section 3.3.3.2 for details on how this field encodes the 3498 traversed realms. When the names of CA's are to be embedded in 3499 the transited field (as specified for some extensions to the 3500 protocol), the X.500 names of the CA's SHOULD be mapped into items 3501 in the transited field using the mapping defined by RFC2253. 3503 authtime 3504 This field indicates the time of initial authentication for the 3505 named principal. It is the time of issue for the original ticket 3506 on which this ticket is based. It is included in the ticket to 3507 provide additional information to the end service, and to provide 3508 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 3510 the necessary information for implementation of a `hot list' 3511 service at the KDC. An end service that is particularly paranoid 3512 could refuse to accept tickets for which the initial 3513 authentication occurred "too far" in the past. This field is also 3514 returned as part of the response from the KDC. When returned as 3515 part of the response to initial authentication (KRB_AS_REP), this 3516 is the current time on the Kerberos server. It is NOT recommended 3517 that this time value be used to adjust the workstation's clock 3518 since the workstation cannot reliably determine that such a 3519 KRB_AS_REP actually came from the proper KDC in a timely manner. 3521 starttime 3523 This field in the ticket specifies the time after which the ticket 3524 is valid. Together with endtime, this field specifies the life of 3525 the ticket. If the starttime field is absent from the ticket, then 3526 the authtime field SHOULD be used in its place to determine the 3527 life of the ticket. 3529 endtime 3530 This field contains the time after which the ticket will not be 3531 honored (its expiration time). Note that individual services MAY 3532 place their own limits on the life of a ticket and MAY reject 3533 tickets which have not yet expired. As such, this is really an 3534 upper bound on the expiration time for the ticket. 3536 renew-till 3537 This field is only present in tickets that have the RENEWABLE flag 3538 set in the flags field. It indicates the maximum endtime that may 3539 be included in a renewal. It can be thought of as the absolute 3540 expiration time for the ticket, including all renewals. 3542 caddr 3543 This field in a ticket contains zero (if omitted) or more (if 3544 present) host addresses. These are the addresses from which the 3545 ticket can be used. If there are no addresses, the ticket can be 3546 used from any location. The decision by the KDC to issue or by the 3547 end server to accept addressless tickets is a policy decision and 3548 is left to the Kerberos and end-service administrators; they MAY 3549 refuse to issue or accept such tickets. Because of the wide 3550 deployment of network address translation, it is recommended that 3551 policy allow the issue and acceptance of such tickets. 3553 Network addresses are included in the ticket to make it harder for 3554 an attacker to use stolen credentials. Because the session key is 3555 not sent over the network in cleartext, credentials can't be 3556 stolen simply by listening to the network; an attacker has to gain 3557 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 3559 access to the session key (perhaps through operating system 3560 security breaches or a careless user's unattended session) to make 3561 use of stolen tickets. 3563 It is important to note that the network address from which a 3564 connection is received cannot be reliably determined. Even if it 3565 could be, an attacker who has compromised the client's workstation 3566 could use the credentials from there. Including the network 3567 addresses only makes it more difficult, not impossible, for an 3568 attacker to walk off with stolen credentials and then use them 3569 from a "safe" location. 3571 authorization-data 3572 The authorization-data field is used to pass authorization data 3573 from the principal on whose behalf a ticket was issued to the 3574 application service. If no authorization data is included, this 3575 field will be left out. Experience has shown that the name of this 3576 field is confusing, and that a better name for this field would be 3577 restrictions. Unfortunately, it is not possible to change the name 3578 of this field at this time. 3580 This field contains restrictions on any authority obtained on the 3581 basis of authentication using the ticket. It is possible for any 3582 principal in possession of credentials to add entries to the 3583 authorization data field since these entries further restrict what 3584 can be done with the ticket. Such additions can be made by 3585 specifying the additional entries when a new ticket is obtained 3586 during the TGS exchange, or they MAY be added during chained 3587 delegation using the authorization data field of the 3588 authenticator. 3590 Because entries may be added to this field by the holder of 3591 credentials, except when an entry is separately authenticated by 3592 encapsulation in the KDC-issued element, it is not allowable for 3593 the presence of an entry in the authorization data field of a 3594 ticket to amplify the privileges one would obtain from using a 3595 ticket. 3597 The data in this field may be specific to the end service; the 3598 field will contain the names of service specific objects, and the 3599 rights to those objects. The format for this field is described in 3600 section 5.2.6. Although Kerberos is not concerned with the format 3601 of the contents of the sub-fields, it does carry type information 3602 (ad-type). 3604 By using the authorization_data field, a principal is able to 3605 issue a proxy that is valid for a specific purpose. For example, a 3606 client wishing to print a file can obtain a file server proxy to 3607 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 3609 be passed to the print server. By specifying the name of the file 3610 in the authorization_data field, the file server knows that the 3611 print server can only use the client's rights when accessing the 3612 particular file to be printed. 3614 A separate service providing authorization or certifying group 3615 membership may be built using the authorization-data field. In 3616 this case, the entity granting authorization (not the authorized 3617 entity), may obtain a ticket in its own name (e.g. the ticket is 3618 issued in the name of a privilege server), and this entity adds 3619 restrictions on its own authority and delegates the restricted 3620 authority through a proxy to the client. The client would then 3621 present this authorization credential to the application server 3622 separately from the authentication exchange. Alternatively, such 3623 authorization credentials MAY be embedded in the ticket 3624 authenticating the authorized entity, when the authorization is 3625 separately authenticated using the KDC-issued authorization data 3626 element (see 5.2.6.2). 3628 Similarly, if one specifies the authorization-data field of a 3629 proxy and leaves the host addresses blank, the resulting ticket 3630 and session key can be treated as a capability. See [Neu93] for 3631 some suggested uses of this field. 3633 The authorization-data field is optional and does not have to be 3634 included in a ticket. 3636 5.4. Specifications for the AS and TGS exchanges 3638 This section specifies the format of the messages used in the 3639 exchange between the client and the Kerberos server. The format of 3640 possible error messages appears in section 5.9.1. 3642 5.4.1. KRB_KDC_REQ definition 3644 The KRB_KDC_REQ message has no application tag number of its own. 3645 Instead, it is incorporated into one of KRB_AS_REQ or KRB_TGS_REQ, 3646 which each have an application tag, depending on whether the request 3647 is for an initial ticket or an additional ticket. In either case, the 3648 message is sent from the client to the KDC to request credentials for 3649 a service. 3651 The message fields are: 3653 AS-REQ ::= [APPLICATION 10] KDC-REQ 3655 TGS-REQ ::= [APPLICATION 12] KDC-REQ 3656 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 3658 KDC-REQ ::= SEQUENCE { 3659 -- NOTE: first tag is [1], not [0] 3660 pvno [1] INTEGER (5) , 3661 msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --), 3662 padata [3] SEQUENCE OF PA-DATA OPTIONAL 3663 -- NOTE: not empty --, 3664 req-body [4] KDC-REQ-BODY 3665 } 3667 KDC-REQ-BODY ::= SEQUENCE { 3668 kdc-options [0] KDCOptions, 3669 cname [1] PrincipalName OPTIONAL 3670 -- Used only in AS-REQ --, 3671 realm [2] Realm 3672 -- Server's realm 3673 -- Also client's in AS-REQ --, 3674 sname [3] PrincipalName OPTIONAL, 3675 from [4] KerberosTime OPTIONAL, 3676 till [5] KerberosTime, 3677 rtime [6] KerberosTime OPTIONAL, 3678 nonce [7] UInt32, 3679 etype [8] SEQUENCE OF Int32 -- EncryptionType 3680 -- in preference order --, 3681 addresses [9] HostAddresses OPTIONAL, 3682 enc-authorization-data [10] EncryptedData OPTIONAL 3683 -- AuthorizationData --, 3684 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 3685 -- NOTE: not empty 3686 } 3688 KDCOptions ::= KerberosFlags 3689 -- reserved(0), 3690 -- forwardable(1), 3691 -- forwarded(2), 3692 -- proxiable(3), 3693 -- proxy(4), 3694 -- allow-postdate(5), 3695 -- postdated(6), 3696 -- unused7(7), 3697 -- renewable(8), 3698 -- unused9(9), 3699 -- unused10(10), 3700 -- opt-hardware-auth(11), 3701 -- unused12(12), 3702 -- unused13(13), 3703 -- 15 is reserved for canonicalize 3704 -- unused15(15), 3705 -- 26 was unused in 1510 3706 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 3708 -- disable-transited-check(26), 3709 -- 3710 -- renewable-ok(27), 3711 -- enc-tkt-in-skey(28), 3712 -- renew(30), 3713 -- validate(31) 3715 The fields in this message are: 3717 pvno 3718 This field is included in each message, and specifies the protocol 3719 version number. This document specifies protocol version 5. 3721 msg-type 3722 This field indicates the type of a protocol message. It will 3723 almost always be the same as the application identifier associated 3724 with a message. It is included to make the identifier more readily 3725 accessible to the application. For the KDC-REQ message, this type 3726 will be KRB_AS_REQ or KRB_TGS_REQ. 3728 padata 3729 Contains pre-authentication data. Requests for additional tickets 3730 (KRB_TGS_REQ) MUST contain a padata of PA-TGS-REQ. 3732 The padata (pre-authentication data) field contains a sequence of 3733 authentication information which may be needed before credentials 3734 can be issued or decrypted. 3736 req-body 3737 This field is a placeholder delimiting the extent of the remaining 3738 fields. If a checksum is to be calculated over the request, it is 3739 calculated over an encoding of the KDC-REQ-BODY sequence which is 3740 enclosed within the req-body field. 3742 kdc-options 3743 This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to 3744 the KDC and indicates the flags that the client wants set on the 3745 tickets as well as other information that is to modify the 3746 behavior of the KDC. Where appropriate, the name of an option may 3747 be the same as the flag that is set by that option. Although in 3748 most case, the bit in the options field will be the same as that 3749 in the flags field, this is not guaranteed, so it is not 3750 acceptable to simply copy the options field to the flags field. 3751 There are various checks that must be made before honoring an 3752 option anyway. 3754 The kdc_options field is a bit-field, where the selected options 3755 are indicated by the bit being set (1), and the unselected options 3756 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 3758 and reserved fields being reset (0). The encoding of the bits is 3759 specified in section 5.2. The options are described in more detail 3760 above in section 2. The meanings of the options are: 3762 Bits Name Description 3764 0 RESERVED Reserved for future expansion of 3765 this field. 3767 The FORWARDABLE option indicates 3768 that the ticket to be issued is to 3769 have its forwardable flag set. It 3770 1 FORWARDABLE may only be set on the initial 3771 request, or in a subsequent request 3772 if the ticket-granting ticket on 3773 which it is based is also 3774 forwardable. 3776 The FORWARDED option is only 3777 specified in a request to the 3778 ticket-granting server and will only 3779 be honored if the ticket-granting 3780 ticket in the request has its 3781 2 FORWARDED FORWARDABLE bit set. This option 3782 indicates that this is a request for 3783 forwarding. The address(es) of the 3784 host from which the resulting ticket 3785 is to be valid are included in the 3786 addresses field of the request. 3788 The PROXIABLE option indicates that 3789 the ticket to be issued is to have 3790 its proxiable flag set. It may only 3791 3 PROXIABLE be set on the initial request, or in 3792 a subsequent request if the 3793 ticket-granting ticket on which it 3794 is based is also proxiable. 3796 The PROXY option indicates that this 3797 is a request for a proxy. This 3798 option will only be honored if the 3799 ticket-granting ticket in the 3800 4 PROXY request has its PROXIABLE bit set. 3801 The address(es) of the host from 3802 which the resulting ticket is to be 3803 valid are included in the addresses 3804 field of the request. 3806 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 3808 The ALLOW-POSTDATE option indicates 3809 that the ticket to be issued is to 3810 have its MAY-POSTDATE flag set. It 3811 5 ALLOW-POSTDATE may only be set on the initial 3812 request, or in a subsequent request 3813 if the ticket-granting ticket on 3814 which it is based also has its 3815 MAY-POSTDATE flag set. 3817 The POSTDATED option indicates that 3818 this is a request for a postdated 3819 ticket. This option will only be 3820 honored if the ticket-granting 3821 ticket on which it is based has its 3822 6 POSTDATED MAY-POSTDATE flag set. The resulting 3823 ticket will also have its INVALID 3824 flag set, and that flag may be reset 3825 by a subsequent request to the KDC 3826 after the starttime in the ticket 3827 has been reached. 3829 7 RESERVED This option is presently unused. 3831 The RENEWABLE option indicates that 3832 the ticket to be issued is to have 3833 its RENEWABLE flag set. It may only 3834 be set on the initial request, or 3835 when the ticket-granting ticket on 3836 8 RENEWABLE which the request is based is also 3837 renewable. If this option is 3838 requested, then the rtime field in 3839 the request contains the desired 3840 absolute expiration time for the 3841 ticket. 3843 9 RESERVED Reserved for PK-Cross 3845 10 RESERVED Reserved for future use. 3847 11 RESERVED Reserved for opt-hardware-auth. 3849 12-25 RESERVED Reserved for future use. 3851 By default the KDC will check the 3852 transited field of a 3853 ticket-granting-ticket against the 3854 policy of the local realm before it 3855 will issue derivative tickets based 3856 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 3858 on the ticket-granting ticket. If 3859 this flag is set in the request, 3860 checking of the transited field is 3861 disabled. Tickets issued without the 3862 26 DISABLE-TRANSITED-CHECK performance of this check will be 3863 noted by the reset (0) value of the 3864 TRANSITED-POLICY-CHECKED flag, 3865 indicating to the application server 3866 that the tranisted field must be 3867 checked locally. KDCs are 3868 encouraged but not required to honor 3869 the DISABLE-TRANSITED-CHECK option. 3871 This flag is new since RFC 1510 3873 The RENEWABLE-OK option indicates 3874 that a renewable ticket will be 3875 acceptable if a ticket with the 3876 requested life cannot otherwise be 3877 provided. If a ticket with the 3878 requested life cannot be provided, 3879 27 RENEWABLE-OK then a renewable ticket may be 3880 issued with a renew-till equal to 3881 the requested endtime. The value 3882 of the renew-till field may still be 3883 limited by local limits, or limits 3884 selected by the individual principal 3885 or server. 3887 This option is used only by the 3888 ticket-granting service. The 3889 ENC-TKT-IN-SKEY option indicates 3890 28 ENC-TKT-IN-SKEY that the ticket for the end server 3891 is to be encrypted in the session 3892 key from the additional 3893 ticket-granting ticket provided. 3895 29 RESERVED Reserved for future use. 3897 This option is used only by the 3898 ticket-granting service. The RENEW 3899 option indicates that the present 3900 request is for a renewal. The ticket 3901 provided is encrypted in the secret 3902 key for the server on which it is 3903 30 RENEW valid. This option will only be 3904 honored if the ticket to be renewed 3905 has its RENEWABLE flag set and if 3906 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 3908 the time in its renew-till field has 3909 not passed. The ticket to be renewed 3910 is passed in the padata field as 3911 part of the authentication header. 3913 This option is used only by the 3914 ticket-granting service. The 3915 VALIDATE option indicates that the 3916 request is to validate a postdated 3917 ticket. It will only be honored if 3918 the ticket presented is postdated, 3919 presently has its INVALID flag set, 3920 31 VALIDATE and would be otherwise usable at 3921 this time. A ticket cannot be 3922 validated before its starttime. The 3923 ticket presented for validation is 3924 encrypted in the key of the server 3925 for which it is valid and is passed 3926 in the padata field as part of the 3927 authentication header. 3928 cname and sname 3929 These fields are the same as those described for the ticket in 3930 section 5.3. The sname may only be absent when the ENC-TKT-IN-SKEY 3931 option is specified. If absent, the name of the server is taken 3932 from the name of the client in the ticket passed as additional- 3933 tickets. 3935 enc-authorization-data 3936 The enc-authorization-data, if present (and it can only be present 3937 in the TGS_REQ form), is an encoding of the desired authorization- 3938 data encrypted under the sub-session key if present in the 3939 Authenticator, or alternatively from the session key in the 3940 ticket-granting ticket (both the Authenticator and ticket-granting 3941 ticket come from the padata field in the KRB_TGS_REQ). The key 3942 usage value used when encrypting is 5 if a sub-session key is 3943 used, or 4 if the session key is used. 3945 realm 3946 This field specifies the realm part of the server's principal 3947 identifier. In the AS exchange, this is also the realm part of the 3948 client's principal identifier. 3950 from 3951 This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket 3952 requests when the requested ticket is to be postdated. It 3953 specifies the desired start time for the requested ticket. If this 3954 field is omitted then the KDC SHOULD use the current time instead. 3956 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 3958 till 3959 This field contains the expiration date requested by the client in 3960 a ticket request. It is not optional, but if the requested endtime 3961 is "19700101000000Z", the requested ticket is to have the maximum 3962 endtime permitted according to KDC policy. Implementation note: 3963 This special timestamp corresponds to a UNIX time_t value of zero 3964 on most systems. 3966 rtime 3967 This field is the requested renew-till time sent from a client to 3968 the KDC in a ticket request. It is optional. 3970 nonce 3971 This field is part of the KDC request and response. It is intended 3972 to hold a random number generated by the client. If the same 3973 number is included in the encrypted response from the KDC, it 3974 provides evidence that the response is fresh and has not been 3975 replayed by an attacker. Nonces MUST NEVER be reused. 3977 etype 3978 This field specifies the desired encryption algorithm to be used 3979 in the response. 3981 addresses 3982 This field is included in the initial request for tickets, and 3983 optionally included in requests for additional tickets from the 3984 ticket-granting server. It specifies the addresses from which the 3985 requested ticket is to be valid. Normally it includes the 3986 addresses for the client's host. If a proxy is requested, this 3987 field will contain other addresses. The contents of this field are 3988 usually copied by the KDC into the caddr field of the resulting 3989 ticket. 3991 additional-tickets 3992 Additional tickets MAY be optionally included in a request to the 3993 ticket-granting server. If the ENC-TKT-IN-SKEY option has been 3994 specified, then the session key from the additional ticket will be 3995 used in place of the server's key to encrypt the new ticket. When 3996 the ENC-TKT-IN-SKEY option is used for user-to-user 3997 authentication, this additional ticket MAY be a TGT issued by the 3998 local realm or an inter-realm TGT issued for the current KDC's 3999 realm by a remote KDC. If more than one option which requires 4000 additional tickets has been specified, then the additional tickets 4001 are used in the order specified by the ordering of the options 4002 bits (see kdc-options, above). 4004 The application tag number will be either ten (10) or twelve (12) 4005 depending on whether the request is for an initial ticket (AS-REQ) or 4006 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 4008 for an additional ticket (TGS-REQ). 4010 The optional fields (addresses, authorization-data and additional- 4011 tickets) are only included if necessary to perform the operation 4012 specified in the kdc-options field. 4014 It should be noted that in KRB_TGS_REQ, the protocol version number 4015 appears twice and two different message types appear: the KRB_TGS_REQ 4016 message contains these fields as does the authentication header 4017 (KRB_AP_REQ) that is passed in the padata field. 4019 5.4.2. KRB_KDC_REP definition 4021 The KRB_KDC_REP message format is used for the reply from the KDC for 4022 either an initial (AS) request or a subsequent (TGS) request. There 4023 is no message type for KRB_KDC_REP. Instead, the type will be either 4024 KRB_AS_REP or KRB_TGS_REP. The key used to encrypt the ciphertext 4025 part of the reply depends on the message type. For KRB_AS_REP, the 4026 ciphertext is encrypted in the client's secret key, and the client's 4027 key version number is included in the key version number for the 4028 encrypted data. For KRB_TGS_REP, the ciphertext is encrypted in the 4029 sub-session key from the Authenticator, or if absent, the session key 4030 from the ticket-granting ticket used in the request. In that case, 4031 no version number will be present in the EncryptedData sequence. 4033 The KRB_KDC_REP message contains the following fields: 4035 AS-REP ::= [APPLICATION 11] KDC-REP 4037 TGS-REP ::= [APPLICATION 13] KDC-REP 4039 KDC-REP ::= SEQUENCE { 4040 pvno [0] INTEGER (5), 4041 msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --), 4042 padata [2] SEQUENCE OF PA-DATA OPTIONAL 4043 -- NOTE: not empty --, 4044 crealm [3] Realm, 4045 cname [4] PrincipalName, 4046 ticket [5] Ticket, 4047 enc-part [6] EncryptedData 4048 -- EncASRepPart or EncTGSRepPart, 4049 -- as appropriate 4050 } 4052 EncASRepPart ::= [APPLICATION 25] EncKDCRepPart 4054 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 4055 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 4057 EncKDCRepPart ::= SEQUENCE { 4058 key [0] EncryptionKey, 4059 last-req [1] LastReq, 4060 nonce [2] UInt32, 4061 key-expiration [3] KerberosTime OPTIONAL, 4062 flags [4] TicketFlags, 4063 authtime [5] KerberosTime, 4064 starttime [6] KerberosTime OPTIONAL, 4065 endtime [7] KerberosTime, 4066 renew-till [8] KerberosTime OPTIONAL, 4067 srealm [9] Realm, 4068 sname [10] PrincipalName, 4069 caddr [11] HostAddresses OPTIONAL 4070 } 4072 LastReq ::= SEQUENCE OF SEQUENCE { 4073 lr-type [0] Int32, 4074 lr-value [1] KerberosTime 4075 } 4077 pvno and msg-type 4078 These fields are described above in section 5.4.1. msg-type is 4079 either KRB_AS_REP or KRB_TGS_REP. 4081 padata 4082 This field is described in detail in section 5.4.1. One possible 4083 use for this field is to encode an alternate "salt" string to be 4084 used with a string-to-key algorithm. This ability is useful to 4085 ease transitions if a realm name needs to change (e.g. when a 4086 company is acquired); in such a case all existing password-derived 4087 entries in the KDC database would be flagged as needing a special 4088 salt string until the next password change. 4090 crealm, cname, srealm and sname 4091 These fields are the same as those described for the ticket in 4092 section 5.3. 4094 ticket 4095 The newly-issued ticket, from section 5.3. 4097 enc-part 4098 This field is a place holder for the ciphertext and related 4099 information that forms the encrypted part of a message. The 4100 description of the encrypted part of the message follows each 4101 appearance of this field. 4103 The key usage value for encrypting this field is 3 in an AS-REP 4104 message, using the client's long-term key or another key selected 4105 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 4107 via pre-authentication mechanisms. In a TGS-REP message, the key 4108 usage value is 8 if the TGS session key is used, or 9 if a TGS 4109 authenticator subkey is used. 4111 Compatibility note: Some implementations unconditionally send an 4112 encrypted EncTGSRepPart (application tag number 26) in this field 4113 regardless of whether the reply is a AS-REP or a TGS-REP. In the 4114 interests of compatibility, implementors MAY relax the check on 4115 the tag number of the decrypted ENC-PART. 4117 key 4118 This field is the same as described for the ticket in section 5.3. 4120 last-req 4121 This field is returned by the KDC and specifies the time(s) of the 4122 last request by a principal. Depending on what information is 4123 available, this might be the last time that a request for a 4124 ticket-granting ticket was made, or the last time that a request 4125 based on a ticket-granting ticket was successful. It also might 4126 cover all servers for a realm, or just the particular server. Some 4127 implementations MAY display this information to the user to aid in 4128 discovering unauthorized use of one's identity. It is similar in 4129 spirit to the last login time displayed when logging into 4130 timesharing systems. 4132 lr-type 4133 This field indicates how the following lr-value field is to be 4134 interpreted. Negative values indicate that the information 4135 pertains only to the responding server. Non-negative values 4136 pertain to all servers for the realm. 4138 If the lr-type field is zero (0), then no information is 4139 conveyed by the lr-value subfield. If the absolute value of the 4140 lr-type field is one (1), then the lr-value subfield is the 4141 time of last initial request for a TGT. If it is two (2), then 4142 the lr-value subfield is the time of last initial request. If 4143 it is three (3), then the lr-value subfield is the time of 4144 issue for the newest ticket-granting ticket used. If it is four 4145 (4), then the lr-value subfield is the time of the last 4146 renewal. If it is five (5), then the lr-value subfield is the 4147 time of last request (of any type). If it is (6), then the lr- 4148 value subfield is the time when the password will expire. If 4149 it is (7), then the lr-value subfield is the time when the 4150 account will expire. 4152 lr-value 4153 This field contains the time of the last request. The time MUST 4154 be interpreted according to the contents of the accompanying 4155 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 4157 lr-type subfield. 4159 nonce 4160 This field is described above in section 5.4.1. 4162 key-expiration 4163 The key-expiration field is part of the response from the KDC and 4164 specifies the time that the client's secret key is due to expire. 4165 The expiration might be the result of password aging or an account 4166 expiration. If present, it SHOULD be set to the earliest of the 4167 user's key expiration and account expiration. The use of this 4168 field is deprecated and the last-req field SHOULD be used to 4169 convey this information instead. This field will usually be left 4170 out of the TGS reply since the response to the TGS request is 4171 encrypted in a session key and no client information need be 4172 retrieved from the KDC database. It is up to the application 4173 client (usually the login program) to take appropriate action 4174 (such as notifying the user) if the expiration time is imminent. 4176 flags, authtime, starttime, endtime, renew-till and caddr 4177 These fields are duplicates of those found in the encrypted 4178 portion of the attached ticket (see section 5.3), provided so the 4179 client MAY verify they match the intended request and to assist in 4180 proper ticket caching. If the message is of type KRB_TGS_REP, the 4181 caddr field will only be filled in if the request was for a proxy 4182 or forwarded ticket, or if the user is substituting a subset of 4183 the addresses from the ticket-granting ticket. If the client- 4184 requested addresses are not present or not used, then the 4185 addresses contained in the ticket will be the same as those 4186 included in the ticket-granting ticket. 4188 5.5. Client/Server (CS) message specifications 4190 This section specifies the format of the messages used for the 4191 authentication of the client to the application server. 4193 5.5.1. KRB_AP_REQ definition 4195 The KRB_AP_REQ message contains the Kerberos protocol version number, 4196 the message type KRB_AP_REQ, an options field to indicate any options 4197 in use, and the ticket and authenticator themselves. The KRB_AP_REQ 4198 message is often referred to as the 'authentication header'. 4200 AP-REQ ::= [APPLICATION 14] SEQUENCE { 4201 pvno [0] INTEGER (5), 4202 msg-type [1] INTEGER (14), 4203 ap-options [2] APOptions, 4204 ticket [3] Ticket, 4205 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 4207 authenticator [4] EncryptedData -- Authenticator 4208 } 4210 APOptions ::= KerberosFlags 4211 -- reserved(0), 4212 -- use-session-key(1), 4213 -- mutual-required(2) 4215 pvno and msg-type 4216 These fields are described above in section 5.4.1. msg-type is 4217 KRB_AP_REQ. 4219 ap-options 4220 This field appears in the application request (KRB_AP_REQ) and 4221 affects the way the request is processed. It is a bit-field, where 4222 the selected options are indicated by the bit being set (1), and 4223 the unselected options and reserved fields being reset (0). The 4224 encoding of the bits is specified in section 5.2. The meanings of 4225 the options are: 4227 Bit(s) Name Description 4229 0 reserved Reserved for future expansion of this field. 4231 The USE-SESSION-KEY option indicates that the 4232 ticket the client is presenting to a server 4233 1 use-session-key is encrypted in the session key from the 4234 server's ticket-granting ticket. When this 4235 option is not specified, the ticket is 4236 encrypted in the server's secret key. 4238 The MUTUAL-REQUIRED option tells the server 4239 2 mutual-required that the client requires mutual 4240 authentication, and that it must respond with 4241 a KRB_AP_REP message. 4243 3-31 reserved Reserved for future use. 4245 ticket 4246 This field is a ticket authenticating the client to the server. 4248 authenticator 4249 This contains the encrypted authenticator, which includes the 4250 client's choice of a subkey. 4252 The encrypted authenticator is included in the AP-REQ; it certifies 4253 to a server that the sender has recent knowledge of the encryption 4254 key in the accompanying ticket, to help the server detect replays. It 4255 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 4257 also assists in the selection of a "true session key" to use with the 4258 particular session. The DER encoding of the following is encrypted 4259 in the ticket's session key, with a key usage value of 11 in normal 4260 application exchanges, or 7 when used as the PA-TGS-REQ PA-DATA field 4261 of a TGS-REQ exchange (see section 5.4.1): 4263 -- Unencrypted authenticator 4264 Authenticator ::= [APPLICATION 2] SEQUENCE { 4265 authenticator-vno [0] INTEGER (5), 4266 crealm [1] Realm, 4267 cname [2] PrincipalName, 4268 cksum [3] Checksum OPTIONAL, 4269 cusec [4] Microseconds, 4270 ctime [5] KerberosTime, 4271 subkey [6] EncryptionKey OPTIONAL, 4272 seq-number [7] UInt32 OPTIONAL, 4273 authorization-data [8] AuthorizationData OPTIONAL 4274 } 4276 authenticator-vno 4277 This field specifies the version number for the format of the 4278 authenticator. This document specifies version 5. 4280 crealm and cname 4281 These fields are the same as those described for the ticket in 4282 section 5.3. 4284 cksum 4285 This field contains a checksum of the application data that 4286 accompanies the KRB_AP_REQ, computed using a key usage value of 10 4287 in normal application exchanges, or 6 when used in the TGS-REQ PA- 4288 TGS-REQ AP-DATA field. 4290 cusec 4291 This field contains the microsecond part of the client's 4292 timestamp. Its value (before encryption) ranges from 0 to 999999. 4293 It often appears along with ctime. The two fields are used 4294 together to specify a reasonably accurate timestamp. 4296 ctime 4297 This field contains the current time on the client's host. 4299 subkey 4300 This field contains the client's choice for an encryption key 4301 which is to be used to protect this specific application session. 4302 Unless an application specifies otherwise, if this field is left 4303 out the session key from the ticket will be used. 4305 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 4307 seq-number 4308 This optional field includes the initial sequence number to be 4309 used by the KRB_PRIV or KRB_SAFE messages when sequence numbers 4310 are used to detect replays (It may also be used by application 4311 specific messages). When included in the authenticator this field 4312 specifies the initial sequence number for messages from the client 4313 to the server. When included in the AP-REP message, the initial 4314 sequence number is that for messages from the server to the 4315 client. When used in KRB_PRIV or KRB_SAFE messages, it is 4316 incremented by one after each message is sent. Sequence numbers 4317 fall in the range of 0 through 2^32 - 1 and wrap to zero following 4318 the value 2^32 - 1. 4320 For sequence numbers to adequately support the detection of 4321 replays they SHOULD be non-repeating, even across connection 4322 boundaries. The initial sequence number SHOULD be random and 4323 uniformly distributed across the full space of possible sequence 4324 numbers, so that it cannot be guessed by an attacker and so that 4325 it and the successive sequence numbers do not repeat other 4326 sequences. In the event that more than 2^32 messages are to be 4327 generated in a series of KRB_PRIV or KRB_SAFE messages, rekeying 4328 SHOULD be performed before sequence numbers are reused with the 4329 same encryption key. 4331 Implmentation note: historically, some implementations transmit 4332 signed twos-complement numbers for sequence numbers. In the 4333 interests of compatibility, implementations MAY accept the 4334 equivalent negative number where a positive number greater than 4335 2^31 - 1 is expected. 4337 Implementation note: as noted before, some implementations omit 4338 the optional sequence number when its value would be zero. 4339 Implementations MAY accept an omitted sequence number when 4340 expecting a value of zero, and SHOULD NOT transmit an 4341 Authenticator with a initial sequence number of zero. 4343 authorization-data 4344 This field is the same as described for the ticket in section 5.3. 4345 It is optional and will only appear when additional restrictions 4346 are to be placed on the use of a ticket, beyond those carried in 4347 the ticket itself. 4349 5.5.2. KRB_AP_REP definition 4351 The KRB_AP_REP message contains the Kerberos protocol version number, 4352 the message type, and an encrypted time-stamp. The message is sent in 4353 response to an application request (KRB_AP_REQ) where the mutual 4354 authentication option has been selected in the ap-options field. 4356 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 4358 AP-REP ::= [APPLICATION 15] SEQUENCE { 4359 pvno [0] INTEGER (5), 4360 msg-type [1] INTEGER (15), 4361 enc-part [2] EncryptedData -- EncAPRepPart 4362 } 4364 EncAPRepPart ::= [APPLICATION 27] SEQUENCE { 4365 ctime [0] KerberosTime, 4366 cusec [1] Microseconds, 4367 subkey [2] EncryptionKey OPTIONAL, 4368 seq-number [3] UInt32 OPTIONAL 4369 } 4371 The encoded EncAPRepPart is encrypted in the shared session key of 4372 the ticket. The optional subkey field can be used in an application- 4373 arranged negotiation to choose a per association session key. 4375 pvno and msg-type 4376 These fields are described above in section 5.4.1. msg-type is 4377 KRB_AP_REP. 4379 enc-part 4380 This field is described above in section 5.4.2. It is computed 4381 with a key usage value of 12. 4383 ctime 4384 This field contains the current time on the client's host. 4386 cusec 4387 This field contains the microsecond part of the client's 4388 timestamp. 4390 subkey 4391 This field contains an encryption key which is to be used to 4392 protect this specific application session. See section 3.2.6 for 4393 specifics on how this field is used to negotiate a key. Unless an 4394 application specifies otherwise, if this field is left out, the 4395 sub-session key from the authenticator, or if also left out, the 4396 session key from the ticket will be used. 4398 seq-number 4399 This field is described above in section 5.3.2. 4401 5.5.3. Error message reply 4403 If an error occurs while processing the application request, the 4404 KRB_ERROR message will be sent in response. See section 5.9.1 for the 4405 format of the error message. The cname and crealm fields MAY be left 4406 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 4408 out if the server cannot determine their appropriate values from the 4409 corresponding KRB_AP_REQ message. If the authenticator was 4410 decipherable, the ctime and cusec fields will contain the values from 4411 it. 4413 5.6. KRB_SAFE message specification 4415 This section specifies the format of a message that can be used by 4416 either side (client or server) of an application to send a tamper- 4417 proof message to its peer. It presumes that a session key has 4418 previously been exchanged (for example, by using the 4419 KRB_AP_REQ/KRB_AP_REP messages). 4421 5.6.1. KRB_SAFE definition 4423 The KRB_SAFE message contains user data along with a collision-proof 4424 checksum keyed with the last encryption key negotiated via subkeys, 4425 or the session key if no negotiation has occurred. The message fields 4426 are: 4428 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 4429 pvno [0] INTEGER (5), 4430 msg-type [1] INTEGER (20), 4431 safe-body [2] KRB-SAFE-BODY, 4432 cksum [3] Checksum 4433 } 4435 KRB-SAFE-BODY ::= SEQUENCE { 4436 user-data [0] OCTET STRING, 4437 timestamp [1] KerberosTime OPTIONAL, 4438 usec [2] Microseconds OPTIONAL, 4439 seq-number [3] UInt32 OPTIONAL, 4440 s-address [4] HostAddress, 4441 r-address [5] HostAddress OPTIONAL 4442 } 4444 pvno and msg-type 4445 These fields are described above in section 5.4.1. msg-type is 4446 KRB_SAFE. 4448 safe-body 4449 This field is a placeholder for the body of the KRB-SAFE message. 4451 cksum 4452 This field contains the checksum of the application data, computed 4453 with a key usage value of 15. 4455 The checksum is computed over the encoding of the KRB-SAFE 4456 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 4458 sequence. First, the cksum is set to a type zero, zero-length 4459 value and the checksum is computed over the encoding of the KRB- 4460 SAFE sequence, then the checksum is set to the result of that 4461 computation, and finally the KRB-SAFE sequence is encoded again. 4462 This method, while different than the one specified in RFC 1510, 4463 corresponds to existing practice. 4465 user-data 4466 This field is part of the KRB_SAFE and KRB_PRIV messages and 4467 contain the application specific data that is being passed from 4468 the sender to the recipient. 4470 timestamp 4471 This field is part of the KRB_SAFE and KRB_PRIV messages. Its 4472 contents are the current time as known by the sender of the 4473 message. By checking the timestamp, the recipient of the message 4474 is able to make sure that it was recently generated, and is not a 4475 replay. 4477 usec 4478 This field is part of the KRB_SAFE and KRB_PRIV headers. It 4479 contains the microsecond part of the timestamp. 4481 seq-number 4482 This field is described above in section 5.3.2. 4484 s-address 4485 Sender's address. 4487 This field specifies the address in use by the sender of the 4488 message. 4490 r-address 4491 This field specifies the address in use by the recipient of the 4492 message. It MAY be omitted for some uses (such as broadcast 4493 protocols), but the recipient MAY arbitrarily reject such 4494 messages. This field, along with s-address, can be used to help 4495 detect messages which have been incorrectly or maliciously 4496 delivered to the wrong recipient. 4498 5.7. KRB_PRIV message specification 4500 This section specifies the format of a message that can be used by 4501 either side (client or server) of an application to securely and 4502 privately send a message to its peer. It presumes that a session key 4503 has previously been exchanged (for example, by using the 4504 KRB_AP_REQ/KRB_AP_REP messages). 4506 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 4508 5.7.1. KRB_PRIV definition 4510 The KRB_PRIV message contains user data encrypted in the Session Key. 4511 The message fields are: 4513 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 4514 pvno [0] INTEGER (5), 4515 msg-type [1] INTEGER (21), 4516 -- NOTE: there is no [2] tag 4517 enc-part [3] EncryptedData -- EncKrbPrivPart 4518 } 4520 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 4521 user-data [0] OCTET STRING, 4522 timestamp [1] KerberosTime OPTIONAL, 4523 usec [2] Microseconds OPTIONAL, 4524 seq-number [3] UInt32 OPTIONAL, 4525 s-address [4] HostAddress -- sender's addr --, 4526 r-address [5] HostAddress OPTIONAL -- recip's addr 4527 } 4529 pvno and msg-type 4530 These fields are described above in section 5.4.1. msg-type is 4531 KRB_PRIV. 4533 enc-part 4534 This field holds an encoding of the EncKrbPrivPart sequence 4535 encrypted under the session key, with a key usage value of 13. 4536 This encrypted encoding is used for the enc-part field of the KRB- 4537 PRIV message. 4539 user-data, timestamp, usec, s-address and r-address 4540 These fields are described above in section 5.6.1. 4542 seq-number 4543 This field is described above in section 5.3.2. 4545 5.8. KRB_CRED message specification 4547 This section specifies the format of a message that can be used to 4548 send Kerberos credentials from one principal to another. It is 4549 presented here to encourage a common mechanism to be used by 4550 applications when forwarding tickets or providing proxies to 4551 subordinate servers. It presumes that a session key has already been 4552 exchanged perhaps by using the KRB_AP_REQ/KRB_AP_REP messages. 4554 5.8.1. KRB_CRED definition 4555 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 4557 The KRB_CRED message contains a sequence of tickets to be sent and 4558 information needed to use the tickets, including the session key from 4559 each. The information needed to use the tickets is encrypted under 4560 an encryption key previously exchanged or transferred alongside the 4561 KRB_CRED message. The message fields are: 4563 KRB-CRED ::= [APPLICATION 22] SEQUENCE { 4564 pvno [0] INTEGER (5), 4565 msg-type [1] INTEGER (22), 4566 tickets [2] SEQUENCE OF Ticket, 4567 enc-part [3] EncryptedData -- EncKrbCredPart 4568 } 4570 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 4571 ticket-info [0] SEQUENCE OF KrbCredInfo, 4572 nonce [1] UInt32 OPTIONAL, 4573 timestamp [2] KerberosTime OPTIONAL, 4574 usec [3] Microseconds OPTIONAL, 4575 s-address [4] HostAddress OPTIONAL, 4576 r-address [5] HostAddress OPTIONAL 4577 } 4579 KrbCredInfo ::= SEQUENCE { 4580 key [0] EncryptionKey, 4581 prealm [1] Realm OPTIONAL, 4582 pname [2] PrincipalName OPTIONAL, 4583 flags [3] TicketFlags OPTIONAL, 4584 authtime [4] KerberosTime OPTIONAL, 4585 starttime [5] KerberosTime OPTIONAL, 4586 endtime [6] KerberosTime OPTIONAL, 4587 renew-till [7] KerberosTime OPTIONAL, 4588 srealm [8] Realm OPTIONAL, 4589 sname [9] PrincipalName OPTIONAL, 4590 caddr [10] HostAddresses OPTIONAL 4591 } 4593 pvno and msg-type 4594 These fields are described above in section 5.4.1. msg-type is 4595 KRB_CRED. 4597 tickets 4598 These are the tickets obtained from the KDC specifically for use 4599 by the intended recipient. Successive tickets are paired with the 4600 corresponding KrbCredInfo sequence from the enc-part of the KRB- 4601 CRED message. 4603 enc-part 4604 This field holds an encoding of the EncKrbCredPart sequence 4605 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 4607 encrypted under the session key shared between the sender and the 4608 intended recipient, with a key usage value of 14. This encrypted 4609 encoding is used for the enc-part field of the KRB-CRED message. 4611 Implementation note: implementations of certain applications, most 4612 notably certain implementations of the Kerberos GSS-API mechanism, 4613 do not separately encrypt the contents of the EncKrbCredPart of 4614 the KRB-CRED message when sending it. In the case of those GSS- 4615 API mechanisms, this is not a security vulnerability, as the 4616 entire KRB-CRED message is itself embedded in an encrypted 4617 message. 4619 nonce 4620 If practical, an application MAY require the inclusion of a nonce 4621 generated by the recipient of the message. If the same value is 4622 included as the nonce in the message, it provides evidence that 4623 the message is fresh and has not been replayed by an attacker. A 4624 nonce MUST NEVER be reused. 4626 timestamp and usec 4627 These fields specify the time that the KRB-CRED message was 4628 generated. The time is used to provide assurance that the message 4629 is fresh. 4631 s-address and r-address 4632 These fields are described above in section 5.6.1. They are used 4633 optionally to provide additional assurance of the integrity of the 4634 KRB-CRED message. 4636 key 4637 This field exists in the corresponding ticket passed by the KRB- 4638 CRED message and is used to pass the session key from the sender 4639 to the intended recipient. The field's encoding is described in 4640 section 5.2.9. 4642 The following fields are optional. If present, they can be associated 4643 with the credentials in the remote ticket file. If left out, then it 4644 is assumed that the recipient of the credentials already knows their 4645 value. 4647 prealm and pname 4648 The name and realm of the delegated principal identity. 4650 flags, authtime, starttime, endtime, renew-till, srealm, sname, and 4651 caddr 4652 These fields contain the values of the corresponding fields from 4653 the ticket found in the ticket field. Descriptions of the fields 4654 are identical to the descriptions in the KDC-REP message. 4656 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 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), 4683 ctime [2] KerberosTime OPTIONAL, 4684 cusec [3] Microseconds OPTIONAL, 4685 stime [4] KerberosTime, 4686 susec [5] Microseconds, 4687 error-code [6] Int32, 4688 crealm [7] Realm OPTIONAL, 4689 cname [8] PrincipalName OPTIONAL, 4690 realm [9] Realm -- service realm --, 4691 sname [10] PrincipalName -- service name --, 4692 e-text [11] KerberosString OPTIONAL, 4693 e-data [12] OCTET STRING OPTIONAL 4694 } 4696 pvno and msg-type 4697 These fields are described above in section 5.4.1. msg-type is 4698 KRB_ERROR. 4700 ctime, cusec 4701 These fields are described above in section 5.5.2. If the values 4702 for these fields are known to the entity generating the error 4703 (such as it would if the KRB-ERROR is generated in reply to, e.g., 4704 a failed authentication service request), they should be populated 4705 in the KRB-ERROR. If the values are not available, these fields 4706 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 4708 can be omitted. 4710 stime 4711 This field contains the current time on the server. It is of type 4712 KerberosTime. 4714 susec 4715 This field contains the microsecond part of the server's 4716 timestamp. Its value ranges from 0 to 999999. It appears along 4717 with stime. The two fields are used in conjunction to specify a 4718 reasonably accurate timestamp. 4720 error-code 4721 This field contains the error code returned by Kerberos or the 4722 server when a request fails. To interpret the value of this field 4723 see the list of error codes in section 7.5.9. Implementations are 4724 encouraged to provide for national language support in the display 4725 of error messages. 4727 crealm, and cname 4728 These fields are described above in section 5.3. When the entity 4729 generating the error knows these values, they should be populated 4730 in the KRB-ERROR. If the values are not known, the crealm and 4731 cname fields SHOULD be omitted. 4733 realm and sname 4734 These fields are described above in section 5.3. 4736 e-text 4737 This field contains additional text to help explain the error code 4738 associated with the failed request (for example, it might include 4739 a principal name which was unknown). 4741 e-data 4742 This field contains additional data about the error for use by the 4743 application to help it recover from or handle the error. If the 4744 errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will 4745 contain an encoding of a sequence of padata fields, each 4746 corresponding to an acceptable pre-authentication method and 4747 optionally containing data for the method: 4749 METHOD-DATA ::= SEQUENCE OF PA-DATA 4751 For error codes defined in this document other than 4752 KDC_ERR_PREAUTH_REQUIRED, the format and contents of the e-data field 4753 are implementation-defined. Similarly, for future error codes, the 4754 format and contents of the e-data field are implementation-defined 4755 unless specified. Whether defined by the implementation or in a 4756 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 4758 future document, the e-data field MAY take the form of TYPED-DATA: 4760 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 4761 data-type [0] INTEGER, 4762 data-value [1] OCTET STRING OPTIONAL 4763 } 4765 5.10. Application Tag Numbers 4767 The following table lists the application class tag numbers used by 4768 various data types defined in this section. 4770 Tag Number(s) Type Name Comments 4772 0 unused 4774 1 Ticket PDU 4776 2 Authenticator non-PDU 4778 3 EncTicketPart non-PDU 4780 4-9 unused 4782 10 AS-REQ PDU 4784 11 AS-REP PDU 4786 12 TGS-REQ PDU 4788 13 TGS-REP PDU 4790 14 AP-REQ PDU 4792 15 AP-REP PDU 4794 16 RESERVED16 TGT-REQ (for user-to-user) 4796 17 RESERVED17 TGT-REP (for user-to-user) 4798 18-19 unused 4800 20 KRB-SAFE PDU 4802 21 KRB-PRIV PDU 4804 22 KRB-CRED PDU 4805 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 4807 23-24 unused 4809 25 EncASRepPart non-PDU 4811 26 EncTGSRepPart non-PDU 4813 27 EncApRepPart non-PDU 4815 28 EncKrbPrivPart non-PDU 4817 29 EncKrbCredPart non-PDU 4819 30 KRB-ERROR PDU 4821 The ASN.1 types marked as "PDU" (Protocol Data Unit) in the above are 4822 the only ASN.1 types intended as top-level types of the Kerberos 4823 protocol, and are the only types that may be used as elements in 4824 another protocol that makes use of Kerberos. 4826 6. Naming Constraints 4828 6.1. Realm Names 4830 Although realm names are encoded as GeneralStrings and although a 4831 realm can technically select any name it chooses, interoperability 4832 across realm boundaries requires agreement on how realm names are to 4833 be assigned, and what information they imply. 4835 To enforce these conventions, each realm MUST conform to the 4836 conventions itself, and it MUST require that any realms with which 4837 inter-realm keys are shared also conform to the conventions and 4838 require the same from its neighbors. 4840 Kerberos realm names are case sensitive. Realm names that differ only 4841 in the case of the characters are not equivalent. There are presently 4842 three styles of realm names: domain, X500, and other. Examples of 4843 each style follow: 4845 domain: ATHENA.MIT.EDU 4846 X500: C=US/O=OSF 4847 other: NAMETYPE:rest/of.name=without-restrictions 4849 Domain style realm names MUST look like domain names: they consist of 4850 components separated by periods (.) and they contain neither colons 4851 (:) nor slashes (/). Though domain names themselves are case 4852 insensitive, in order for realms to match, the case must match as 4853 well. When establishing a new realm name based on an internet domain 4854 name it is recommended by convention that the characters be converted 4855 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 4857 to upper case. 4859 X.500 names contain an equal (=) and cannot contain a colon (:) 4860 before the equal. The realm names for X.500 names will be string 4861 representations of the names with components separated by slashes. 4862 Leading and trailing slashes will not be included. Note that the 4863 slash separator is consistent with Kerberos implementations based on 4864 RFC1510, but it is different from the separator recommended in 4865 RFC2253. 4867 Names that fall into the other category MUST begin with a prefix that 4868 contains no equal (=) or period (.) and the prefix MUST be followed 4869 by a colon (:) and the rest of the name. All prefixes expect those 4870 beginning with used. Presently none are assigned. 4872 The reserved category includes strings which do not fall into the 4873 first three categories. All names in this category are reserved. It 4874 is unlikely that names will be assigned to this category unless there 4875 is a very strong argument for not using the 'other' category. 4877 These rules guarantee that there will be no conflicts between the 4878 various name styles. The following additional constraints apply to 4879 the assignment of realm names in the domain and X.500 categories: the 4880 name of a realm for the domain or X.500 formats must either be used 4881 by the organization owning (to whom it was assigned) an Internet 4882 domain name or X.500 name, or in the case that no such names are 4883 registered, authority to use a realm name MAY be derived from the 4884 authority of the parent realm. For example, if there is no domain 4885 name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can 4886 authorize the creation of a realm with that name. 4888 This is acceptable because the organization to which the parent is 4889 assigned is presumably the organization authorized to assign names to 4890 its children in the X.500 and domain name systems as well. If the 4891 parent assigns a realm name without also registering it in the domain 4892 name or X.500 hierarchy, it is the parent's responsibility to make 4893 sure that there will not in the future exist a name identical to the 4894 realm name of the child unless it is assigned to the same entity as 4895 the realm name. 4897 6.2. Principal Names 4899 As was the case for realm names, conventions are needed to ensure 4900 that all agree on what information is implied by a principal name. 4901 The name-type field that is part of the principal name indicates the 4902 kind of information implied by the name. The name-type SHOULD be 4903 treated only as a hint to interpreting the meaning of a name. It is 4904 not significant when checking for equivalence. Principal names that 4905 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 4907 differ only in the name-type identify the same principal. The name 4908 type does not partition the name space. Ignoring the name type, no 4909 two names can be the same (i.e. at least one of the components, or 4910 the realm, MUST be different). The following name types are defined: 4912 name-type value meaning 4914 name types 4916 NT-UNKNOWN 0 Name type not known 4917 NT-PRINCIPAL 1 Just the name of the principal as in DCE, or for users 4918 NT-SRV-INST 2 Service and other unique instance (krbtgt) 4919 NT-SRV-HST 3 Service with host name as instance (telnet, rcommands) 4920 NT-SRV-XHST 4 Service with host as remaining components 4921 NT-UID 5 Unique ID 4922 NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] 4923 NT-SMTP-NAME 7 Name in form of SMTP email name (e.g. user@foo.com) 4924 NT-ENTERPRISE 10 Enterprise name - may be mapped to principal name 4926 When a name implies no information other than its uniqueness at a 4927 particular time the name type PRINCIPAL SHOULD be used. The principal 4928 name type SHOULD be used for users, and it might also be used for a 4929 unique server. If the name is a unique machine generated ID that is 4930 guaranteed never to be reassigned then the name type of UID SHOULD be 4931 used (note that it is generally a bad idea to reassign names of any 4932 type since stale entries might remain in access control lists). 4934 If the first component of a name identifies a service and the 4935 remaining components identify an instance of the service in a server 4936 specified manner, then the name type of SRV-INST SHOULD be used. An 4937 example of this name type is the Kerberos ticket-granting service 4938 whose name has a first component of krbtgt and a second component 4939 identifying the realm for which the ticket is valid. 4941 If the first component of a name identifies a service and there is a 4942 single component following the service name identifying the instance 4943 as the host on which the server is running, then the name type SRV- 4944 HST SHOULD be used. This type is typically used for Internet services 4945 such as telnet and the Berkeley R commands. If the separate 4946 components of the host name appear as successive components following 4947 the name of the service, then the name type SRV-XHST SHOULD be used. 4948 This type might be used to identify servers on hosts with X.500 names 4949 where the slash (/) might otherwise be ambiguous. 4951 A name type of NT-X500-PRINCIPAL SHOULD be used when a name from an 4952 X.509 certificate is translated into a Kerberos name. The encoding of 4953 the X.509 name as a Kerberos principal shall conform to the encoding 4954 rules specified in RFC 2253. 4956 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 4958 A name type of SMTP allows a name to be of a form that resembles a 4959 SMTP email name. This name, including an "@" and a domain name, is 4960 used as the one component of the principal name. 4962 A name type of UNKNOWN SHOULD be used when the form of the name is 4963 not known. When comparing names, a name of type UNKNOWN will match 4964 principals authenticated with names of any type. A principal 4965 authenticated with a name of type UNKNOWN, however, will only match 4966 other names of type UNKNOWN. 4968 Names of any type with an initial component of 'krbtgt' are reserved 4969 for the Kerberos ticket granting service. See section 7.3 for the 4970 form of such names. 4972 6.2.1. Name of server principals 4974 The principal identifier for a server on a host will generally be 4975 composed of two parts: (1) the realm of the KDC with which the server 4976 is registered, and (2) a two-component name of type NT-SRV-HST if the 4977 host name is an Internet domain name or a multi-component name of 4978 type NT-SRV-XHST if the name of the host is of a form such as X.500 4979 that allows slash (/) separators. The first component of the two- or 4980 multi-component name will identify the service and the latter 4981 components will identify the host. Where the name of the host is not 4982 case sensitive (for example, with Internet domain names) the name of 4983 the host MUST be lower case. If specified by the application protocol 4984 for services such as telnet and the Berkeley R commands which run 4985 with system privileges, the first component MAY be the string 'host' 4986 instead of a service specific identifier. 4988 7. Constants and other defined values 4990 7.1. Host address types 4992 All negative values for the host address type are reserved for local 4993 use. All non-negative values are reserved for officially assigned 4994 type fields and interpretations. 4996 Internet (IPv4) Addresses 4998 Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded 4999 in MSB order. The IPv4 loopback address SHOULD NOT appear in a 5000 Kerberos packet. The type of IPv4 addresses is two (2). 5002 Internet (IPv6) Addresses 5004 IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities, 5005 encoded in MSB order. The type of IPv6 addresses is twenty-four 5006 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 5008 (24). The following addresses MUST NOT appear in any Kerberos 5009 packet: 5011 * the Unspecified Address 5012 * the Loopback Address 5013 * Link-Local addresses 5015 IPv4-mapped IPv6 addresses MUST be represented as addresses of 5016 type 2. 5018 DECnet Phase IV addresses 5020 DECnet Phase IV addresses are 16-bit addresses, encoded in LSB 5021 order. The type of DECnet Phase IV addresses is twelve (12). 5023 Netbios addresses 5025 Netbios addresses are 16-octet addresses typically composed of 1 5026 to 15 alphanumeric characters and padded with the US-ASCII SPC 5027 character (code 32). The 16th octet MUST be the US-ASCII NUL 5028 character (code 0). The type of Netbios addresses is twenty (20). 5030 Directional Addresses 5032 In many environments, including the sender address in KRB_SAFE and 5033 KRB_PRIV messages is undesirable because the addresses may be 5034 changed in transport by network address translators. However, if 5035 these addresses are removed, the messages may be subject to a 5036 reflection attack in which a message is reflected back to its 5037 originator. The directional address type provides a way to avoid 5038 transport addresses and reflection attacks. Directional addresses 5039 are encoded as four byte unsigned integers in network byte order. 5040 If the message is originated by the party sending the original 5041 KRB_AP_REQ message, then an address of 0 SHOULD be used. If the 5042 message is originated by the party to whom that KRB_AP_REQ was 5043 sent, then the address 1 SHOULD be used. Applications involving 5044 multiple parties can specify the use of other addresses. 5046 Directional addresses MUST only be used for the sender address 5047 field in the KRB_SAFE or KRB_PRIV messages. They MUST NOT be used 5048 as a ticket address or in a KRB_AP_REQ message. This address type 5049 SHOULD only be used in situations where the sending party knows 5050 that the receiving party supports the address type. This generally 5051 means that directional addresses may only be used when the 5052 application protocol requires their support. Directional addresses 5053 are type (3). 5055 7.2. KDC messaging - IP Transports 5056 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 5058 Kerberos defines two IP transport mechanisms for communication 5059 between clients and servers: UDP/IP and TCP/IP. 5061 7.2.1. UDP/IP transport 5063 Kerberos servers (KDCs) supporting IP transports MUST accept UDP 5064 requests and SHOULD listen for such requests on port 88 (decimal) 5065 unless specifically configured to listen on an alternative UDP port. 5066 Alternate ports MAY be used when running multiple KDCs for multiple 5067 realms on the same host. 5069 Kerberos clients supporting IP transports SHOULD support the sending 5070 of UDP requests. Clients SHOULD use KDC discovery [7.2.3] to identify 5071 the IP address and port to which they will send their request. 5073 When contacting a KDC for a KRB_KDC_REQ request using UDP/IP 5074 transport, the client shall send a UDP datagram containing only an 5075 encoding of the request to the KDC. The KDC will respond with a reply 5076 datagram containing only an encoding of the reply message (either a 5077 KRB_ERROR or a KRB_KDC_REP) to the sending port at the sender's IP 5078 address. The response to a request made through UDP/IP transport MUST 5079 also use UDP/IP transport. If the response can not be handled using 5080 UDP (for example because it is too large), the KDC MUST return 5081 KRB_ERR_RESPONSE_TOO_BIG, forcing the client to retry the request 5082 using the TCP transport. 5084 7.2.2. TCP/IP transport 5086 Kerberos servers (KDCs) supporting IP transports MUST accept TCP 5087 requests and SHOULD listen for such requests on port 88 (decimal) 5088 unless specifically configured to listen on an alternate TCP port. 5089 Alternate ports MAY be used when running multiple KDCs for multiple 5090 realms on the same host. 5092 Clients MUST support the sending of TCP requests, but MAY choose to 5093 initially try a request using the UDP transport. Clients SHOULD use 5094 KDC discovery [7.2.3] to identify the IP address and port to which 5095 they will send their request. 5097 Implementation note: Some extensions to the Kerberos protocol will 5098 not succeed if any client or KDC not supporting the TCP transport is 5099 involved. Implementations of RFC 1510 were not required to support 5100 TCP/IP transports. 5102 When the KRB_KDC_REQ message is sent to the KDC over a TCP stream, 5103 the response (KRB_KDC_REP or KRB_ERROR message) MUST be returned to 5104 the client on the same TCP stream that was established for the 5105 request. The KDC MAY close the TCP stream after sending a response, 5106 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 5108 but MAY leave the stream open for a reasonable period of time if it 5109 expects a followup. Care must be taken in managing TCP/IP connections 5110 on the KDC to prevent denial of service attacks based on the number 5111 of open TCP/IP connections. 5113 The client MUST be prepared to have the stream closed by the KDC at 5114 anytime after the receipt of a response. A stream closure SHOULD NOT 5115 be treated as a fatal error. Instead, if multiple exchanges are 5116 required (e.g., certain forms of pre-authentication) the client may 5117 need to establish a new connection when it is ready to send 5118 subsequent messages. A client MAY close the stream after receiving a 5119 response, and SHOULD close the stream if it does not expect to send 5120 followup messages. 5122 A client MAY send multiple requests before receiving responses, 5123 though it must be prepared to handle the connection being closed 5124 after the first response. 5126 Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR) 5127 sent over the TCP stream is preceded by the length of the request as 5128 4 octets in network byte order. The high bit of the length is 5129 reserved for future expansion and MUST currently be set to zero. If 5130 a KDC that does not understand how to interpret a set high bit of the 5131 length encoding receives a request with the high order bit of the 5132 length set, it MUST return a KRB-ERROR message with the error 5133 KRB_ERR_FIELD_TOOLONG and MUST close the TCP stream. 5135 If multiple requests are sent over a single TCP connection, and the 5136 KDC sends multiple responses, the KDC is not required to send the 5137 responses in the order of the corresponding requests. This may permit 5138 some implementations to send each response as soon as it is ready 5139 even if earlier requests are still being processed (for example, 5140 waiting for a response from an external device or database). 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 5155 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 5157 In Kerberos, realm names are case sensitive. While it is strongly 5158 encouraged that all realm names be all upper case this recommendation 5159 has not been adopted by all sites. Some sites use all lower case 5160 names and other use mixed case. DNS on the other hand is case 5161 insensitive for queries. Since the realm names "MYREALM", "myrealm", 5162 and "MyRealm" are all different, but resolve the same in the domain 5163 name system, it is necessary that only one of the possible 5164 combinations of upper and lower case characters be used in realm 5165 names. 5167 7.2.3.2. Specifying KDC Location information with DNS SRV records 5169 KDC location information is to be stored using the DNS SRV RR [RFC 5170 2782]. The format of this RR is as follows: 5172 _Service._Proto.Realm TTL Class SRV Priority Weight Port Target 5174 The Service name for Kerberos is always "kerberos". 5176 The Proto can be one of "udp", "tcp". If these SRV records are to be 5177 used, both "udp" and "tcp" records MUST be specified for all KDC 5178 deployments. 5180 The Realm is the Kerberos realm that this record corresponds to. The 5181 realm MUST be a domain style realm name. 5183 TTL, Class, SRV, Priority, Weight, and Target have the standard 5184 meaning as defined in RFC 2782. 5186 As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV 5187 records SHOULD be the value assigned to "kerberos" by the Internet 5188 Assigned Number Authority: 88 (decimal) unless the KDC is configured 5189 to listen on an alternate TCP port. 5191 Implementation note: Many existing client implementations do not 5192 support KDC Discovery and are configured to send requests to the IANA 5193 assigned port (88 decimal), so it is strongly recommended that KDCs 5194 be configured to listen on that port. 5196 7.2.3.3. KDC Discovery for Domain Style Realm Names on IP Networks 5198 These are DNS records for a Kerberos realm EXAMPLE.COM. It has two 5199 Kerberos servers, kdc1.example.com and kdc2.example.com. Queries 5200 should be directed to kdc1.example.com first as per the specified 5201 priority. Weights are not used in these sample records. 5203 _kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. 5204 _kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. 5206 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 5208 _kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. 5209 _kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. 5211 7.3. Name of the TGS 5213 The principal identifier of the ticket-granting service shall be 5214 composed of three parts: (1) the realm of the KDC issuing the TGS 5215 ticket (2) a two-part name of type NT-SRV-INST, with the first part 5216 "krbtgt" and the second part the name of the realm which will accept 5217 the ticket-granting ticket. For example, a ticket-granting ticket 5218 issued by the ATHENA.MIT.EDU realm to be used to get tickets from the 5219 ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU" 5220 (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting 5221 ticket issued by the ATHENA.MIT.EDU realm to be used to get tickets 5222 from the MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" 5223 (realm), ("krbtgt", "MIT.EDU") (name). 5225 7.4. OID arc for KerberosV5 5227 This OID MAY be used to identify Kerberos protocol messages 5228 encapsulated in other protocols. It also designates the OID arc for 5229 KerberosV5-related OIDs assigned by future IETF action. 5230 Implementation note:: RFC 1510 had an incorrect value (5) for "dod" 5231 in its OID. 5233 id-krb5 OBJECT IDENTIFIER ::= { 5234 iso(1) identified-organization(3) dod(6) internet(1) 5235 security(5) kerberosV5(2) 5236 } 5238 Assignment of OIDs beneath the id-krb5 arc must be obtained by 5239 contacting the registrar for the id-krb5 arc, or its designee. At 5240 the time of the issuance of this RFC, such registrations can be 5241 obtained by contacting krb5-oid-registrar@mit.edu. 5243 7.5. Protocol constants and associated values 5245 The following tables list constants used in the protocol and define 5246 their meanings. Ranges are specified in the "specification" section 5247 that limit the values of constants for which values are defined here. 5248 This allows implementations to make assumptions about the maximum 5249 values that will be received for these constants. Implementation 5250 receiving values outside the range specified in the "specification" 5251 section MAY reject the request, but they MUST recover cleanly. 5253 7.5.1. Key usage numbers 5254 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 5256 The encryption and checksum specifications in [@KCRYPTO] require as 5257 input a "key usage number", to alter the encryption key used in any 5258 specific message, to make certain types of cryptographic attack more 5259 difficult. These are the key usage values assigned in this document: 5261 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted 5262 with the client key (section 5.2.7.2) 5263 2. AS-REP Ticket and TGS-REP Ticket (includes TGS session 5264 key or application session key), encrypted with the 5265 service key (section 5.3) 5266 3. AS-REP encrypted part (includes TGS session key or 5267 application session key), encrypted with the client key 5268 (section 5.4.2) 5269 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with 5270 the TGS session key (section 5.4.1) 5271 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with 5272 the TGS authenticator subkey (section 5.4.1) 5273 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, 5274 keyed with the TGS session key (sections 5.5.1) 5275 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator 5276 (includes TGS authenticator subkey), encrypted with the 5277 TGS session key (section 5.5.1) 5278 8. TGS-REP encrypted part (includes application session 5279 key), encrypted with the TGS session key (section 5280 5.4.2) 5281 9. TGS-REP encrypted part (includes application session 5282 key), encrypted with the TGS authenticator subkey 5283 (section 5.4.2) 5284 10. AP-REQ Authenticator cksum, keyed with the application 5285 session key (section 5.5.1) 5286 11. AP-REQ Authenticator (includes application 5287 authenticator subkey), encrypted with the application 5288 session key (section 5.5.1) 5289 12. AP-REP encrypted part (includes application session 5290 subkey), encrypted with the application session key 5291 (section 5.5.2) 5292 13. KRB-PRIV encrypted part, encrypted with a key chosen by 5293 the application (section 5.7.1) 5294 14. KRB-CRED encrypted part, encrypted with a key chosen by 5295 the application (section 5.8.1) 5296 15. KRB-SAFE cksum, keyed with a key chosen by the 5297 application (section 5.6.1) 5298 19. AD-KDC-ISSUED checksum (ad-checksum in 5.2.6.4) 5299 22-25. Reserved for use in GSSAPI mechanisms derived from RFC 5300 1964. (raeburn/MIT) 5301 16-18,20-21,26-511. Reserved for future use in Kerberos and related 5302 protocols. 5303 512-1023. Reserved for uses internal to a Kerberos 5304 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 5306 implementation. 5307 1024. Encryption for application use in protocols that 5308 do not specify key usage values 5309 1025. Checksums for application use in protocols that 5310 do not specify key usage values 5311 1026-2047. Reserved for application use. 5313 7.5.2. PreAuthentication Data Types 5315 padata and data types padata-type value comment 5317 PA-TGS-REQ 1 5318 PA-ENC-TIMESTAMP 2 5319 PA-PW-SALT 3 5320 [reserved] 4 5321 PA-ENC-UNIX-TIME 5 (deprecated) 5322 PA-SANDIA-SECUREID 6 5323 PA-SESAME 7 5324 PA-OSF-DCE 8 5325 PA-CYBERSAFE-SECUREID 9 5326 PA-AFS3-SALT 10 5327 PA-ETYPE-INFO 11 5328 PA-SAM-CHALLENGE 12 (sam/otp) 5329 PA-SAM-RESPONSE 13 (sam/otp) 5330 PA-PK-AS-REQ 14 (pkinit) 5331 PA-PK-AS-REP 15 (pkinit) 5332 PA-ETYPE-INFO2 19 (replaces pa-etype-info) 5333 PA-USE-SPECIFIED-KVNO 20 5334 PA-SAM-REDIRECT 21 (sam/otp) 5335 PA-GET-FROM-TYPED-DATA 22 (embedded in typed data) 5336 TD-PADATA 22 (embeds padata) 5337 PA-SAM-ETYPE-INFO 23 (sam/otp) 5338 PA-ALT-PRINC 24 (crawdad@fnal.gov) 5339 PA-SAM-CHALLENGE2 30 (kenh@pobox.com) 5340 PA-SAM-RESPONSE2 31 (kenh@pobox.com) 5341 PA-EXTRA-TGT 41 Reserved extra TGT 5342 TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS 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 5353 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 5355 Address type value 5357 IPv4 2 5358 Directional 3 5359 ChaosNet 5 5360 XNS 6 5361 ISO 7 5362 DECNET Phase IV 12 5363 AppleTalk DDP 16 5364 NetBios 20 5365 IPv6 24 5367 7.5.4. Authorization Data Types 5369 authorization data type ad-type value 5370 AD-IF-RELEVANT 1 5371 AD-INTENDED-FOR-SERVER 2 5372 AD-INTENDED-FOR-APPLICATION-CLASS 3 5373 AD-KDC-ISSUED 4 5374 AD-AND-OR 5 5375 AD-MANDATORY-TICKET-EXTENSIONS 6 5376 AD-IN-TICKET-EXTENSIONS 7 5377 AD-MANDATORY-FOR-KDC 8 5378 reserved values 9-63 5379 OSF-DCE 64 5380 SESAME 65 5381 AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com) 5382 AD-WIN2K-PAC 128 (jbrezak@exchange.microsoft.com) 5384 7.5.5. Transited Encoding Types 5386 transited encoding type tr-type value 5387 DOMAIN-X500-COMPRESS 1 5388 reserved values all others 5390 7.5.6. Protocol Version Number 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 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 5405 KRB_TGS_REP 13 Response to KRB_TGS_REQ request 5406 KRB_AP_REQ 14 application request to server 5407 KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL 5408 KRB_RESERVED16 16 Reserved for user-to-user krb_tgt_request 5409 KRB_RESERVED17 17 Reserved for user-to-user krb_tgt_reply 5410 KRB_SAFE 20 Safe (checksummed) application message 5411 KRB_PRIV 21 Private (encrypted) application message 5412 KRB_CRED 22 Private (encrypted) message to forward credentials 5413 KRB_ERROR 30 Error response 5415 7.5.8. Name Types 5417 name types 5419 KRB_NT_UNKNOWN 0 Name type not known 5420 KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users 5421 KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) 5422 KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands) 5423 KRB_NT_SRV_XHST 4 Service with host as remaining components 5424 KRB_NT_UID 5 Unique ID 5425 KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253] 5426 KRB_NT_SMTP_NAME 7 Name in form of SMTP email name (e.g. user@foo.com) 5427 KRB_NT_ENTERPRISE 10 Enterprise name - may be mapped to principal name 5429 7.5.9. Error Codes 5431 error codes 5433 KDC_ERR_NONE 0 No error 5434 KDC_ERR_NAME_EXP 1 Client's entry in database has expired 5435 KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired 5436 KDC_ERR_BAD_PVNO 3 Requested protocol version number 5437 not supported 5438 KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key 5439 KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key 5440 KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database 5441 KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database 5442 KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database 5443 KDC_ERR_NULL_KEY 9 The client or server has a null key 5444 KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating 5445 KDC_ERR_NEVER_VALID 11 Requested start time is later than end time 5446 KDC_ERR_POLICY 12 KDC policy rejects request 5447 KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option 5448 KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type 5449 KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type 5450 KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type 5451 KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type 5452 KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked 5453 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 5455 KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked 5456 KDC_ERR_TGT_REVOKED 20 TGT has been revoked 5457 KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later 5458 KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later 5459 KDC_ERR_KEY_EXPIRED 23 Password has expired 5460 - change password to reset 5461 KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid 5462 KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired 5463 KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match 5464 KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user only 5465 KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path 5466 KDC_ERR_SVC_UNAVAILABLE 29 A service is not available 5467 KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed 5468 KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired 5469 KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid 5470 KRB_AP_ERR_REPEAT 34 Request is a replay 5471 KRB_AP_ERR_NOT_US 35 The ticket isn't for us 5472 KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match 5473 KRB_AP_ERR_SKEW 37 Clock skew too great 5474 KRB_AP_ERR_BADADDR 38 Incorrect net address 5475 KRB_AP_ERR_BADVERSION 39 Protocol version mismatch 5476 KRB_AP_ERR_MSG_TYPE 40 Invalid msg type 5477 KRB_AP_ERR_MODIFIED 41 Message stream modified 5478 KRB_AP_ERR_BADORDER 42 Message out of order 5479 KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available 5480 KRB_AP_ERR_NOKEY 45 Service key not available 5481 KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed 5482 KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction 5483 KRB_AP_ERR_METHOD 48 Alternative authentication method required 5484 KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message 5485 KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message 5486 KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path 5487 KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP, retry with TCP 5488 KRB_ERR_GENERIC 60 Generic error (description in e-text) 5489 KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation 5490 KDC_ERROR_CLIENT_NOT_TRUSTED 62 Reserved for PKINIT 5491 KDC_ERROR_KDC_NOT_TRUSTED 63 Reserved for PKINIT 5492 KDC_ERROR_INVALID_SIG 64 Reserved for PKINIT 5493 KDC_ERR_KEY_TOO_WEAK 65 Reserved for PKINIT 5494 KDC_ERR_CERTIFICATE_MISMATCH 66 Reserved for PKINIT 5495 KRB_AP_ERR_NO_TGT 67 No TGT available to validate USER-TO-USER 5496 KDC_ERR_WRONG_REALM 68 USER-TO-USER TGT issued different KDC 5497 KRB_AP_ERR_USER_TO_USER_REQUIRED 69 Ticket must be for USER-TO-USER 5498 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 Reserved for PKINIT 5499 KDC_ERR_INVALID_CERTIFICATE 71 Reserved for PKINIT 5500 KDC_ERR_REVOKED_CERTIFICATE 72 Reserved for PKINIT 5501 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 Reserved for PKINIT 5502 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 Reserved for PKINIT 5503 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 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 Encryption: AES256-CTS-HMAC-SHA1-96 5543 Checksums: HMAC-SHA1-96-AES256 5545 Implementations SHOULD support other mechanisms as well, but the 5546 additional mechanisms may only be used when communicating with 5547 principals known to also support them. The mechanisms that SHOULD 5548 be supported are: 5550 Encryption: DES-CBC-MD5, DES3-CBC-SHA1-KD 5551 Checksums: DES-MD5, HMAC-SHA1-DES3-KD 5552 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 5554 Implementations MAY support other mechanisms as well, but the 5555 additional mechanisms may only be used when communicating with 5556 principals known to also support them. 5558 Implementation note: earlier implementations of Kerberos generate 5559 messages using the CRC-32, RSA-MD5 checksum methods. For 5560 interoperability with these earlier releases implementors MAY 5561 consider supporting these checksum methods but should carefully 5562 analyze the security impplications to limit the situations within 5563 which these methods are accepted. 5565 Realm Names 5567 All implementations MUST understand hierarchical realms in both 5568 the Internet Domain and the X.500 style. When a ticket-granting 5569 ticket for an unknown realm is requested, the KDC MUST be able to 5570 determine the names of the intermediate realms between the KDCs 5571 realm and the requested realm. 5573 Transited field encoding 5575 DOMAIN-X500-COMPRESS (described in section 3.3.3.2) MUST be 5576 supported. Alternative encodings MAY be supported, but they may 5577 be used only when that encoding is supported by ALL intermediate 5578 realms. 5580 Pre-authentication methods 5582 The TGS-REQ method MUST be supported. The TGS-REQ method is not 5583 used on the initial request. The PA-ENC-TIMESTAMP method MUST be 5584 supported by clients but whether it is enabled by default MAY be 5585 determined on a realm by realm basis. If not used in the initial 5586 request and the error KDC_ERR_PREAUTH_REQUIRED is returned 5587 specifying PA-ENC-TIMESTAMP as an acceptable method, the client 5588 SHOULD retry the initial request using the PA-ENC-TIMESTAMP pre- 5589 authentication method. Servers need not support the PA-ENC- 5590 TIMESTAMP method, but if not supported the server SHOULD ignore 5591 the presence of PA-ENC-TIMESTAMP pre-authentication in a request. 5593 The ETYPE-INFO2 method MUST be supported; this method is used to 5594 communicate the set of supported encryption types, and 5595 corresponding salt and string to key paramters. The ETYPE-INFO 5596 method SHOULD be supported for interoperability with older 5597 implementation. 5599 Mutual authentication 5601 Mutual authentication (via the KRB_AP_REP message) MUST be 5602 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 5604 supported. 5606 Ticket addresses and flags 5608 All KDCs MUST pass through tickets that carry no addresses (i.e. 5609 if a TGT contains no addresses, the KDC will return derivative 5610 tickets). Implementations SHOULD default to requesting 5611 addressless tickets as this significantly increases 5612 interoperability with network address translation. In some cases 5613 realms or application servers MAY require that tickets have an 5614 address. 5616 Implementations SHOULD accept directional address type for the 5617 KRB_SAFE and KRB_PRIV message and SHOULD include directional 5618 addresses in these messages when other address types are not 5619 available. 5621 Proxies and forwarded tickets MUST be supported. Individual realms 5622 and application servers can set their own policy on when such 5623 tickets will be accepted. 5625 All implementations MUST recognize renewable and postdated 5626 tickets, but need not actually implement them. If these options 5627 are not supported, the starttime and endtime in the ticket shall 5628 specify a ticket's entire useful life. When a postdated ticket is 5629 decoded by a server, all implementations shall make the presence 5630 of the postdated flag visible to the calling server. 5632 User-to-user authentication 5634 Support for user-to-user authentication (via the ENC-TKT-IN-SKEY 5635 KDC option) MUST be provided by implementations, but individual 5636 realms MAY decide as a matter of policy to reject such requests on 5637 a per-principal or realm-wide basis. 5639 Authorization data 5641 Implementations MUST pass all authorization data subfields from 5642 ticket-granting tickets to any derivative tickets unless directed 5643 to suppress a subfield as part of the definition of that 5644 registered subfield type (it is never incorrect to pass on a 5645 subfield, and no registered subfield types presently specify 5646 suppression at the KDC). 5648 Implementations MUST make the contents of any authorization data 5649 subfields available to the server when a ticket is used. 5650 Implementations are not required to allow clients to specify the 5651 contents of the authorization data fields. 5653 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 5655 Constant ranges 5657 All protocol constants are constrained to 32 bit (signed) values 5658 unless further constrained by the protocol definition. This limit 5659 is provided to allow implementations to make assumptions about the 5660 maximum values that will be received for these constants. 5661 Implementation receiving values outside this range MAY reject the 5662 request, but they MUST recover cleanly. 5664 8.2. Recommended KDC values 5666 Following is a list of recommended values for a KDC configuration. 5668 minimum lifetime 5 minutes 5669 maximum renewable lifetime 1 week 5670 maximum ticket lifetime 1 day 5671 acceptable clock skew 5 minutes 5672 empty addresses Allowed. 5673 proxiable, etc. Allowed. 5675 9. IANA considerations 5677 Section 7 of this document specifies protocol constants and other 5678 defined values required for the interoperability of multiple 5679 implementations. Until otherwise specified in a subsequent RFC, or 5680 upon disbanding of the Kerberos working group, allocations of 5681 additional protocol constants and other defined values required for 5682 extensions to the Kerberos protocol will be administered by the 5683 kerberos working group. Following the recomendations outlined in 5684 [RFC 2434], guidance is provided to the IANA as follows: 5686 "reserved" realm name types in section 6.1 and "other" realm types 5687 except those beginning with "X-" or "x-" will not be registered 5688 without IETF standards action, at which point guidlines for further 5689 assignment will be specified. Realm name types beginning with "X-" 5690 or "x-" are for private use. 5692 For host address types described in section 7.1, negative values are 5693 for private use. Assignment of additional positive numbers is 5694 subject to review by the kerberos working group or other expert 5695 review. 5697 Additional key usage numbers as defined in section 7.5.1 will be 5698 assigned subject to review by the kerberos working group or other 5699 expert review. 5701 Additional preauthentciation data type values as defined in section 5702 7.5.2 will be assigned subject to review by the kerberos working 5703 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 5705 group or other expert review. 5707 Additional Authorization Data Types as defined in section 7.5.4 will 5708 be assigned subject to review by the kerberos working group or other 5709 expert review. Although it is anticipated that there may be 5710 significant demand for private use types, provision is intentionaly 5711 not made for a private use portion of the namespace because conficts 5712 between privately assigned values coule have detrimental security 5713 implications. 5715 Additional Transited Encoding Types as defined in section 7.5.5 5716 present special concerns for interoperability with existing 5717 implementations. As such, such assignments will only be made by 5718 standards action, except that the Kerberos working group or another 5719 other working group with competent jurisdiction may make preliminary 5720 assignments for documents which are moving through the standards 5721 process. 5723 Additional Kerberos Message Types as described in section 7.5.7 will 5724 be assigned subject to review by the kerberos working group or other 5725 expert review. 5727 Additional Name Types as described in section 7.5.8 will be assigned 5728 subject to review by the kerberos working group or other expert 5729 review. 5731 Additional error codes described in section 7.5.9 will be assigned 5732 subject to review by the kerberos working group or other expert 5733 review. 5735 10. Security Considerations 5737 As an authentication service, Kerberos provides a means of verifying 5738 the identity of principals on a network. Kerberos does not, by 5739 itself, provide authorization. Applications should not accept the 5740 issuance of a service ticket by the Kerberos server as granting 5741 authority to use the service, since such applications may become 5742 vulnerable to the bypass of this authorization check in an 5743 environment if they inter-operate with other KDCs or where other 5744 options for application authentication are provided. 5746 Denial of service attacks are not solved with Kerberos. There are 5747 places in the protocols where an intruder can prevent an application 5748 from participating in the proper authentication steps. Because 5749 authentication is a required step for the use of many services, 5750 successful denial of service attacks on a Kerberos server might 5751 result in the denial of other network services that rely on Kerberos 5752 for authentication. Kerberos is vulnerable to many kinds of denial of 5753 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 5755 service attacks: denial of service attacks on the network which would 5756 prevent clients from contacting the KDC; denial of service attacks on 5757 the domain name system which could prevent a client from finding the 5758 IP address of the Kerberos server; and denial of service attack by 5759 overloading the Kerberos KDC itself with repeated requests. 5761 Interoperability conflicts caused by incompatible character-set usage 5762 (see 5.2.1) can result in denial of service for clients that utilize 5763 character-sets in Kerberos strings other than those stored in the KDC 5764 database. 5766 Authentication servers maintain a database of principals (i.e., users 5767 and servers) and their secret keys. The security of the 5768 authentication server machines is critical. The breach of security of 5769 an authentication server will compromise the security of all servers 5770 that rely upon the compromised KDC, and will compromise the 5771 authentication of any principals registered in the realm of the 5772 compromised KDC. 5774 Principals must keep their secret keys secret. If an intruder somehow 5775 steals a principal's key, it will be able to masquerade as that 5776 principal or impersonate any server to the legitimate principal. 5778 Password guessing attacks are not solved by Kerberos. If a user 5779 chooses a poor password, it is possible for an attacker to 5780 successfully mount an off-line dictionary attack by repeatedly 5781 attempting to decrypt, with successive entries from a dictionary, 5782 messages obtained which are encrypted under a key derived from the 5783 user's password. 5785 Unless pre-authentication options are required by the policy of a 5786 realm, the KDC will not know whether a request for authentication 5787 succeeds. An attacker can request a reply with credentials for any 5788 principal. These credentials will likely not be of much use to the 5789 attacker unless it knows the client's secret key, but the 5790 availability of the response encrypted in the client's secret key 5791 provides the attacker with ciphertext that may be used to mount brute 5792 force or dictionary attacks to decrypt the credentials, by guessing 5793 the user's password. For this reason it is strongly encouraged that 5794 Kerberos realms require the use of pre-authentication. Even with pre- 5795 authentication, attackers may try brute force or dictionary attacks 5796 against credentials that are observed by eavesdropping on the 5797 network. 5799 Because a client can request a ticket for any server principal and 5800 can attempt a brute force or dictionary attack against the server 5801 principal's key using that ticket, it is strongly encouraged that 5802 keys be randomly generated (rather than generated from passwords) for 5803 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 5805 any principals that are usable as the target principal for a 5806 KRB_TGS_REQ or KRB_AS_REQ messages. [RFC1750] 5808 Although the DES-CBC-MD5 encryption method and DES-MD5 checksum 5809 methods are listed as SHOULD be implemented for backward 5810 compatibility, the single DES encryption algorithm on which these are 5811 based is weak and stronger algorithms should be used whenever 5812 possible. 5814 Each host on the network must have a clock which is loosely 5815 synchronized to the time of the other hosts; this synchronization is 5816 used to reduce the bookkeeping needs of application servers when they 5817 do replay detection. The degree of "looseness" can be configured on a 5818 per-server basis, but is typically on the order of 5 minutes. If the 5819 clocks are synchronized over the network, the clock synchronization 5820 protocol MUST itself be secured from network attackers. 5822 Principal identifiers must not recycled on a short-term basis. A 5823 typical mode of access control will use access control lists (ACLs) 5824 to grant permissions to particular principals. If a stale ACL entry 5825 remains for a deleted principal and the principal identifier is 5826 reused, the new principal will inherit rights specified in the stale 5827 ACL entry. By not reusing principal identifiers, the danger of 5828 inadvertent access is removed. 5830 Proper decryption of an KRB_AS_REP message from the KDC is not 5831 sufficient for the host to verify the identity of the user; the user 5832 and an attacker could cooperate to generate a KRB_AS_REP format 5833 message which decrypts properly but is not from the proper KDC. To 5834 authenticate a user logging on to a local system, the credentials 5835 obtained in the AS exchange may first be used in a TGS exchange to 5836 obtain credentials for a local server. Those credentials must then be 5837 verified by a local server through successful completion of the 5838 Client/Server exchange. 5840 Many RFC 1510 compliant implementations ignore unknown authorization 5841 data elements. Depending on these implementations to honor 5842 authorization data restrictions may create a security weakness. 5844 Kerberos credentials contain clear-text information identifying the 5845 principals to which they apply. If privacy of this information is 5846 needed, this exchange should itself be encapsulated in a protocol 5847 providing for confidentiality on the exchange of these credentials. 5849 Applications must take care to protect communications subsequent to 5850 authentication either by using the KRB_PRIV or KRB_SAFE messages as 5851 appropriate, or by applying their own confidentiality or integrity 5852 mechanisms on such communications. Completion of the KRB_AP_REQ and 5853 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 5855 KRB_AP_REP exchange without subsequent use of confidentiality and 5856 integrity mechanisms provides only for authentication of the parties 5857 to the communication and not confidentiality and integrity of the 5858 subsequent communication. Application applying confidentiality and 5859 integrity protection mechanisms other than KRB_PRIV and KRB_SAFE must 5860 make sure that the authentication step is appropriately linked with 5861 the protected communication channel that is established by the 5862 application. 5864 Unless the application server provides its own suitable means to 5865 protect against replay (for example, a challenge-response sequence 5866 initiated by the server after authentication, or use of a server- 5867 generated encryption subkey), the server must utilize a replay cache 5868 to remember any authenticator presented within the allowable clock 5869 skew. All services sharing a key need to use the same replay cache. 5870 If separate replay caches are used, then and authenticator used with 5871 one such service could later be replayed to a different service with 5872 the same service principal. 5874 If a server loses track of authenticators presented within the 5875 allowable clock skew, it must reject all requests until the clock 5876 skew interval has passed, providing assurance that any lost or 5877 replayed authenticators will fall outside the allowable clock skew 5878 and can no longer be successfully replayed. 5880 Implementations of Kerberos should not use untrusted directory 5881 servers to determine the realm of a host. To allow such would allow 5882 the compromise of the directory server to enable an attacker to 5883 direct the client to accept authentication with the wrong principal 5884 (i.e. one with a similar name, but in a realm with which the 5885 legitimate host was not registered). 5887 Implementations of Kerberos must not use DNS to map one name to 5888 another (canonicalize) to determine the host part of the principal 5889 name with which one is to communicate. To allow such 5890 canonicalization would allow a compromise of the DNS to result in a 5891 client obtaining credentials and correctly authenticating to the 5892 wrong principal. Though the client will know who it is communicating 5893 with, it will not be the principal with which it intended to 5894 communicate. 5896 If the Kerberos server returns a TGT for a 'closer' realm other than 5897 the desired realm, the client may use local policy configuration to 5898 verify that the authentication path used is an acceptable one. 5899 Alternatively, a client may choose its own authentication path, 5900 rather than relying on the Kerberos server to select one. In either 5901 case, any policy or configuration information used to choose or 5902 validate authentication paths, whether by the Kerberos server or 5903 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 5905 client, must be obtained from a trusted source. 5907 The Kerberos protocol in its basic form does not provide perfect 5908 forward secrecy for communications. If traffic has been recorded by 5909 an eavesdropper, then messages encrypted using the KRB_PRIV message, 5910 or messages encrypted using application specific encryption under 5911 keys exchanged using Kerberos can be decrypted if any of the user's, 5912 application server's, or KDC's key is subsequently discovered. This 5913 is because the session key use to encrypt such messages is 5914 transmitted over the network encrypted in the key of the application 5915 server, and also encrypted under the session key from the user's 5916 ticket-granting ticket when returned to the user in the KRB_TGS_REP 5917 message. The session key from the ticket-granting ticket was sent to 5918 the user in the KRB_AS_REP message encrypted in the user's secret 5919 key, and embedded in the ticket-granting ticket, which was encrypted 5920 in the key of the KDC. Application requiring perfect forward secrecy 5921 must exchange keys through mechanisms that provide such assurance, 5922 but may use Kerberos for authentication of the encrypted channel 5923 established through such other means. 5925 11. Author's Addresses 5927 Clifford Neuman 5928 Information Sciences Institute 5929 University of Southern California 5930 4676 Admiralty Way 5931 Marina del Rey, CA 90292, USA 5932 Email: bcn@isi.edu 5934 Tom Yu 5935 Massachusetts Institute of Technology 5936 77 Massachusetts Avenue 5937 Cambridge, MA 02139, USA 5938 Email: tlyu@mit.edu 5940 Sam Hartman 5941 Massachusetts Institute of Technology 5942 77 Massachusetts Avenue 5943 Cambridge, MA 02139, USA 5944 Email: hartmans@mit.edu 5946 Kenneth Raeburn 5947 Massachusetts Institute of Technology 5948 77 Massachusetts Avenue 5949 Cambridge, MA 02139, USA 5950 Email: raeburn@MIT.EDU 5951 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 5953 12. Acknowledgements 5955 This document is a revision to RFC1510 which was co-authored with 5956 John Kohl. The specification of the Kerberos protocol described in 5957 this document is the result of many years of effort. Over this 5958 period many individuals have contributed to the definition of the 5959 protocol and to the writing of the specification. Unfortunately it is 5960 not possible to list all contributors as authors of this document, 5961 though there are many not listed who are authors in spirit, because 5962 they contributed text for parts of some sections, because they 5963 contributed to the design of parts of the protocol, or because they 5964 contributed significantly to the discussion of the protocol in the 5965 IETF common authentication technology (CAT) and Kerberos working 5966 groups. 5968 Among those contributing to the development and specification of 5969 Kerberos were Jeffrey Altman, John Brezak, Marc Colan, Johan 5970 Danielsson, Don Davis, Doug Engert, Dan Geer, Paul Hill, John Kohl, 5971 Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John Linn, 5972 Ari Medvinsky, Sasha Medvinsky, Steve Miller, Jon Rochlis, Jerome 5973 Saltzer, Jeffrey Schiller, Jennifer Steiner, Ralph Swick, Mike Swift, 5974 Jonathan Trostle, Theodore Ts'o, Brian Tung, Jacques Vidrine, Assar 5975 Westerlund, and Nicolas Williams. Many other members of MIT Project 5976 Athena, the MIT networking group, and the Kerberos and CAT working 5977 groups of the IETF contributed but are not listed. 5979 Funding for the RFC Editor function is currently provided by the 5980 Internet Society. 5982 13. REFERENCES 5984 13.1 NORMATIVE REFERENCES 5986 [@KCRYPTO] 5987 RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg- 5988 crypto. 5990 [@AES] 5991 RFC-Editor: To be replaced by RFC number for draft-raeburn0krb- 5992 rijndael-krb. 5994 [ISO-646/ECMA-6] 5995 7-bit Coded Character Set 5997 [ISO-2022/ECMA-35] 5998 Character Code Structure and Extension Techniques 6000 [RFC1035] 6001 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 6003 P.V. Mockapetris, RFC1035: "Domain Names - Implementations and 6004 Specification," November 1, 1987, Obsoletes - RFC973, RFC882, 6005 RFC883. Updated by RFC1101, RFC1183, RFC1348, RFCRFC1876, RFC1982, 6006 RFC1995, RFC1996, RFC2065, RFC2136, RFC2137, RFC2181, RFC2308, 6007 RFC2535, RFC2845, and RFC3425. Status: Standard. 6009 [RFC2119] 6011 S. Bradner, RFC2119: "Key words for use in RFC's to Indicate 6012 Requirement Levels", March 1997. 6014 [RFC2434] 6015 T. Narten, H. Alvestrand, RFC2434: "Guidelines for writing IANA 6016 Consideration Secionts in RFCs" October, 1998. 6018 [RFC2782] 6019 A. Gulbrandsen, P. Vixie and L. Esibov., RFC2782: "A DNS RR for 6020 Specifying the Location of Services (DNS SRV)," February 2000. 6022 [RFC2253] 6023 M. Wahl, S. Killie, and T. Howes, RFC2253: "Lightweight Directory 6024 Access Protocol (v3): UTF-8 String Representation or Distinguished 6025 Names," December 1997, Obsoletes - RFC1779, Updated by RFC3377, 6026 Status: Proposed Standard. 6028 [RFC2373] 6029 R. Hinden, S. Deering, RFC2373: "IP Version 6 Addressing 6030 Architecture," July 1998, Status: Proposed Standard. 6032 [X680] 6033 Abstract Syntax Notation One (ASN.1): Specification of Basic 6034 Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC 6035 International Standard 8824-1:1998. 6037 [X690] 6038 ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), 6039 Canonical Encoding Rules (CER) and Distinguished Encoding Rules 6040 (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International 6041 Standard 8825-1:1998. 6043 13.2 INFORMATIVE REFERENCES 6045 [DGT96] 6046 Don Davis, Daniel Geer, and Theodore Ts'o, "Kerberos With Clocks 6047 Adrift: History, Protocols, and Implementation", USENIX Computing 6048 Systems 9:1 (January 1996). 6050 [DS81] 6051 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 6053 Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key 6054 Distribution Protocols," Communications of the ACM, Vol. 24(8), 6055 pp. 533-536 (August 1981). 6057 [KNT94] 6059 John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The 6060 Evolution of the Kerberos Authentication System". In Distributed 6061 Open Systems, pages 78-94. IEEE Computer Society Press, 1994. 6063 [MNSS87] 6064 S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer, 6065 Section E.2.1: Kerberos Authentication and Authorization System, 6066 M.I.T. Project Athena, Cambridge, Massachusetts (December 21, 6067 1987). 6069 [NS78] 6070 Roger M. Needham and Michael D. Schroeder, "Using Encryption for 6071 Authentication in Large Networks of Computers," Communications of 6072 the ACM, Vol. 21(12), pp. 993-999 (December, 1978). 6074 [Neu93] 6075 B. Clifford Neuman, "Proxy-Based Authorization and Accounting for 6076 Distributed Systems," in Proceedings of the 13th International 6077 Conference on Distributed Computing Systems, Pittsburgh, PA (May, 6078 1993). 6080 [NT94] 6081 B. Clifford Neuman and Theodore Y. Ts'o, "An Authentication 6082 Service for Computer Networks," IEEE Communications Magazine, Vol. 6083 32(9), pp. 33-38 (September 1994). 6085 [Pat92]. 6086 J. Pato, Using Pre-Authentication to Avoid Password Guessing 6087 Attacks, Open Software Foundation DCE Request for Comments 26 6088 (December 1992). 6090 [RFC1510] 6091 J. Kohl and B. C. Neuman, RFC1510: "The Kerberos Network 6092 Authentication Service (v5)," September 1993, Status: Proposed 6093 Standard. 6095 [RFC1750] 6096 D. Eastlake, S. Crocker, and J. Schiller "Randomness 6097 Recommendation for Security" December 1994, Status: Informational. 6099 [RFC2026] 6100 S. Bradner, RFC2026: "The Internet Standard Process - Revision 6101 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 6103 3," October 1996, Obsoletes - RFC 1602, Status: Best Current 6104 Practice. 6106 [SNS88] 6107 J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Kerberos: An 6108 Authentication Service for Open Network Systems," pp. 191-202 in 6109 Usenix Conference Proceedings, Dallas, Texas (February, 1988). 6111 14. Copyright Statement 6113 Copyright (C) The Internet Society (2004). This document is 6114 subject to the rights, licenses and restrictions contained in BCP 6115 78 and except as set forth therein, the authors retain all their 6116 rights. 6118 This document and the information contained herein are provided on 6119 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 6120 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 6121 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 6122 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 6123 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 6124 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 6125 PARTICULAR PURPOSE. 6127 15. Intellectual Property 6129 The IETF takes no position regarding the validity or scope of any 6130 Intellectual Property Rights or other rights that might be claimed 6131 to pertain to the implementation or use of the technology 6132 described in this document or the extent to which any license 6133 under such rights might or might not be available; nor does it 6134 represent that it has made any independent effort to identify any 6135 such rights. Information on the procedures with respect to rights 6136 in RFC documents can be found in BCP 78 and BCP 79. 6138 Copies of IPR disclosures made to the IETF Secretariat and any 6139 assurances of licenses to be made available, or the result of an 6140 attempt made to obtain a general license or permission for the use 6141 of such proprietary rights by implementers or users of this 6142 specification can be obtained from the IETF on-line IPR repository 6143 at http://www.ietf.org/ipr. 6145 The IETF invites any interested party to bring to its attention 6146 any copyrights, patents or patent applications, or other 6147 proprietary rights that may cover technology that may be required 6148 to implement this standard. Please address the information to the 6149 IETF at ietf-ipr@ietf.org. 6151 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 6153 A. ASN.1 module 6155 KerberosV5Spec2 { 6156 iso(1) identified-organization(3) dod(6) internet(1) 6157 security(5) kerberosV5(2) modules(4) krb5spec2(2) 6158 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 6160 -- OID arc for KerberosV5 6161 -- 6162 -- This OID may be used to identify Kerberos protocol messages 6163 -- encapsulated in other protocols. 6164 -- 6165 -- This OID also designates the OID arc for KerberosV5-related OIDs. 6166 -- 6167 -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its OID. 6168 id-krb5 OBJECT IDENTIFIER ::= { 6169 iso(1) identified-organization(3) dod(6) internet(1) 6170 security(5) kerberosV5(2) 6171 } 6173 Int32 ::= INTEGER (-2147483648..2147483647) 6174 -- signed values representable in 32 bits 6176 UInt32 ::= INTEGER (0..4294967295) 6177 -- unsigned 32 bit values 6179 Microseconds ::= INTEGER (0..999999) 6180 -- microseconds 6182 KerberosString ::= GeneralString (IA5String) 6184 Realm ::= KerberosString 6186 PrincipalName ::= SEQUENCE { 6187 name-type [0] Int32, 6188 name-string [1] SEQUENCE OF KerberosString 6189 } 6191 KerberosTime ::= GeneralizedTime -- with no fractional seconds 6193 HostAddress ::= SEQUENCE { 6194 addr-type [0] Int32, 6195 address [1] OCTET STRING 6196 } 6198 -- NOTE: HostAddresses is always used as an OPTIONAL field and 6199 -- should not be empty. 6200 HostAddresses -- NOTE: subtly different from rfc1510, 6201 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 6203 -- but has a value mapping and encodes the same 6204 ::= SEQUENCE OF HostAddress 6206 -- NOTE: AuthorizationData is always used as an OPTIONAL field and 6207 -- should not be empty. 6208 AuthorizationData ::= SEQUENCE OF SEQUENCE { 6209 ad-type [0] Int32, 6210 ad-data [1] OCTET STRING 6211 } 6213 PA-DATA ::= SEQUENCE { 6214 -- NOTE: first tag is [1], not [0] 6215 padata-type [1] Int32, 6216 padata-value [2] OCTET STRING -- might be encoded AP-REQ 6217 } 6219 KerberosFlags ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits 6220 -- shall be sent, but no fewer than 32 6222 EncryptedData ::= SEQUENCE { 6223 etype [0] Int32 -- EncryptionType --, 6224 kvno [1] UInt32 OPTIONAL, 6225 cipher [2] OCTET STRING -- ciphertext 6226 } 6228 EncryptionKey ::= SEQUENCE { 6229 keytype [0] Int32 -- actually encryption type --, 6230 keyvalue [1] OCTET STRING 6231 } 6233 Checksum ::= SEQUENCE { 6234 cksumtype [0] Int32, 6235 checksum [1] OCTET STRING 6236 } 6238 Ticket ::= [APPLICATION 1] SEQUENCE { 6239 tkt-vno [0] INTEGER (5), 6240 realm [1] Realm, 6241 sname [2] PrincipalName, 6242 enc-part [3] EncryptedData -- EncTicketPart 6243 } 6245 -- Encrypted part of ticket 6246 EncTicketPart ::= [APPLICATION 3] SEQUENCE { 6247 flags [0] TicketFlags, 6248 key [1] EncryptionKey, 6249 crealm [2] Realm, 6250 cname [3] PrincipalName, 6251 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 6253 transited [4] TransitedEncoding, 6254 authtime [5] KerberosTime, 6255 starttime [6] KerberosTime OPTIONAL, 6256 endtime [7] KerberosTime, 6257 renew-till [8] KerberosTime OPTIONAL, 6258 caddr [9] HostAddresses OPTIONAL, 6259 authorization-data [10] AuthorizationData OPTIONAL 6260 } 6262 -- encoded Transited field 6263 TransitedEncoding ::= SEQUENCE { 6264 tr-type [0] Int32 -- must be registered --, 6265 contents [1] OCTET STRING 6266 } 6268 TicketFlags ::= KerberosFlags 6269 -- reserved(0), 6270 -- forwardable(1), 6271 -- forwarded(2), 6272 -- proxiable(3), 6273 -- proxy(4), 6274 -- may-postdate(5), 6275 -- postdated(6), 6276 -- invalid(7), 6277 -- renewable(8), 6278 -- initial(9), 6279 -- pre-authent(10), 6280 -- hw-authent(11), 6281 -- the following are new since 1510 6282 -- transited-policy-checked(12), 6283 -- ok-as-delegate(13) 6285 AS-REQ ::= [APPLICATION 10] KDC-REQ 6287 TGS-REQ ::= [APPLICATION 12] KDC-REQ 6289 KDC-REQ ::= SEQUENCE { 6290 -- NOTE: first tag is [1], not [0] 6291 pvno [1] INTEGER (5) , 6292 msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --), 6293 padata [3] SEQUENCE OF PA-DATA OPTIONAL 6294 -- NOTE: not empty --, 6295 req-body [4] KDC-REQ-BODY 6296 } 6298 KDC-REQ-BODY ::= SEQUENCE { 6299 kdc-options [0] KDCOptions, 6300 cname [1] PrincipalName OPTIONAL 6301 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 6303 -- Used only in AS-REQ --, 6304 realm [2] Realm 6305 -- Server's realm 6306 -- Also client's in AS-REQ --, 6307 sname [3] PrincipalName OPTIONAL, 6308 from [4] KerberosTime OPTIONAL, 6309 till [5] KerberosTime, 6310 rtime [6] KerberosTime OPTIONAL, 6311 nonce [7] UInt32, 6312 etype [8] SEQUENCE OF Int32 -- EncryptionType 6313 -- in preference order --, 6314 addresses [9] HostAddresses OPTIONAL, 6315 enc-authorization-data [10] EncryptedData OPTIONAL 6316 -- AuthorizationData --, 6317 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL 6318 -- NOTE: not empty 6319 } 6321 KDCOptions ::= KerberosFlags 6322 -- reserved(0), 6323 -- forwardable(1), 6324 -- forwarded(2), 6325 -- proxiable(3), 6326 -- proxy(4), 6327 -- allow-postdate(5), 6328 -- postdated(6), 6329 -- unused7(7), 6330 -- renewable(8), 6331 -- unused9(9), 6332 -- unused10(10), 6333 -- opt-hardware-auth(11), 6334 -- unused12(12), 6335 -- unused13(13), 6336 -- 15 is reserved for canonicalize 6337 -- unused15(15), 6338 -- 26 was unused in 1510 6339 -- disable-transited-check(26), 6340 -- 6341 -- renewable-ok(27), 6342 -- enc-tkt-in-skey(28), 6343 -- renew(30), 6344 -- validate(31) 6346 AS-REP ::= [APPLICATION 11] KDC-REP 6348 TGS-REP ::= [APPLICATION 13] KDC-REP 6350 KDC-REP ::= SEQUENCE { 6351 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 6353 pvno [0] INTEGER (5), 6354 msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --), 6355 padata [2] SEQUENCE OF PA-DATA OPTIONAL 6356 -- NOTE: not empty --, 6357 crealm [3] Realm, 6358 cname [4] PrincipalName, 6359 ticket [5] Ticket, 6360 enc-part [6] EncryptedData 6361 -- EncASRepPart or EncTGSRepPart, 6362 -- as appropriate 6363 } 6365 EncASRepPart ::= [APPLICATION 25] EncKDCRepPart 6367 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart 6369 EncKDCRepPart ::= SEQUENCE { 6370 key [0] EncryptionKey, 6371 last-req [1] LastReq, 6372 nonce [2] UInt32, 6373 key-expiration [3] KerberosTime OPTIONAL, 6374 flags [4] TicketFlags, 6375 authtime [5] KerberosTime, 6376 starttime [6] KerberosTime OPTIONAL, 6377 endtime [7] KerberosTime, 6378 renew-till [8] KerberosTime OPTIONAL, 6379 srealm [9] Realm, 6380 sname [10] PrincipalName, 6381 caddr [11] HostAddresses OPTIONAL 6382 } 6384 LastReq ::= SEQUENCE OF SEQUENCE { 6385 lr-type [0] Int32, 6386 lr-value [1] KerberosTime 6387 } 6389 AP-REQ ::= [APPLICATION 14] SEQUENCE { 6390 pvno [0] INTEGER (5), 6391 msg-type [1] INTEGER (14), 6392 ap-options [2] APOptions, 6393 ticket [3] Ticket, 6394 authenticator [4] EncryptedData -- Authenticator 6395 } 6397 APOptions ::= KerberosFlags 6398 -- reserved(0), 6399 -- use-session-key(1), 6400 -- mutual-required(2) 6401 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 6403 -- Unencrypted authenticator 6404 Authenticator ::= [APPLICATION 2] SEQUENCE { 6405 authenticator-vno [0] INTEGER (5), 6406 crealm [1] Realm, 6407 cname [2] PrincipalName, 6408 cksum [3] Checksum OPTIONAL, 6409 cusec [4] Microseconds, 6410 ctime [5] KerberosTime, 6411 subkey [6] EncryptionKey OPTIONAL, 6412 seq-number [7] UInt32 OPTIONAL, 6413 authorization-data [8] AuthorizationData OPTIONAL 6414 } 6416 AP-REP ::= [APPLICATION 15] SEQUENCE { 6417 pvno [0] INTEGER (5), 6418 msg-type [1] INTEGER (15), 6419 enc-part [2] EncryptedData -- EncAPRepPart 6420 } 6422 EncAPRepPart ::= [APPLICATION 27] SEQUENCE { 6423 ctime [0] KerberosTime, 6424 cusec [1] Microseconds, 6425 subkey [2] EncryptionKey OPTIONAL, 6426 seq-number [3] UInt32 OPTIONAL 6427 } 6429 KRB-SAFE ::= [APPLICATION 20] SEQUENCE { 6430 pvno [0] INTEGER (5), 6431 msg-type [1] INTEGER (20), 6432 safe-body [2] KRB-SAFE-BODY, 6433 cksum [3] Checksum 6434 } 6436 KRB-SAFE-BODY ::= SEQUENCE { 6437 user-data [0] OCTET STRING, 6438 timestamp [1] KerberosTime OPTIONAL, 6439 usec [2] Microseconds OPTIONAL, 6440 seq-number [3] UInt32 OPTIONAL, 6441 s-address [4] HostAddress, 6442 r-address [5] HostAddress OPTIONAL 6443 } 6445 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 6446 pvno [0] INTEGER (5), 6447 msg-type [1] INTEGER (21), 6448 -- NOTE: there is no [2] tag 6449 enc-part [3] EncryptedData -- EncKrbPrivPart 6450 } 6451 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 6453 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 6454 user-data [0] OCTET STRING, 6455 timestamp [1] KerberosTime OPTIONAL, 6456 usec [2] Microseconds OPTIONAL, 6457 seq-number [3] UInt32 OPTIONAL, 6458 s-address [4] HostAddress -- sender's addr --, 6459 r-address [5] HostAddress OPTIONAL -- recip's addr 6460 } 6462 KRB-CRED ::= [APPLICATION 22] SEQUENCE { 6463 pvno [0] INTEGER (5), 6464 msg-type [1] INTEGER (22), 6465 tickets [2] SEQUENCE OF Ticket, 6466 enc-part [3] EncryptedData -- EncKrbCredPart 6467 } 6469 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { 6470 ticket-info [0] SEQUENCE OF KrbCredInfo, 6471 nonce [1] UInt32 OPTIONAL, 6472 timestamp [2] KerberosTime OPTIONAL, 6473 usec [3] Microseconds OPTIONAL, 6474 s-address [4] HostAddress OPTIONAL, 6475 r-address [5] HostAddress OPTIONAL 6476 } 6478 KrbCredInfo ::= SEQUENCE { 6479 key [0] EncryptionKey, 6480 prealm [1] Realm OPTIONAL, 6481 pname [2] PrincipalName OPTIONAL, 6482 flags [3] TicketFlags OPTIONAL, 6483 authtime [4] KerberosTime OPTIONAL, 6484 starttime [5] KerberosTime OPTIONAL, 6485 endtime [6] KerberosTime OPTIONAL, 6486 renew-till [7] KerberosTime OPTIONAL, 6487 srealm [8] Realm OPTIONAL, 6488 sname [9] PrincipalName OPTIONAL, 6489 caddr [10] HostAddresses OPTIONAL 6490 } 6492 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 6493 pvno [0] INTEGER (5), 6494 msg-type [1] INTEGER (30), 6495 ctime [2] KerberosTime OPTIONAL, 6496 cusec [3] Microseconds OPTIONAL, 6497 stime [4] KerberosTime, 6498 susec [5] Microseconds, 6499 error-code [6] Int32, 6500 crealm [7] Realm OPTIONAL, 6501 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 6503 cname [8] PrincipalName OPTIONAL, 6504 realm [9] Realm -- service realm --, 6505 sname [10] PrincipalName -- service name --, 6506 e-text [11] KerberosString OPTIONAL, 6507 e-data [12] OCTET STRING OPTIONAL 6508 } 6510 METHOD-DATA ::= SEQUENCE OF PA-DATA 6512 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 6513 data-type [0] INTEGER, 6514 data-value [1] OCTET STRING OPTIONAL 6515 } 6517 -- preauth stuff follows 6519 PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC 6521 PA-ENC-TS-ENC ::= SEQUENCE { 6522 patimestamp [0] KerberosTime -- client's time --, 6523 pausec [1] Microseconds OPTIONAL 6524 } 6526 ETYPE-INFO-ENTRY ::= SEQUENCE { 6527 etype [0] Int32, 6528 salt [1] OCTET STRING OPTIONAL 6529 } 6531 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY 6533 ETYPE-INFO2-ENTRY ::= SEQUENCE { 6534 etype [0] Int32, 6535 salt [1] KerberosString OPTIONAL, 6536 s2kparams [2] OCTET STRING OPTIONAL 6537 } 6539 ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY 6541 AD-IF-RELEVANT ::= AuthorizationData 6543 AD-KDCIssued ::= SEQUENCE { 6544 ad-checksum [0] Checksum, 6545 i-realm [1] Realm OPTIONAL, 6546 i-sname [2] PrincipalName OPTIONAL, 6547 elements [3] AuthorizationData 6548 } 6550 AD-AND-OR ::= SEQUENCE { 6551 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 6553 condition-count [0] INTEGER, 6554 elements [1] AuthorizationData 6555 } 6557 AD-MANDATORY-FOR-KDC ::= AuthorizationData 6559 END 6561 B. Changes since RFC-1510 6563 This document replaces RFC-1510 and clarifies specification of items 6564 that were not completely specified. Where changes to recommended 6565 implementation choices were made, or where new options were added, 6566 those changes are described within the document and listed in this 6567 section. More significantly, "Specification 2" in section 8 changes 6568 the required encryption and checksum methods to bring them in line 6569 with the best current practices and to deprecate methods that are no 6570 longer considered sufficiently strong. 6572 Discussion was added to section 1 regarding the ability to rely on 6573 the KDC to check the transited field, and on the inclusion of a flag 6574 in a ticket indicating that this check has occurred. This is a new 6575 capability not present in RFC1510. Pre-existing implementations may 6576 ignore or not set this flag without negative security implications. 6578 The definition of the secret key says that in the case of a user the 6579 key may be derived from a password. In 1510, it said that the key was 6580 derived from the password. This change was made to accommodate 6581 situations where the user key might be stored on a smart-card, or 6582 otherwise obtained independent of a password. 6584 The introduction mentions the use of public key cryptography for 6585 initial authentication in Kerberos by reference. RFC1510 did not 6586 include such a reference. 6588 Section 1.2 was added to explain that while Kerberos provides 6589 authentication of a named principal, it is still the responsibility 6590 of the application to ensure that the authenticated name is the 6591 entity with which the application wishes to communicate. 6593 Discussion of extensibility has been added to the introduction. 6595 Discussion of how extensibility affects ticket flags and KDC options 6596 was added to the introduction of section 2. No changes were made to 6597 existing options and flags specified in RFC1510, though some of the 6598 sections in the specification were renumbered, and text was revised 6599 to make the description and intent of existing options clearer, 6600 especially with respect to the ENC-TKT-IN-SKEY option (now section 6601 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 6603 2.9.2) which is used for user-to-user authentication. The new option 6604 and ticket flag transited policy checking (section 2.7) was added. 6606 A warning regarding generation of session keys for application use 6607 was added to section 3, urging the inclusion of key entropy from the 6608 KDC generated session key in the ticket. An example regarding use of 6609 the sub-session key was added to section 3.2.6. Descriptions of the 6610 pa-etype-info, pa-etype-info2, and pa-pw-salt pre-authentication data 6611 items were added. The recommendation for use of pre-authentication 6612 was changed from "may" to "should" and a note was added regarding 6613 known plaintext attacks. 6615 In RFC 1510, section 4 described the database in the KDC. This 6616 discussion was not necessary for interoperability and unnecessarily 6617 constrained implementation. The old section 4 was removed. 6619 The current section 4 was formerly section 6 on encryption and 6620 checksum specifications. The major part of this section was brought 6621 up to date to support new encryption methods, and move to a separate 6622 document. Those few remaining aspects of the encryption and checksum 6623 specification specific to Kerberos are now specified in section 4. 6625 Significant changes were made to the layout of section 5 to clarify 6626 the correct behavior for optional fields. Many of these changes were 6627 made necessary because of improper ASN.1 description in the original 6628 Kerberos specification which left the correct behavior 6629 underspecified. Additionally, the wording in this section was 6630 tightened wherever possible to ensure that implementations conforming 6631 to this specification will be extensible with the addition of new 6632 fields in future specifications. 6634 Text was added describing time_t=0 issues in the ASN.1. Text was also 6635 added, clarifying issues with implementations treating omitted 6636 optional integers as zero. Text was added clarifying behavior for 6637 optional SEQUENCE or SEQUENCE OF that may be empty. Discussion was 6638 added regarding sequence numbers and behavior of some 6639 implementations, including "zero" behavior and negative numbers. A 6640 compatibility note was added regarding the unconditional sending of 6641 EncTGSRepPart regardless of the enclosing reply type. Minor changes 6642 were made to the description of the HostAddresses type. Integer types 6643 were constrained. KerberosString was defined as a (significantly) 6644 constrained GeneralString. KerberosFlags was defined to reflect 6645 existing implementation behavior that departs from the definition in 6646 RFC 1510. The transited-policy-checked(12) and the ok-as-delegate(13) 6647 ticket flags were added. The disable-transited-check(26) KDC option 6648 was added. 6650 Descriptions of commonly implemented PA-DATA were added to section 5. 6652 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT 6654 The description of KRB-SAFE has been updated to note the existing 6655 implementation behavior of double-encoding. 6657 There were two definitions of METHOD-DATA in RFC 1510. The second 6658 one, intended for use with KRB_AP_ERR_METHOD was removed leaving the 6659 SEQUENCE OF PA-DATA definition. 6661 Section 7, naming constraints, from RFC1510 was moved to section 6. 6663 Words were added describing the convention that domain based realm 6664 names for newly created realms should be specified as upper case. 6665 This recommendation does not make lower case realm names illegal. 6666 Words were added highlighting that the slash separated components in 6667 the X500 style of realm names is consistent with existing RFC1510 6668 based implementations, but that it conflicts with the general 6669 recommendation of X.500 name representation specified in RFC2253. 6671 Section 8, network transport, constants and defined values, from 6672 RFC1510 was moved to section 7. Since RFC1510, the definition of the 6673 TCP transport for Kerberos messages was added, and the encryption and 6674 checksum number assignments have been moved into a separate document. 6676 "Specification 2" in section 8 of the current document changes the 6677 required encryption and checksum methods to bring them in line with 6678 the best current practices and to deprecate methods that are no 6679 longer considered sufficiently strong. 6681 Two new sections, on IANA considerations and security considerations 6682 were added. 6684 The pseudo-code has been removed from the appendix. The pseudo-code 6685 was sometimes misinterpreted to limit implementation choices and in 6686 RFC 1510, it was not always consistent with the words in the 6687 specification. Effort was made to clear up any ambiguities in the 6688 specification, rather than to rely on the pseudo-code. 6690 An appendix was added containing the complete ASN.1 module drawn from 6691 the discussion in section 5 of the current document. 6693 END NOTES 6695 (*TM) Project Athena, Athena, and Kerberos are trademarks of the 6696 Massachusetts Institute of Technology (MIT). No commercial use of 6697 these trademarks may be made without prior written permission of MIT.