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