doc/specifications/draft-ietf-krb-wg-kerberos-clarifications-07.txt

   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
   9
  10             The Kerberos Network Authentication Service (V5)
  11             draft-ietf-krb-wg-kerberos-clarifications-07.txt
  12
  13 STATUS OF THIS MEMO
  14
  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.
  20
  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."
  25
  26    The list of current Internet-Drafts can be accessed at
  27    http://www.ietf.org/ietf/1id-abstracts.txt
  28
  29    The list of Internet-Draft Shadow Directories can be accessed at
  30    http://www.ietf.org/shadow.html.
  31
  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).
  36
  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
  40
  41 ABSTRACT
  42
  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.
  50
  51
  52
  53 September 2004                                                  [Page 1]\f
  54
  55
  56
  57
  58
  59 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
  60
  61
  62 OVERVIEW
  63
  64    This document describes the concepts and model upon which the
  65    Kerberos network authentication system is based. It also specifies
  66    Version 5 of the Kerberos protocol.  The motivations, goals,
  67    assumptions, and rationale behind most design decisions are treated
  68    cursorily; they are more fully described in a paper available in IEEE
  69    communications [NT94] and earlier in the Kerberos portion of the
  70    Athena Technical Plan [MNSS87].
  71
  72    This document is not intended to describe Kerberos to the end user,
  73    system administrator, or application developer. Higher level papers
  74    describing Version 5 of the Kerberos system [NT94] and documenting
  75    version 4 [SNS88], are available elsewhere.
  76
  77 BACKGROUND
  78
  79    The Kerberos model is based in part on Needham and Schroeder's
  80    trusted third-party authentication protocol [NS78] and on
  81    modifications suggested by Denning and Sacco [DS81]. The original
  82    design and implementation of Kerberos Versions 1 through 4 was the
  83    work of two former Project Athena staff members, Steve Miller of
  84    Digital Equipment Corporation and Clifford Neuman (now at the
  85    Information Sciences Institute of the University of Southern
  86    California), along with Jerome Saltzer, Technical Director of Project
  87    Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other
  88    members of Project Athena have also contributed to the work on
  89    Kerberos.
  90
  91    Version 5 of the Kerberos protocol (described in this document) has
  92    evolved from Version 4 based on new requirements and desires for
  93    features not available in Version 4. The design of Version 5 of the
  94    Kerberos protocol was led by Clifford Neuman and John Kohl with much
  95    input from the community. The development of the MIT reference
  96    implementation was led at MIT by John Kohl and Theodore Ts'o, with
  97    help and contributed code from many others. Since RFC1510 was issued,
  98    extensions and revisions to the protocol have been proposed by many
  99    individuals. Some of these proposals are reflected in this document.
 100    Where such changes involved significant effort, the document cites
 101    the contribution of the proposer.
 102
 103    Reference implementations of both version 4 and version 5 of Kerberos
 104    are publicly available and commercial implementations have been
 105    developed and are widely used. Details on the differences between
 106    Kerberos Versions 4 and 5 can be found in [KNT94].
 107
 108    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 109    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 110    document are to be interpreted as described in RFC 2119.
 111
 112
 113 September 2004                                                  [Page 2]\f
 114
 115
 116
 117
 118                            Table of Contents
 119
 120
 121 1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
 122 1.1. Cross-realm operation . . . . . . . . . . . . . . . . . . . . .   8
 123 1.2. Choosing a principal with which to communicate  . . . . . . . .   9
 124 1.3. Authorization . . . . . . . . . . . . . . . . . . . . . . . . .  10
 125 1.4. Extending Kerberos Without Breaking Interoperability  . . . . .  11
 126 1.4.1. Compatibility with RFC 1510 . . . . . . . . . . . . . . . . .  11
 127 1.4.2. Sending Extensible Messages . . . . . . . . . . . . . . . . .  12
 128 1.5. Environmental assumptions . . . . . . . . . . . . . . . . . . .  12
 129 1.6. Glossary of terms . . . . . . . . . . . . . . . . . . . . . . .  13
 130 2. Ticket flag uses and requests . . . . . . . . . . . . . . . . . .  16
 131 2.1. Initial, pre-authenticated, and hardware authenticated
 132       tickets  . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
 133 2.2. Invalid tickets . . . . . . . . . . . . . . . . . . . . . . . .  17
 134 2.3. Renewable tickets . . . . . . . . . . . . . . . . . . . . . . .  17
 135 2.4. Postdated tickets . . . . . . . . . . . . . . . . . . . . . . .  18
 136 2.5. Proxiable and proxy tickets . . . . . . . . . . . . . . . . . .  19
 137 2.6. Forwardable tickets . . . . . . . . . . . . . . . . . . . . . .  19
 138 2.7. Transited Policy Checking . . . . . . . . . . . . . . . . . . .  20
 139 2.8. OK as Delegate  . . . . . . . . . . . . . . . . . . . . . . . .  21
 140 2.9. Other KDC options . . . . . . . . . . . . . . . . . . . . . . .  21
 141 2.9.1. Renewable-OK  . . . . . . . . . . . . . . . . . . . . . . . .  21
 142 2.9.2. ENC-TKT-IN-SKEY . . . . . . . . . . . . . . . . . . . . . . .  22
 143 2.9.3. Passwordless Hardware Authentication  . . . . . . . . . . . .  22
 144 3. Message Exchanges . . . . . . . . . . . . . . . . . . . . . . . .  22
 145 3.1. The Authentication Service Exchange . . . . . . . . . . . . . .  22
 146 3.1.1. Generation of KRB_AS_REQ message  . . . . . . . . . . . . . .  24
 147 3.1.2. Receipt of KRB_AS_REQ message . . . . . . . . . . . . . . . .  24
 148 3.1.3. Generation of KRB_AS_REP message  . . . . . . . . . . . . . .  24
 149 3.1.4. Generation of KRB_ERROR message . . . . . . . . . . . . . . .  27
 150 3.1.5. Receipt of KRB_AS_REP message . . . . . . . . . . . . . . . .  27
 151 3.1.6. Receipt of KRB_ERROR message  . . . . . . . . . . . . . . . .  28
 152 3.2. The Client/Server Authentication Exchange . . . . . . . . . . .  29
 153 3.2.1. The KRB_AP_REQ message  . . . . . . . . . . . . . . . . . . .  29
 154 3.2.2. Generation of a KRB_AP_REQ message  . . . . . . . . . . . . .  29
 155 3.2.3. Receipt of KRB_AP_REQ message . . . . . . . . . . . . . . . .  30
 156 3.2.4. Generation of a KRB_AP_REP message  . . . . . . . . . . . . .  32
 157 3.2.5. Receipt of KRB_AP_REP message . . . . . . . . . . . . . . . .  33
 158 3.2.6. Using the encryption key  . . . . . . . . . . . . . . . . . .  33
 159 3.3. The Ticket-Granting Service (TGS) Exchange  . . . . . . . . . .  34
 160 3.3.1. Generation of KRB_TGS_REQ message . . . . . . . . . . . . . .  35
 161 3.3.2. Receipt of KRB_TGS_REQ message  . . . . . . . . . . . . . . .  37
 162 3.3.3. Generation of KRB_TGS_REP message . . . . . . . . . . . . . .  38
 163 3.3.3.1. Checking for revoked tickets  . . . . . . . . . . . . . . .  40
 164 3.3.3.2. Encoding the transited field  . . . . . . . . . . . . . . .  40
 165 3.3.4. Receipt of KRB_TGS_REP message  . . . . . . . . . . . . . . .  42
 166
 167
 168
 169 September 2004                                                  [Page 3]\f
 170
 171
 172
 173
 174
 175 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
 176
 177
 178 3.4. The KRB_SAFE Exchange . . . . . . . . . . . . . . . . . . . . .  42
 179 3.4.1. Generation of a KRB_SAFE message  . . . . . . . . . . . . . .  42
 180 3.4.2. Receipt of KRB_SAFE message . . . . . . . . . . . . . . . . .  43
 181 3.5. The KRB_PRIV Exchange . . . . . . . . . . . . . . . . . . . . .  44
 182 3.5.1. Generation of a KRB_PRIV message  . . . . . . . . . . . . . .  44
 183 3.5.2. Receipt of KRB_PRIV message . . . . . . . . . . . . . . . . .  44
 184 3.6. The KRB_CRED Exchange . . . . . . . . . . . . . . . . . . . . .  45
 185 3.6.1. Generation of a KRB_CRED message  . . . . . . . . . . . . . .  45
 186 3.6.2. Receipt of KRB_CRED message . . . . . . . . . . . . . . . . .  46
 187 3.7. User-to-User Authentication Exchanges . . . . . . . . . . . . .  47
 188 4. Encryption and Checksum Specifications  . . . . . . . . . . . . .  48
 189 5. Message Specifications  . . . . . . . . . . . . . . . . . . . . .  50
 190 5.1. Specific Compatibility Notes on ASN.1 . . . . . . . . . . . . .  51
 191 5.1.1. ASN.1 Distinguished Encoding Rules  . . . . . . . . . . . . .  51
 192 5.1.2. Optional Integer Fields . . . . . . . . . . . . . . . . . . .  51
 193 5.1.3. Empty SEQUENCE OF Types . . . . . . . . . . . . . . . . . . .  52
 194 5.1.4. Unrecognized Tag Numbers  . . . . . . . . . . . . . . . . . .  52
 195 5.1.5. Tag Numbers Greater Than 30 . . . . . . . . . . . . . . . . .  52
 196 5.2. Basic Kerberos Types  . . . . . . . . . . . . . . . . . . . . .  52
 197 5.2.1. KerberosString  . . . . . . . . . . . . . . . . . . . . . . .  53
 198 5.2.2. Realm and PrincipalName . . . . . . . . . . . . . . . . . . .  54
 199 5.2.3. KerberosTime  . . . . . . . . . . . . . . . . . . . . . . . .  55
 200 5.2.4. Constrained Integer types . . . . . . . . . . . . . . . . . .  55
 201 5.2.5. HostAddress and HostAddresses . . . . . . . . . . . . . . . .  56
 202 5.2.6. AuthorizationData . . . . . . . . . . . . . . . . . . . . . .  56
 203 5.2.6.1. IF-RELEVANT . . . . . . . . . . . . . . . . . . . . . . . .  58
 204 5.2.6.2. KDCIssued . . . . . . . . . . . . . . . . . . . . . . . . .  58
 205 5.2.6.3. AND-OR  . . . . . . . . . . . . . . . . . . . . . . . . . .  59
 206 5.2.6.4. MANDATORY-FOR-KDC . . . . . . . . . . . . . . . . . . . . .  59
 207 5.2.7. PA-DATA . . . . . . . . . . . . . . . . . . . . . . . . . . .  60
 208 5.2.7.1. PA-TGS-REQ  . . . . . . . . . . . . . . . . . . . . . . . .  61
 209 5.2.7.2. Encrypted Timestamp Pre-authentication  . . . . . . . . . .  61
 210 5.2.7.3. PA-PW-SALT  . . . . . . . . . . . . . . . . . . . . . . . .  61
 211 5.2.7.4. PA-ETYPE-INFO . . . . . . . . . . . . . . . . . . . . . . .  62
 212 5.2.7.5. PA-ETYPE-INFO2  . . . . . . . . . . . . . . . . . . . . . .  62
 213 5.2.8. KerberosFlags . . . . . . . . . . . . . . . . . . . . . . . .  63
 214 5.2.9. Cryptosystem-related Types  . . . . . . . . . . . . . . . . .  64
 215 5.3. Tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . .  66
 216 5.4. Specifications for the AS and TGS exchanges . . . . . . . . . .  73
 217 5.4.1. KRB_KDC_REQ definition  . . . . . . . . . . . . . . . . . . .  73
 218 5.4.2. KRB_KDC_REP definition  . . . . . . . . . . . . . . . . . . .  81
 219 5.5. Client/Server (CS) message specifications . . . . . . . . . . .  84
 220 5.5.1. KRB_AP_REQ definition . . . . . . . . . . . . . . . . . . . .  84
 221 5.5.2. KRB_AP_REP definition . . . . . . . . . . . . . . . . . . . .  87
 222 5.5.3. Error message reply . . . . . . . . . . . . . . . . . . . . .  88
 223 5.6. KRB_SAFE message specification  . . . . . . . . . . . . . . . .  89
 224 5.6.1. KRB_SAFE definition . . . . . . . . . . . . . . . . . . . . .  89
 225 5.7. KRB_PRIV message specification  . . . . . . . . . . . . . . . .  90
 226
 227
 228
 229 September 2004                                                  [Page 4]\f
 230
 231
 232
 233
 234
 235 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
 236
 237
 238 5.7.1. KRB_PRIV definition . . . . . . . . . . . . . . . . . . . . .  91
 239 5.8. KRB_CRED message specification  . . . . . . . . . . . . . . . .  91
 240 5.8.1. KRB_CRED definition . . . . . . . . . . . . . . . . . . . . .  91
 241 5.9. Error message specification . . . . . . . . . . . . . . . . . .  94
 242 5.9.1. KRB_ERROR definition  . . . . . . . . . . . . . . . . . . . .  94
 243 5.10. Application Tag Numbers  . . . . . . . . . . . . . . . . . . .  96
 244 6. Naming Constraints  . . . . . . . . . . . . . . . . . . . . . . .  97
 245 6.1. Realm Names . . . . . . . . . . . . . . . . . . . . . . . . . .  97
 246 6.2. Principal Names . . . . . . . . . . . . . . . . . . . . . . . .  98
 247 6.2.1. Name of server principals . . . . . . . . . . . . . . . . . . 100
 248 7. Constants and other defined values  . . . . . . . . . . . . . . . 100
 249 7.1. Host address types  . . . . . . . . . . . . . . . . . . . . . . 100
 250 7.2. KDC messaging - IP Transports . . . . . . . . . . . . . . . . . 102
 251 7.2.1. UDP/IP transport  . . . . . . . . . . . . . . . . . . . . . . 102
 252 7.2.2. TCP/IP transport  . . . . . . . . . . . . . . . . . . . . . . 102
 253 7.2.3. KDC Discovery on IP Networks  . . . . . . . . . . . . . . . . 103
 254 7.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names  . . . . 104
 255 7.2.3.2. Specifying KDC Location information with DNS SRV
 256       records  . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
 257 7.2.3.3. KDC Discovery for Domain Style Realm Names on IP
 258       Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
 259 7.3. Name of the TGS . . . . . . . . . . . . . . . . . . . . . . . . 105
 260 7.4. OID arc for KerberosV5  . . . . . . . . . . . . . . . . . . . . 105
 261 7.5. Protocol constants and associated values  . . . . . . . . . . . 105
 262 7.5.1. Key usage numbers . . . . . . . . . . . . . . . . . . . . . . 106
 263 7.5.2. PreAuthentication Data Types  . . . . . . . . . . . . . . . . 107
 264 7.5.3. Address Types . . . . . . . . . . . . . . . . . . . . . . . . 108
 265 7.5.4. Authorization Data Types  . . . . . . . . . . . . . . . . . . 108
 266 7.5.5. Transited Encoding Types  . . . . . . . . . . . . . . . . . . 108
 267 7.5.6. Protocol Version Number . . . . . . . . . . . . . . . . . . . 109
 268 7.5.7. Kerberos Message Types  . . . . . . . . . . . . . . . . . . . 109
 269 7.5.8. Name Types  . . . . . . . . . . . . . . . . . . . . . . . . . 109
 270 7.5.9. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 109
 271 8. Interoperability requirements . . . . . . . . . . . . . . . . . . 111
 272 8.1. Specification 2 . . . . . . . . . . . . . . . . . . . . . . . . 111
 273 8.2. Recommended KDC values  . . . . . . . . . . . . . . . . . . . . 114
 274 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . . . 114
 275 10. Security Considerations  . . . . . . . . . . . . . . . . . . . . 115
 276 11. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 119
 277 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 120
 278 13. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
 279 13.1 NORMATIVE REFERENCES  . . . . . . . . . . . . . . . . . . . . . 120
 280 13.2 INFORMATIVE REFERENCES  . . . . . . . . . . . . . . . . . . . . 122
 281 14. Copyright Statement  . . . . . . . . . . . . . . . . . . . . . . 123
 282 15. Intellectual Property  . . . . . . . . . . . . . . . . . . . . . 123
 283 A. ASN.1 module  . . . . . . . . . . . . . . . . . . . . . . . . . . 124
 284 B. Changes since RFC-1510  . . . . . . . . . . . . . . . . . . . . . 132
 285 END NOTES  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
 286
 287
 288
 289 September 2004                                                  [Page 5]\f
 290
 291
 292
 293
 294 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
 295
 296
 297 1. Introduction
 298
 299    Kerberos provides a means of verifying the identities of principals,
 300    (e.g. a workstation user or a network server) on an open
 301    (unprotected) network. This is accomplished without relying on
 302    assertions by the host operating system, without basing trust on host
 303    addresses, without requiring physical security of all the hosts on
 304    the network, and under the assumption that packets traveling along
 305    the network can be read, modified, and inserted at will. Kerberos
 306    performs authentication under these conditions as a trusted third-
 307    party authentication service by using conventional (shared secret
 308    key) cryptography.  Extensions to Kerberos (outside the scope of this
 309    document) can provide for the use of public key cryptography during
 310    certain phases of the authentication protocol [@RFCE: if PKINIT
 311    advances concurrently include reference to the RFC here]. Such
 312    extensions support Kerberos authentication for users registered with
 313    public key certification authorities and provide certain benefits of
 314    public key cryptography in situations where they are needed.
 315
 316    The basic Kerberos authentication process proceeds as follows: A
 317    client sends a request to the authentication server (AS) requesting
 318    "credentials" for a given server. The AS responds with these
 319    credentials, encrypted in the client's key. The credentials consist
 320    of a "ticket" for the server and a temporary encryption key (often
 321    called a "session key"). The client transmits the ticket (which
 322    contains the client's identity and a copy of the session key, all
 323    encrypted in the server's key) to the server. The session key (now
 324    shared by the client and server) is used to authenticate the client,
 325    and may optionally be used to authenticate the server. It may also be
 326    used to encrypt further communication between the two parties or to
 327    exchange a separate sub-session key to be used to encrypt further
 328    communication.  Note that many applications use Kerberos' functions
 329    only upon the initiation of a stream-based network connection. Unless
 330    an application performs encryption or integrity protection for the
 331    data stream, the identity verification applies only to the initiation
 332    of the connection, and does not guarantee that subsequent messages on
 333    the connection originate from the same principal.
 334
 335    Implementation of the basic protocol consists of one or more
 336    authentication servers running on physically secure hosts. The
 337    authentication servers maintain a database of principals (i.e., users
 338    and servers) and their secret keys. Code libraries provide encryption
 339    and implement the Kerberos protocol.  In order to add authentication
 340    to its transactions, a typical network application adds calls to the
 341    Kerberos library directly or through the Generic Security Services
 342    Application Programming Interface, GSSAPI, described in separate
 343    document [ref to GSSAPI RFC]. These calls result in the transmission
 344    of the necessary messages to achieve authentication.
 345
 346
 347
 348 September 2004                                                  [Page 6]\f
 349
 350
 351
 352
 353
 354 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
 355
 356
 357    The Kerberos protocol consists of several sub-protocols (or
 358    exchanges).  There are two basic methods by which a client can ask a
 359    Kerberos server for credentials. In the first approach, the client
 360    sends a cleartext request for a ticket for the desired server to the
 361    AS. The reply is sent encrypted in the client's secret key. Usually
 362    this request is for a ticket-granting ticket (TGT) which can later be
 363    used with the ticket-granting server (TGS).  In the second method,
 364    the client sends a request to the TGS. The client uses the TGT to
 365    authenticate itself to the TGS in the same manner as if it were
 366    contacting any other application server that requires Kerberos
 367    authentication. The reply is encrypted in the session key from the
 368    TGT.  Though the protocol specification describes the AS and the TGS
 369    as separate servers, they are implemented in practice as different
 370    protocol entry points within a single Kerberos server.
 371
 372    Once obtained, credentials may be used to verify the identity of the
 373    principals in a transaction, to ensure the integrity of messages
 374    exchanged between them, or to preserve privacy of the messages. The
 375    application is free to choose whatever protection may be necessary.
 376
 377    To verify the identities of the principals in a transaction, the
 378    client transmits the ticket to the application server. Since the
 379    ticket is sent "in the clear" (parts of it are encrypted, but this
 380    encryption doesn't thwart replay) and might be intercepted and reused
 381    by an attacker, additional information is sent to prove that the
 382    message originated with the principal to whom the ticket was issued.
 383    This information (called the authenticator) is encrypted in the
 384    session key, and includes a timestamp. The timestamp proves that the
 385    message was recently generated and is not a replay.  Encrypting the
 386    authenticator in the session key proves that it was generated by a
 387    party possessing the session key. Since no one except the requesting
 388    principal and the server know the session key (it is never sent over
 389    the network in the clear) this guarantees the identity of the client.
 390
 391    The integrity of the messages exchanged between principals can also
 392    be guaranteed using the session key (passed in the ticket and
 393    contained in the credentials). This approach provides detection of
 394    both replay attacks and message stream modification attacks. It is
 395    accomplished by generating and transmitting a collision-proof
 396    checksum (elsewhere called a hash or digest function) of the client's
 397    message, keyed with the session key. Privacy and integrity of the
 398    messages exchanged between principals can be secured by encrypting
 399    the data to be passed using the session key contained in the ticket
 400    or the sub-session key found in the authenticator.
 401
 402    The authentication exchanges mentioned above require read-only access
 403    to the Kerberos database. Sometimes, however, the entries in the
 404    database must be modified, such as when adding new principals or
 405
 406
 407
 408 September 2004                                                  [Page 7]\f
 409
 410
 411
 412
 413
 414 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
 415
 416
 417    changing a principal's key.  This is done using a protocol between a
 418    client and a third Kerberos server, the Kerberos Administration
 419    Server (KADM). There is also a protocol for maintaining multiple
 420    copies of the Kerberos database. Neither of these protocols are
 421    described in this document.
 422
 423 1.1. Cross-realm operation
 424
 425    The Kerberos protocol is designed to operate across organizational
 426    boundaries. A client in one organization can be authenticated to a
 427    server in another. Each organization wishing to run a Kerberos server
 428    establishes its own "realm". The name of the realm in which a client
 429    is registered is part of the client's name, and can be used by the
 430    end-service to decide whether to honor a request.
 431
 432    By establishing "inter-realm" keys, the administrators of two realms
 433    can allow a client authenticated in the local realm to prove its
 434    identity to servers in other realms. The exchange of inter-realm keys
 435    (a separate key may be used for each direction) registers the ticket-
 436    granting service of each realm as a principal in the other realm. A
 437    client is then able to obtain a ticket-granting ticket for the remote
 438    realm's ticket-granting service from its local realm. When that
 439    ticket-granting ticket is used, the remote ticket-granting service
 440    uses the inter-realm key (which usually differs from its own normal
 441    TGS key) to decrypt the ticket-granting ticket, and is thus certain
 442    that it was issued by the client's own TGS. Tickets issued by the
 443    remote ticket-granting service will indicate to the end-service that
 444    the client was authenticated from another realm.
 445
 446    Without cross-realm operation, and with appropriate permission the
 447    client can arrange registration of a separately-named principal in a
 448    remote realm, and engage in normal exchanges with that realm's
 449    services. However, for even small numbers of clients this becomes
 450    cumbersome, and more automatic methods as described here are
 451    necessary.
 452
 453    A realm is said to communicate with another realm if the two realms
 454    share an inter-realm key, or if the local realm shares an inter-realm
 455    key with an intermediate realm that communicates with the remote
 456    realm. An authentication path is the sequence of intermediate realms
 457    that are transited in communicating from one realm to another.
 458
 459    Realms may be organized hierarchically. Each realm shares a key with
 460    its parent and a different key with each child. If an inter-realm key
 461    is not directly shared by two realms, the hierarchical organization
 462    allows an authentication path to be easily constructed. If a
 463    hierarchical organization is not used, it may be necessary to consult
 464    a database in order to construct an authentication path between
 465
 466
 467
 468 September 2004                                                  [Page 8]\f
 469
 470
 471
 472
 473
 474 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
 475
 476
 477    realms.
 478
 479    Although realms are typically hierarchical, intermediate realms may
 480    be bypassed to achieve cross-realm authentication through alternate
 481    authentication paths (these might be established to make
 482    communication between two realms more efficient). It is important for
 483    the end-service to know which realms were transited when deciding how
 484    much faith to place in the authentication process. To facilitate this
 485    decision, a field in each ticket contains the names of the realms
 486    that were involved in authenticating the client.
 487
 488    The application server is ultimately responsible for accepting or
 489    rejecting authentication and SHOULD check the transited field. The
 490    application server may choose to rely on the KDC for the application
 491    server's realm to check the transited field. The application server's
 492    KDC will set the TRANSITED-POLICY-CHECKED flag in this case. The KDCs
 493    for intermediate realms may also check the transited field as they
 494    issue ticket-granting tickets for other realms, but they are
 495    encouraged not to do so. A client may request that the KDCs not check
 496    the transited field by setting the DISABLE-TRANSITED-CHECK flag. KDCs
 497    SHOULD honor this flag.
 498
 499 1.2. Choosing a principal with which to communicate
 500
 501    The Kerberos protocol provides the means for verifying (subject to
 502    the assumptions in 1.5) that the entity with which one communicates
 503    is the same entity that was registered with the KDC using the claimed
 504    identity (principal name). It is still necessary to determine whether
 505    that identity corresponds to the entity with which one intends to
 506    communicate.
 507
 508    When appropriate data has been exchanged in advance, this
 509    determination may be performed syntactically by the application based
 510    on the application protocol specification, information provided by
 511    the user, and configuration files. For example, the server principal
 512    name (including realm) for a telnet server might be derived from the
 513    user specified host name (from the telnet command line), the "host/"
 514    prefix specified in the application protocol specification, and a
 515    mapping to a Kerberos realm derived syntactically from the domain
 516    part of the specified hostname and information from the local
 517    Kerberos realms database.
 518
 519    One can also rely on trusted third parties to make this
 520    determination, but only when the data obtained from the third party
 521    is suitably integrity protected while resident on the third party
 522    server and when transmitted.  Thus, for example, one should not rely
 523    on an unprotected domain name system record to map a host alias to
 524    the primary name of a server, accepting the primary name as the party
 525
 526
 527
 528 September 2004                                                  [Page 9]\f
 529
 530
 531
 532
 533
 534 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
 535
 536
 537    one intends to contact, since an attacker can modify the mapping and
 538    impersonate the party with which one intended to communicate.
 539
 540    Implementations of Kerberos and protocols based on Kerberos MUST NOT
 541    use insecure DNS queries to canonicalize the hostname components of
 542    the service principal names (i.e. MUST NOT use insecure DNS queries
 543    to map one name to another to determine the host part of the
 544    principal name with which one is to communicate).  In an environment
 545    without secure name service, application authors MAY append a
 546    statically configured domain name to unqualified hostnames before
 547    passing the name to the security mechanisms, but should do no more
 548    than that.  Secure name service facilities, if available, might be
 549    trusted for hostname canonicalization, but such canonicalization by
 550    the client SHOULD NOT be required by KDC implementations.
 551
 552    Implementation note: Many current implementations do some degree of
 553    canonicalization of the provided service name, often using DNS even
 554    though it creates security problems. However there is no consistency
 555    among implementations about whether the service name is case folded
 556    to lower case or whether reverse resolution is used. To maximize
 557    interoperability and security, applications SHOULD provide security
 558    mechanisms with names which result from folding the user-entered name
 559    to lower case, without performing any other modifications or
 560    canonicalization.
 561
 562 1.3. Authorization
 563
 564    As an authentication service, Kerberos provides a means of verifying
 565    the identity of principals on a network. Authentication is usually
 566    useful primarily as a first step in the process of authorization,
 567    determining whether a client may use a service, which objects the
 568    client is allowed to access, and the type of access allowed for each.
 569    Kerberos does not, by itself, provide authorization. Possession of a
 570    client ticket for a service provides only for authentication of the
 571    client to that service, and in the absence of a separate
 572    authorization procedure, it should not be considered by an
 573    application as authorizing the use of that service.
 574
 575    Such separate authorization methods MAY be implemented as application
 576    specific access control functions and may utilize files on the
 577    application server, or on separately issued authorization credentials
 578    such as those based on proxies [Neu93], or on other authorization
 579    services. Separately authenticated authorization credentials MAY be
 580    embedded in a ticket's authorization data when encapsulated by the
 581    KDC-issued authorization data element.
 582
 583    Applications should not accept the mere issuance of a service ticket
 584    by the Kerberos server (even by a modified Kerberos server) as
 585
 586
 587
 588 September 2004                                                 [Page 10]\f
 589
 590
 591
 592
 593
 594 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
 595
 596
 597    granting authority to use the service, since such applications may
 598    become vulnerable to the bypass of this authorization check in an
 599    environment if they interoperate with other KDCs or where other
 600    options for application authentication are provided.
 601
 602 1.4. Extending Kerberos Without Breaking Interoperability
 603
 604    As the deployed base of Kerberos implementations grows, extending
 605    Kerberos becomes more important. Unfortunately some extensions to the
 606    existing Kerberos protocol create interoperability issues because of
 607    uncertainty regarding the treatment of certain extensibility options
 608    by some implementations. This section includes guidelines that will
 609    enable future implementations to maintain interoperability.
 610
 611    Kerberos provides a general mechanism for protocol extensibility.
 612    Some protocol messages contain typed holes -- sub-messages that
 613    contain an octet-string along with an integer that defines how to
 614    interpret the octet-string. The integer types are registered
 615    centrally, but can be used both for vendor extensions and for
 616    extensions standardized through the IETF.
 617
 618    In this document, the word "extension" means an extension by defining
 619    a new type to insert into an existing typed hole in a protocol
 620    message.  It does not mean extension by addition of new fields to
 621    ASN.1 types, unless explicitly indicated otherwise in the text.
 622
 623 1.4.1. Compatibility with RFC 1510
 624
 625    It is important to note that existing Kerberos message formats can
 626    not be readily extended by adding fields to the ASN.1 types. Sending
 627    additional fields often results in the entire message being discarded
 628    without an error indication. Future versions of this specification
 629    will provide guidelines to ensure that ASN.1 fields can be added
 630    without creating an interoperability problem.
 631
 632    In the meantime, all new or modified implementations of Kerberos that
 633    receive an unknown message extension SHOULD preserve the encoding of
 634    the extension but otherwise ignore the presence of the extension.
 635    Recipients MUST NOT decline a request simply because an extension is
 636    present.
 637
 638    There is one exception to this rule. If an unknown authorization data
 639    element type is received by a server other than the ticket granting
 640    service either in an AP-REQ or in a ticket contained in an AP-REQ,
 641    then authentication MUST fail. One of the primary uses of
 642    authorization data is to restrict the use of the ticket. If the
 643    service cannot determine whether the restriction applies to that
 644    service then a security weakness may result if the ticket can be used
 645
 646
 647
 648 September 2004                                                 [Page 11]\f
 649
 650
 651
 652
 653
 654 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
 655
 656
 657    for that service. Authorization elements that are optional SHOULD be
 658    enclosed in the AD-IF-RELEVANT element.
 659
 660    The ticket granting service MUST ignore but propagate to derivative
 661    tickets any unknown authorization data types, unless those data types
 662    are embedded in a MANDATORY-FOR-KDC element, in which case the
 663    request will be rejected.  This behavior is appropriate because
 664    requiring that the ticket granting service understand unknown
 665    authorization data types would require that KDC software be upgraded
 666    to understand new application-level restrictions before applications
 667    used these restrictions, decreasing the utility of authorization data
 668    as a mechanism for restricting the use of tickets. No security
 669    problem is created because services to which the tickets are issued
 670    will verify the authorization data.
 671
 672    Implementation note: Many RFC 1510 implementations ignore unknown
 673    authorization data elements. Depending on these implementations to
 674    honor authorization data restrictions may create a security weakness.
 675
 676 1.4.2. Sending Extensible Messages
 677
 678    Care must be taken to ensure that old implementations can understand
 679    messages sent to them even if they do not understand an extension
 680    that is used. Unless the sender knows an extension is supported, the
 681    extension cannot change the semantics of the core message or
 682    previously defined extensions.
 683
 684    For example, an extension including key information necessary to
 685    decrypt the encrypted part of a KDC-REP could only be used in
 686    situations where the recipient was known to support the extension.
 687    Thus when designing such extensions it is important to provide a way
 688    for the recipient to notify the sender of support for the extension.
 689    For example in the case of an extension that changes the KDC-REP
 690    reply key, the client could indicate support for the extension by
 691    including a padata element in the AS-REQ sequence. The KDC should
 692    only use the extension if this padata element is present in the AS-
 693    REQ. Even if policy requires the use of the extension, it is better
 694    to return an error indicating that the extension is required than to
 695    use the extension when the recipient may not support it; debugging
 696    why implementations do not interoperate is easier when errors are
 697    returned.
 698
 699 1.5. Environmental assumptions
 700
 701    Kerberos imposes a few assumptions on the environment in which it can
 702    properly function:
 703
 704    *  "Denial of service" attacks are not solved with Kerberos. There
 705
 706
 707
 708 September 2004                                                 [Page 12]\f
 709
 710
 711
 712
 713
 714 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
 715
 716
 717       are places in the protocols where an intruder can prevent an
 718       application from participating in the proper authentication steps.
 719       Detection and solution of such attacks (some of which can appear
 720       to be not-uncommon "normal" failure modes for the system) is
 721       usually best left to the human administrators and users.
 722
 723    *  Principals MUST keep their secret keys secret. If an intruder
 724       somehow steals a principal's key, it will be able to masquerade as
 725       that principal or impersonate any server to the legitimate
 726       principal.
 727
 728    *  "Password guessing" attacks are not solved by Kerberos. If a user
 729       chooses a poor password, it is possible for an attacker to
 730       successfully mount an offline dictionary attack by repeatedly
 731       attempting to decrypt, with successive entries from a dictionary,
 732       messages obtained which are encrypted under a key derived from the
 733       user's password.
 734
 735    *  Each host on the network MUST have a clock which is "loosely
 736       synchronized" to the time of the other hosts; this synchronization
 737       is used to reduce the bookkeeping needs of application servers
 738       when they do replay detection. The degree of "looseness" can be
 739       configured on a per-server basis, but is typically on the order of
 740       5 minutes. If the clocks are synchronized over the network, the
 741       clock synchronization protocol MUST itself be secured from network
 742       attackers.
 743
 744    *  Principal identifiers are not recycled on a short-term basis. A
 745       typical mode of access control will use access control lists
 746       (ACLs) to grant permissions to particular principals. If a stale
 747       ACL entry remains for a deleted principal and the principal
 748       identifier is reused, the new principal will inherit rights
 749       specified in the stale ACL entry. By not re-using principal
 750       identifiers, the danger of inadvertent access is removed.
 751
 752 1.6. Glossary of terms
 753
 754       Below is a list of terms used throughout this document.
 755
 756    Authentication
 757       Verifying the claimed identity of a principal.
 758
 759    Authentication header
 760       A record containing a Ticket and an Authenticator to be presented
 761       to a server as part of the authentication process.
 762
 763    Authentication path
 764       A sequence of intermediate realms transited in the authentication
 765
 766
 767
 768 September 2004                                                 [Page 13]\f
 769
 770
 771
 772
 773
 774 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
 775
 776
 777       process when communicating from one realm to another.
 778
 779    Authenticator
 780       A record containing information that can be shown to have been
 781       recently generated using the session key known only by the client
 782       and server.
 783
 784    Authorization
 785       The process of determining whether a client may use a service,
 786       which objects the client is allowed to access, and the type of
 787       access allowed for each.
 788
 789    Capability
 790       A token that grants the bearer permission to access an object or
 791       service. In Kerberos, this might be a ticket whose use is
 792       restricted by the contents of the authorization data field, but
 793       which lists no network addresses, together with the session key
 794       necessary to use the ticket.
 795
 796    Ciphertext
 797       The output of an encryption function. Encryption transforms
 798       plaintext into ciphertext.
 799
 800    Client
 801       A process that makes use of a network service on behalf of a user.
 802       Note that in some cases a Server may itself be a client of some
 803       other server (e.g. a print server may be a client of a file
 804       server).
 805
 806    Credentials
 807       A ticket plus the secret session key necessary to successfully use
 808       that ticket in an authentication exchange.
 809
 810    Encryption Type (etype)
 811       When associated with encrypted data, an encryption type identifies
 812       the algorithm used to encrypt the data and is used to select the
 813       appropriate algorithm for decrypting the data.  Encryption type
 814       tags are communicated in other messages to enumerate algorithms
 815       that are desired, supported, preferred, or allowed to be used for
 816       encryption of data between parties.  This preference is combined
 817       with local information and policy to select an algorithm to be
 818       used.
 819
 820    KDC
 821       Key Distribution Center, a network service that supplies tickets
 822       and temporary session keys; or an instance of that service or the
 823       host on which it runs. The KDC services both initial ticket and
 824       ticket-granting ticket requests. The initial ticket portion is
 825
 826
 827
 828 September 2004                                                 [Page 14]\f
 829
 830
 831
 832
 833
 834 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
 835
 836
 837       sometimes referred to as the Authentication Server (or service).
 838       The ticket-granting ticket portion is sometimes referred to as the
 839       ticket-granting server (or service).
 840
 841    Kerberos
 842       The name given to the Project Athena's authentication service, the
 843       protocol used by that service, or the code used to implement the
 844       authentication service.  The name is adopted from the three-headed
 845       dog which guards Hades.
 846
 847    Key Version Number (kvno)
 848       A tag associated with encrypted data identifies which key was used
 849       for encryption when a long lived key associated with a principal
 850       changes over time.  It is used during the transition to a new key
 851       so that the party decrypting a message can tell whether the data
 852       was encrypted using the old or the new key.
 853
 854    Plaintext
 855       The input to an encryption function or the output of a decryption
 856       function. Decryption transforms ciphertext into plaintext.
 857
 858    Principal
 859       A named client or server entity that participates in a network
 860       communication, with one name that is considered canonical.
 861
 862    Principal identifier
 863       The canonical name used to uniquely identify each different
 864       principal.
 865
 866    Seal
 867       To encipher a record containing several fields in such a way that
 868       the fields cannot be individually replaced without either
 869       knowledge of the encryption key or leaving evidence of tampering.
 870
 871    Secret key
 872       An encryption key shared by a principal and the KDC, distributed
 873       outside the bounds of the system, with a long lifetime. In the
 874       case of a human user's principal, the secret key MAY be derived
 875       from a password.
 876
 877    Server
 878       A particular Principal which provides a resource to network
 879       clients.  The server is sometimes referred to as the Application
 880       Server.
 881
 882    Service
 883       A resource provided to network clients; often provided by more
 884       than one server (for example, remote file service).
 885
 886
 887
 888 September 2004                                                 [Page 15]\f
 889
 890
 891
 892
 893
 894 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
 895
 896
 897    Session key
 898       A temporary encryption key used between two principals, with a
 899       lifetime limited to the duration of a single login "session".  In
 900       the Kerberos system, a session key is generated by the KDC.  The
 901       session key is distinct from the sub-session key, described next..
 902
 903    Sub-session key
 904       A temporary encryption key used between two principals, selected
 905       and exchanged by the principals using the session key, and with a
 906       lifetime limited to the duration of a single association. The sub-
 907       session key is also referred to as the subkey.
 908
 909    Ticket
 910       A record that helps a client authenticate itself to a server; it
 911       contains the client's identity, a session key, a timestamp, and
 912       other information, all sealed using the server's secret key. It
 913       only serves to authenticate a client when presented along with a
 914       fresh Authenticator.
 915
 916
 917 2. Ticket flag uses and requests
 918
 919    Each Kerberos ticket contains a set of flags which are used to
 920    indicate attributes of that ticket. Most flags may be requested by a
 921    client when the ticket is obtained; some are automatically turned on
 922    and off by a Kerberos server as required. The following sections
 923    explain what the various flags mean and give examples of reasons to
 924    use them. With the exception of the INVALID flag clients MUST ignore
 925    ticket flags that are not recognized. KDCs MUST ignore KDC options
 926    that are not recognized. Some implementations of RFC 1510 are known
 927    to reject unknown KDC options, so clients may need to resend a
 928    request without new KDC options if the request was rejected when sent
 929    with options added since RFC 1510. Since new KDCs will ignore unknown
 930    options, clients MUST confirm that the ticket returned by the KDC
 931    meets their needs.
 932
 933    Note that it is not, in general, possible to determine whether an
 934    option was not honored because it was not understood or because it
 935    was rejected either through configuration or policy. When adding a
 936    new option to the Kerberos protocol, designers should consider
 937    whether the distinction is important for their option. In cases where
 938    it is, a mechanism for the KDC to return an indication that the
 939    option was understood but rejected needs to be provided in the
 940    specification of the option. Often in such cases, the mechanism needs
 941    to be broad enough to permit an error or reason to be returned.
 942
 943 2.1. Initial, pre-authenticated, and hardware authenticated tickets
 944
 945
 946
 947
 948 September 2004                                                 [Page 16]\f
 949
 950
 951
 952
 953
 954 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
 955
 956
 957    The INITIAL flag indicates that a ticket was issued using the AS
 958    protocol, rather than issued based on a ticket-granting ticket.
 959    Application servers that want to require the demonstrated knowledge
 960    of a client's secret key (e.g. a password-changing program) can
 961    insist that this flag be set in any tickets they accept, and thus be
 962    assured that the client's key was recently presented to the
 963    application client.
 964
 965    The PRE-AUTHENT and HW-AUTHENT flags provide additional information
 966    about the initial authentication, regardless of whether the current
 967    ticket was issued directly (in which case INITIAL will also be set)
 968    or issued on the basis of a ticket-granting ticket (in which case the
 969    INITIAL flag is clear, but the PRE-AUTHENT and HW-AUTHENT flags are
 970    carried forward from the ticket-granting ticket).
 971
 972 2.2. Invalid tickets
 973
 974    The INVALID flag indicates that a ticket is invalid. Application
 975    servers MUST reject tickets which have this flag set. A postdated
 976    ticket will be issued in this form. Invalid tickets MUST be validated
 977    by the KDC before use, by presenting them to the KDC in a TGS request
 978    with the VALIDATE option specified. The KDC will only validate
 979    tickets after their starttime has passed. The validation is required
 980    so that postdated tickets which have been stolen before their
 981    starttime can be rendered permanently invalid (through a hot-list
 982    mechanism) (see section 3.3.3.1).
 983
 984 2.3. Renewable tickets
 985
 986    Applications may desire to hold tickets which can be valid for long
 987    periods of time. However, this can expose their credentials to
 988    potential theft for equally long periods, and those stolen
 989    credentials would be valid until the expiration time of the
 990    ticket(s). Simply using short-lived tickets and obtaining new ones
 991    periodically would require the client to have long-term access to its
 992    secret key, an even greater risk. Renewable tickets can be used to
 993    mitigate the consequences of theft. Renewable tickets have two
 994    "expiration times": the first is when the current instance of the
 995    ticket expires, and the second is the latest permissible value for an
 996    individual expiration time. An application client must periodically
 997    (i.e. before it expires) present a renewable ticket to the KDC, with
 998    the RENEW option set in the KDC request. The KDC will issue a new
 999    ticket with a new session key and a later expiration time. All other
1000    fields of the ticket are left unmodified by the renewal process. When
1001    the latest permissible expiration time arrives, the ticket expires
1002    permanently. At each renewal, the KDC MAY consult a hot-list to
1003    determine if the ticket had been reported stolen since its last
1004    renewal; it will refuse to renew such stolen tickets, and thus the
1005
1006
1007
1008 September 2004                                                 [Page 17]\f
1009
1010
1011
1012
1013
1014 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
1015
1016
1017    usable lifetime of stolen tickets is reduced.
1018
1019    The RENEWABLE flag in a ticket is normally only interpreted by the
1020    ticket-granting service (discussed below in section 3.3). It can
1021    usually be ignored by application servers. However, some particularly
1022    careful application servers MAY disallow renewable tickets.
1023
1024    If a renewable ticket is not renewed by its expiration time, the KDC
1025    will not renew the ticket. The RENEWABLE flag is reset by default,
1026    but a client MAY request it be set by setting the RENEWABLE option in
1027    the KRB_AS_REQ message. If it is set, then the renew-till field in
1028    the ticket contains the time after which the ticket may not be
1029    renewed.
1030
1031 2.4. Postdated tickets
1032
1033    Applications may occasionally need to obtain tickets for use much
1034    later, e.g. a batch submission system would need tickets to be valid
1035    at the time the batch job is serviced. However, it is dangerous to
1036    hold valid tickets in a batch queue, since they will be on-line
1037    longer and more prone to theft.  Postdated tickets provide a way to
1038    obtain these tickets from the KDC at job submission time, but to
1039    leave them "dormant" until they are activated and validated by a
1040    further request of the KDC. If a ticket theft were reported in the
1041    interim, the KDC would refuse to validate the ticket, and the thief
1042    would be foiled.
1043
1044    The MAY-POSTDATE flag in a ticket is normally only interpreted by the
1045    ticket-granting service. It can be ignored by application servers.
1046    This flag MUST be set in a ticket-granting ticket in order to issue a
1047    postdated ticket based on the presented ticket. It is reset by
1048    default; it MAY be requested by a client by setting the ALLOW-
1049    POSTDATE option in the KRB_AS_REQ message.  This flag does not allow
1050    a client to obtain a postdated ticket-granting ticket; postdated
1051    ticket-granting tickets can only by obtained by requesting the
1052    postdating in the KRB_AS_REQ message. The life (endtime-starttime) of
1053    a postdated ticket will be the remaining life of the ticket-granting
1054    ticket at the time of the request, unless the RENEWABLE option is
1055    also set, in which case it can be the full life (endtime-starttime)
1056    of the ticket-granting ticket. The KDC MAY limit how far in the
1057    future a ticket may be postdated.
1058
1059    The POSTDATED flag indicates that a ticket has been postdated. The
1060    application server can check the authtime field in the ticket to see
1061    when the original authentication occurred. Some services MAY choose
1062    to reject postdated tickets, or they may only accept them within a
1063    certain period after the original authentication. When the KDC issues
1064    a POSTDATED ticket, it will also be marked as INVALID, so that the
1065
1066
1067
1068 September 2004                                                 [Page 18]\f
1069
1070
1071
1072
1073
1074 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
1075
1076
1077    application client MUST present the ticket to the KDC to be validated
1078    before use.
1079
1080 2.5. Proxiable and proxy tickets
1081
1082    At times it may be necessary for a principal to allow a service to
1083    perform an operation on its behalf. The service must be able to take
1084    on the identity of the client, but only for a particular purpose. A
1085    principal can allow a service to take on the principal's identity for
1086    a particular purpose by granting it a proxy.
1087
1088    The process of granting a proxy using the proxy and proxiable flags
1089    is used to provide credentials for use with specific services. Though
1090    conceptually also a proxy, users wishing to delegate their identity
1091    in a form usable for all purpose MUST use the ticket forwarding
1092    mechanism described in the next section to forward a ticket-granting
1093    ticket.
1094
1095    The PROXIABLE flag in a ticket is normally only interpreted by the
1096    ticket-granting service. It can be ignored by application servers.
1097    When set, this flag tells the ticket-granting server that it is OK to
1098    issue a new ticket (but not a ticket-granting ticket) with a
1099    different network address based on this ticket. This flag is set if
1100    requested by the client on initial authentication. By default, the
1101    client will request that it be set when requesting a ticket-granting
1102    ticket, and reset when requesting any other ticket.
1103
1104    This flag allows a client to pass a proxy to a server to perform a
1105    remote request on its behalf (e.g. a print service client can give
1106    the print server a proxy to access the client's files on a particular
1107    file server in order to satisfy a print request).
1108
1109    In order to complicate the use of stolen credentials, Kerberos
1110    tickets are often valid from only those network addresses
1111    specifically included in the ticket, but it is permissible as a
1112    policy option to allow requests and issue tickets with no network
1113    addresses specified.  When granting a proxy, the client MUST specify
1114    the new network address from which the proxy is to be used, or
1115    indicate that the proxy is to be issued for use from any address.
1116
1117    The PROXY flag is set in a ticket by the TGS when it issues a proxy
1118    ticket.  Application servers MAY check this flag and at their option
1119    they MAY require additional authentication from the agent presenting
1120    the proxy in order to provide an audit trail.
1121
1122 2.6. Forwardable tickets
1123
1124    Authentication forwarding is an instance of a proxy where the service
1125
1126
1127
1128 September 2004                                                 [Page 19]\f
1129
1130
1131
1132
1133
1134 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
1135
1136
1137    that is granted is complete use of the client's identity. An example
1138    where it might be used is when a user logs in to a remote system and
1139    wants authentication to work from that system as if the login were
1140    local.
1141
1142    The FORWARDABLE flag in a ticket is normally only interpreted by the
1143    ticket-granting service. It can be ignored by application servers.
1144    The FORWARDABLE flag has an interpretation similar to that of the
1145    PROXIABLE flag, except ticket-granting tickets may also be issued
1146    with different network addresses. This flag is reset by default, but
1147    users MAY request that it be set by setting the FORWARDABLE option in
1148    the AS request when they request their initial ticket-granting
1149    ticket.
1150
1151    This flag allows for authentication forwarding without requiring the
1152    user to enter a password again. If the flag is not set, then
1153    authentication forwarding is not permitted, but the same result can
1154    still be achieved if the user engages in the AS exchange specifying
1155    the requested network addresses and supplies a password.
1156
1157    The FORWARDED flag is set by the TGS when a client presents a ticket
1158    with the FORWARDABLE flag set and requests a forwarded ticket by
1159    specifying the FORWARDED KDC option and supplying a set of addresses
1160    for the new ticket. It is also set in all tickets issued based on
1161    tickets with the FORWARDED flag set. Application servers may choose
1162    to process FORWARDED tickets differently than non-FORWARDED tickets.
1163
1164    If addressless tickets are forwarded from one system to another,
1165    clients SHOULD still use this option to obtain a new TGT in order to
1166    have different session keys on the different systems.
1167
1168 2.7. Transited Policy Checking
1169
1170    In Kerberos, the application server is ultimately responsible for
1171    accepting or rejecting authentication and SHOULD check that only
1172    suitably trusted KDCs are relied upon to authenticate a principal.
1173    The transited field in the ticket identifies which realms (and thus
1174    which KDCs) were involved in the authentication process and an
1175    application server would normally check this field. If any of these
1176    are untrusted to authenticate the indicated client principal
1177    (probably determined by a realm-based policy), the authentication
1178    attempt MUST be rejected. The presence of trusted KDCs in this list
1179    does not provide any guarantee; an untrusted KDC may have fabricated
1180    the list.
1181
1182    While the end server ultimately decides whether authentication is
1183    valid, the KDC for the end server's realm MAY apply a realm specific
1184    policy for validating the transited field and accepting credentials
1185
1186
1187
1188 September 2004                                                 [Page 20]\f
1189
1190
1191
1192
1193
1194 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
1195
1196
1197    for cross-realm authentication. When the KDC applies such checks and
1198    accepts such cross-realm authentication it will set the TRANSITED-
1199    POLICY-CHECKED flag in the service tickets it issues based on the
1200    cross-realm TGT. A client MAY request that the KDCs not check the
1201    transited field by setting the DISABLE-TRANSITED-CHECK flag. KDCs are
1202    encouraged but not required to honor this flag.
1203
1204    Application servers MUST either do the transited-realm checks
1205    themselves, or reject cross-realm tickets without TRANSITED-POLICY-
1206    CHECKED set.
1207
1208 2.8. OK as Delegate
1209
1210    For some applications a client may need to delegate authority to a
1211    server to act on its behalf in contacting other services.  This
1212    requires that the client forward credentials to an intermediate
1213    server.  The ability for a client to obtain a service ticket to a
1214    server conveys no information to the client about whether the server
1215    should be trusted to accept delegated credentials.  The OK-AS-
1216    DELEGATE provides a way for a KDC to communicate local realm policy
1217    to a client regarding whether an intermediate server is trusted to
1218    accept such credentials.
1219
1220    The copy of the ticket flags in the encrypted part of the KDC reply
1221    may have the OK-AS-DELEGATE flag set to indicates to the client that
1222    the server specified in the ticket has been determined by policy of
1223    the realm to be a suitable recipient of delegation.  A client can use
1224    the presence of this flag to help it make a decision whether to
1225    delegate credentials (either grant a proxy or a forwarded ticket-
1226    granting ticket) to this server.  It is acceptable to ignore the
1227    value of this flag. When setting this flag, an administrator should
1228    consider the security and placement of the server on which the
1229    service will run, as well as whether the service requires the use of
1230    delegated credentials.
1231
1232 2.9. Other KDC options
1233
1234    There are three additional options which MAY be set in a client's
1235    request of the KDC.
1236
1237 2.9.1. Renewable-OK
1238
1239    The RENEWABLE-OK option indicates that the client will accept a
1240    renewable ticket if a ticket with the requested life cannot otherwise
1241    be provided. If a ticket with the requested life cannot be provided,
1242    then the KDC MAY issue a renewable ticket with a renew-till equal to
1243    the requested endtime. The value of the renew-till field MAY still be
1244    adjusted by site-determined limits or limits imposed by the
1245
1246
1247
1248 September 2004                                                 [Page 21]\f
1249
1250
1251
1252
1253
1254 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
1255
1256
1257    individual principal or server.
1258
1259 2.9.2. ENC-TKT-IN-SKEY
1260
1261    In its basic form the Kerberos protocol supports authentication in a
1262    client-server
1263     setting and is not well suited to authentication in a peer-to-peer
1264    environment because the long term key of the user does not remain on
1265    the workstation after initial login. Authentication of such peers may
1266    be supported by Kerberos in its user-to-user variant. The ENC-TKT-IN-
1267    SKEY option supports user-to-user authentication by allowing the KDC
1268    to issue a service ticket encrypted using the session key from
1269    another ticket-granting ticket issued to another user. The ENC-TKT-
1270    IN-SKEY option is honored only by the ticket-granting service. It
1271    indicates that the ticket to be issued for the end server is to be
1272    encrypted in the session key from the additional second ticket-
1273    granting ticket provided with the request. See section 3.3.3 for
1274    specific details.
1275
1276 2.9.3. Passwordless Hardware Authentication
1277
1278    The OPT-HARDWARE-AUTH option indicates that the client wishes to use
1279    some form of hardware authentication instead of or in addition to the
1280    client's password or other long-lived encryption key. OPT-HARDWARE-
1281    AUTH is honored only by the authentication service. If supported and
1282    allowed by policy, the KDC will return an errorcode
1283    KDC_ERR_PREAUTH_REQUIRED and include the required METHOD-DATA to
1284    perform such authentication.
1285
1286 3. Message Exchanges
1287
1288    The following sections describe the interactions between network
1289    clients and servers and the messages involved in those exchanges.
1290
1291 3.1. The Authentication Service Exchange
1292
1293                              Summary
1294
1295          Message direction       Message type    Section
1296          1. Client to Kerberos   KRB_AS_REQ      5.4.1
1297          2. Kerberos to client   KRB_AS_REP or   5.4.2
1298                                  KRB_ERROR       5.9.1
1299
1300
1301    The Authentication Service (AS) Exchange between the client and the
1302    Kerberos Authentication Server is initiated by a client when it
1303    wishes to obtain authentication credentials for a given server but
1304    currently holds no credentials. In its basic form, the client's
1305
1306
1307
1308 September 2004                                                 [Page 22]\f
1309
1310
1311
1312
1313
1314 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
1315
1316
1317    secret key is used for encryption and decryption. This exchange is
1318    typically used at the initiation of a login session to obtain
1319    credentials for a Ticket-Granting Server which will subsequently be
1320    used to obtain credentials for other servers (see section 3.3)
1321    without requiring further use of the client's secret key. This
1322    exchange is also used to request credentials for services which must
1323    not be mediated through the Ticket-Granting Service, but rather
1324    require knowledge of a principal's secret key, such as the password-
1325    changing service (the password changing service denies requests
1326    unless the requester can demonstrate knowledge of the user's old
1327    password; requiring this knowledge prevents unauthorized password
1328    changes by someone walking up to an unattended session).
1329
1330    This exchange does not by itself provide any assurance of the
1331    identity of the user (to authenticate a user logging on to a local
1332    system, the credentials obtained in the AS exchange may first be used
1333    in a TGS exchange to obtain credentials for a local server; those
1334    credentials must then be verified by a local server through
1335    successful completion of the Client/Server exchange).
1336
1337    The AS exchange consists of two messages: KRB_AS_REQ from the client
1338    to Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for
1339    these messages are described in sections 5.4.1, 5.4.2, and 5.9.1.
1340
1341    In the request, the client sends (in cleartext) its own identity and
1342    the identity of the server for which it is requesting credentials,
1343    other information about the credentials it is requesting, and a
1344    randomly generated nonce which can be used to detect replays, and to
1345    associate replies with the matching requests. This nonce MUST be
1346    generated randomly by the client and remembered for checking against
1347    the nonce in the expected reply. The response, KRB_AS_REP, contains a
1348    ticket for the client to present to the server, and a session key
1349    that will be shared by the client and the server.  The session key
1350    and additional information are encrypted in the client's secret key.
1351    The encrypted part of the KRB_AS_REP message also contains the nonce
1352    which MUST be matched with the nonce from the KRB_AS_REQ message.
1353
1354    Without pre-authentication, the authentication server does not know
1355    whether the client is actually the principal named in the request. It
1356    simply sends a reply without knowing or caring whether they are the
1357    same. This is acceptable because nobody but the principal whose
1358    identity was given in the request will be able to use the reply. Its
1359    critical information is encrypted in that principal's key. However,
1360    an attacker can send a KRB_AS_REQ message to get known plaintext in
1361    order to attack the principal's key. Especially if the key is based
1362    on a password, this may create a security exposure. So, the initial
1363    request supports an optional field that can be used to pass
1364    additional information that might be needed for the initial exchange.
1365
1366
1367
1368 September 2004                                                 [Page 23]\f
1369
1370
1371
1372
1373
1374 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
1375
1376
1377    This field SHOULD be used for pre-authentication as described in
1378    sections 3.1.1 and 5.2.7.
1379
1380    Various errors can occur; these are indicated by an error response
1381    (KRB_ERROR) instead of the KRB_AS_REP response. The error message is
1382    not encrypted. The KRB_ERROR message contains information which can
1383    be used to associate it with the message to which it replies. The
1384    contents of the KRB_ERROR message are not integrity-protected. As
1385    such, the client cannot detect replays, fabrications or
1386    modifications. A solution to this problem will be included in a
1387    future version of the protocol.
1388
1389 3.1.1. Generation of KRB_AS_REQ message
1390
1391    The client may specify a number of options in the initial request.
1392    Among these options are whether pre-authentication is to be
1393    performed; whether the requested ticket is to be renewable,
1394    proxiable, or forwardable; whether it should be postdated or allow
1395    postdating of derivative tickets; and whether a renewable ticket will
1396    be accepted in lieu of a non-renewable ticket if the requested ticket
1397    expiration date cannot be satisfied by a non-renewable ticket (due to
1398    configuration constraints).
1399
1400    The client prepares the KRB_AS_REQ message and sends it to the KDC.
1401
1402 3.1.2. Receipt of KRB_AS_REQ message
1403
1404    If all goes well, processing the KRB_AS_REQ message will result in
1405    the creation of a ticket for the client to present to the server. The
1406    format for the ticket is described in section 5.3.
1407
1408    Because Kerberos can run over unreliable transports such as UDP, the
1409    KDC MUST be prepared to retransmit responses in case they are lost.
1410    If a KDC receives a request identical to one it has recently
1411    successfully processed, the KDC MUST respond with a KRB_AS_REP
1412    message rather than a replay error.  In order to reduce ciphertext
1413    given to a potential attacker, KDCs MAY send the same response
1414    generated when the request was first handled. KDCs MUST obey this
1415    replay behavior even if the actual transport in use is reliable.
1416
1417 3.1.3. Generation of KRB_AS_REP message
1418
1419    The authentication server looks up the client and server principals
1420    named in the KRB_AS_REQ in its database, extracting their respective
1421    keys. If the requested client principal named in the request is not
1422    known because it doesn't exist in the KDC's principal database, then
1423    an error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is returned.
1424
1425
1426
1427
1428 September 2004                                                 [Page 24]\f
1429
1430
1431
1432
1433
1434 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
1435
1436
1437    If required, the server pre-authenticates the request, and if the
1438    pre-authentication check fails, an error message with the code
1439    KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is
1440    required, but was not present in the request, an error message with
1441    the code KDC_ERR_PREAUTH_REQUIRED is returned and a METHOD-DATA
1442    object will be stored in the e-data field of the KRB-ERROR message to
1443    specify which pre-authentication mechanisms are acceptable.  Usually
1444    this will include PA-ETYPE-INFO and/or PA-ETYPE-INFO2 elements as
1445    described below. If the server cannot accommodate any encryption type
1446    requested by the client, an error message with code
1447    KDC_ERR_ETYPE_NOSUPP is returned. Otherwise the KDC generates a
1448    'random' session key, meaning that, among other things, it should be
1449    impossible to guess the next session key based on knowledge of past
1450    session keys. While this can be achieved in a pseudo-random number
1451    generator if it is based on cryptographic principles, it is more
1452    desirable to use a truly random number generator, such as one based
1453    on measurements of random physical phenomena.  See [RFC1750] for an
1454    in depth discussion of randomness.
1455
1456    When responding to an AS request, if there are multiple encryption
1457    keys registered for a client in the Kerberos database, then the etype
1458    field from the AS request is used by the KDC to select the encryption
1459    method to be used to protect the encrypted part of the KRB_AS_REP
1460    message which is sent to the client. If there is more than one
1461    supported strong encryption type in the etype list, the KDC SHOULD
1462    use the first valid strong etype for which an encryption key is
1463    available.
1464
1465    When the user's key is generated from a password or pass phrase, the
1466    string-to-key function for the particular encryption key type is
1467    used, as specified in [@KCRYPTO]. The salt value and additional
1468    parameters for the string-to-key function have default values
1469    (specified by section 4 and by the encryption mechanism
1470    specification, respectively) that may be overridden by pre-
1471    authentication data (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA-
1472    ETYPE-INFO2, etc). Since the KDC is presumed to store a copy of the
1473    resulting key only, these values should not be changed for password-
1474    based keys except when changing the principal's key.
1475
1476    When the AS server is to include pre-authentication data in a KRB-
1477    ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE-INFO,
1478    if the etype field of the client's AS-REQ lists at least one "newer"
1479    encryption type.  Otherwise (when the etype field of the client's AS-
1480    REQ does not list any "newer" encryption types) it MUST send both,
1481    PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an entry for each
1482    enctype).  A "newer" enctype is any enctype first officially
1483    specified concurrently with or subsequent to the issue of this RFC.
1484    The enctypes DES, 3DES or RC4 and any defined in [RFC1510] are not
1485
1486
1487
1488 September 2004                                                 [Page 25]\f
1489
1490
1491
1492
1493
1494 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
1495
1496
1497    "newer" enctypes.
1498
1499    It is not possible to reliably generate a user's key given a pass
1500    phrase without contacting the KDC, since it will not be known whether
1501    alternate salt or parameter values are required.
1502
1503    The KDC will attempt to assign the type of the random session key
1504    from the list of methods in the etype field. The KDC will select the
1505    appropriate type using the list of methods provided together with
1506    information from the Kerberos database indicating acceptable
1507    encryption methods for the application server. The KDC will not issue
1508    tickets with a weak session key encryption type.
1509
1510    If the requested start time is absent, indicates a time in the past,
1511    or is within the window of acceptable clock skew for the KDC and the
1512    POSTDATE option has not been specified, then the start time of the
1513    ticket is set to the authentication server's current time. If it
1514    indicates a time in the future beyond the acceptable clock skew, but
1515    the POSTDATED option has not been specified then the error
1516    KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the requested start
1517    time is checked against the policy of the local realm (the
1518    administrator might decide to prohibit certain types or ranges of
1519    postdated tickets), and if acceptable, the ticket's start time is set
1520    as requested and the INVALID flag is set in the new ticket. The
1521    postdated ticket MUST be validated before use by presenting it to the
1522    KDC after the start time has been reached.
1523
1524    The expiration time of the ticket will be set to the earlier of the
1525    requested endtime and a time determined by local policy, possibly
1526    determined using realm or principal specific factors. For example,
1527    the expiration time MAY be set to the earliest of the following:
1528
1529       *  The expiration time (endtime) requested in the KRB_AS_REQ
1530          message.
1531
1532       *  The ticket's start time plus the maximum allowable lifetime
1533          associated with the client principal from the authentication
1534          server's database.
1535
1536       *  The ticket's start time plus the maximum allowable lifetime
1537          associated with the server principal.
1538
1539       *  The ticket's start time plus the maximum lifetime set by the
1540          policy of the local realm.
1541
1542    If the requested expiration time minus the start time (as determined
1543    above) is less than a site-determined minimum lifetime, an error
1544    message with code KDC_ERR_NEVER_VALID is returned. If the requested
1545
1546
1547
1548 September 2004                                                 [Page 26]\f
1549
1550
1551
1552
1553
1554 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
1555
1556
1557    expiration time for the ticket exceeds what was determined as above,
1558    and if the 'RENEWABLE-OK' option was requested, then the 'RENEWABLE'
1559    flag is set in the new ticket, and the renew-till value is set as if
1560    the 'RENEWABLE' option were requested (the field and option names are
1561    described fully in section 5.4.1).
1562
1563    If the RENEWABLE option has been requested or if the RENEWABLE-OK
1564    option has been set and a renewable ticket is to be issued, then the
1565    renew-till field MAY be set to the earliest of:
1566
1567       *  Its requested value.
1568
1569       *  The start time of the ticket plus the minimum of the two
1570          maximum renewable lifetimes associated with the principals'
1571          database entries.
1572
1573       *  The start time of the ticket plus the maximum renewable
1574          lifetime set by the policy of the local realm.
1575
1576    The flags field of the new ticket will have the following options set
1577    if they have been requested and if the policy of the local realm
1578    allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE.
1579    If the new ticket is postdated (the start time is in the future), its
1580    INVALID flag will also be set.
1581
1582    If all of the above succeed, the server will encrypt the ciphertext
1583    part of the ticket using the encryption key extracted from the server
1584    principal's record in the Kerberos database using the encryption type
1585    associated with the server principal's key (this choice is NOT
1586    affected by the etype field in the request). It then formats a
1587    KRB_AS_REP message (see section 5.4.2), copying the addresses in the
1588    request into the caddr of the response, placing any required pre-
1589    authentication data into the padata of the response, and encrypts the
1590    ciphertext part in the client's key using an acceptable encryption
1591    method requested in the etype field of the request, or in some key
1592    specified by pre-authentication mechanisms being used.
1593
1594 3.1.4. Generation of KRB_ERROR message
1595
1596    Several errors can occur, and the Authentication Server responds by
1597    returning an error message, KRB_ERROR, to the client, with the error-
1598    code and e-text fields set to appropriate values. The error message
1599    contents and details are described in Section 5.9.1.
1600
1601 3.1.5. Receipt of KRB_AS_REP message
1602
1603    If the reply message type is KRB_AS_REP, then the client verifies
1604    that the cname and crealm fields in the cleartext portion of the
1605
1606
1607
1608 September 2004                                                 [Page 27]\f
1609
1610
1611
1612
1613
1614 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
1615
1616
1617    reply match what it requested. If any padata fields are present, they
1618    may be used to derive the proper secret key to decrypt the message.
1619    The client decrypts the encrypted part of the response using its
1620    secret key, verifies that the nonce in the encrypted part matches the
1621    nonce it supplied in its request (to detect replays). It also
1622    verifies that the sname and srealm in the response match those in the
1623    request (or are otherwise expected values), and that the host address
1624    field is also correct. It then stores the ticket, session key, start
1625    and expiration times, and other information for later use. The last-
1626    req field (and the deprecated key-expiration field) from the
1627    encrypted part of the response MAY be checked to notify the user of
1628    impending key expiration. This enables the client program to suggest
1629    remedial action, such as a password change.
1630
1631    Upon validation of the KRB_AS_REP message (by checking the returned
1632    nonce against that sent in the KRB_AS_REQ message) the client knows
1633    that the current time on the KDC is that read from the authtime field
1634    of the encrypted part of the reply. The client can optionally use
1635    this value for clock synchronization in subsequent messages by
1636    recording with the ticket the difference (offset) between the
1637    authtime value and the local clock. This offset can then be used by
1638    the same user to adjust the time read from the system clock when
1639    generating messages [DGT96].
1640
1641    This technique MUST be used when adjusting for clock skew instead of
1642    directly changing the system clock because the KDC reply is only
1643    authenticated to the user whose secret key was used, but not to the
1644    system or workstation. If the clock were adjusted, an attacker
1645    colluding with a user logging into a workstation could agree on a
1646    password, resulting in a KDC reply that would be correctly validated
1647    even though it did not originate from a KDC trusted by the
1648    workstation.
1649
1650    Proper decryption of the KRB_AS_REP message is not sufficient for the
1651    host to verify the identity of the user; the user and an attacker
1652    could cooperate to generate a KRB_AS_REP format message which
1653    decrypts properly but is not from the proper KDC. If the host wishes
1654    to verify the identity of the user, it MUST require the user to
1655    present application credentials which can be verified using a
1656    securely-stored secret key for the host. If those credentials can be
1657    verified, then the identity of the user can be assured.
1658
1659 3.1.6. Receipt of KRB_ERROR message
1660
1661    If the reply message type is KRB_ERROR, then the client interprets it
1662    as an error and performs whatever application-specific tasks are
1663    necessary to recover.
1664
1665
1666
1667
1668 September 2004                                                 [Page 28]\f
1669
1670
1671
1672
1673
1674 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
1675
1676
1677 3.2. The Client/Server Authentication Exchange
1678
1679                                 Summary
1680    Message direction                         Message type    Section
1681    Client to Application server              KRB_AP_REQ      5.5.1
1682    [optional] Application server to client   KRB_AP_REP or   5.5.2
1683                                              KRB_ERROR       5.9.1
1684
1685    The client/server authentication (CS) exchange is used by network
1686    applications to authenticate the client to the server and vice versa.
1687    The client MUST have already acquired credentials for the server
1688    using the AS or TGS exchange.
1689
1690 3.2.1. The KRB_AP_REQ message
1691
1692    The KRB_AP_REQ contains authentication information which SHOULD be
1693    part of the first message in an authenticated transaction. It
1694    contains a ticket, an authenticator, and some additional bookkeeping
1695    information (see section 5.5.1 for the exact format). The ticket by
1696    itself is insufficient to authenticate a client, since tickets are
1697    passed across the network in cleartext (tickets contain both an
1698    encrypted and unencrypted portion, so cleartext here refers to the
1699    entire unit, which can be copied from one message and replayed in
1700    another without any cryptographic skill), so the authenticator is
1701    used to prevent invalid replay of tickets by proving to the server
1702    that the client knows the session key of the ticket and thus is
1703    entitled to use the ticket. The KRB_AP_REQ message is referred to
1704    elsewhere as the 'authentication header.'
1705
1706 3.2.2. Generation of a KRB_AP_REQ message
1707
1708    When a client wishes to initiate authentication to a server, it
1709    obtains (either through a credentials cache, the AS exchange, or the
1710    TGS exchange) a ticket and session key for the desired service. The
1711    client MAY re-use any tickets it holds until they expire. To use a
1712    ticket the client constructs a new Authenticator from the system
1713    time, its name, and optionally an application specific checksum, an
1714    initial sequence number to be used in KRB_SAFE or KRB_PRIV messages,
1715    and/or a session subkey to be used in negotiations for a session key
1716    unique to this particular session.  Authenticators MUST NOT be re-
1717    used and SHOULD be rejected if replayed to a server.  Note that this
1718    can make applications based on unreliable transports difficult to
1719    code correctly. If the transport might deliver duplicated messages,
1720    either a new authenticator MUST be generated for each retry, or the
1721    application server MUST match requests and replies and replay the
1722    first reply in response to a detected duplicate.
1723
1724    If a sequence number is to be included, it SHOULD be randomly chosen
1725
1726
1727
1728 September 2004                                                 [Page 29]\f
1729
1730
1731
1732
1733
1734 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
1735
1736
1737    so that even after many messages have been exchanged it is not likely
1738    to collide with other sequence numbers in use.
1739
1740    The client MAY indicate a requirement of mutual authentication or the
1741    use of a session-key based ticket (for user-to-user authentication -
1742    see section 3.7) by setting the appropriate flag(s) in the ap-options
1743    field of the message.
1744
1745    The Authenticator is encrypted in the session key and combined with
1746    the ticket to form the KRB_AP_REQ message which is then sent to the
1747    end server along with any additional application-specific
1748    information.
1749
1750 3.2.3. Receipt of KRB_AP_REQ message
1751
1752    Authentication is based on the server's current time of day (clocks
1753    MUST be loosely synchronized), the authenticator, and the ticket.
1754    Several errors are possible. If an error occurs, the server is
1755    expected to reply to the client with a KRB_ERROR message. This
1756    message MAY be encapsulated in the application protocol if its raw
1757    form is not acceptable to the protocol.  The format of error messages
1758    is described in section 5.9.1.
1759
1760    The algorithm for verifying authentication information is as follows.
1761    If the message type is not KRB_AP_REQ, the server returns the
1762    KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the Ticket
1763    in the KRB_AP_REQ is not one the server can use (e.g., it indicates
1764    an old key, and the server no longer possesses a copy of the old
1765    key), the KRB_AP_ERR_BADKEYVER error is returned. If the USE-SESSION-
1766    KEY flag is set in the ap-options field, it indicates to the server
1767    that user-to-user authentication is in use, and that the ticket is
1768    encrypted in the session key from the server's ticket-granting ticket
1769    rather than in the server's secret key. See section 3.7 for a more
1770    complete description of the effect of user-to-user authentication on
1771    all messages in the Kerberos protocol.
1772
1773    Since it is possible for the server to be registered in multiple
1774    realms, with different keys in each, the srealm field in the
1775    unencrypted portion of the ticket in the KRB_AP_REQ is used to
1776    specify which secret key the server should use to decrypt that
1777    ticket. The KRB_AP_ERR_NOKEY error code is returned if the server
1778    doesn't have the proper key to decipher the ticket.
1779
1780    The ticket is decrypted using the version of the server's key
1781    specified by the ticket. If the decryption routines detect a
1782    modification of the ticket (each encryption system MUST provide
1783    safeguards to detect modified ciphertext), the
1784    KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that
1785
1786
1787
1788 September 2004                                                 [Page 30]\f
1789
1790
1791
1792
1793
1794 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
1795
1796
1797    different keys were used to encrypt and decrypt).
1798
1799    The authenticator is decrypted using the session key extracted from
1800    the decrypted ticket. If decryption shows it to have been modified,
1801    the KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of
1802    the client from the ticket are compared against the same fields in
1803    the authenticator.  If they don't match, the KRB_AP_ERR_BADMATCH
1804    error is returned; this normally is caused by a client error or
1805    attempted attack. The addresses in the ticket (if any) are then
1806    searched for an address matching the operating-system reported
1807    address of the client. If no match is found or the server insists on
1808    ticket addresses but none are present in the ticket, the
1809    KRB_AP_ERR_BADADDR error is returned. If the local (server) time and
1810    the client time in the authenticator differ by more than the
1811    allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW error is
1812    returned.
1813
1814    Unless the application server provides its own suitable means to
1815    protect against replay (for example, a challenge-response sequence
1816    initiated by the server after authentication, or use of a server-
1817    generated encryption subkey), the server MUST utilize a replay cache
1818    to remember any authenticator presented within the allowable clock
1819    skew. Careful analysis of the application protocol and implementation
1820    is recommended before eliminating this cache. The replay cache will
1821    store at least the server name, along with the client name, time and
1822    microsecond fields from the recently-seen authenticators and if a
1823    matching tuple is found, the KRB_AP_ERR_REPEAT error is returned.
1824    Note that the rejection here is restricted to authenticators from the
1825    same principal to the same server. Other client principals
1826    communicating with the same server principal should not have their
1827    authenticators rejected if the time and microsecond fields happen to
1828    match some other client's authenticator.
1829
1830    If a server loses track of authenticators presented within the
1831    allowable clock skew, it MUST reject all requests until the clock
1832    skew interval has passed, providing assurance that any lost or
1833    replayed authenticators will fall outside the allowable clock skew
1834    and can no longer be successfully replayed.  If this were not done,
1835    an attacker could subvert the authentication by recording the ticket
1836    and authenticator sent over the network to a server and replaying
1837    them following an event that caused the server to lose track of
1838    recently seen authenticators.
1839
1840    Implementation note: If a client generates multiple requests to the
1841    KDC with the same timestamp, including the microsecond field, all but
1842    the first of the requests received will be rejected as replays. This
1843    might happen, for example, if the resolution of the client's clock is
1844    too coarse.  Client implementations SHOULD ensure that the timestamps
1845
1846
1847
1848 September 2004                                                 [Page 31]\f
1849
1850
1851
1852
1853
1854 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
1855
1856
1857    are not reused, possibly by incrementing the microseconds field in
1858    the time stamp when the clock returns the same time for multiple
1859    requests.
1860
1861    If multiple servers (for example, different services on one machine,
1862    or a single service implemented on multiple machines) share a service
1863    principal (a practice we do not recommend in general, but acknowledge
1864    will be used in some cases), they MUST either share this replay
1865    cache, or the application protocol MUST be designed so as to
1866    eliminate the need for it. Note that this applies to all of the
1867    services, if any of the application protocols does not have replay
1868    protection built in; an authenticator used with such a service could
1869    later be replayed to a different service with the same service
1870    principal but no replay protection, if the former doesn't record the
1871    authenticator information in the common replay cache.
1872
1873    If a sequence number is provided in the authenticator, the server
1874    saves it for later use in processing KRB_SAFE and/or KRB_PRIV
1875    messages. If a subkey is present, the server either saves it for
1876    later use or uses it to help generate its own choice for a subkey to
1877    be returned in a KRB_AP_REP message.
1878
1879    The server computes the age of the ticket: local (server) time minus
1880    the start time inside the Ticket. If the start time is later than the
1881    current time by more than the allowable clock skew or if the INVALID
1882    flag is set in the ticket, the KRB_AP_ERR_TKT_NYV error is returned.
1883    Otherwise, if the current time is later than end time by more than
1884    the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error is
1885    returned.
1886
1887    If all these checks succeed without an error, the server is assured
1888    that the client possesses the credentials of the principal named in
1889    the ticket and thus, the client has been authenticated to the server.
1890
1891    Passing these checks provides only authentication of the named
1892    principal; it does not imply authorization to use the named service.
1893    Applications MUST make a separate authorization decision based upon
1894    the authenticated name of the user, the requested operation, local
1895    access control information such as that contained in a .k5login or
1896    .k5users file, and possibly a separate distributed authorization
1897    service.
1898
1899 3.2.4. Generation of a KRB_AP_REP message
1900
1901    Typically, a client's request will include both the authentication
1902    information and its initial request in the same message, and the
1903    server need not explicitly reply to the KRB_AP_REQ. However, if
1904    mutual authentication (not only authenticating the client to the
1905
1906
1907
1908 September 2004                                                 [Page 32]\f
1909
1910
1911
1912
1913
1914 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
1915
1916
1917    server, but also the server to the client) is being performed, the
1918    KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options
1919    field, and a KRB_AP_REP message is required in response. As with the
1920    error message, this message MAY be encapsulated in the application
1921    protocol if its "raw" form is not acceptable to the application's
1922    protocol. The timestamp and microsecond field used in the reply MUST
1923    be the client's timestamp and microsecond field (as provided in the
1924    authenticator). If a sequence number is to be included, it SHOULD be
1925    randomly chosen as described above for the authenticator. A subkey
1926    MAY be included if the server desires to negotiate a different
1927    subkey. The KRB_AP_REP message is encrypted in the session key
1928    extracted from the ticket.
1929
1930    Note that in the Kerberos version 4 protocol, the timestamp in the
1931    reply was the client's timestamp plus one. This is not necessary in
1932    version 5 because version 5 messages are formatted in such a way that
1933    it is not possible to create the reply by judicious message surgery
1934    (even in encrypted form) without knowledge of the appropriate
1935    encryption keys.
1936
1937 3.2.5. Receipt of KRB_AP_REP message
1938
1939    If a KRB_AP_REP message is returned, the client uses the session key
1940    from the credentials obtained for the server to decrypt the message
1941    (Note that for encrypting the KRB_AP_REP message, the sub-session key
1942    is not used, even if present in the Authenticator), and verifies that
1943    the timestamp and microsecond fields match those in the Authenticator
1944    it sent to the server. If they match, then the client is assured that
1945    the server is genuine. The sequence number and subkey (if present)
1946    are retained for later use.
1947
1948 3.2.6. Using the encryption key
1949
1950    After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and
1951    server share an encryption key which can be used by the application.
1952    In some cases, the use of this session key will be implicit in the
1953    protocol; in others the method of use must be chosen from several
1954    alternatives. The actual encryption key to be used for KRB_PRIV,
1955    KRB_SAFE, or other application-specific uses MAY be chosen by the
1956    application based on the session key from the ticket and subkeys in
1957    the KRB_AP_REP message and the authenticator.  Implementations of the
1958    protocol MAY provide routines to choose subkeys based on session keys
1959    and random numbers and to generate a negotiated key to be returned in
1960    the KRB_AP_REP message.
1961
1962    To mitigate the effect of failures in random number generation on the
1963    client it is strongly encouraged that any key derived by an
1964    application for subsequent use include the full key entropy derived
1965
1966
1967
1968 September 2004                                                 [Page 33]\f
1969
1970
1971
1972
1973
1974 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
1975
1976
1977    from the KDC generated session key carried in the ticket. We leave
1978    the protocol negotiations of how to use the key (e.g. selecting an
1979    encryption or checksum type) to the application programmer; the
1980    Kerberos protocol does not constrain the implementation options, but
1981    an example of how this might be done follows.
1982
1983    One way that an application may choose to negotiate a key to be used
1984    for subsequent integrity and privacy protection is for the client to
1985    propose a key in the subkey field of the authenticator. The server
1986    can then choose a key using the proposed key from the client as
1987    input, returning the new subkey in the subkey field of the
1988    application reply. This key could then be used for subsequent
1989    communication.
1990
1991    With both the one-way and mutual authentication exchanges, the peers
1992    should take care not to send sensitive information to each other
1993    without proper assurances. In particular, applications that require
1994    privacy or integrity SHOULD use the KRB_AP_REP response from the
1995    server to client to assure both client and server of their peer's
1996    identity. If an application protocol requires privacy of its
1997    messages, it can use the KRB_PRIV message (section 3.5). The KRB_SAFE
1998    message (section 3.4) can be used to assure integrity.
1999
2000 3.3. The Ticket-Granting Service (TGS) Exchange
2001
2002                              Summary
2003          Message direction       Message type     Section
2004          1. Client to Kerberos   KRB_TGS_REQ      5.4.1
2005          2. Kerberos to client   KRB_TGS_REP or   5.4.2
2006                                  KRB_ERROR        5.9.1
2007
2008    The TGS exchange between a client and the Kerberos Ticket-Granting
2009    Server is initiated by a client when it wishes to obtain
2010    authentication credentials for a given server (which might be
2011    registered in a remote realm), when it wishes to renew or validate an
2012    existing ticket, or when it wishes to obtain a proxy ticket. In the
2013    first case, the client must already have acquired a ticket for the
2014    Ticket-Granting Service using the AS exchange (the ticket-granting
2015    ticket is usually obtained when a client initially authenticates to
2016    the system, such as when a user logs in). The message format for the
2017    TGS exchange is almost identical to that for the AS exchange.  The
2018    primary difference is that encryption and decryption in the TGS
2019    exchange does not take place under the client's key. Instead, the
2020    session key from the ticket-granting ticket or renewable ticket, or
2021    sub-session key from an Authenticator is used. As is the case for all
2022    application servers, expired tickets are not accepted by the TGS, so
2023    once a renewable or ticket-granting ticket expires, the client must
2024    use a separate exchange to obtain valid tickets.
2025
2026
2027
2028 September 2004                                                 [Page 34]\f
2029
2030
2031
2032
2033
2034 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
2035
2036
2037    The TGS exchange consists of two messages: A request (KRB_TGS_REQ)
2038    from the client to the Kerberos Ticket-Granting Server, and a reply
2039    (KRB_TGS_REP or KRB_ERROR). The KRB_TGS_REQ message includes
2040    information authenticating the client plus a request for credentials.
2041    The authentication information consists of the authentication header
2042    (KRB_AP_REQ) which includes the client's previously obtained ticket-
2043    granting, renewable, or invalid ticket.  In the ticket-granting
2044    ticket and proxy cases, the request MAY include one or more of: a
2045    list of network addresses, a collection of typed authorization data
2046    to be sealed in the ticket for authorization use by the application
2047    server, or additional tickets (the use of which are described later).
2048    The TGS reply (KRB_TGS_REP) contains the requested credentials,
2049    encrypted in the session key from the ticket-granting ticket or
2050    renewable ticket, or if present, in the sub-session key from the
2051    Authenticator (part of the authentication header). The KRB_ERROR
2052    message contains an error code and text explaining what went wrong.
2053    The KRB_ERROR message is not encrypted. The KRB_TGS_REP message
2054    contains information which can be used to detect replays, and to
2055    associate it with the message to which it replies. The KRB_ERROR
2056    message also contains information which can be used to associate it
2057    with the message to which it replies. The same comments about
2058    integrity protection of KRB_ERROR messages mentioned in section 3.1
2059    apply to the TGS exchange.
2060
2061 3.3.1. Generation of KRB_TGS_REQ message
2062
2063    Before sending a request to the ticket-granting service, the client
2064    MUST determine in which realm the application server is believed to
2065    be registered. This can be accomplished in several ways. It might be
2066    known beforehand (since the realm is part of the principal
2067    identifier), it might be stored in a nameserver, or it might be
2068    obtained from a configuration file. If the realm to be used is
2069    obtained from a nameserver, there is a danger of being spoofed if the
2070    nameservice providing the realm name is not authenticated.  This
2071    might result in the use of a realm which has been compromised, and
2072    would result in an attacker's ability to compromise the
2073    authentication of the application server to the client.
2074
2075    If the client knows the service principal name and realm and it does
2076    not already possess a ticket-granting ticket for the appropriate
2077    realm, then one must be obtained. This is first attempted by
2078    requesting a ticket-granting ticket for the destination realm from a
2079    Kerberos server for which the client possesses a ticket-granting
2080    ticket (using the KRB_TGS_REQ message recursively). The Kerberos
2081    server MAY return a TGT for the desired realm in which case one can
2082    proceed. Alternatively, the Kerberos server MAY return a TGT for a
2083    realm which is 'closer' to the desired realm (further along the
2084    standard hierarchical path between the client's realm and the
2085
2086
2087
2088 September 2004                                                 [Page 35]\f
2089
2090
2091
2092
2093
2094 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
2095
2096
2097    requested realm server's realm). It should be noted in this case that
2098    misconfiguration of the Kerberos servers may cause loops in the
2099    resulting authentication path, which the client should be careful to
2100    detect and avoid.
2101
2102    If the Kerberos server returns a TGT for a 'closer' realm other than
2103    the desired realm, the client MAY use local policy configuration to
2104    verify that the authentication path used is an acceptable one.
2105    Alternatively, a client MAY choose its own authentication path,
2106    rather than relying on the Kerberos server to select one. In either
2107    case, any policy or configuration information used to choose or
2108    validate authentication paths, whether by the Kerberos server or
2109    client, MUST be obtained from a trusted source.
2110
2111    When a client obtains a ticket-granting ticket that is 'closer' to
2112    the destination realm, the client MAY cache this ticket and reuse it
2113    in future KRB-TGS exchanges with services in the 'closer' realm.
2114    However, if the client were to obtain a ticket-granting ticket for
2115    the 'closer' realm by starting at the initial KDC rather than as part
2116    of obtaining another ticket, then a shorter path to the 'closer'
2117    realm might be used. This shorter path may be desirable because fewer
2118    intermediate KDCs would know the session key of the ticket involved.
2119    For this reason, clients SHOULD evaluate whether they trust the
2120    realms transited in obtaining the 'closer' ticket when making a
2121    decision to use the ticket in future.
2122
2123    Once the client obtains a ticket-granting ticket for the appropriate
2124    realm, it determines which Kerberos servers serve that realm, and
2125    contacts one. The list might be obtained through a configuration file
2126    or network service or it MAY be generated from the name of the realm;
2127    as long as the secret keys exchanged by realms are kept secret, only
2128    denial of service results from using a false Kerberos server.
2129
2130     As in the AS exchange, the client MAY specify a number of options in
2131    the KRB_TGS_REQ message. One of these options is the ENC-TKT-IN-SKEY
2132    option used for user-to-user authentication. An overview of user-to-
2133    user authentication can be found in section 3.7. When generating the
2134    KRB_TGS_REQ message, this option indicates that the client is
2135    including a ticket-granting ticket obtained from the application
2136    server in the additional tickets field of the request and that the
2137    KDC SHOULD encrypt the ticket for the application server using the
2138    session key from this additional ticket, instead of using a server
2139    key from the principal database.
2140
2141    The client prepares the KRB_TGS_REQ message, providing an
2142    authentication header as an element of the padata field, and
2143    including the same fields as used in the KRB_AS_REQ message along
2144    with several optional fields: the enc-authorizatfion-data field for
2145
2146
2147
2148 September 2004                                                 [Page 36]\f
2149
2150
2151
2152
2153
2154 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
2155
2156
2157    application server use and additional tickets required by some
2158    options.
2159
2160    In preparing the authentication header, the client can select a sub-
2161    session key under which the response from the Kerberos server will be
2162    encrypted. If the client selects a sub-session key, care must be
2163    taken to ensure the randomness of the selected sub-session key.
2164
2165    If the sub-session key is not specified, the session key from the
2166    ticket-granting ticket will be used. If the enc-authorization-data is
2167    present, it MUST be encrypted in the sub-session key, if present,
2168    from the authenticator portion of the authentication header, or if
2169    not present, using the session key from the ticket-granting ticket.
2170
2171    Once prepared, the message is sent to a Kerberos server for the
2172    destination realm.
2173
2174 3.3.2. Receipt of KRB_TGS_REQ message
2175
2176    The KRB_TGS_REQ message is processed in a manner similar to the
2177    KRB_AS_REQ message, but there are many additional checks to be
2178    performed. First, the Kerberos server MUST determine which server the
2179    accompanying ticket is for and it MUST select the appropriate key to
2180    decrypt it. For a normal KRB_TGS_REQ message, it will be for the
2181    ticket granting service, and the TGS's key will be used. If the TGT
2182    was issued by another realm, then the appropriate inter-realm key
2183    MUST be used. If the accompanying ticket is not a ticket-granting
2184    ticket for the current realm, but is for an application server in the
2185    current realm, the RENEW, VALIDATE, or PROXY options are specified in
2186    the request, and the server for which a ticket is requested is the
2187    server named in the accompanying ticket, then the KDC will decrypt
2188    the ticket in the authentication header using the key of the server
2189    for which it was issued. If no ticket can be found in the padata
2190    field, the KDC_ERR_PADATA_TYPE_NOSUPP error is returned.
2191
2192    Once the accompanying ticket has been decrypted, the user-supplied
2193    checksum in the Authenticator MUST be verified against the contents
2194    of the request, and the message rejected if the checksums do not
2195    match (with an error code of KRB_AP_ERR_MODIFIED) or if the checksum
2196    is not collision-proof (with an error code of
2197    KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported, the
2198    KDC_ERR_SUMTYPE_NOSUPP error is returned. If the authorization-data
2199    are present, they are decrypted using the sub-session key from the
2200    Authenticator.
2201
2202    If any of the decryptions indicate failed integrity checks, the
2203    KRB_AP_ERR_BAD_INTEGRITY error is returned.
2204
2205
2206
2207
2208 September 2004                                                 [Page 37]\f
2209
2210
2211
2212
2213
2214 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
2215
2216
2217    As discussed in section 3.1.2, the KDC MUST send a valid KRB_TGS_REP
2218    message if it receives a KRB_TGS_REQ message identical to one it has
2219    recently processed. However, if the authenticator is a replay, but
2220    the rest of the request is not identical, then the KDC SHOULD return
2221    KRB_AP_ERR_REPEAT.
2222
2223 3.3.3. Generation of KRB_TGS_REP message
2224
2225    The KRB_TGS_REP message shares its format with the KRB_AS_REP
2226    (KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The
2227    detailed specification is in section 5.4.2.
2228
2229    The response will include a ticket for the requested server or for a
2230    ticket granting server of an intermediate KDC to be contacted to
2231    obtain the requested ticket. The Kerberos database is queried to
2232    retrieve the record for the appropriate server (including the key
2233    with which the ticket will be encrypted). If the request is for a
2234    ticket-granting ticket for a remote realm, and if no key is shared
2235    with the requested realm, then the Kerberos server will select the
2236    realm 'closest' to the requested realm with which it does share a
2237    key, and use that realm instead.  This is the only case where the
2238    response for the KDC will be for a different server than that
2239    requested by the client.
2240
2241    By default, the address field, the client's name and realm, the list
2242    of transited realms, the time of initial authentication, the
2243    expiration time, and the authorization data of the newly-issued
2244    ticket will be copied from the ticket-granting ticket (TGT) or
2245    renewable ticket. If the transited field needs to be updated, but the
2246    transited type is not supported, the KDC_ERR_TRTYPE_NOSUPP error is
2247    returned.
2248
2249    If the request specifies an endtime, then the endtime of the new
2250    ticket is set to the minimum of (a) that request, (b) the endtime
2251    from the TGT, and (c) the starttime of the TGT plus the minimum of
2252    the maximum life for the application server and the maximum life for
2253    the local realm (the maximum life for the requesting principal was
2254    already applied when the TGT was issued). If the new ticket is to be
2255    a renewal, then the endtime above is replaced by the minimum of (a)
2256    the value of the renew_till field of the ticket and (b) the starttime
2257    for the new ticket plus the life (endtime-starttime) of the old
2258    ticket.
2259
2260    If the FORWARDED option has been requested, then the resulting ticket
2261    will contain the addresses specified by the client. This option will
2262    only be honored if the FORWARDABLE flag is set in the TGT. The PROXY
2263    option is similar; the resulting ticket will contain the addresses
2264    specified by the client. It will be honored only if the PROXIABLE
2265
2266
2267
2268 September 2004                                                 [Page 38]\f
2269
2270
2271
2272
2273
2274 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
2275
2276
2277    flag in the TGT is set. The PROXY option will not be honored on
2278    requests for additional ticket-granting tickets.
2279
2280    If the requested start time is absent, indicates a time in the past,
2281    or is within the window of acceptable clock skew for the KDC and the
2282    POSTDATE option has not been specified, then the start time of the
2283    ticket is set to the authentication server's current time. If it
2284    indicates a time in the future beyond the acceptable clock skew, but
2285    the POSTDATED option has not been specified or the MAY-POSTDATE flag
2286    is not set in the TGT, then the error KDC_ERR_CANNOT_POSTDATE is
2287    returned. Otherwise, if the ticket-granting ticket has the MAY-
2288    POSTDATE flag set, then the resulting ticket will be postdated and
2289    the requested starttime is checked against the policy of the local
2290    realm. If acceptable, the ticket's start time is set as requested,
2291    and the INVALID flag is set. The postdated ticket MUST be validated
2292    before use by presenting it to the KDC after the starttime has been
2293    reached. However, in no case may the starttime, endtime, or renew-
2294    till time of a newly-issued postdated ticket extend beyond the renew-
2295    till time of the ticket-granting ticket.
2296
2297    If the ENC-TKT-IN-SKEY option has been specified and an additional
2298    ticket has been included in the request, it indicates that the client
2299    is using user- to-user authentication to prove its identity to a
2300    server that does not have access to a persistent key. Section 3.7
2301    describes the affect of this option on the entire Kerberos protocol.
2302    When generating the KRB_TGS_REP message, this option in the
2303    KRB_TGS_REQ message tells the KDC to decrypt the additional ticket
2304    using the key for the server to which the additional ticket was
2305    issued and verify that it is a ticket-granting ticket. If the name of
2306    the requested server is missing from the request, the name of the
2307    client in the additional ticket will be used. Otherwise the name of
2308    the requested server will be compared to the name of the client in
2309    the additional ticket and if different, the request will be rejected.
2310    If the request succeeds, the session key from the additional ticket
2311    will be used to encrypt the new ticket that is issued instead of
2312    using the key of the server for which the new ticket will be used.
2313
2314    If the name of the server in the ticket that is presented to the KDC
2315    as part of the authentication header is not that of the ticket-
2316    granting server itself, the server is registered in the realm of the
2317    KDC, and the RENEW option is requested, then the KDC will verify that
2318    the RENEWABLE flag is set in the ticket, that the INVALID flag is not
2319    set in the ticket, and that the renew_till time is still in the
2320    future. If the VALIDATE option is requested, the KDC will check that
2321    the starttime has passed and the INVALID flag is set. If the PROXY
2322    option is requested, then the KDC will check that the PROXIABLE flag
2323    is set in the ticket. If the tests succeed, and the ticket passes the
2324    hotlist check described in the next section, the KDC will issue the
2325
2326
2327
2328 September 2004                                                 [Page 39]\f
2329
2330
2331
2332
2333
2334 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
2335
2336
2337    appropriate new ticket.
2338
2339    The ciphertext part of the response in the KRB_TGS_REP message is
2340    encrypted in the sub-session key from the Authenticator, if present,
2341    or the session key from the ticket-granting ticket. It is not
2342    encrypted using the client's secret key. Furthermore, the client's
2343    key's expiration date and the key version number fields are left out
2344    since these values are stored along with the client's database
2345    record, and that record is not needed to satisfy a request based on a
2346    ticket-granting ticket.
2347
2348 3.3.3.1. Checking for revoked tickets
2349
2350    Whenever a request is made to the ticket-granting server, the
2351    presented ticket(s) is(are) checked against a hot-list of tickets
2352    which have been canceled. This hot-list might be implemented by
2353    storing a range of issue timestamps for 'suspect tickets'; if a
2354    presented ticket had an authtime in that range, it would be rejected.
2355    In this way, a stolen ticket-granting ticket or renewable ticket
2356    cannot be used to gain additional tickets (renewals or otherwise)
2357    once the theft has been reported to the KDC for the realm in which
2358    the server resides. Any normal ticket obtained before it was reported
2359    stolen will still be valid (because they require no interaction with
2360    the KDC), but only until their normal expiration time. If TGT's have
2361    been issued for cross-realm authentication, use of the cross-realm
2362    TGT will not be affected unless the hot-list is propagated to the
2363    KDCs for the realms for which such cross-realm tickets were issued.
2364
2365 3.3.3.2. Encoding the transited field
2366
2367    If the identity of the server in the TGT that is presented to the KDC
2368    as part of the authentication header is that of the ticket-granting
2369    service, but the TGT was issued from another realm, the KDC will look
2370    up the inter-realm key shared with that realm and use that key to
2371    decrypt the ticket. If the ticket is valid, then the KDC will honor
2372    the request, subject to the constraints outlined above in the section
2373    describing the AS exchange.  The realm part of the client's identity
2374    will be taken from the ticket-granting ticket. The name of the realm
2375    that issued the ticket-granting ticket, if it is not the realm of the
2376    client principal, will be added to the transited field of the ticket
2377    to be issued. This is accomplished by reading the transited field
2378    from the ticket-granting ticket (which is treated as an unordered set
2379    of realm names), adding the new realm to the set, then constructing
2380    and writing out its encoded (shorthand) form (this may involve a
2381    rearrangement of the existing encoding).
2382
2383    Note that the ticket-granting service does not add the name of its
2384    own realm. Instead, its responsibility is to add the name of the
2385
2386
2387
2388 September 2004                                                 [Page 40]\f
2389
2390
2391
2392
2393
2394 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
2395
2396
2397    previous realm.  This prevents a malicious Kerberos server from
2398    intentionally leaving out its own name (it could, however, omit other
2399    realms' names).
2400
2401    The names of neither the local realm nor the principal's realm are to
2402    be included in the transited field. They appear elsewhere in the
2403    ticket and both are known to have taken part in authenticating the
2404    principal. Since the endpoints are not included, both local and
2405    single-hop inter-realm authentication result in a transited field
2406    that is empty.
2407
2408    Because the name of each realm transited is added to this field, it
2409    might potentially be very long. To decrease the length of this field,
2410    its contents are encoded. The initially supported encoding is
2411    optimized for the normal case of inter-realm communication: a
2412    hierarchical arrangement of realms using either domain or X.500 style
2413    realm names. This encoding (called DOMAIN-X500-COMPRESS) is now
2414    described.
2415
2416    Realm names in the transited field are separated by a ",". The ",",
2417    "\", trailing "."s, and leading spaces (" ") are special characters,
2418    and if they are part of a realm name, they MUST be quoted in the
2419    transited field by preceding them with a "\".
2420
2421    A realm name ending with a "." is interpreted as being prepended to
2422    the previous realm. For example, we can encode traversal of EDU,
2423    MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as:
2424
2425       "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
2426
2427    Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points,
2428    that they would not be included in this field, and we would have:
2429
2430       "EDU,MIT.,WASHINGTON.EDU"
2431
2432    A realm name beginning with a "/" is interpreted as being appended to
2433    the previous realm.  For the purpose of appending, the realm
2434    preceding the first listed realm is considered to be the null realm
2435    ("").  If a realm name beginning with a "/" is to stand by itself,
2436    then it SHOULD be preceded by a space (" "). For example, we can
2437    encode traversal of /COM/HP/APOLLO, /COM/HP, /COM, and /COM/DEC as:
2438
2439       "/COM,/HP,/APOLLO, /COM/DEC".
2440
2441    Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints,
2442    they would not be included in this field, and we would have:
2443
2444       "/COM,/HP"
2445
2446
2447
2448 September 2004                                                 [Page 41]\f
2449
2450
2451
2452
2453
2454 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
2455
2456
2457    A null subfield preceding or following a "," indicates that all
2458    realms between the previous realm and the next realm have been
2459    traversed.  For the purpose of interpreting null subfields, the
2460    client's realm is considered to precede those in the transited field,
2461    and the server's realm is considered to follow them.  Thus, "," means
2462    that all realms along the path between the client and the server have
2463    been traversed. ",EDU, /COM," means that all realms from the client's
2464    realm up to EDU (in a domain style hierarchy) have been traversed,
2465    and that everything from /COM down to the server's realm in an X.500
2466    style has also been traversed. This could occur if the EDU realm in
2467    one hierarchy shares an inter-realm key directly with the /COM realm
2468    in another hierarchy.
2469
2470 3.3.4. Receipt of KRB_TGS_REP message
2471
2472    When the KRB_TGS_REP is received by the client, it is processed in
2473    the same manner as the KRB_AS_REP processing described above. The
2474    primary difference is that the ciphertext part of the response must
2475    be decrypted using the sub-session key from the Authenticator, if it
2476    was specified in the request, or the session key from the ticket-
2477    granting ticket, rather than the client's secret key. The server name
2478    returned in the reply is the true principal name of the service.
2479
2480 3.4. The KRB_SAFE Exchange
2481
2482    The KRB_SAFE message MAY be used by clients requiring the ability to
2483    detect modifications of messages they exchange. It achieves this by
2484    including a keyed collision-proof checksum of the user data and some
2485    control information. The checksum is keyed with an encryption key
2486    (usually the last key negotiated via subkeys, or the session key if
2487    no negotiation has occurred).
2488
2489 3.4.1. Generation of a KRB_SAFE message
2490
2491    When an application wishes to send a KRB_SAFE message, it collects
2492    its data and the appropriate control information and computes a
2493    checksum over them.  The checksum algorithm should be the keyed
2494    checksum mandated to be implemented along with the crypto system used
2495    for the sub-session or session key. The checksum is generated using
2496    the sub-session key if present or the session key. Some
2497    implementations use a different checksum algorithm for the KRB_SAFE
2498    messages but doing so in a interoperable manner is not always
2499    possible.
2500
2501    The control information for the KRB_SAFE message includes both a
2502    timestamp and a sequence number. The designer of an application using
2503    the KRB_SAFE message MUST choose at least one of the two mechanisms.
2504    This choice SHOULD be based on the needs of the application protocol.
2505
2506
2507
2508 September 2004                                                 [Page 42]\f
2509
2510
2511
2512
2513
2514 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
2515
2516
2517    Sequence numbers are useful when all messages sent will be received
2518    by one's peer. Connection state is presently required to maintain the
2519    session key, so maintaining the next sequence number should not
2520    present an additional problem.
2521
2522    If the application protocol is expected to tolerate lost messages
2523    without them being resent, the use of the timestamp is the
2524    appropriate replay detection mechanism. Using timestamps is also the
2525    appropriate mechanism for multi-cast protocols where all of one's
2526    peers share a common sub-session key, but some messages will be sent
2527    to a subset of one's peers.
2528
2529    After computing the checksum, the client then transmits the
2530    information and checksum to the recipient in the message format
2531    specified in section 5.6.1.
2532
2533 3.4.2. Receipt of KRB_SAFE message
2534
2535    When an application receives a KRB_SAFE message, it verifies it as
2536    follows.  If any error occurs, an error code is reported for use by
2537    the application.
2538
2539    The message is first checked by verifying that the protocol version
2540    and type fields match the current version and KRB_SAFE, respectively.
2541    A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE
2542    error. The application verifies that the checksum used is a
2543    collision-proof keyed checksum that uses keys compatible with the
2544    sub-session or session key as appropriate (or with the application
2545    key derived from the session or sub-session keys), and if it is not,
2546    a KRB_AP_ERR_INAPP_CKSUM error is generated.  The sender's address
2547    MUST be included in the control information; the recipient verifies
2548    that the operating system's report of the sender's address matches
2549    the sender's address in the message, and (if a recipient address is
2550    specified or the recipient requires an address) that one of the
2551    recipient's addresses appears as the recipient's address in the
2552    message. To work with network address translation, senders MAY use
2553    the directional address type specified in section 8.1 for the sender
2554    address and not include recipient addresses. A failed match for
2555    either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp
2556    and usec and/or the sequence number fields are checked. If timestamp
2557    and usec are expected and not present, or they are present but not
2558    current, the KRB_AP_ERR_SKEW error is generated. Timestamps are not
2559    required to be strictly ordered; they are only required to be in the
2560    skew window.  If the server name, along with the client name, time
2561    and microsecond fields from the Authenticator match any recently-seen
2562    (sent or received) such tuples, the KRB_AP_ERR_REPEAT error is
2563    generated. If an incorrect sequence number is included, or a sequence
2564    number is expected but not present, the KRB_AP_ERR_BADORDER error is
2565
2566
2567
2568 September 2004                                                 [Page 43]\f
2569
2570
2571
2572
2573
2574 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
2575
2576
2577    generated. If neither a time-stamp and usec or a sequence number is
2578    present, a KRB_AP_ERR_MODIFIED error is generated. Finally, the
2579    checksum is computed over the data and control information, and if it
2580    doesn't match the received checksum, a KRB_AP_ERR_MODIFIED error is
2581    generated.
2582
2583    If all the checks succeed, the application is assured that the
2584    message was generated by its peer and was not modified in transit.
2585
2586    Implementations SHOULD accept any checksum algorithm they implement
2587    that both have adequate security and that have keys compatible with
2588    the sub-session or session key. Unkeyed or non-collision-proof
2589    checksums are not suitable for this use.
2590
2591 3.5. The KRB_PRIV Exchange
2592
2593    The KRB_PRIV message MAY be used by clients requiring confidentiality
2594    and the ability to detect modifications of exchanged messages. It
2595    achieves this by encrypting the messages and adding control
2596    information.
2597
2598 3.5.1. Generation of a KRB_PRIV message
2599
2600    When an application wishes to send a KRB_PRIV message, it collects
2601    its data and the appropriate control information (specified in
2602    section 5.7.1) and encrypts them under an encryption key (usually the
2603    last key negotiated via subkeys, or the session key if no negotiation
2604    has occurred). As part of the control information, the client MUST
2605    choose to use either a timestamp or a sequence number (or both); see
2606    the discussion in section 3.4.1 for guidelines on which to use. After
2607    the user data and control information are encrypted, the client
2608    transmits the ciphertext and some 'envelope' information to the
2609    recipient.
2610
2611 3.5.2. Receipt of KRB_PRIV message
2612
2613    When an application receives a KRB_PRIV message, it verifies it as
2614    follows.  If any error occurs, an error code is reported for use by
2615    the application.
2616
2617    The message is first checked by verifying that the protocol version
2618    and type fields match the current version and KRB_PRIV, respectively.
2619    A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE
2620    error. The application then decrypts the ciphertext and processes the
2621    resultant plaintext. If decryption shows the data to have been
2622    modified, a KRB_AP_ERR_BAD_INTEGRITY error is generated.
2623
2624    The sender's address MUST be included in the control information; the
2625
2626
2627
2628 September 2004                                                 [Page 44]\f
2629
2630
2631
2632
2633
2634 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
2635
2636
2637    recipient verifies that the operating system's report of the sender's
2638    address matches the sender's address in the message.  If a recipient
2639    address is specified or the recipient requires an address then one of
2640    the recipient's addresses MUST also appear as the recipient's address
2641    in the message.  Where a sender's or receiver's address might not
2642    otherwise match the address in a message because of network address
2643    translation, an application MAY be written to use addresses of the
2644    directional address type in place of the actual network address.
2645
2646    A failed match for either case generates a KRB_AP_ERR_BADADDR error.
2647    To work with network address translation, implementations MAY use the
2648    directional address type defined in section 7.1 for the sender
2649    address and include no recipient address.
2650
2651    Then the timestamp and usec and/or the sequence number fields are
2652    checked. If timestamp and usec are expected and not present, or they
2653    are present but not current, the KRB_AP_ERR_SKEW error is generated.
2654    If the server name, along with the client name, time and microsecond
2655    fields from the Authenticator match any recently-seen such tuples,
2656    the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence
2657    number is included, or a sequence number is expected but not present,
2658    the KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp
2659    and usec or a sequence number is present, a KRB_AP_ERR_MODIFIED error
2660    is generated.
2661
2662    If all the checks succeed, the application can assume the message was
2663    generated by its peer, and was securely transmitted (without
2664    intruders able to see the unencrypted contents).
2665
2666 3.6. The KRB_CRED Exchange
2667
2668    The KRB_CRED message MAY be used by clients requiring the ability to
2669    send Kerberos credentials from one host to another. It achieves this
2670    by sending the tickets together with encrypted data containing the
2671    session keys and other information associated with the tickets.
2672
2673 3.6.1. Generation of a KRB_CRED message
2674
2675    When an application wishes to send a KRB_CRED message it first (using
2676    the KRB_TGS exchange) obtains credentials to be sent to the remote
2677    host. It then constructs a KRB_CRED message using the ticket or
2678    tickets so obtained, placing the session key needed to use each
2679    ticket in the key field of the corresponding KrbCredInfo sequence of
2680    the encrypted part of the KRB_CRED message.
2681
2682    Other information associated with each ticket and obtained during the
2683    KRB_TGS exchange is also placed in the corresponding KrbCredInfo
2684    sequence in the encrypted part of the KRB_CRED message. The current
2685
2686
2687
2688 September 2004                                                 [Page 45]\f
2689
2690
2691
2692
2693
2694 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
2695
2696
2697    time and, if specifically required by the application the nonce, s-
2698    address, and r-address fields, are placed in the encrypted part of
2699    the KRB_CRED message which is then encrypted under an encryption key
2700    previously exchanged in the KRB_AP exchange (usually the last key
2701    negotiated via subkeys, or the session key if no negotiation has
2702    occurred).
2703
2704    Implementation note: When constructing a KRB_CRED message for
2705    inclusion in a GSSAPI initial context token, the MIT implementation
2706    of Kerberos will not encrypt the KRB_CRED message if the session key
2707    is a DES or triple DES key.  For interoperability with MIT, the
2708    Microsoft implementation will not encrypt the KRB_CRED in a GSSAPI
2709    token if it is using a DES session key. Starting at version 1.2.5,
2710    MIT Kerberos can receive and decode either encrypted or unencrypted
2711    KRB_CRED tokens in the GSSAPI exchange. The Heimdal implementation of
2712    Kerberos can also accept either encrypted or unencrypted KRB_CRED
2713    messages. Since the KRB_CRED message in a GSSAPI token is encrypted
2714    in the authenticator, the MIT behavior does not present a security
2715    problem, although it is a violation of the Kerberos specification.
2716
2717 3.6.2. Receipt of KRB_CRED message
2718
2719    When an application receives a KRB_CRED message, it verifies it. If
2720    any error occurs, an error code is reported for use by the
2721    application. The message is verified by checking that the protocol
2722    version and type fields match the current version and KRB_CRED,
2723    respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or
2724    KRB_AP_ERR_MSG_TYPE error. The application then decrypts the
2725    ciphertext and processes the resultant plaintext. If decryption shows
2726    the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is
2727    generated.
2728
2729    If present or required, the recipient MAY verify that the operating
2730    system's report of the sender's address matches the sender's address
2731    in the message, and that one of the recipient's addresses appears as
2732    the recipient's address in the message. The address check does not
2733    provide any added security, since the address if present has already
2734    been checked in the KRB_AP_REQ message and there is not any benefit
2735    to be gained by an attacker in reflecting a KRB_CRED message back to
2736    its originator. Thus, the recipient MAY ignore the address even if
2737    present in order to work better in NAT environments. A failed match
2738    for either case generates a KRB_AP_ERR_BADADDR error. Recipients MAY
2739    skip the address check as the KRB_CRED message cannot generally be
2740    reflected back to the originator.  The timestamp and usec fields (and
2741    the nonce field if required) are checked next. If the timestamp and
2742    usec are not present, or they are present but not current, the
2743    KRB_AP_ERR_SKEW error is generated.
2744
2745
2746
2747
2748 September 2004                                                 [Page 46]\f
2749
2750
2751
2752
2753
2754 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
2755
2756
2757    If all the checks succeed, the application stores each of the new
2758    tickets in its credentials cache together with the session key and
2759    other information in the corresponding KrbCredInfo sequence from the
2760    encrypted part of the KRB_CRED message.
2761
2762 3.7. User-to-User Authentication Exchanges
2763
2764    User-to-User authentication provides a method to perform
2765    authentication when the verifier does not have a access to long term
2766    service key. This might be the case when running a server (for
2767    example a window server) as a user on a workstation. In such cases,
2768    the server may have access to the ticket-granting ticket obtained
2769    when the user logged in to the workstation, but because the server is
2770    running as an unprivileged user it might not have access to system
2771    keys. Similar situations may arise when running peer-to-peer
2772    applications.
2773
2774                              Summary
2775        Message direction                    Message type     Sections
2776        0. Message from application server   Not Specified
2777        1. Client to Kerberos                KRB_TGS_REQ      3.3 + 5.4.1
2778        2. Kerberos to client                KRB_TGS_REP or   3.3 + 5.4.2
2779                                             KRB_ERROR        5.9.1
2780        3. Client to Application server      KRB_AP_REQ       3.2 + 5.5.1
2781
2782    To address this problem, the Kerberos protocol allows the client to
2783    request that the ticket issued by the KDC be encrypted using a
2784    session key from a ticket-granting ticket issued to the party that
2785    will verify the authentication.  This ticket-granting ticket must be
2786    obtained from the verifier by means of an exchange external to the
2787    Kerberos protocol, usually as part of the application protocol. This
2788    message is shown in the summary above as message 0. Note that because
2789    the ticket-granting ticket is encrypted in the KDC's secret key, it
2790    can not be used for authentication without possession of the
2791    corresponding secret key.  Furthermore, because the verifier does not
2792    reveal the corresponding secret key, providing a copy of the
2793    verifier's ticket-granting ticket does not allow impersonation of the
2794    verifier.
2795
2796    Message 0 in the table above represents an application specific
2797    negotiation between the client and server, at the end of which both
2798    have determined that they will use user-to-user authentication and
2799    the client has obtained the server's TGT.
2800
2801    Next, the client includes the server's TGT as an additional ticket in
2802    its KRB_TGS_REQ request to the KDC (message 1 in the table above) and
2803    specifies the ENC-TKT-IN-SKEY option in its request.
2804
2805
2806
2807
2808 September 2004                                                 [Page 47]\f
2809
2810
2811
2812
2813
2814 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
2815
2816
2817    If validated according to the instructions in 3.3.3, the application
2818    ticket returned to the client (message 2 in the table above) will be
2819    encrypted using the session key from the additional ticket and the
2820    client will note this when it uses or stores the application ticket.
2821
2822    When contacting the server using a ticket obtained for user-to-user
2823    authentication (message 3 in the table above), the client MUST
2824    specify the USE-SESSION-KEY flag in the ap-options field. This tells
2825    the application server to use the session key associated with its
2826    ticket-granting ticket to decrypt the server ticket provided in the
2827    application request.
2828
2829 4. Encryption and Checksum Specifications
2830
2831    The Kerberos protocols described in this document are designed to
2832    encrypt messages of arbitrary sizes, using stream or block encryption
2833    ciphers.  Encryption is used to prove the identities of the network
2834    entities participating in message exchanges. The Key Distribution
2835    Center for each realm is trusted by all principals registered in that
2836    realm to store a secret key in confidence. Proof of knowledge of this
2837    secret key is used to verify the authenticity of a principal.
2838
2839    The KDC uses the principal's secret key (in the AS exchange) or a
2840    shared session key (in the TGS exchange) to encrypt responses to
2841    ticket requests; the ability to obtain the secret key or session key
2842    implies the knowledge of the appropriate keys and the identity of the
2843    KDC. The ability of a principal to decrypt the KDC response and
2844    present a Ticket and a properly formed Authenticator (generated with
2845    the session key from the KDC response) to a service verifies the
2846    identity of the principal; likewise the ability of the service to
2847    extract the session key from the Ticket and prove its knowledge
2848    thereof in a response verifies the identity of the service.
2849
2850    [@KCRYPTO] defines a framework for defining encryption and checksum
2851    mechanisms for use with Kerberos. It also defines several such
2852    mechanisms, and more may be added in future updates to that document.
2853
2854    The string-to-key operation provided by [@KCRYPTO] is used to produce
2855    a long-term key for a principal (generally for a user). The default
2856    salt string, if none is provided via pre-authentication data, is the
2857    concatenation of the principal's realm and name components, in order,
2858    with no separators.  Unless otherwise indicated, the default string-
2859    to-key opaque parameter set as defined in [@KCRYPTO] is used.
2860
2861    Encrypted data, keys and checksums are transmitted using the
2862    EncryptedData, EncryptionKey and Checksum data objects defined in
2863    section 5.2.9. The encryption, decryption, and checksum operations
2864    described in this document use the corresponding encryption,
2865
2866
2867
2868 September 2004                                                 [Page 48]\f
2869
2870
2871
2872
2873
2874 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
2875
2876
2877    decryption, and get_mic operations described in [@KCRYPTO], with
2878    implicit "specific key" generation using the "key usage" values
2879    specified in the description of each EncryptedData or Checksum object
2880    to vary the key for each operation. Note that in some cases, the
2881    value to be used is dependent on the method of choosing the key or
2882    the context of the message.
2883
2884    Key usages are unsigned 32 bit integers; zero is not permitted. The
2885    key usage values for encrypting or checksumming Kerberos messages are
2886    indicated in section 5 along with the message definitions. Key usage
2887    values 512-1023 are reserved for uses internal to a Kerberos
2888    implementation. (For example, seeding a pseudo-random number
2889    generator with a value produced by encrypting something with a
2890    session key and a key usage value not used for any other purpose.)
2891    Key usage values between 1024 and 2047 (inclusive) are reserved for
2892    application use; applications SHOULD use even values for encryption
2893    and odd values for checksums within this range. Key usage values are
2894    also summarized in a table in section 7.5.1.
2895
2896    There might exist other documents which define protocols in terms of
2897    the RFC1510 encryption types or checksum types. Such documents would
2898    not know about key usages. In order that these specifications
2899    continue to be meaningful until they are updated, if no key usage
2900    values are specified then key usages 1024 and 1025 must be used to
2901    derive keys for encryption and checksums, respectively (this does not
2902    apply to protocols that do their own encryption independent of this
2903    framework, directly using the key resulting from the Kerberos
2904    authentication exchange.) New protocols defined in terms of the
2905    Kerberos encryption and checksum types SHOULD use their own key usage
2906    values.
2907
2908    Unless otherwise indicated, no cipher state chaining is done from one
2909    encryption operation to another.
2910
2911    Implementation note: While not recommended, some application
2912    protocols will continue to use the key data directly, even if only in
2913    currently existing protocol specifications. An implementation
2914    intended to support general Kerberos applications may therefore need
2915    to make key data available, as well as the attributes and operations
2916    described in [@KCRYPTO].  One of the more common reasons for directly
2917    performing encryption is direct control over negotiation and
2918    selection of a "sufficiently strong" encryption algorithm (in the
2919    context of a given application). While Kerberos does not directly
2920    provide a facility for negotiating encryption types between the
2921    application client and server, there are approaches for using
2922    Kerberos to facilitate this negotiation - for example, a client may
2923    request only "sufficiently strong" session key types from the KDC and
2924    expect that any type returned by the KDC will be understood and
2925
2926
2927
2928 September 2004                                                 [Page 49]\f
2929
2930
2931
2932
2933
2934 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
2935
2936
2937    supported by the application server.
2938
2939 5. Message Specifications
2940
2941    NOTE: The ASN.1 collected here should be identical to the contents of
2942    Appendix A. In case of conflict, the contents of Appendix A shall
2943    take precedence.
2944
2945    The Kerberos protocol is defined here in terms of Abstract Syntax
2946    Notation One (ASN.1) [X680], which provides a syntax for specifying
2947    both the abstract layout of protocol messages as well as their
2948    encodings. Implementors not utilizing an existing ASN.1 compiler or
2949    support library are cautioned to thoroughly understand the actual
2950    ASN.1 specification to ensure correct implementation behavior, as
2951    there is more complexity in the notation than is immediately obvious,
2952    and some tutorials and guides to ASN.1 are misleading or erroneous.
2953
2954    Note that in several places, there have been changes here from RFC
2955    1510 that change the abstract types. This is in part to address
2956    widespread assumptions that various implementors have made, in some
2957    cases resulting in unintentional violations of the ASN.1 standard.
2958    These are clearly flagged where they occur. The differences between
2959    the abstract types in RFC 1510 and abstract types in this document
2960    can cause incompatible encodings to be emitted when certain encoding
2961    rules, e.g. the Packed Encoding Rules (PER), are used. This
2962    theoretical incompatibility should not be relevant for Kerberos,
2963    since Kerberos explicitly specifies the use of the Distinguished
2964    Encoding Rules (DER). It might be an issue for protocols wishing to
2965    use Kerberos types with other encoding rules. (This practice is not
2966    recommended.) With very few exceptions (most notably the usages of
2967    BIT STRING), the encodings resulting from using the DER remain
2968    identical between the types defined in RFC 1510 and the types defined
2969    in this document.
2970
2971    The type definitions in this section assume an ASN.1 module
2972    definition of the following form:
2973
2974    KerberosV5Spec2 {
2975            iso(1) identified-organization(3) dod(6) internet(1)
2976            security(5) kerberosV5(2) modules(4) krb5spec2(2)
2977    } DEFINITIONS EXPLICIT TAGS ::= BEGIN
2978
2979    -- rest of definitions here
2980
2981    END
2982
2983    This specifies that the tagging context for the module will be
2984    explicit and non-automatic.
2985
2986
2987
2988 September 2004                                                 [Page 50]\f
2989
2990
2991
2992
2993
2994 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
2995
2996
2997    Note that in some other publications [RFC1510] [RFC1964], the "dod"
2998    portion of the object identifier is erroneously specified as having
2999    the value "5".  In the case of RFC 1964, use of the "correct" OID
3000    value would result in a change in the wire protocol; therefore, it
3001    remains unchanged for now.
3002
3003    Note that elsewhere in this document, nomenclature for various
3004    message types is inconsistent, but largely follows C language
3005    conventions, including use of underscore (_) characters and all-caps
3006    spelling of names intended to be numeric constants. Also, in some
3007    places, identifiers (especially ones referring to constants) are
3008    written in all-caps in order to distinguish them from surrounding
3009    explanatory text.
3010
3011    The ASN.1 notation does not permit underscores in identifiers, so in
3012    actual ASN.1 definitions, underscores are replaced with hyphens (-).
3013    Additionally, structure member names and defined values in ASN.1 MUST
3014    begin with a lowercase letter, while type names MUST begin with an
3015    uppercase letter.
3016
3017 5.1. Specific Compatibility Notes on ASN.1
3018
3019    For compatibility purposes, implementors should heed the following
3020    specific notes regarding the use of ASN.1 in Kerberos. These notes do
3021    not describe deviations from standard usage of ASN.1. The purpose of
3022    these notes is to instead describe some historical quirks and non-
3023    compliance of various implementations, as well as historical
3024    ambiguities, which, while being valid ASN.1, can lead to confusion
3025    during implementation.
3026
3027 5.1.1. ASN.1 Distinguished Encoding Rules
3028
3029    The encoding of Kerberos protocol messages shall obey the
3030    Distinguished Encoding Rules (DER) of ASN.1 as described in [X690].
3031    Some implementations (believed to be primarily ones derived from DCE
3032    1.1 and earlier) are known to use the more general Basic Encoding
3033    Rules (BER); in particular, these implementations send indefinite
3034    encodings of lengths. Implementations MAY accept such encodings in
3035    the interests of backwards compatibility, though implementors are
3036    warned that decoding fully-general BER is fraught with peril.
3037
3038 5.1.2. Optional Integer Fields
3039
3040    Some implementations do not internally distinguish between an omitted
3041    optional integer value and a transmitted value of zero. The places in
3042    the protocol where this is relevant include various microseconds
3043    fields, nonces, and sequence numbers. Implementations SHOULD treat
3044    omitted optional integer values as having been transmitted with a
3045
3046
3047
3048 September 2004                                                 [Page 51]\f
3049
3050
3051
3052
3053
3054 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
3055
3056
3057    value of zero, if the application is expecting this.
3058
3059 5.1.3. Empty SEQUENCE OF Types
3060
3061    There are places in the protocol where a message contains a SEQUENCE
3062    OF type as an optional member. This can result in an encoding that
3063    contains an empty SEQUENCE OF encoding. The Kerberos protocol does
3064    not semantically distinguish between an absent optional SEQUENCE OF
3065    type and a present optional but empty SEQUENCE OF type.
3066    Implementations SHOULD NOT send empty SEQUENCE OF encodings that are
3067    marked OPTIONAL, but SHOULD accept them as being equivalent to an
3068    omitted OPTIONAL type. In the ASN.1 syntax describing Kerberos
3069    messages, instances of these problematic optional SEQUENCE OF types
3070    are indicated with a comment.
3071
3072 5.1.4. Unrecognized Tag Numbers
3073
3074    Future revisions to this protocol may include new message types with
3075    different APPLICATION class tag numbers. Such revisions should
3076    protect older implementations by only sending the message types to
3077    parties that are known to understand them, e.g. by means of a flag
3078    bit set by the receiver in a preceding request. In the interest of
3079    robust error handling, implementations SHOULD gracefully handle
3080    receiving a message with an unrecognized tag anyway, and return an
3081    error message if appropriate.
3082
3083    In particular, KDCs SHOULD return KRB_AP_ERR_MSG_TYPE if the
3084    incorrect tag is sent over a TCP transport.  The KDCs SHOULD NOT
3085    respond to messages received with an unknown tag over UDP transport
3086    in order to avoid denial of service attacks.  For non-KDC
3087    applications, the Kerberos implementation typically indicates an
3088    error to the application which takes appropriate steps based on the
3089    application protocol.
3090
3091 5.1.5. Tag Numbers Greater Than 30
3092
3093    A naive implementation of a DER ASN.1 decoder may experience problems
3094    with ASN.1 tag numbers greater than 30, due to such tag numbers being
3095    encoded using more than one byte. Future revisions of this protocol
3096    may utilize tag numbers greater than 30, and implementations SHOULD
3097    be prepared to gracefully return an error, if appropriate, if they do
3098    not recognize the tag.
3099
3100 5.2. Basic Kerberos Types
3101
3102    This section defines a number of basic types that are potentially
3103    used in multiple Kerberos protocol messages.
3104
3105
3106
3107
3108 September 2004                                                 [Page 52]\f
3109
3110
3111
3112
3113
3114 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
3115
3116
3117 5.2.1. KerberosString
3118
3119    The original specification of the Kerberos protocol in RFC 1510 uses
3120    GeneralString in numerous places for human-readable string data.
3121    Historical implementations of Kerberos cannot utilize the full power
3122    of GeneralString.  This ASN.1 type requires the use of designation
3123    and invocation escape sequences as specified in ISO-2022/ECMA-35
3124    [ISO-2022/ECMA-35] to switch character sets, and the default
3125    character set that is designated as G0 is the ISO-646/ECMA-6
3126    [ISO-646,ECMA-6] International Reference Version (IRV) (aka U.S.
3127    ASCII), which mostly works.
3128
3129    ISO-2022/ECMA-35 defines four character-set code elements (G0..G3)
3130    and two Control-function code elements (C0..C1). DER prohibits the
3131    designation of character sets as any but the G0 and C0 sets.
3132    Unfortunately, this seems to have the side effect of prohibiting the
3133    use of ISO-8859 (ISO Latin) [ISO-8859] character-sets or any other
3134    character-sets that utilize a 96-character set, since it is
3135    prohibited by ISO-2022/ECMA-35 to designate them as the G0 code
3136    element. This side effect is being investigated in the ASN.1
3137    standards community.
3138
3139    In practice, many implementations treat GeneralStrings as if they
3140    were 8-bit strings of whichever character set the implementation
3141    defaults to, without regard for correct usage of character-set
3142    designation escape sequences. The default character set is often
3143    determined by the current user's operating system dependent locale.
3144    At least one major implementation places unescaped UTF-8 encoded
3145    Unicode characters in the GeneralString. This failure to adhere to
3146    the GeneralString specifications results in interoperability issues
3147    when conflicting character encodings are utilized by the Kerberos
3148    clients, services, and KDC.
3149
3150    This unfortunate situation is the result of improper documentation of
3151    the restrictions of the ASN.1 GeneralString type in prior Kerberos
3152    specifications.
3153
3154    The new (post-RFC 1510) type KerberosString, defined below, is a
3155    GeneralString that is constrained to only contain characters in
3156    IA5String
3157
3158       KerberosString  ::= GeneralString (IA5String)
3159
3160    In general, US-ASCII control characters should not be used in
3161    KerberosString. Control characters SHOULD NOT be used in principal
3162    names or realm names.
3163
3164    For compatibility, implementations MAY choose to accept GeneralString
3165
3166
3167
3168 September 2004                                                 [Page 53]\f
3169
3170
3171
3172
3173
3174 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
3175
3176
3177    values that contain characters other than those permitted by
3178    IA5String, but they should be aware that character set designation
3179    codes will likely be absent, and that the encoding should probably be
3180    treated as locale-specific in almost every way. Implementations MAY
3181    also choose to emit GeneralString values that are beyond those
3182    permitted by IA5String, but should be aware that doing so is
3183    extraordinarily risky from an interoperability perspective.
3184
3185    Some existing implementations use GeneralString to encode unescaped
3186    locale-specific characters. This is a violation of the ASN.1
3187    standard. Most of these implementations encode US-ASCII in the left-
3188    hand half, so as long the implementation transmits only US-ASCII, the
3189    ASN.1 standard is not violated in this regard. As soon as such an
3190    implementation encodes unescaped locale-specific characters with the
3191    high bit set, it violates the ASN.1 standard.
3192
3193    Other implementations have been known to use GeneralString to contain
3194    a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8
3195    is a different encoding, not a 94 or 96 character "G" set as defined
3196    by ISO 2022.  It is believed that these implementations do not even
3197    use the ISO 2022 escape sequence to change the character encoding.
3198    Even if implementations were to announce the change of encoding by
3199    using that escape sequence, the ASN.1 standard prohibits the use of
3200    any escape sequences other than those used to designate/invoke "G" or
3201    "C" sets allowed by GeneralString.
3202
3203    Future revisions to this protocol will almost certainly allow for a
3204    more interoperable representation of principal names, probably
3205    including UTF8String.
3206
3207    Note that applying a new constraint to a previously unconstrained
3208    type constitutes creation of a new ASN.1 type. In this particular
3209    case, the change does not result in a changed encoding under DER.
3210
3211 5.2.2. Realm and PrincipalName
3212
3213    Realm           ::= KerberosString
3214
3215    PrincipalName   ::= SEQUENCE {
3216            name-type       [0] Int32,
3217            name-string     [1] SEQUENCE OF KerberosString
3218    }
3219
3220    Kerberos realm names are encoded as KerberosStrings. Realms shall not
3221    contain a character with the code 0 (the US-ASCII NUL). Most realms
3222    will usually consist of several components separated by periods (.),
3223    in the style of Internet Domain Names, or separated by slashes (/) in
3224    the style of X.500 names. Acceptable forms for realm names are
3225
3226
3227
3228 September 2004                                                 [Page 54]\f
3229
3230
3231
3232
3233
3234 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
3235
3236
3237    specified in section 6.1.. A PrincipalName is a typed sequence of
3238    components consisting of the following sub-fields:
3239
3240    name-type
3241       This field specifies the type of name that follows. Pre-defined
3242       values for this field are specified in section 6.2. The name-type
3243       SHOULD be treated as a hint. Ignoring the name type, no two names
3244       can be the same (i.e. at least one of the components, or the
3245       realm, must be different).
3246
3247    name-string
3248       This field encodes a sequence of components that form a name, each
3249       component encoded as a KerberosString. Taken together, a
3250       PrincipalName and a Realm form a principal identifier. Most
3251       PrincipalNames will have only a few components (typically one or
3252       two).
3253
3254 5.2.3. KerberosTime
3255
3256    KerberosTime    ::= GeneralizedTime -- with no fractional seconds
3257
3258    The timestamps used in Kerberos are encoded as GeneralizedTimes. A
3259    KerberosTime value shall not include any fractional portions of the
3260    seconds.  As required by the DER, it further shall not include any
3261    separators, and it shall specify the UTC time zone (Z). Example: The
3262    only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
3263    November 1985 is 19851106210627Z.
3264
3265 5.2.4. Constrained Integer types
3266
3267    Some integer members of types SHOULD be constrained to values
3268    representable in 32 bits, for compatibility with reasonable
3269    implementation limits.
3270
3271    Int32           ::= INTEGER (-2147483648..2147483647)
3272                        -- signed values representable in 32 bits
3273
3274    UInt32          ::= INTEGER (0..4294967295)
3275                        -- unsigned 32 bit values
3276
3277    Microseconds    ::= INTEGER (0..999999)
3278                        -- microseconds
3279
3280    While this results in changes to the abstract types from the RFC 1510
3281    version, the encoding in DER should be unaltered. Historical
3282    implementations were typically limited to 32-bit integer values
3283    anyway, and assigned numbers SHOULD fall in the space of integer
3284    values representable in 32 bits in order to promote interoperability
3285
3286
3287
3288 September 2004                                                 [Page 55]\f
3289
3290
3291
3292
3293
3294 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
3295
3296
3297    anyway.
3298
3299    There are several integer fields in messages that are constrained to
3300    fixed values.
3301
3302    pvno
3303       also TKT-VNO or AUTHENTICATOR-VNO, this recurring field is always
3304       the constant integer 5. There is no easy way to make this field
3305       into a useful protocol version number, so its value is fixed.
3306
3307    msg-type
3308       this integer field is usually identical to the application tag
3309       number of the containing message type.
3310
3311 5.2.5. HostAddress and HostAddresses
3312
3313    HostAddress     ::= SEQUENCE  {
3314            addr-type       [0] Int32,
3315            address         [1] OCTET STRING
3316    }
3317
3318    -- NOTE: HostAddresses is always used as an OPTIONAL field and
3319    -- should not be empty.
3320    HostAddresses   -- NOTE: subtly different from rfc1510,
3321                    -- but has a value mapping and encodes the same
3322            ::= SEQUENCE OF HostAddress
3323
3324    The host address encodings consists of two fields:
3325
3326    addr-type
3327       This field specifies the type of address that follows. Pre-defined
3328       values for this field are specified in section 7.5.3.
3329
3330    address
3331       This field encodes a single address of type addr-type.
3332
3333 5.2.6. AuthorizationData
3334
3335       -- NOTE: AuthorizationData is always used as an OPTIONAL field and
3336       -- should not be empty.
3337       AuthorizationData       ::= SEQUENCE OF SEQUENCE {
3338               ad-type         [0] Int32,
3339               ad-data         [1] OCTET STRING
3340       }
3341
3342    ad-data
3343       This field contains authorization data to be interpreted according
3344       to the value of the corresponding ad-type field.
3345
3346
3347
3348 September 2004                                                 [Page 56]\f
3349
3350
3351
3352
3353
3354 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
3355
3356
3357    ad-type
3358       This field specifies the format for the ad-data subfield. All
3359       negative values are reserved for local use. Non-negative values
3360       are reserved for registered use.
3361
3362    Each sequence of type and data is referred to as an authorization
3363    element.  Elements MAY be application specific, however, there is a
3364    common set of recursive elements that should be understood by all
3365    implementations. These elements contain other elements embedded
3366    within them, and the interpretation of the encapsulating element
3367    determines which of the embedded elements must be interpreted, and
3368    which may be ignored.
3369
3370    These common authorization data elements are recursively defined,
3371    meaning the ad-data for these types will itself contain a sequence of
3372    authorization data whose interpretation is affected by the
3373    encapsulating element. Depending on the meaning of the encapsulating
3374    element, the encapsulated elements may be ignored, might be
3375    interpreted as issued directly by the KDC, or they might be stored in
3376    a separate plaintext part of the ticket. The types of the
3377    encapsulating elements are specified as part of the Kerberos
3378    specification because the behavior based on these values should be
3379    understood across implementations whereas other elements need only be
3380    understood by the applications which they affect.
3381
3382    Authorization data elements are considered critical if present in a
3383    ticket or authenticator. Unless encapsulated in a known authorization
3384    data element amending the criticality of the elements it contains, if
3385    an unknown authorization data element type is received by a server
3386    either in an AP-REQ or in a ticket contained in an AP-REQ, then
3387    authentication MUST fail.  Authorization data is intended to restrict
3388    the use of a ticket. If the service cannot determine whether the
3389    restriction applies to that service then a security weakness may
3390    result if the ticket can be used for that service. Authorization
3391    elements that are optional can be enclosed in AD-IF-RELEVANT element.
3392
3393    In the definitions that follow, the value of the ad-type for the
3394    element will be specified as the least significant part of the
3395    subsection number, and the value of the ad-data will be as shown in
3396    the ASN.1 structure that follows the subsection heading.
3397
3398              contents of ad-data          ad-type
3399
3400     DER encoding of AD-IF-RELEVANT        1
3401
3402     DER encoding of AD-KDCIssued          4
3403
3404     DER encoding of AD-AND-OR             5
3405
3406
3407
3408 September 2004                                                 [Page 57]\f
3409
3410
3411
3412
3413
3414 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
3415
3416
3417     DER encoding of AD-MANDATORY-FOR-KDC  8
3418
3419 5.2.6.1. IF-RELEVANT
3420
3421    AD-IF-RELEVANT          ::= AuthorizationData
3422
3423    AD elements encapsulated within the if-relevant element are intended
3424    for interpretation only by application servers that understand the
3425    particular ad-type of the embedded element. Application servers that
3426    do not understand the type of an element embedded within the if-
3427    relevant element MAY ignore the uninterpretable element. This element
3428    promotes interoperability across implementations which may have local
3429    extensions for authorization.  The ad-type for AD-IF-RELEVANT is (1).
3430
3431 5.2.6.2. KDCIssued
3432
3433    AD-KDCIssued            ::= SEQUENCE {
3434            ad-checksum     [0] Checksum,
3435            i-realm         [1] Realm OPTIONAL,
3436            i-sname         [2] PrincipalName OPTIONAL,
3437            elements        [3] AuthorizationData
3438    }
3439
3440    ad-checksum
3441       A cryptographic checksum computed over the DER encoding of the
3442       AuthorizationData in the "elements" field, keyed with the session
3443       key.  Its checksumtype is the mandatory checksum type for the
3444       encryption type of the session key, and its key usage value is 19.
3445
3446    i-realm, i-sname
3447       The name of the issuing principal if different from the KDC
3448       itself.  This field would be used when the KDC can verify the
3449       authenticity of elements signed by the issuing principal and it
3450       allows this KDC to notify the application server of the validity
3451       of those elements.
3452
3453    elements
3454       A sequence of authorization data elements issued by the KDC.
3455
3456    The KDC-issued ad-data field is intended to provide a means for
3457    Kerberos principal credentials to embed within themselves privilege
3458    attributes and other mechanisms for positive authorization,
3459    amplifying the privileges of the principal beyond what can be done
3460    using a credentials without such an a-data element.
3461
3462    This can not be provided without this element because the definition
3463    of the authorization-data field allows elements to be added at will
3464    by the bearer of a TGT at the time that they request service tickets
3465
3466
3467
3468 September 2004                                                 [Page 58]\f
3469
3470
3471
3472
3473
3474 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
3475
3476
3477    and elements may also be added to a delegated ticket by inclusion in
3478    the authenticator.
3479
3480    For KDC-issued elements this is prevented because the elements are
3481    signed by the KDC by including a checksum encrypted using the
3482    server's key (the same key used to encrypt the ticket - or a key
3483    derived from that key). Elements encapsulated with in the KDC-issued
3484    element MUST  be ignored by the application server if this
3485    "signature" is not present. Further, elements encapsulated within
3486    this element from a ticket-granting ticket MAY be interpreted by the
3487    KDC, and used as a basis according to policy for including new signed
3488    elements within derivative tickets, but they will not be copied to a
3489    derivative ticket directly. If they are copied directly to a
3490    derivative ticket by a KDC that is not aware of this element, the
3491    signature will not be correct for the application ticket elements,
3492    and the field will be ignored by the application server.
3493
3494    This element and the elements it encapsulates MAY be safely ignored
3495    by applications, application servers, and KDCs that do not implement
3496    this element.
3497
3498    The ad-type for AD-KDC-ISSUED is (4).
3499
3500 5.2.6.3. AND-OR
3501
3502    AD-AND-OR               ::= SEQUENCE {
3503            condition-count [0] INTEGER,
3504            elements        [1] AuthorizationData
3505    }
3506
3507
3508    When restrictive AD elements are encapsulated within the and-or
3509    element, the and-or element is considered satisfied if and only if at
3510    least the number of encapsulated elements specified in condition-
3511    count are satisfied.  Therefore, this element MAY be used to
3512    implement an "or" operation by setting the condition-count field to
3513    1, and it MAY specify an "and" operation by setting the condition
3514    count to the number of embedded elements. Application servers that do
3515    not implement this element MUST reject tickets that contain
3516    authorization data elements of this type.
3517
3518    The ad-type for AD-AND-OR is (5).
3519
3520 5.2.6.4. MANDATORY-FOR-KDC
3521
3522    AD-MANDATORY-FOR-KDC    ::= AuthorizationData
3523
3524    AD elements encapsulated within the mandatory-for-kdc element are to
3525
3526
3527
3528 September 2004                                                 [Page 59]\f
3529
3530
3531
3532
3533
3534 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
3535
3536
3537    be interpreted by the KDC. KDCs that do not understand the type of an
3538    element embedded within the mandatory-for-kdc element MUST reject the
3539    request.
3540
3541    The ad-type for AD-MANDATORY-FOR-KDC is (8).
3542
3543 5.2.7. PA-DATA
3544
3545    Historically, PA-DATA have been known as "pre-authentication data",
3546    meaning that they were used to augment the initial authentication
3547    with the KDC.  Since that time, they have also been used as a typed
3548    hole with which to extend protocol exchanges with the KDC.
3549
3550    PA-DATA         ::= SEQUENCE {
3551            -- NOTE: first tag is [1], not [0]
3552            padata-type     [1] Int32,
3553            padata-value    [2] OCTET STRING -- might be encoded AP-REQ
3554    }
3555
3556    padata-type
3557       indicates the way that the padata-value element is to be
3558       interpreted.  Negative values of padata-type are reserved for
3559       unregistered use; non-negative values are used for a registered
3560       interpretation of the element type.
3561
3562    padata-value
3563       Usually contains the DER encoding of another type; the padata-type
3564       field identifies which type is encoded here.
3565
3566        padata-type        name           contents of padata-value
3567
3568        1            pa-tgs-req       DER encoding of AP-REQ
3569
3570        2            pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP
3571
3572        3            pa-pw-salt       salt (not ASN.1 encoded)
3573
3574        11           pa-etype-info    DER encoding of ETYPE-INFO
3575
3576        19           pa-etype-info2   DER encoding of ETYPE-INFO2
3577
3578       This field MAY also contain information needed by certain
3579       extensions to the Kerberos protocol. For example, it might be used
3580       to initially verify the identity of a client before any response
3581       is returned.
3582
3583       The padata field can also contain information needed to help the
3584       KDC or the client select the key needed for generating or
3585
3586
3587
3588 September 2004                                                 [Page 60]\f
3589
3590
3591
3592
3593
3594 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
3595
3596
3597       decrypting the response. This form of the padata is useful for
3598       supporting the use of certain token cards with Kerberos. The
3599       details of such extensions are specified in separate documents.
3600       See [Pat92] for additional uses of this field.
3601
3602 5.2.7.1. PA-TGS-REQ
3603
3604    In the case of requests for additional tickets (KRB_TGS_REQ), padata-
3605    value will contain an encoded AP-REQ. The checksum in the
3606    authenticator (which MUST be collision-proof) is to be computed over
3607    the KDC-REQ-BODY encoding.
3608
3609 5.2.7.2. Encrypted Timestamp Pre-authentication
3610
3611    There are pre-authentication types that may be used to pre-
3612    authenticate a client by means of an encrypted timestamp.
3613
3614    PA-ENC-TIMESTAMP        ::= EncryptedData -- PA-ENC-TS-ENC
3615
3616    PA-ENC-TS-ENC           ::= SEQUENCE {
3617            patimestamp     [0] KerberosTime -- client's time --,
3618            pausec          [1] Microseconds OPTIONAL
3619    }
3620
3621    Patimestamp contains the client's time, and pausec contains the
3622    microseconds, which MAY be omitted if a client will not generate more
3623    than one request per second. The ciphertext (padata-value) consists
3624    of the PA-ENC-TS-ENC encoding, encrypted using the client's secret
3625    key and a key usage value of 1.
3626
3627    This pre-authentication type was not present in RFC 1510, but many
3628    implementations support it.
3629
3630 5.2.7.3. PA-PW-SALT
3631
3632    The padata-value for this pre-authentication type contains the salt
3633    for the string-to-key to be used by the client to obtain the key for
3634    decrypting the encrypted part of an AS-REP message. Unfortunately,
3635    for historical reasons, the character set to be used is unspecified
3636    and probably locale-specific.
3637
3638    This pre-authentication type was not present in RFC 1510, but many
3639    implementations support it. It is necessary in any case where the
3640    salt for the string-to-key algorithm is not the default.
3641
3642    In the trivial example, a zero-length salt string is very commonplace
3643    for realms that have converted their principal databases from
3644    Kerberos 4.
3645
3646
3647
3648 September 2004                                                 [Page 61]\f
3649
3650
3651
3652
3653
3654 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
3655
3656
3657    A KDC SHOULD NOT send PA-PW-SALT when issuing a KRB-ERROR message
3658    that requests additional pre-authentication. Implementation note:
3659    some KDC implementations issue an erroneous PA-PW-SALT when issuing a
3660    KRB-ERROR message that requests additional pre-authentication.
3661    Therefore, clients SHOULD ignore a PA-PW-SALT accompanying a KRB-
3662    ERROR message that requests additional pre-authentication.  As noted
3663    in section 3.1.3, a KDC MUST NOT send PA-PW-SALT when the client's
3664    AS-REQ includes at least one "newer" etype.
3665
3666 5.2.7.4. PA-ETYPE-INFO
3667
3668    The ETYPE-INFO pre-authentication type is sent by the KDC in a KRB-
3669    ERROR indicating a requirement for additional pre-authentication. It
3670    is usually used to notify a client of which key to use for the
3671    encryption of an encrypted timestamp for the purposes of sending a
3672    PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an
3673    AS-REP to provide information to the client about which key salt to
3674    use for the string-to-key to be used by the client to obtain the key
3675    for decrypting the encrypted part the AS-REP.
3676
3677    ETYPE-INFO-ENTRY        ::= SEQUENCE {
3678            etype           [0] Int32,
3679            salt            [1] OCTET STRING OPTIONAL
3680    }
3681
3682    ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
3683
3684    The salt, like that of PA-PW-SALT, is also completely unspecified
3685    with respect to character set and is probably locale-specific.
3686
3687    If ETYPE-INFO is sent in an AS-REP, there shall be exactly one ETYPE-
3688    INFO-ENTRY, and its etype shall match that of the enc-part in the AS-
3689    REP.
3690
3691    This pre-authentication type was not present in RFC 1510, but many
3692    implementations that support encrypted timestamps for pre-
3693    authentication need to support ETYPE-INFO as well.  As noted in
3694    section 3.1.3, a KDC MUST NOT send PA-ETYPE-INFO when the client's
3695    AS-REQ includes at least one "newer" etype.
3696
3697 5.2.7.5. PA-ETYPE-INFO2
3698
3699    The ETYPE-INFO2 pre-authentication type is sent by the KDC in a KRB-
3700    ERROR indicating a requirement for additional pre-authentication. It
3701    is usually used to notify a client of which key to use for the
3702    encryption of an encrypted timestamp for the purposes of sending a
3703    PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an
3704    AS-REP to provide information to the client about which key salt to
3705
3706
3707
3708 September 2004                                                 [Page 62]\f
3709
3710
3711
3712
3713
3714 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
3715
3716
3717    use for the string-to-key to be used by the client to obtain the key
3718    for decrypting the encrypted part the AS-REP.
3719
3720    ETYPE-INFO2-ENTRY       ::= SEQUENCE {
3721            etype           [0] Int32,
3722            salt            [1] KerberosString OPTIONAL,
3723            s2kparams       [2] OCTET STRING OPTIONAL
3724    }
3725
3726    ETYPE-INFO2              ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY
3727
3728    The type of the salt is KerberosString, but existing installations
3729    might have locale-specific characters stored in salt strings, and
3730    implementors MAY choose to handle them.
3731
3732    The interpretation of s2kparams is specified in the cryptosystem
3733    description associated with the etype. Each cryptosystem has a
3734    default interpretation of s2kparams that will hold if that element is
3735    omitted from the encoding of ETYPE-INFO2-ENTRY.
3736
3737    If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one
3738    ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part in
3739    the AS-REP.
3740
3741    The preferred ordering of the "hint" pre-authentication data that
3742    affect client key selection is: ETYPE-INFO2, followed by ETYPE-INFO,
3743    followed by PW-SALT.  As noted in section 3.1.3, a KDC MUST NOT send
3744    ETYPE-INFO or PW-SALT when the client's AS-REQ includes at least one
3745    "newer" etype.
3746
3747    The ETYPE-INFO2 pre-authentication type was not present in RFC 1510.
3748
3749 5.2.8. KerberosFlags
3750
3751    For several message types, a specific constrained bit string type,
3752    KerberosFlags, is used.
3753
3754    KerberosFlags   ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits
3755                        -- shall be sent, but no fewer than 32
3756
3757    Compatibility note: the following paragraphs describe a change from
3758    the RFC1510 description of bit strings that would result in
3759    incompatility in the case of an implementation that strictly
3760    conformed to ASN.1 DER and RFC1510.
3761
3762    ASN.1 bit strings have multiple uses. The simplest use of a bit
3763    string is to contain a vector of bits, with no particular meaning
3764    attached to individual bits. This vector of bits is not necessarily a
3765
3766
3767
3768 September 2004                                                 [Page 63]\f
3769
3770
3771
3772
3773
3774 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
3775
3776
3777    multiple of eight bits long.  The use in Kerberos of a bit string as
3778    a compact boolean vector wherein each element has a distinct meaning
3779    poses some problems. The natural notation for a compact boolean
3780    vector is the ASN.1 "NamedBit" notation, and the DER require that
3781    encodings of a bit string using "NamedBit" notation exclude any
3782    trailing zero bits. This truncation is easy to neglect, especially
3783    given C language implementations that naturally choose to store
3784    boolean vectors as 32 bit integers.
3785
3786    For example, if the notation for KDCOptions were to include the
3787    "NamedBit" notation, as in RFC 1510, and a KDCOptions value to be
3788    encoded had only the "forwardable" (bit number one) bit set, the DER
3789    encoding MUST include only two bits: the first reserved bit
3790    ("reserved", bit number zero, value zero) and the one-valued bit (bit
3791    number one) for "forwardable".
3792
3793    Most existing implementations of Kerberos unconditionally send 32
3794    bits on the wire when encoding bit strings used as boolean vectors.
3795    This behavior violates the ASN.1 syntax used for flag values in RFC
3796    1510, but occurs on such a widely installed base that the protocol
3797    description is being modified to accommodate it.
3798
3799    Consequently, this document removes the "NamedBit" notations for
3800    individual bits, relegating them to comments. The size constraint on
3801    the KerberosFlags type requires that at least 32 bits be encoded at
3802    all times, though a lenient implementation MAY choose to accept fewer
3803    than 32 bits and to treat the missing bits as set to zero.
3804
3805    Currently, no uses of KerberosFlags specify more than 32 bits worth
3806    of flags, although future revisions of this document may do so. When
3807    more than 32 bits are to be transmitted in a KerberosFlags value,
3808    future revisions to this document will likely specify that the
3809    smallest number of bits needed to encode the highest-numbered one-
3810    valued bit should be sent. This is somewhat similar to the DER
3811    encoding of a bit string that is declared with the "NamedBit"
3812    notation.
3813
3814 5.2.9. Cryptosystem-related Types
3815
3816    Many Kerberos protocol messages contain an EncryptedData as a
3817    container for arbitrary encrypted data, which is often the encrypted
3818    encoding of another data type. Fields within EncryptedData assist the
3819    recipient in selecting a key with which to decrypt the enclosed data.
3820
3821    EncryptedData   ::= SEQUENCE {
3822            etype   [0] Int32 -- EncryptionType --,
3823            kvno    [1] UInt32 OPTIONAL,
3824            cipher  [2] OCTET STRING -- ciphertext
3825
3826
3827
3828 September 2004                                                 [Page 64]\f
3829
3830
3831
3832
3833
3834 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
3835
3836
3837    }
3838
3839    etype
3840       This field identifies which encryption algorithm was used to
3841       encipher the cipher.
3842
3843    kvno
3844       This field contains the version number of the key under which data
3845       is encrypted. It is only present in messages encrypted under long
3846       lasting keys, such as principals' secret keys.
3847
3848    cipher
3849       This field contains the enciphered text, encoded as an OCTET
3850       STRING.  (Note that the encryption mechanisms defined in
3851       [@KCRYPTO] MUST incorporate integrity protection as well, so no
3852       additional checksum is required.)
3853
3854    The EncryptionKey type is the means by which cryptographic keys used
3855    for encryption are transferred.
3856
3857    EncryptionKey   ::= SEQUENCE {
3858            keytype         [0] Int32 -- actually encryption type --,
3859            keyvalue        [1] OCTET STRING
3860    }
3861
3862    keytype
3863       This field specifies the encryption type of the encryption key
3864       that follows in the keyvalue field. While its name is "keytype",
3865       it actually specifies an encryption type. Previously, multiple
3866       cryptosystems that performed encryption differently but were
3867       capable of using keys with the same characteristics were permitted
3868       to share an assigned number to designate the type of key; this
3869       usage is now deprecated.
3870
3871    keyvalue
3872       This field contains the key itself, encoded as an octet string.
3873
3874    Messages containing cleartext data to be authenticated will usually
3875    do so by using a member of type Checksum. Most instances of Checksum
3876    use a keyed hash, though exceptions will be noted.
3877
3878    Checksum        ::= SEQUENCE {
3879            cksumtype       [0] Int32,
3880            checksum        [1] OCTET STRING
3881    }
3882
3883    cksumtype
3884       This field indicates the algorithm used to generate the
3885
3886
3887
3888 September 2004                                                 [Page 65]\f
3889
3890
3891
3892
3893
3894 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
3895
3896
3897       accompanying checksum.
3898
3899    checksum
3900       This field contains the checksum itself, encoded as an octet
3901       string.
3902
3903    See section 4 for a brief description of the use of encryption and
3904    checksums in Kerberos.
3905
3906 5.3. Tickets
3907
3908    This section describes the format and encryption parameters for
3909    tickets and authenticators. When a ticket or authenticator is
3910    included in a protocol message it is treated as an opaque object. A
3911    ticket is a record that helps a client authenticate to a service. A
3912    Ticket contains the following information:
3913
3914    Ticket          ::= [APPLICATION 1] SEQUENCE {
3915            tkt-vno         [0] INTEGER (5),
3916            realm           [1] Realm,
3917            sname           [2] PrincipalName,
3918            enc-part        [3] EncryptedData -- EncTicketPart
3919    }
3920
3921    -- Encrypted part of ticket
3922    EncTicketPart   ::= [APPLICATION 3] SEQUENCE {
3923            flags                   [0] TicketFlags,
3924            key                     [1] EncryptionKey,
3925            crealm                  [2] Realm,
3926            cname                   [3] PrincipalName,
3927            transited               [4] TransitedEncoding,
3928            authtime                [5] KerberosTime,
3929            starttime               [6] KerberosTime OPTIONAL,
3930            endtime                 [7] KerberosTime,
3931            renew-till              [8] KerberosTime OPTIONAL,
3932            caddr                   [9] HostAddresses OPTIONAL,
3933            authorization-data      [10] AuthorizationData OPTIONAL
3934    }
3935
3936    -- encoded Transited field
3937    TransitedEncoding       ::= SEQUENCE {
3938            tr-type         [0] Int32 -- must be registered --,
3939            contents        [1] OCTET STRING
3940    }
3941
3942    TicketFlags     ::= KerberosFlags
3943            -- reserved(0),
3944            -- forwardable(1),
3945
3946
3947
3948 September 2004                                                 [Page 66]\f
3949
3950
3951
3952
3953
3954 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
3955
3956
3957            -- forwarded(2),
3958            -- proxiable(3),
3959            -- proxy(4),
3960            -- may-postdate(5),
3961            -- postdated(6),
3962            -- invalid(7),
3963            -- renewable(8),
3964            -- initial(9),
3965            -- pre-authent(10),
3966            -- hw-authent(11),
3967    -- the following are new since 1510
3968            -- transited-policy-checked(12),
3969            -- ok-as-delegate(13)
3970
3971    tkt-vno
3972       This field specifies the version number for the ticket format.
3973       This document describes version number 5.
3974
3975    realm
3976       This field specifies the realm that issued a ticket. It also
3977       serves to identify the realm part of the server's principal
3978       identifier. Since a Kerberos server can only issue tickets for
3979       servers within its realm, the two will always be identical.
3980
3981    sname
3982       This field specifies all components of the name part of the
3983       server's identity, including those parts that identify a specific
3984       instance of a service.
3985
3986    enc-part
3987       This field holds the encrypted encoding of the EncTicketPart
3988       sequence.  It is encrypted in the key shared by Kerberos and the
3989       end server (the server's secret key), using a key usage value of
3990       2.
3991
3992    flags
3993       This field indicates which of various options were used or
3994       requested when the ticket was issued. The meanings of the flags
3995       are:
3996
3997          Bit(s)  Name                   Description
3998
3999          0       reserved               Reserved for future expansion of this
4000                                         field.
4001
4002                                         The FORWARDABLE flag is normally only
4003                                         interpreted by the TGS, and can be
4004                                         ignored by end servers. When set, this
4005
4006
4007
4008 September 2004                                                 [Page 67]\f
4009
4010
4011
4012
4013
4014 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
4015
4016
4017          1       forwardable            flag tells the ticket-granting server
4018                                         that it is OK to issue a new
4019                                         ticket-granting ticket with a
4020                                         different network address based on the
4021                                         presented ticket.
4022
4023                                         When set, this flag indicates that the
4024                                         ticket has either been forwarded or
4025          2       forwarded              was issued based on authentication
4026                                         involving a forwarded ticket-granting
4027                                         ticket.
4028
4029                                         The PROXIABLE flag is normally only
4030                                         interpreted by the TGS, and can be
4031                                         ignored by end servers. The PROXIABLE
4032                                         flag has an interpretation identical
4033          3       proxiable              to that of the FORWARDABLE flag,
4034                                         except that the PROXIABLE flag tells
4035                                         the ticket-granting server that only
4036                                         non-ticket-granting tickets may be
4037                                         issued with different network
4038                                         addresses.
4039
4040          4       proxy                  When set, this flag indicates that a
4041                                         ticket is a proxy.
4042
4043                                         The MAY-POSTDATE flag is normally only
4044                                         interpreted by the TGS, and can be
4045          5       may-postdate           ignored by end servers. This flag
4046                                         tells the ticket-granting server that
4047                                         a post-dated ticket MAY be issued
4048                                         based on this ticket-granting ticket.
4049
4050                                         This flag indicates that this ticket
4051                                         has been postdated. The end-service
4052          6       postdated              can check the authtime field to see
4053                                         when the original authentication
4054                                         occurred.
4055
4056                                         This flag indicates that a ticket is
4057                                         invalid, and it must be validated by
4058          7       invalid                the KDC before use. Application
4059                                         servers must reject tickets which have
4060                                         this flag set.
4061
4062                                         The RENEWABLE flag is normally only
4063                                         interpreted by the TGS, and can
4064                                         usually be ignored by end servers
4065
4066
4067
4068 September 2004                                                 [Page 68]\f
4069
4070
4071
4072
4073
4074 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
4075
4076
4077          8       renewable              (some particularly careful servers MAY
4078                                         disallow renewable tickets). A
4079                                         renewable ticket can be used to obtain
4080                                         a replacement ticket that expires at a
4081                                         later date.
4082
4083                                         This flag indicates that this ticket
4084          9       initial                was issued using the AS protocol, and
4085                                         not issued based on a ticket-granting
4086                                         ticket.
4087
4088                                         This flag indicates that during
4089                                         initial authentication, the client was
4090                                         authenticated by the KDC before a
4091          10      pre-authent            ticket was issued. The strength of the
4092                                         pre-authentication method is not
4093                                         indicated, but is acceptable to the
4094                                         KDC.
4095
4096                                         This flag indicates that the protocol
4097                                         employed for initial authentication
4098                                         required the use of hardware expected
4099          11      hw-authent             to be possessed solely by the named
4100                                         client. The hardware authentication
4101                                         method is selected by the KDC and the
4102                                         strength of the method is not
4103                                         indicated.
4104
4105                                         This flag indicates that the KDC for
4106                                         the realm has checked the transited
4107                                         field against a realm defined policy
4108                                         for trusted certifiers. If this flag
4109                                         is reset (0), then the application
4110                                         server must check the transited field
4111                                         itself, and if unable to do so it must
4112                                         reject the authentication. If the flag
4113          12      transited-             is set (1) then the application server
4114                  policy-checked         MAY skip its own validation of the
4115                                         transited field, relying on the
4116                                         validation performed by the KDC. At
4117                                         its option the application server MAY
4118                                         still apply its own validation based
4119                                         on a separate policy for acceptance.
4120
4121                                         This flag is new since RFC 1510.
4122
4123                                         This flag indicates that the server
4124                                         (not the client) specified in the
4125
4126
4127
4128 September 2004                                                 [Page 69]\f
4129
4130
4131
4132
4133
4134 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
4135
4136
4137                                         ticket has been determined by policy
4138                                         of the realm to be a suitable
4139                                         recipient of delegation. A client can
4140                                         use the presence of this flag to help
4141                                         it make a decision whether to delegate
4142                                         credentials (either grant a proxy or a
4143                                         forwarded ticket-granting ticket) to
4144          13      ok-as-delegate         this server. The client is free to
4145                                         ignore the value of this flag. When
4146                                         setting this flag, an administrator
4147                                         should consider the Security and
4148                                         placement of the server on which the
4149                                         service will run, as well as whether
4150                                         the service requires the use of
4151                                         delegated credentials.
4152
4153                                         This flag is new since RFC 1510.
4154
4155          14-31   reserved               Reserved for future use.
4156
4157    key
4158       This field exists in the ticket and the KDC response and is used
4159       to pass the session key from Kerberos to the application server
4160       and the client.
4161
4162    crealm
4163       This field contains the name of the realm in which the client is
4164       registered and in which initial authentication took place.
4165
4166    cname
4167       This field contains the name part of the client's principal
4168       identifier.
4169
4170    transited
4171       This field lists the names of the Kerberos realms that took part
4172       in authenticating the user to whom this ticket was issued. It does
4173       not specify the order in which the realms were transited. See
4174       section 3.3.3.2 for details on how this field encodes the
4175       traversed realms.  When the names of CA's are to be embedded in
4176       the transited field (as specified for some extensions to the
4177       protocol), the X.500 names of the CA's SHOULD be mapped into items
4178       in the transited field using the mapping defined by RFC2253.
4179
4180    authtime
4181       This field indicates the time of initial authentication for the
4182       named principal. It is the time of issue for the original ticket
4183       on which this ticket is based. It is included in the ticket to
4184       provide additional information to the end service, and to provide
4185
4186
4187
4188 September 2004                                                 [Page 70]\f
4189
4190
4191
4192
4193
4194 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
4195
4196
4197       the necessary information for implementation of a `hot list'
4198       service at the KDC. An end service that is particularly paranoid
4199       could refuse to accept tickets for which the initial
4200       authentication occurred "too far" in the past. This field is also
4201       returned as part of the response from the KDC.  When returned as
4202       part of the response to initial authentication (KRB_AS_REP), this
4203       is the current time on the Kerberos server.  It is NOT recommended
4204       that this time value be used to adjust the workstation's clock
4205       since the workstation cannot reliably determine that such a
4206       KRB_AS_REP actually came from the proper KDC in a timely manner.
4207
4208
4209    starttime
4210
4211       This field in the ticket specifies the time after which the ticket
4212       is valid. Together with endtime, this field specifies the life of
4213       the ticket. If the starttime field is absent from the ticket, then
4214       the authtime field SHOULD be used in its place to determine the
4215       life of the ticket.
4216
4217    endtime
4218       This field contains the time after which the ticket will not be
4219       honored (its expiration time). Note that individual services MAY
4220       place their own limits on the life of a ticket and MAY reject
4221       tickets which have not yet expired. As such, this is really an
4222       upper bound on the expiration time for the ticket.
4223
4224    renew-till
4225       This field is only present in tickets that have the RENEWABLE flag
4226       set in the flags field. It indicates the maximum endtime that may
4227       be included in a renewal. It can be thought of as the absolute
4228       expiration time for the ticket, including all renewals.
4229
4230    caddr
4231       This field in a ticket contains zero (if omitted) or more (if
4232       present) host addresses. These are the addresses from which the
4233       ticket can be used. If there are no addresses, the ticket can be
4234       used from any location. The decision by the KDC to issue or by the
4235       end server to accept addressless tickets is a policy decision and
4236       is left to the Kerberos and end-service administrators; they MAY
4237       refuse to issue or accept such tickets. Because of the wide
4238       deployment of network address translation, it is recommended that
4239       policy allow the issue and acceptance of such tickets.
4240
4241       Network addresses are included in the ticket to make it harder for
4242       an attacker to use stolen credentials. Because the session key is
4243       not sent over the network in cleartext, credentials can't be
4244       stolen simply by listening to the network; an attacker has to gain
4245
4246
4247
4248 September 2004                                                 [Page 71]\f
4249
4250
4251
4252
4253
4254 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
4255
4256
4257       access to the session key (perhaps through operating system
4258       security breaches or a careless user's unattended session) to make
4259       use of stolen tickets.
4260
4261       It is important to note that the network address from which a
4262       connection is received cannot be reliably determined. Even if it
4263       could be, an attacker who has compromised the client's workstation
4264       could use the credentials from there. Including the network
4265       addresses only makes it more difficult, not impossible, for an
4266       attacker to walk off with stolen credentials and then use them
4267       from a "safe" location.
4268
4269    authorization-data
4270       The authorization-data field is used to pass authorization data
4271       from the principal on whose behalf a ticket was issued to the
4272       application service. If no authorization data is included, this
4273       field will be left out. Experience has shown that the name of this
4274       field is confusing, and that a better name for this field would be
4275       restrictions. Unfortunately, it is not possible to change the name
4276       of this field at this time.
4277
4278       This field contains restrictions on any authority obtained on the
4279       basis of authentication using the ticket. It is possible for any
4280       principal in possession of credentials to add entries to the
4281       authorization data field since these entries further restrict what
4282       can be done with the ticket.  Such additions can be made by
4283       specifying the additional entries when a new ticket is obtained
4284       during the TGS exchange, or they MAY be added during chained
4285       delegation using the authorization data field of the
4286       authenticator.
4287
4288       Because entries may be added to this field by the holder of
4289       credentials, except when an entry is separately authenticated by
4290       encapsulation in the KDC-issued element, it is not allowable for
4291       the presence of an entry in the authorization data field of a
4292       ticket to amplify the privileges one would obtain from using a
4293       ticket.
4294
4295       The data in this field may be specific to the end service; the
4296       field will contain the names of service specific objects, and the
4297       rights to those objects. The format for this field is described in
4298       section 5.2.6.  Although Kerberos is not concerned with the format
4299       of the contents of the sub-fields, it does carry type information
4300       (ad-type).
4301
4302       By using the authorization_data field, a principal is able to
4303       issue a proxy that is valid for a specific purpose. For example, a
4304       client wishing to print a file can obtain a file server proxy to
4305
4306
4307
4308 September 2004                                                 [Page 72]\f
4309
4310
4311
4312
4313
4314 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
4315
4316
4317       be passed to the print server. By specifying the name of the file
4318       in the authorization_data field, the file server knows that the
4319       print server can only use the client's rights when accessing the
4320       particular file to be printed.
4321
4322       A separate service providing authorization or certifying group
4323       membership may be built using the authorization-data field. In
4324       this case, the entity granting authorization (not the authorized
4325       entity), may obtain a ticket in its own name (e.g. the ticket is
4326       issued in the name of a privilege server), and this entity adds
4327       restrictions on its own authority and delegates the restricted
4328       authority through a proxy to the client. The client would then
4329       present this authorization credential to the application server
4330       separately from the authentication exchange.  Alternatively, such
4331       authorization credentials MAY be embedded in the ticket
4332       authenticating the authorized entity, when the authorization is
4333       separately authenticated using the KDC-issued authorization data
4334       element (see 5.2.6.2).
4335
4336       Similarly, if one specifies the authorization-data field of a
4337       proxy and leaves the host addresses blank, the resulting ticket
4338       and session key can be treated as a capability. See [Neu93] for
4339       some suggested uses of this field.
4340
4341       The authorization-data field is optional and does not have to be
4342       included in a ticket.
4343
4344 5.4. Specifications for the AS and TGS exchanges
4345
4346    This section specifies the format of the messages used in the
4347    exchange between the client and the Kerberos server. The format of
4348    possible error messages appears in section 5.9.1.
4349
4350 5.4.1. KRB_KDC_REQ definition
4351
4352    The KRB_KDC_REQ message has no application tag number of its own.
4353    Instead, it is incorporated into one of KRB_AS_REQ or KRB_TGS_REQ,
4354    which each have an application tag, depending on whether the request
4355    is for an initial ticket or an additional ticket. In either case, the
4356    message is sent from the client to the KDC to request credentials for
4357    a service.
4358
4359    The message fields are:
4360
4361    AS-REQ          ::= [APPLICATION 10] KDC-REQ
4362
4363    TGS-REQ         ::= [APPLICATION 12] KDC-REQ
4364
4365
4366
4367
4368 September 2004                                                 [Page 73]\f
4369
4370
4371
4372
4373
4374 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
4375
4376
4377    KDC-REQ         ::= SEQUENCE {
4378            -- NOTE: first tag is [1], not [0]
4379            pvno            [1] INTEGER (5) ,
4380            msg-type        [2] INTEGER (10 -- AS -- | 12 -- TGS --),
4381            padata          [3] SEQUENCE OF PA-DATA OPTIONAL
4382                                -- NOTE: not empty --,
4383            req-body        [4] KDC-REQ-BODY
4384    }
4385
4386    KDC-REQ-BODY    ::= SEQUENCE {
4387            kdc-options             [0] KDCOptions,
4388            cname                   [1] PrincipalName OPTIONAL
4389                                        -- Used only in AS-REQ --,
4390            realm                   [2] Realm
4391                                        -- Server's realm
4392                                        -- Also client's in AS-REQ --,
4393            sname                   [3] PrincipalName OPTIONAL,
4394            from                    [4] KerberosTime OPTIONAL,
4395            till                    [5] KerberosTime,
4396            rtime                   [6] KerberosTime OPTIONAL,
4397            nonce                   [7] UInt32,
4398            etype                   [8] SEQUENCE OF Int32 -- EncryptionType
4399                                        -- in preference order --,
4400            addresses               [9] HostAddresses OPTIONAL,
4401            enc-authorization-data  [10] EncryptedData OPTIONAL
4402                                        -- AuthorizationData --,
4403            additional-tickets      [11] SEQUENCE OF Ticket OPTIONAL
4404                                            -- NOTE: not empty
4405    }
4406
4407    KDCOptions      ::= KerberosFlags
4408            -- reserved(0),
4409            -- forwardable(1),
4410            -- forwarded(2),
4411            -- proxiable(3),
4412            -- proxy(4),
4413            -- allow-postdate(5),
4414            -- postdated(6),
4415            -- unused7(7),
4416            -- renewable(8),
4417            -- unused9(9),
4418            -- unused10(10),
4419            -- opt-hardware-auth(11),
4420            -- unused12(12),
4421            -- unused13(13),
4422    -- 15 is reserved for canonicalize
4423            -- unused15(15),
4424    -- 26 was unused in 1510
4425
4426
4427
4428 September 2004                                                 [Page 74]\f
4429
4430
4431
4432
4433
4434 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
4435
4436
4437            -- disable-transited-check(26),
4438    --
4439            -- renewable-ok(27),
4440            -- enc-tkt-in-skey(28),
4441            -- renew(30),
4442            -- validate(31)
4443
4444    The fields in this message are:
4445
4446    pvno
4447       This field is included in each message, and specifies the protocol
4448       version number. This document specifies protocol version 5.
4449
4450    msg-type
4451       This field indicates the type of a protocol message. It will
4452       almost always be the same as the application identifier associated
4453       with a message. It is included to make the identifier more readily
4454       accessible to the application. For the KDC-REQ message, this type
4455       will be KRB_AS_REQ or KRB_TGS_REQ.
4456
4457    padata
4458       Contains pre-authentication data. Requests for additional tickets
4459       (KRB_TGS_REQ) MUST contain a padata of PA-TGS-REQ.
4460
4461       The padata (pre-authentication data) field contains a sequence of
4462       authentication information which may be needed before credentials
4463       can be issued or decrypted.
4464
4465    req-body
4466       This field is a placeholder delimiting the extent of the remaining
4467       fields. If a checksum is to be calculated over the request, it is
4468       calculated over an encoding of the KDC-REQ-BODY sequence which is
4469       enclosed within the req-body field.
4470
4471    kdc-options
4472       This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to
4473       the KDC and indicates the flags that the client wants set on the
4474       tickets as well as other information that is to modify the
4475       behavior of the KDC.  Where appropriate, the name of an option may
4476       be the same as the flag that is set by that option. Although in
4477       most case, the bit in the options field will be the same as that
4478       in the flags field, this is not guaranteed, so it is not
4479       acceptable to simply copy the options field to the flags field.
4480       There are various checks that must be made before honoring an
4481       option anyway.
4482
4483       The kdc_options field is a bit-field, where the selected options
4484       are indicated by the bit being set (1), and the unselected options
4485
4486
4487
4488 September 2004                                                 [Page 75]\f
4489
4490
4491
4492
4493
4494 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
4495
4496
4497       and reserved fields being reset (0). The encoding of the bits is
4498       specified in section 5.2. The options are described in more detail
4499       above in section 2. The meanings of the options are:
4500
4501          Bits    Name                     Description
4502
4503          0       RESERVED                 Reserved for future expansion of
4504                                           this field.
4505
4506                                           The FORWARDABLE option indicates
4507                                           that the ticket to be issued is to
4508                                           have its forwardable flag set. It
4509          1       FORWARDABLE              may only be set on the initial
4510                                           request, or in a subsequent request
4511                                           if the ticket-granting ticket on
4512                                           which it is based is also
4513                                           forwardable.
4514
4515                                           The FORWARDED option is only
4516                                           specified in a request to the
4517                                           ticket-granting server and will only
4518                                           be honored if the ticket-granting
4519                                           ticket in the request has its
4520          2       FORWARDED                FORWARDABLE bit set. This option
4521                                           indicates that this is a request for
4522                                           forwarding. The address(es) of the
4523                                           host from which the resulting ticket
4524                                           is to be valid are included in the
4525                                           addresses field of the request.
4526
4527                                           The PROXIABLE option indicates that
4528                                           the ticket to be issued is to have
4529                                           its proxiable flag set. It may only
4530          3       PROXIABLE                be set on the initial request, or in
4531                                           a subsequent request if the
4532                                           ticket-granting ticket on which it
4533                                           is based is also proxiable.
4534
4535                                           The PROXY option indicates that this
4536                                           is a request for a proxy. This
4537                                           option will only be honored if the
4538                                           ticket-granting ticket in the
4539          4       PROXY                    request has its PROXIABLE bit set.
4540                                           The address(es) of the host from
4541                                           which the resulting ticket is to be
4542                                           valid are included in the addresses
4543                                           field of the request.
4544
4545
4546
4547
4548 September 2004                                                 [Page 76]\f
4549
4550
4551
4552
4553
4554 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
4555
4556
4557                                           The ALLOW-POSTDATE option indicates
4558                                           that the ticket to be issued is to
4559                                           have its MAY-POSTDATE flag set. It
4560          5       ALLOW-POSTDATE           may only be set on the initial
4561                                           request, or in a subsequent request
4562                                           if the ticket-granting ticket on
4563                                           which it is based also has its
4564                                           MAY-POSTDATE flag set.
4565
4566                                           The POSTDATED option indicates that
4567                                           this is a request for a postdated
4568                                           ticket. This option will only be
4569                                           honored if the ticket-granting
4570                                           ticket on which it is based has its
4571          6       POSTDATED                MAY-POSTDATE flag set. The resulting
4572                                           ticket will also have its INVALID
4573                                           flag set, and that flag may be reset
4574                                           by a subsequent request to the KDC
4575                                           after the starttime in the ticket
4576                                           has been reached.
4577
4578          7       RESERVED                 This option is presently unused.
4579
4580                                           The RENEWABLE option indicates that
4581                                           the ticket to be issued is to have
4582                                           its RENEWABLE flag set. It may only
4583                                           be set on the initial request, or
4584                                           when the ticket-granting ticket on
4585          8       RENEWABLE                which the request is based is also
4586                                           renewable. If this option is
4587                                           requested, then the rtime field in
4588                                           the request contains the desired
4589                                           absolute expiration time for the
4590                                           ticket.
4591
4592          9       RESERVED                 Reserved for PK-Cross
4593
4594          10      RESERVED                 Reserved for future use.
4595
4596          11      RESERVED                 Reserved for opt-hardware-auth.
4597
4598          12-25   RESERVED                 Reserved for future use.
4599
4600                                           By default the KDC will check the
4601                                           transited field of a
4602                                           ticket-granting-ticket against the
4603                                           policy of the local realm before it
4604                                           will issue derivative tickets based
4605
4606
4607
4608 September 2004                                                 [Page 77]\f
4609
4610
4611
4612
4613
4614 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
4615
4616
4617                                           on the ticket-granting ticket. If
4618                                           this flag is set in the request,
4619                                           checking of the transited field is
4620                                           disabled. Tickets issued without the
4621          26      DISABLE-TRANSITED-CHECK  performance of this check will be
4622                                           noted by the reset (0) value of the
4623                                           TRANSITED-POLICY-CHECKED flag,
4624                                           indicating to the application server
4625                                           that the tranisted field must be
4626                                           checked locally. KDCs are
4627                                           encouraged but not required to honor
4628                                           the DISABLE-TRANSITED-CHECK option.
4629
4630                                           This flag is new since RFC 1510
4631
4632                                           The RENEWABLE-OK option indicates
4633                                           that a renewable ticket will be
4634                                           acceptable if a ticket with the
4635                                           requested life cannot otherwise be
4636                                           provided. If a ticket with the
4637                                           requested life cannot be provided,
4638          27      RENEWABLE-OK             then a renewable ticket may be
4639                                           issued with a renew-till equal to
4640                                           the requested endtime. The value
4641                                           of the renew-till field may still be
4642                                           limited by local limits, or limits
4643                                           selected by the individual principal
4644                                           or server.
4645
4646                                           This option is used only by the
4647                                           ticket-granting service. The
4648                                           ENC-TKT-IN-SKEY option indicates
4649          28      ENC-TKT-IN-SKEY          that the ticket for the end server
4650                                           is to be encrypted in the session
4651                                           key from the additional
4652                                           ticket-granting ticket provided.
4653
4654          29      RESERVED                 Reserved for future use.
4655
4656                                           This option is used only by the
4657                                           ticket-granting service. The RENEW
4658                                           option indicates that the present
4659                                           request is for a renewal. The ticket
4660                                           provided is encrypted in the secret
4661                                           key for the server on which it is
4662          30      RENEW                    valid. This option will only be
4663                                           honored if the ticket to be renewed
4664                                           has its RENEWABLE flag set and if
4665
4666
4667
4668 September 2004                                                 [Page 78]\f
4669
4670
4671
4672
4673
4674 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
4675
4676
4677                                           the time in its renew-till field has
4678                                           not passed. The ticket to be renewed
4679                                           is passed in the padata field as
4680                                           part of the authentication header.
4681
4682                                           This option is used only by the
4683                                           ticket-granting service. The
4684                                           VALIDATE option indicates that the
4685                                           request is to validate a postdated
4686                                           ticket. It will only be honored if
4687                                           the ticket presented is postdated,
4688                                           presently has its INVALID flag set,
4689          31      VALIDATE                 and would be otherwise usable at
4690                                           this time. A ticket cannot be
4691                                           validated before its starttime. The
4692                                           ticket presented for validation is
4693                                           encrypted in the key of the server
4694                                           for which it is valid and is passed
4695                                           in the padata field as part of the
4696                                           authentication header.
4697    cname and sname
4698       These fields are the same as those described for the ticket in
4699       section 5.3. The sname may only be absent when the ENC-TKT-IN-SKEY
4700       option is specified. If absent, the name of the server is taken
4701       from the name of the client in the ticket passed as additional-
4702       tickets.
4703
4704    enc-authorization-data
4705       The enc-authorization-data, if present (and it can only be present
4706       in the TGS_REQ form), is an encoding of the desired authorization-
4707       data encrypted under the sub-session key if present in the
4708       Authenticator, or alternatively from the session key in the
4709       ticket-granting ticket (both the Authenticator and ticket-granting
4710       ticket come from the padata field in the KRB_TGS_REQ). The key
4711       usage value used when encrypting is 5 if a sub-session key is
4712       used, or 4 if the session key is used.
4713
4714    realm
4715       This field specifies the realm part of the server's principal
4716       identifier. In the AS exchange, this is also the realm part of the
4717       client's principal identifier.
4718
4719    from
4720       This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket
4721       requests when the requested ticket is to be postdated. It
4722       specifies the desired start time for the requested ticket. If this
4723       field is omitted then the KDC SHOULD use the current time instead.
4724
4725
4726
4727
4728 September 2004                                                 [Page 79]\f
4729
4730
4731
4732
4733
4734 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
4735
4736
4737    till
4738       This field contains the expiration date requested by the client in
4739       a ticket request. It is not optional, but if the requested endtime
4740       is "19700101000000Z", the requested ticket is to have the maximum
4741       endtime permitted according to KDC policy. Implementation note:
4742       This special timestamp corresponds to a UNIX time_t value of zero
4743       on most systems.
4744
4745    rtime
4746       This field is the requested renew-till time sent from a client to
4747       the KDC in a ticket request. It is optional.
4748
4749    nonce
4750       This field is part of the KDC request and response. It is intended
4751       to hold a random number generated by the client. If the same
4752       number is included in the encrypted response from the KDC, it
4753       provides evidence that the response is fresh and has not been
4754       replayed by an attacker.  Nonces MUST NEVER be reused.
4755
4756    etype
4757       This field specifies the desired encryption algorithm to be used
4758       in the response.
4759
4760    addresses
4761       This field is included in the initial request for tickets, and
4762       optionally included in requests for additional tickets from the
4763       ticket-granting server. It specifies the addresses from which the
4764       requested ticket is to be valid. Normally it includes the
4765       addresses for the client's host. If a proxy is requested, this
4766       field will contain other addresses. The contents of this field are
4767       usually copied by the KDC into the caddr field of the resulting
4768       ticket.
4769
4770    additional-tickets
4771       Additional tickets MAY be optionally included in a request to the
4772       ticket-granting server. If the ENC-TKT-IN-SKEY option has been
4773       specified, then the session key from the additional ticket will be
4774       used in place of the server's key to encrypt the new ticket. When
4775       the ENC-TKT-IN-SKEY option is used for user-to-user
4776       authentication, this additional ticket MAY be a TGT issued by the
4777       local realm or an inter-realm TGT issued for the current KDC's
4778       realm by a remote KDC. If more than one option which requires
4779       additional tickets has been specified, then the additional tickets
4780       are used in the order specified by the ordering of the options
4781       bits (see kdc-options, above).
4782
4783    The application tag number will be either ten (10) or twelve (12)
4784    depending on whether the request is for an initial ticket (AS-REQ) or
4785
4786
4787
4788 September 2004                                                 [Page 80]\f
4789
4790
4791
4792
4793
4794 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
4795
4796
4797    for an additional ticket (TGS-REQ).
4798
4799    The optional fields (addresses, authorization-data and additional-
4800    tickets) are only included if necessary to perform the operation
4801    specified in the kdc-options field.
4802
4803    It should be noted that in KRB_TGS_REQ, the protocol version number
4804    appears twice and two different message types appear: the KRB_TGS_REQ
4805    message contains these fields as does the authentication header
4806    (KRB_AP_REQ) that is passed in the padata field.
4807
4808 5.4.2. KRB_KDC_REP definition
4809
4810    The KRB_KDC_REP message format is used for the reply from the KDC for
4811    either an initial (AS) request or a subsequent (TGS) request. There
4812    is no message type for KRB_KDC_REP. Instead, the type will be either
4813    KRB_AS_REP or KRB_TGS_REP. The key used to encrypt the ciphertext
4814    part of the reply depends on the message type. For KRB_AS_REP, the
4815    ciphertext is encrypted in the client's secret key, and the client's
4816    key version number is included in the key version number for the
4817    encrypted data. For KRB_TGS_REP, the ciphertext is encrypted in the
4818    sub-session key from the Authenticator, or if absent, the session key
4819    from the ticket-granting ticket used in the request.  In that case,
4820    no version number will be present in the EncryptedData sequence.
4821
4822    The KRB_KDC_REP message contains the following fields:
4823
4824    AS-REP          ::= [APPLICATION 11] KDC-REP
4825
4826    TGS-REP         ::= [APPLICATION 13] KDC-REP
4827
4828    KDC-REP         ::= SEQUENCE {
4829            pvno            [0] INTEGER (5),
4830            msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
4831            padata          [2] SEQUENCE OF PA-DATA OPTIONAL
4832                                    -- NOTE: not empty --,
4833            crealm          [3] Realm,
4834            cname           [4] PrincipalName,
4835            ticket          [5] Ticket,
4836            enc-part        [6] EncryptedData
4837                                    -- EncASRepPart or EncTGSRepPart,
4838                                    -- as appropriate
4839    }
4840
4841    EncASRepPart    ::= [APPLICATION 25] EncKDCRepPart
4842
4843    EncTGSRepPart   ::= [APPLICATION 26] EncKDCRepPart
4844
4845
4846
4847
4848 September 2004                                                 [Page 81]\f
4849
4850
4851
4852
4853
4854 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
4855
4856
4857    EncKDCRepPart   ::= SEQUENCE {
4858            key             [0] EncryptionKey,
4859            last-req        [1] LastReq,
4860            nonce           [2] UInt32,
4861            key-expiration  [3] KerberosTime OPTIONAL,
4862            flags           [4] TicketFlags,
4863            authtime        [5] KerberosTime,
4864            starttime       [6] KerberosTime OPTIONAL,
4865            endtime         [7] KerberosTime,
4866            renew-till      [8] KerberosTime OPTIONAL,
4867            srealm          [9] Realm,
4868            sname           [10] PrincipalName,
4869            caddr           [11] HostAddresses OPTIONAL
4870    }
4871
4872    LastReq         ::=     SEQUENCE OF SEQUENCE {
4873            lr-type         [0] Int32,
4874            lr-value        [1] KerberosTime
4875    }
4876
4877    pvno and msg-type
4878       These fields are described above in section 5.4.1. msg-type is
4879       either KRB_AS_REP or KRB_TGS_REP.
4880
4881    padata
4882       This field is described in detail in section 5.4.1. One possible
4883       use for this field is to encode an alternate "salt" string to be
4884       used with a string-to-key algorithm. This ability is useful to
4885       ease transitions if a realm name needs to change (e.g. when a
4886       company is acquired); in such a case all existing password-derived
4887       entries in the KDC database would be flagged as needing a special
4888       salt string until the next password change.
4889
4890    crealm, cname, srealm and sname
4891       These fields are the same as those described for the ticket in
4892       section 5.3.
4893
4894    ticket
4895       The newly-issued ticket, from section 5.3.
4896
4897    enc-part
4898       This field is a place holder for the ciphertext and related
4899       information that forms the encrypted part of a message. The
4900       description of the encrypted part of the message follows each
4901       appearance of this field.
4902
4903       The key usage value for encrypting this field is 3 in an AS-REP
4904       message, using the client's long-term key or another key selected
4905
4906
4907
4908 September 2004                                                 [Page 82]\f
4909
4910
4911
4912
4913
4914 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
4915
4916
4917       via pre-authentication mechanisms. In a TGS-REP message, the key
4918       usage value is 8 if the TGS session key is used, or 9 if a TGS
4919       authenticator subkey is used.
4920
4921       Compatibility note: Some implementations unconditionally send an
4922       encrypted EncTGSRepPart (application tag number 26) in this field
4923       regardless of whether the reply is a AS-REP or a TGS-REP. In the
4924       interests of compatibility, implementors MAY relax the check on
4925       the tag number of the decrypted ENC-PART.
4926
4927    key
4928       This field is the same as described for the ticket in section 5.3.
4929
4930    last-req
4931       This field is returned by the KDC and specifies the time(s) of the
4932       last request by a principal. Depending on what information is
4933       available, this might be the last time that a request for a
4934       ticket-granting ticket was made, or the last time that a request
4935       based on a ticket-granting ticket was successful. It also might
4936       cover all servers for a realm, or just the particular server. Some
4937       implementations MAY display this information to the user to aid in
4938       discovering unauthorized use of one's identity. It is similar in
4939       spirit to the last login time displayed when logging into
4940       timesharing systems.
4941
4942       lr-type
4943          This field indicates how the following lr-value field is to be
4944          interpreted. Negative values indicate that the information
4945          pertains only to the responding server. Non-negative values
4946          pertain to all servers for the realm.
4947
4948          If the lr-type field is zero (0), then no information is
4949          conveyed by the lr-value subfield. If the absolute value of the
4950          lr-type field is one (1), then the lr-value subfield is the
4951          time of last initial request for a TGT. If it is two (2), then
4952          the lr-value subfield is the time of last initial request. If
4953          it is three (3), then the lr-value subfield is the time of
4954          issue for the newest ticket-granting ticket used. If it is four
4955          (4), then the lr-value subfield is the time of the last
4956          renewal. If it is five (5), then the lr-value subfield is the
4957          time of last request (of any type).  If it is (6), then the lr-
4958          value subfield is the time when the password will expire.  If
4959          it is (7), then the lr-value subfield is the time when the
4960          account will expire.
4961
4962       lr-value
4963          This field contains the time of the last request. The time MUST
4964          be interpreted according to the contents of the accompanying
4965
4966
4967
4968 September 2004                                                 [Page 83]\f
4969
4970
4971
4972
4973
4974 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
4975
4976
4977          lr-type subfield.
4978
4979    nonce
4980       This field is described above in section 5.4.1.
4981
4982    key-expiration
4983       The key-expiration field is part of the response from the KDC and
4984       specifies the time that the client's secret key is due to expire.
4985       The expiration might be the result of password aging or an account
4986       expiration. If present, it SHOULD be set to the earliest of the
4987       user's key expiration and account expiration.  The use of this
4988       field is deprecated and the last-req field SHOULD be used to
4989       convey this information instead.  This field will usually be left
4990       out of the TGS reply since the response to the TGS request is
4991       encrypted in a session key and no client information need be
4992       retrieved from the KDC database. It is up to the application
4993       client (usually the login program) to take appropriate action
4994       (such as notifying the user) if the expiration time is imminent.
4995
4996    flags, authtime, starttime, endtime, renew-till and caddr
4997       These fields are duplicates of those found in the encrypted
4998       portion of the attached ticket (see section 5.3), provided so the
4999       client MAY verify they match the intended request and to assist in
5000       proper ticket caching. If the message is of type KRB_TGS_REP, the
5001       caddr field will only be filled in if the request was for a proxy
5002       or forwarded ticket, or if the user is substituting a subset of
5003       the addresses from the ticket-granting ticket. If the client-
5004       requested addresses are not present or not used, then the
5005       addresses contained in the ticket will be the same as those
5006       included in the ticket-granting ticket.
5007
5008 5.5. Client/Server (CS) message specifications
5009
5010    This section specifies the format of the messages used for the
5011    authentication of the client to the application server.
5012
5013 5.5.1. KRB_AP_REQ definition
5014
5015    The KRB_AP_REQ message contains the Kerberos protocol version number,
5016    the message type KRB_AP_REQ, an options field to indicate any options
5017    in use, and the ticket and authenticator themselves. The KRB_AP_REQ
5018    message is often referred to as the 'authentication header'.
5019
5020    AP-REQ          ::= [APPLICATION 14] SEQUENCE {
5021            pvno            [0] INTEGER (5),
5022            msg-type        [1] INTEGER (14),
5023            ap-options      [2] APOptions,
5024            ticket          [3] Ticket,
5025
5026
5027
5028 September 2004                                                 [Page 84]\f
5029
5030
5031
5032
5033
5034 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
5035
5036
5037            authenticator   [4] EncryptedData -- Authenticator
5038    }
5039
5040    APOptions       ::= KerberosFlags
5041            -- reserved(0),
5042            -- use-session-key(1),
5043            -- mutual-required(2)
5044
5045    pvno and msg-type
5046       These fields are described above in section 5.4.1. msg-type is
5047       KRB_AP_REQ.
5048
5049    ap-options
5050       This field appears in the application request (KRB_AP_REQ) and
5051       affects the way the request is processed. It is a bit-field, where
5052       the selected options are indicated by the bit being set (1), and
5053       the unselected options and reserved fields being reset (0). The
5054       encoding of the bits is specified in section 5.2. The meanings of
5055       the options are:
5056
5057          Bit(s)  Name            Description
5058
5059          0       reserved        Reserved for future expansion of this field.
5060
5061                                  The USE-SESSION-KEY option indicates that the
5062                                  ticket the client is presenting to a server
5063          1       use-session-key is encrypted in the session key from the
5064                                  server's ticket-granting ticket. When this
5065                                  option is not specified, the ticket is
5066                                  encrypted in the server's secret key.
5067
5068                                  The MUTUAL-REQUIRED option tells the server
5069          2       mutual-required that the client requires mutual
5070                                  authentication, and that it must respond with
5071                                  a KRB_AP_REP message.
5072
5073          3-31    reserved        Reserved for future use.
5074
5075    ticket
5076       This field is a ticket authenticating the client to the server.
5077
5078    authenticator
5079       This contains the encrypted authenticator, which includes the
5080       client's choice of a subkey.
5081
5082    The encrypted authenticator is included in the AP-REQ; it certifies
5083    to a server that the sender has recent knowledge of the encryption
5084    key in the accompanying ticket, to help the server detect replays. It
5085
5086
5087
5088 September 2004                                                 [Page 85]\f
5089
5090
5091
5092
5093
5094 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
5095
5096
5097    also assists in the selection of a "true session key" to use with the
5098    particular session.  The DER encoding of the following is encrypted
5099    in the ticket's session key, with a key usage value of 11 in normal
5100    application exchanges, or 7 when used as the PA-TGS-REQ PA-DATA field
5101    of a TGS-REQ exchange (see section 5.4.1):
5102
5103    -- Unencrypted authenticator
5104    Authenticator   ::= [APPLICATION 2] SEQUENCE  {
5105            authenticator-vno       [0] INTEGER (5),
5106            crealm                  [1] Realm,
5107            cname                   [2] PrincipalName,
5108            cksum                   [3] Checksum OPTIONAL,
5109            cusec                   [4] Microseconds,
5110            ctime                   [5] KerberosTime,
5111            subkey                  [6] EncryptionKey OPTIONAL,
5112            seq-number              [7] UInt32 OPTIONAL,
5113            authorization-data      [8] AuthorizationData OPTIONAL
5114    }
5115
5116    authenticator-vno
5117       This field specifies the version number for the format of the
5118       authenticator. This document specifies version 5.
5119
5120    crealm and cname
5121       These fields are the same as those described for the ticket in
5122       section 5.3.
5123
5124    cksum
5125       This field contains a checksum of the application data that
5126       accompanies the KRB_AP_REQ, computed using a key usage value of 10
5127       in normal application exchanges, or 6 when used in the TGS-REQ PA-
5128       TGS-REQ AP-DATA field.
5129
5130    cusec
5131       This field contains the microsecond part of the client's
5132       timestamp. Its value (before encryption) ranges from 0 to 999999.
5133       It often appears along with ctime. The two fields are used
5134       together to specify a reasonably accurate timestamp.
5135
5136    ctime
5137       This field contains the current time on the client's host.
5138
5139    subkey
5140       This field contains the client's choice for an encryption key
5141       which is to be used to protect this specific application session.
5142       Unless an application specifies otherwise, if this field is left
5143       out the session key from the ticket will be used.
5144
5145
5146
5147
5148 September 2004                                                 [Page 86]\f
5149
5150
5151
5152
5153
5154 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
5155
5156
5157    seq-number
5158       This optional field includes the initial sequence number to be
5159       used by the KRB_PRIV or KRB_SAFE messages when sequence numbers
5160       are used to detect replays (It may also be used by application
5161       specific messages).  When included in the authenticator this field
5162       specifies the initial sequence number for messages from the client
5163       to the server. When included in the AP-REP message, the initial
5164       sequence number is that for messages from the server to the
5165       client. When used in KRB_PRIV or KRB_SAFE messages, it is
5166       incremented by one after each message is sent.  Sequence numbers
5167       fall in the range of 0 through 2^32 - 1 and wrap to zero following
5168       the value 2^32 - 1.
5169
5170       For sequence numbers to adequately support the detection of
5171       replays they SHOULD be non-repeating, even across connection
5172       boundaries. The initial sequence number SHOULD be random and
5173       uniformly distributed across the full space of possible sequence
5174       numbers, so that it cannot be guessed by an attacker and so that
5175       it and the successive sequence numbers do not repeat other
5176       sequences.  In the event that more than 2^32 messages are to be
5177       generated in a series of KRB_PRIV or KRB_SAFE messages, rekeying
5178       SHOULD be performed before sequence numbers are reused with the
5179       same encryption key.
5180
5181       Implmentation note: historically, some implementations transmit
5182       signed twos-complement numbers for sequence numbers. In the
5183       interests of compatibility, implementations MAY accept the
5184       equivalent negative number where a positive number greater than
5185       2^31 - 1 is expected.
5186
5187       Implementation note: as noted before, some implementations omit
5188       the optional sequence number when its value would be zero.
5189       Implementations MAY accept an omitted sequence number when
5190       expecting a value of zero, and SHOULD NOT transmit an
5191       Authenticator with a initial sequence number of zero.
5192
5193    authorization-data
5194       This field is the same as described for the ticket in section 5.3.
5195       It is optional and will only appear when additional restrictions
5196       are to be placed on the use of a ticket, beyond those carried in
5197       the ticket itself.
5198
5199 5.5.2. KRB_AP_REP definition
5200
5201    The KRB_AP_REP message contains the Kerberos protocol version number,
5202    the message type, and an encrypted time-stamp. The message is sent in
5203    response to an application request (KRB_AP_REQ) where the mutual
5204    authentication option has been selected in the ap-options field.
5205
5206
5207
5208 September 2004                                                 [Page 87]\f
5209
5210
5211
5212
5213
5214 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
5215
5216
5217    AP-REP          ::= [APPLICATION 15] SEQUENCE {
5218            pvno            [0] INTEGER (5),
5219            msg-type        [1] INTEGER (15),
5220            enc-part        [2] EncryptedData -- EncAPRepPart
5221    }
5222
5223    EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
5224            ctime           [0] KerberosTime,
5225            cusec           [1] Microseconds,
5226            subkey          [2] EncryptionKey OPTIONAL,
5227            seq-number      [3] UInt32 OPTIONAL
5228    }
5229
5230    The encoded EncAPRepPart is encrypted in the shared session key of
5231    the ticket. The optional subkey field can be used in an application-
5232    arranged negotiation to choose a per association session key.
5233
5234    pvno and msg-type
5235       These fields are described above in section 5.4.1. msg-type is
5236       KRB_AP_REP.
5237
5238    enc-part
5239       This field is described above in section 5.4.2. It is computed
5240       with a key usage value of 12.
5241
5242    ctime
5243       This field contains the current time on the client's host.
5244
5245    cusec
5246       This field contains the microsecond part of the client's
5247       timestamp.
5248
5249    subkey
5250       This field contains an encryption key which is to be used to
5251       protect this specific application session. See section 3.2.6 for
5252       specifics on how this field is used to negotiate a key. Unless an
5253       application specifies otherwise, if this field is left out, the
5254       sub-session key from the authenticator, or if also left out, the
5255       session key from the ticket will be used.
5256
5257    seq-number
5258       This field is described above in section 5.3.2.
5259
5260 5.5.3. Error message reply
5261
5262    If an error occurs while processing the application request, the
5263    KRB_ERROR message will be sent in response. See section 5.9.1 for the
5264    format of the error message. The cname and crealm fields MAY be left
5265
5266
5267
5268 September 2004                                                 [Page 88]\f
5269
5270
5271
5272
5273
5274 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
5275
5276
5277    out if the server cannot determine their appropriate values from the
5278    corresponding KRB_AP_REQ message. If the authenticator was
5279    decipherable, the ctime and cusec fields will contain the values from
5280    it.
5281
5282 5.6. KRB_SAFE message specification
5283
5284    This section specifies the format of a message that can be used by
5285    either side (client or server) of an application to send a tamper-
5286    proof message to its peer. It presumes that a session key has
5287    previously been exchanged (for example, by using the
5288    KRB_AP_REQ/KRB_AP_REP messages).
5289
5290 5.6.1. KRB_SAFE definition
5291
5292    The KRB_SAFE message contains user data along with a collision-proof
5293    checksum keyed with the last encryption key negotiated via subkeys,
5294    or the session key if no negotiation has occurred. The message fields
5295    are:
5296
5297    KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
5298            pvno            [0] INTEGER (5),
5299            msg-type        [1] INTEGER (20),
5300            safe-body       [2] KRB-SAFE-BODY,
5301            cksum           [3] Checksum
5302    }
5303
5304    KRB-SAFE-BODY   ::= SEQUENCE {
5305            user-data       [0] OCTET STRING,
5306            timestamp       [1] KerberosTime OPTIONAL,
5307            usec            [2] Microseconds OPTIONAL,
5308            seq-number      [3] UInt32 OPTIONAL,
5309            s-address       [4] HostAddress,
5310            r-address       [5] HostAddress OPTIONAL
5311    }
5312
5313    pvno and msg-type
5314       These fields are described above in section 5.4.1. msg-type is
5315       KRB_SAFE.
5316
5317    safe-body
5318       This field is a placeholder for the body of the KRB-SAFE message.
5319
5320    cksum
5321       This field contains the checksum of the application data, computed
5322       with a key usage value of 15.
5323
5324       The checksum is computed over the encoding of the KRB-SAFE
5325
5326
5327
5328 September 2004                                                 [Page 89]\f
5329
5330
5331
5332
5333
5334 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
5335
5336
5337       sequence.  First, the cksum is set to a type zero, zero-length
5338       value and the checksum is computed over the encoding of the KRB-
5339       SAFE sequence, then the checksum is set to the result of that
5340       computation, and finally the KRB-SAFE sequence is encoded again.
5341       This method, while different than the one specified in RFC 1510,
5342       corresponds to existing practice.
5343
5344    user-data
5345       This field is part of the KRB_SAFE and KRB_PRIV messages and
5346       contain the application specific data that is being passed from
5347       the sender to the recipient.
5348
5349    timestamp
5350       This field is part of the KRB_SAFE and KRB_PRIV messages. Its
5351       contents are the current time as known by the sender of the
5352       message. By checking the timestamp, the recipient of the message
5353       is able to make sure that it was recently generated, and is not a
5354       replay.
5355
5356    usec
5357       This field is part of the KRB_SAFE and KRB_PRIV headers. It
5358       contains the microsecond part of the timestamp.
5359
5360    seq-number
5361       This field is described above in section 5.3.2.
5362
5363    s-address
5364       Sender's address.
5365
5366       This field specifies the address in use by the sender of the
5367       message.
5368
5369    r-address
5370       This field specifies the address in use by the recipient of the
5371       message. It MAY be omitted for some uses (such as broadcast
5372       protocols), but the recipient MAY arbitrarily reject such
5373       messages. This field, along with s-address, can be used to help
5374       detect messages which have been incorrectly or maliciously
5375       delivered to the wrong recipient.
5376
5377 5.7. KRB_PRIV message specification
5378
5379    This section specifies the format of a message that can be used by
5380    either side (client or server) of an application to securely and
5381    privately send a message to its peer. It presumes that a session key
5382    has previously been exchanged (for example, by using the
5383    KRB_AP_REQ/KRB_AP_REP messages).
5384
5385
5386
5387
5388 September 2004                                                 [Page 90]\f
5389
5390
5391
5392
5393
5394 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
5395
5396
5397 5.7.1. KRB_PRIV definition
5398
5399    The KRB_PRIV message contains user data encrypted in the Session Key.
5400    The message fields are:
5401
5402    KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
5403            pvno            [0] INTEGER (5),
5404            msg-type        [1] INTEGER (21),
5405                            -- NOTE: there is no [2] tag
5406            enc-part        [3] EncryptedData -- EncKrbPrivPart
5407    }
5408
5409    EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
5410            user-data       [0] OCTET STRING,
5411            timestamp       [1] KerberosTime OPTIONAL,
5412            usec            [2] Microseconds OPTIONAL,
5413            seq-number      [3] UInt32 OPTIONAL,
5414            s-address       [4] HostAddress -- sender's addr --,
5415            r-address       [5] HostAddress OPTIONAL -- recip's addr
5416    }
5417
5418    pvno and msg-type
5419       These fields are described above in section 5.4.1. msg-type is
5420       KRB_PRIV.
5421
5422    enc-part
5423       This field holds an encoding of the EncKrbPrivPart sequence
5424       encrypted under the session key, with a key usage value of 13.
5425       This encrypted encoding is used for the enc-part field of the KRB-
5426       PRIV message.
5427
5428    user-data, timestamp, usec, s-address and r-address
5429       These fields are described above in section 5.6.1.
5430
5431    seq-number
5432       This field is described above in section 5.3.2.
5433
5434 5.8. KRB_CRED message specification
5435
5436    This section specifies the format of a message that can be used to
5437    send Kerberos credentials from one principal to another. It is
5438    presented here to encourage a common mechanism to be used by
5439    applications when forwarding tickets or providing proxies to
5440    subordinate servers. It presumes that a session key has already been
5441    exchanged perhaps by using the KRB_AP_REQ/KRB_AP_REP messages.
5442
5443 5.8.1. KRB_CRED definition
5444
5445
5446
5447
5448 September 2004                                                 [Page 91]\f
5449
5450
5451
5452
5453
5454 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
5455
5456
5457    The KRB_CRED message contains a sequence of tickets to be sent and
5458    information needed to use the tickets, including the session key from
5459    each.  The information needed to use the tickets is encrypted under
5460    an encryption key previously exchanged or transferred alongside the
5461    KRB_CRED message. The message fields are:
5462
5463    KRB-CRED        ::= [APPLICATION 22] SEQUENCE {
5464            pvno            [0] INTEGER (5),
5465            msg-type        [1] INTEGER (22),
5466            tickets         [2] SEQUENCE OF Ticket,
5467            enc-part        [3] EncryptedData -- EncKrbCredPart
5468    }
5469
5470    EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
5471            ticket-info     [0] SEQUENCE OF KrbCredInfo,
5472            nonce           [1] UInt32 OPTIONAL,
5473            timestamp       [2] KerberosTime OPTIONAL,
5474            usec            [3] Microseconds OPTIONAL,
5475            s-address       [4] HostAddress OPTIONAL,
5476            r-address       [5] HostAddress OPTIONAL
5477    }
5478
5479    KrbCredInfo     ::= SEQUENCE {
5480            key             [0] EncryptionKey,
5481            prealm          [1] Realm OPTIONAL,
5482            pname           [2] PrincipalName OPTIONAL,
5483            flags           [3] TicketFlags OPTIONAL,
5484            authtime        [4] KerberosTime OPTIONAL,
5485            starttime       [5] KerberosTime OPTIONAL,
5486            endtime         [6] KerberosTime OPTIONAL,
5487            renew-till      [7] KerberosTime OPTIONAL,
5488            srealm          [8] Realm OPTIONAL,
5489            sname           [9] PrincipalName OPTIONAL,
5490            caddr           [10] HostAddresses OPTIONAL
5491    }
5492
5493    pvno and msg-type
5494       These fields are described above in section 5.4.1. msg-type is
5495       KRB_CRED.
5496
5497    tickets
5498       These are the tickets obtained from the KDC specifically for use
5499       by the intended recipient. Successive tickets are paired with the
5500       corresponding KrbCredInfo sequence from the enc-part of the KRB-
5501       CRED message.
5502
5503    enc-part
5504       This field holds an encoding of the EncKrbCredPart sequence
5505
5506
5507
5508 September 2004                                                 [Page 92]\f
5509
5510
5511
5512
5513
5514 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
5515
5516
5517       encrypted under the session key shared between the sender and the
5518       intended recipient, with a key usage value of 14. This encrypted
5519       encoding is used for the enc-part field of the KRB-CRED message.
5520
5521       Implementation note: implementations of certain applications, most
5522       notably certain implementations of the Kerberos GSS-API mechanism,
5523       do not separately encrypt the contents of the EncKrbCredPart of
5524       the KRB-CRED message when sending it.  In the case of those GSS-
5525       API mechanisms, this is not a security vulnerability, as the
5526       entire KRB-CRED message is itself embedded in an encrypted
5527       message.
5528
5529    nonce
5530       If practical, an application MAY require the inclusion of a nonce
5531       generated by the recipient of the message. If the same value is
5532       included as the nonce in the message, it provides evidence that
5533       the message is fresh and has not been replayed by an attacker. A
5534       nonce MUST NEVER be reused.
5535
5536    timestamp and usec
5537       These fields specify the time that the KRB-CRED message was
5538       generated.  The time is used to provide assurance that the message
5539       is fresh.
5540
5541    s-address and r-address
5542       These fields are described above in section 5.6.1. They are used
5543       optionally to provide additional assurance of the integrity of the
5544       KRB-CRED message.
5545
5546    key
5547       This field exists in the corresponding ticket passed by the KRB-
5548       CRED message and is used to pass the session key from the sender
5549       to the intended recipient. The field's encoding is described in
5550       section 5.2.9.
5551
5552    The following fields are optional. If present, they can be associated
5553    with the credentials in the remote ticket file. If left out, then it
5554    is assumed that the recipient of the credentials already knows their
5555    value.
5556
5557    prealm and pname
5558       The name and realm of the delegated principal identity.
5559
5560    flags, authtime, starttime, endtime, renew-till, srealm, sname, and
5561       caddr
5562       These fields contain the values of the corresponding fields from
5563       the ticket found in the ticket field. Descriptions of the fields
5564       are identical to the descriptions in the KDC-REP message.
5565
5566
5567
5568 September 2004                                                 [Page 93]\f
5569
5570
5571
5572
5573
5574 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
5575
5576
5577 5.9. Error message specification
5578
5579    This section specifies the format for the KRB_ERROR message. The
5580    fields included in the message are intended to return as much
5581    information as possible about an error. It is not expected that all
5582    the information required by the fields will be available for all
5583    types of errors. If the appropriate information is not available when
5584    the message is composed, the corresponding field will be left out of
5585    the message.
5586
5587    Note that since the KRB_ERROR message is not integrity protected, it
5588    is quite possible for an intruder to synthesize or modify such a
5589    message. In particular, this means that the client SHOULD NOT use any
5590    fields in this message for security-critical purposes, such as
5591    setting a system clock or generating a fresh authenticator. The
5592    message can be useful, however, for advising a user on the reason for
5593    some failure.
5594
5595 5.9.1. KRB_ERROR definition
5596
5597    The KRB_ERROR message consists of the following fields:
5598
5599    KRB-ERROR       ::= [APPLICATION 30] SEQUENCE {
5600            pvno            [0] INTEGER (5),
5601            msg-type        [1] INTEGER (30),
5602            ctime           [2] KerberosTime OPTIONAL,
5603            cusec           [3] Microseconds OPTIONAL,
5604            stime           [4] KerberosTime,
5605            susec           [5] Microseconds,
5606            error-code      [6] Int32,
5607            crealm          [7] Realm OPTIONAL,
5608            cname           [8] PrincipalName OPTIONAL,
5609            realm           [9] Realm -- service realm --,
5610            sname           [10] PrincipalName -- service name --,
5611            e-text          [11] KerberosString OPTIONAL,
5612            e-data          [12] OCTET STRING OPTIONAL
5613    }
5614
5615    pvno and msg-type
5616       These fields are described above in section 5.4.1. msg-type is
5617       KRB_ERROR.
5618
5619    ctime, cusec
5620       These fields are described above in section 5.5.2.  If the values
5621       for these fields are known to the entity generating the error
5622       (such as it would if the KRB-ERROR is generated in reply to, e.g.,
5623       a failed authentication service request), they should be populated
5624       in the KRB-ERROR.  If the values are not available, these fields
5625
5626
5627
5628 September 2004                                                 [Page 94]\f
5629
5630
5631
5632
5633
5634 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
5635
5636
5637       can be omitted.
5638
5639    stime
5640       This field contains the current time on the server. It is of type
5641       KerberosTime.
5642
5643    susec
5644       This field contains the microsecond part of the server's
5645       timestamp. Its value ranges from 0 to 999999. It appears along
5646       with stime. The two fields are used in conjunction to specify a
5647       reasonably accurate timestamp.
5648
5649    error-code
5650       This field contains the error code returned by Kerberos or the
5651       server when a request fails. To interpret the value of this field
5652       see the list of error codes in section 7.5.9. Implementations are
5653       encouraged to provide for national language support in the display
5654       of error messages.
5655
5656    crealm, and cname
5657       These fields are described above in section 5.3.  When the entity
5658       generating the error knows these values, they should be populated
5659       in the KRB-ERROR.  If the values are not known, the crealm and
5660       cname fields SHOULD be omitted.
5661
5662    realm and sname
5663       These fields are described above in section 5.3.
5664
5665    e-text
5666       This field contains additional text to help explain the error code
5667       associated with the failed request (for example, it might include
5668       a principal name which was unknown).
5669
5670    e-data
5671       This field contains additional data about the error for use by the
5672       application to help it recover from or handle the error. If the
5673       errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will
5674       contain an encoding of a sequence of padata fields, each
5675       corresponding to an acceptable pre-authentication method and
5676       optionally containing data for the method:
5677
5678       METHOD-DATA     ::= SEQUENCE OF PA-DATA
5679
5680    For error codes defined in this document other than
5681    KDC_ERR_PREAUTH_REQUIRED, the format and contents of the e-data field
5682    are implementation-defined. Similarly, for future error codes, the
5683    format and contents of the e-data field are implementation-defined
5684    unless specified. Whether defined by the implementation or in a
5685
5686
5687
5688 September 2004                                                 [Page 95]\f
5689
5690
5691
5692
5693
5694 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
5695
5696
5697    future document, the e-data field MAY take the form of TYPED-DATA:
5698
5699    TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
5700            data-type       [0] INTEGER,
5701            data-value      [1] OCTET STRING OPTIONAL
5702    }
5703
5704 5.10. Application Tag Numbers
5705
5706    The following table lists the application class tag numbers used by
5707    various data types defined in this section.
5708
5709     Tag Number(s)    Type Name    Comments
5710
5711     0                             unused
5712
5713     1              Ticket         PDU
5714
5715     2              Authenticator  non-PDU
5716
5717     3              EncTicketPart  non-PDU
5718
5719     4-9                           unused
5720
5721     10             AS-REQ         PDU
5722
5723     11             AS-REP         PDU
5724
5725     12             TGS-REQ        PDU
5726
5727     13             TGS-REP        PDU
5728
5729     14             AP-REQ         PDU
5730
5731     15             AP-REP         PDU
5732
5733     16             RESERVED16     TGT-REQ (for user-to-user)
5734
5735     17             RESERVED17     TGT-REP (for user-to-user)
5736
5737     18-19                         unused
5738
5739     20             KRB-SAFE       PDU
5740
5741     21             KRB-PRIV       PDU
5742
5743     22             KRB-CRED       PDU
5744
5745
5746
5747
5748 September 2004                                                 [Page 96]\f
5749
5750
5751
5752
5753
5754 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
5755
5756
5757     23-24                         unused
5758
5759     25             EncASRepPart   non-PDU
5760
5761     26             EncTGSRepPart  non-PDU
5762
5763     27             EncApRepPart   non-PDU
5764
5765     28             EncKrbPrivPart non-PDU
5766
5767     29             EncKrbCredPart non-PDU
5768
5769     30             KRB-ERROR      PDU
5770
5771    The ASN.1 types marked as "PDU" (Protocol Data Unit) in the above are
5772    the only ASN.1 types intended as top-level types of the Kerberos
5773    protocol, and are the only types that may be used as elements in
5774    another protocol that makes use of Kerberos.
5775
5776 6. Naming Constraints
5777
5778 6.1. Realm Names
5779
5780    Although realm names are encoded as GeneralStrings and although a
5781    realm can technically select any name it chooses, interoperability
5782    across realm boundaries requires agreement on how realm names are to
5783    be assigned, and what information they imply.
5784
5785    To enforce these conventions, each realm MUST conform to the
5786    conventions itself, and it MUST require that any realms with which
5787    inter-realm keys are shared also conform to the conventions and
5788    require the same from its neighbors.
5789
5790    Kerberos realm names are case sensitive. Realm names that differ only
5791    in the case of the characters are not equivalent. There are presently
5792    three styles of realm names: domain, X500, and other. Examples of
5793    each style follow:
5794
5795         domain:   ATHENA.MIT.EDU
5796           X500:   C=US/O=OSF
5797          other:   NAMETYPE:rest/of.name=without-restrictions
5798
5799    Domain style realm names MUST look like domain names: they consist of
5800    components separated by periods (.) and they contain neither colons
5801    (:) nor slashes (/). Though domain names themselves are case
5802    insensitive, in order for realms to match, the case must match as
5803    well. When establishing a new realm name based on an internet domain
5804    name it is recommended by convention that the characters be converted
5805
5806
5807
5808 September 2004                                                 [Page 97]\f
5809
5810
5811
5812
5813
5814 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
5815
5816
5817    to upper case.
5818
5819    X.500 names contain an equal (=) and cannot contain a colon (:)
5820    before the equal. The realm names for X.500 names will be string
5821    representations of the names with components separated by slashes.
5822    Leading and trailing slashes will not be included. Note that the
5823    slash separator is consistent with Kerberos implementations based on
5824    RFC1510, but it is different from the separator recommended in
5825    RFC2253.
5826
5827    Names that fall into the other category MUST begin with a prefix that
5828    contains no equal (=) or period (.) and the prefix MUST be followed
5829    by a colon (:) and the rest of the name. All prefixes expect those
5830    beginning with used. Presently none are assigned.
5831
5832    The reserved category includes strings which do not fall into the
5833    first three categories. All names in this category are reserved. It
5834    is unlikely that names will be assigned to this category unless there
5835    is a very strong argument for not using the 'other' category.
5836
5837    These rules guarantee that there will be no conflicts between the
5838    various name styles. The following additional constraints apply to
5839    the assignment of realm names in the domain and X.500 categories: the
5840    name of a realm for the domain or X.500 formats must either be used
5841    by the organization owning (to whom it was assigned) an Internet
5842    domain name or X.500 name, or in the case that no such names are
5843    registered, authority to use a realm name MAY be derived from the
5844    authority of the parent realm. For example, if there is no domain
5845    name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can
5846    authorize the creation of a realm with that name.
5847
5848    This is acceptable because the organization to which the parent is
5849    assigned is presumably the organization authorized to assign names to
5850    its children in the X.500 and domain name systems as well. If the
5851    parent assigns a realm name without also registering it in the domain
5852    name or X.500 hierarchy, it is the parent's responsibility to make
5853    sure that there will not in the future exist a name identical to the
5854    realm name of the child unless it is assigned to the same entity as
5855    the realm name.
5856
5857 6.2. Principal Names
5858
5859    As was the case for realm names, conventions are needed to ensure
5860    that all agree on what information is implied by a principal name.
5861    The name-type field that is part of the principal name indicates the
5862    kind of information implied by the name. The name-type SHOULD be
5863    treated only as a hint to interpreting the meaning of a name. It is
5864    not significant when checking for equivalence. Principal names that
5865
5866
5867
5868 September 2004                                                 [Page 98]\f
5869
5870
5871
5872
5873
5874 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
5875
5876
5877    differ only in the name-type identify the same principal. The name
5878    type does not partition the name space. Ignoring the name type, no
5879    two names can be the same (i.e. at least one of the components, or
5880    the realm, MUST be different). The following name types are defined:
5881
5882    name-type      value   meaning
5883
5884    name types
5885
5886    NT-UNKNOWN        0  Name type not known
5887    NT-PRINCIPAL      1  Just the name of the principal as in DCE, or for users
5888    NT-SRV-INST       2  Service and other unique instance (krbtgt)
5889    NT-SRV-HST        3  Service with host name as instance (telnet, rcommands)
5890    NT-SRV-XHST       4  Service with host as remaining components
5891    NT-UID            5  Unique ID
5892    NT-X500-PRINCIPAL 6  Encoded X.509 Distingished name [RFC 2253]
5893    NT-SMTP-NAME      7  Name in form of SMTP email name (e.g. user@foo.com)
5894    NT-ENTERPRISE    10   Enterprise name - may be mapped to principal name
5895
5896    When a name implies no information other than its uniqueness at a
5897    particular time the name type PRINCIPAL SHOULD be used. The principal
5898    name type SHOULD be used for users, and it might also be used for a
5899    unique server. If the name is a unique machine generated ID that is
5900    guaranteed never to be reassigned then the name type of UID SHOULD be
5901    used (note that it is generally a bad idea to reassign names of any
5902    type since stale entries might remain in access control lists).
5903
5904    If the first component of a name identifies a service and the
5905    remaining components identify an instance of the service in a server
5906    specified manner, then the name type of SRV-INST SHOULD be used. An
5907    example of this name type is the Kerberos ticket-granting service
5908    whose name has a first component of krbtgt and a second component
5909    identifying the realm for which the ticket is valid.
5910
5911    If the first component of a name identifies a service and there is a
5912    single component following the service name identifying the instance
5913    as the host on which the server is running, then the name type SRV-
5914    HST SHOULD be used. This type is typically used for Internet services
5915    such as telnet and the Berkeley R commands. If the separate
5916    components of the host name appear as successive components following
5917    the name of the service, then the name type SRV-XHST SHOULD be used.
5918    This type might be used to identify servers on hosts with X.500 names
5919    where the slash (/) might otherwise be ambiguous.
5920
5921    A name type of NT-X500-PRINCIPAL SHOULD be used when a name from an
5922    X.509 certificate is translated into a Kerberos name. The encoding of
5923    the X.509 name as a Kerberos principal shall conform to the encoding
5924    rules specified in RFC 2253.
5925
5926
5927
5928 September 2004                                                 [Page 99]\f
5929
5930
5931
5932
5933
5934 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
5935
5936
5937    A name type of SMTP allows a name to be of a form that resembles a
5938    SMTP email name. This name, including an "@" and a domain name, is
5939    used as the one component of the principal name.
5940
5941    A name type of UNKNOWN SHOULD be used when the form of the name is
5942    not known. When comparing names, a name of type UNKNOWN will match
5943    principals authenticated with names of any type. A principal
5944    authenticated with a name of type UNKNOWN, however, will only match
5945    other names of type UNKNOWN.
5946
5947    Names of any type with an initial component of 'krbtgt' are reserved
5948    for the Kerberos ticket granting service. See section 7.3 for the
5949    form of such names.
5950
5951 6.2.1. Name of server principals
5952
5953    The principal identifier for a server on a host will generally be
5954    composed of two parts: (1) the realm of the KDC with which the server
5955    is registered, and (2) a two-component name of type NT-SRV-HST if the
5956    host name is an Internet domain name or a multi-component name of
5957    type NT-SRV-XHST if the name of the host is of a form such as X.500
5958    that allows slash (/) separators. The first component of the two- or
5959    multi-component name will identify the service and the latter
5960    components will identify the host. Where the name of the host is not
5961    case sensitive (for example, with Internet domain names) the name of
5962    the host MUST be lower case. If specified by the application protocol
5963    for services such as telnet and the Berkeley R commands which run
5964    with system privileges, the first component MAY be the string 'host'
5965    instead of a service specific identifier.
5966
5967 7. Constants and other defined values
5968
5969 7.1. Host address types
5970
5971    All negative values for the host address type are reserved for local
5972    use.  All non-negative values are reserved for officially assigned
5973    type fields and interpretations.
5974
5975    Internet (IPv4) Addresses
5976
5977       Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded
5978       in MSB order (most significant byte first). The IPv4 loopback
5979       address SHOULD NOT appear in a Kerberos PDU. The type of IPv4
5980       addresses is two (2).
5981
5982    Internet (IPv6) Addresses
5983
5984       IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities,
5985
5986
5987
5988 September 2004                                                [Page 100]\f
5989
5990
5991
5992
5993
5994 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
5995
5996
5997       encoded in MSB order (most significant byte first). The type of
5998       IPv6 addresses is twenty-four (24). The following addresses MUST
5999       NOT appear in any Kerberos PDU:
6000
6001          *  the Unspecified Address
6002          *  the Loopback Address
6003          *  Link-Local addresses
6004
6005       This restriction applies to the inclusion in the address fields of
6006       Kerberos PDU's, but not to the address fields of packets that
6007       might carry such PDU's.  The restriction is necessary because the
6008       use of an address with non-global scope could allow the acceptance
6009       of a message sent from a node that may have the same address, but
6010       which is not the host intended by the entity that added the
6011       restriction.  If the link-local address type needs to be used for
6012       communication, then the address restriction in tickets must not be
6013       used (i.e. addressless tickets must be used).
6014
6015       IPv4-mapped IPv6 addresses MUST be represented as addresses of
6016       type 2.
6017
6018    DECnet Phase IV addresses
6019
6020       DECnet Phase IV addresses are 16-bit addresses, encoded in LSB
6021       order. The type of DECnet Phase IV addresses is twelve (12).
6022
6023    Netbios addresses
6024
6025       Netbios addresses are 16-octet addresses typically composed of 1
6026       to 15 alphanumeric characters and padded with the US-ASCII SPC
6027       character (code 32).  The 16th octet MUST be the US-ASCII NUL
6028       character (code 0).  The type of Netbios addresses is twenty (20).
6029
6030    Directional Addresses
6031
6032       In many environments, including the sender address in KRB_SAFE and
6033       KRB_PRIV messages is undesirable because the addresses may be
6034       changed in transport by network address translators. However, if
6035       these addresses are removed, the messages may be subject to a
6036       reflection attack in which a message is reflected back to its
6037       originator. The directional address type provides a way to avoid
6038       transport addresses and reflection attacks. Directional addresses
6039       are encoded as four byte unsigned integers in network byte order.
6040       If the message is originated by the party sending the original
6041       KRB_AP_REQ message, then an address of 0 SHOULD be used. If the
6042       message is originated by the party to whom that KRB_AP_REQ was
6043       sent, then the address 1 SHOULD be used. Applications involving
6044       multiple parties can specify the use of other addresses.
6045
6046
6047
6048 September 2004                                                [Page 101]\f
6049
6050
6051
6052
6053
6054 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
6055
6056
6057       Directional addresses MUST only be used for the sender address
6058       field in the KRB_SAFE or KRB_PRIV messages. They MUST NOT be used
6059       as a ticket address or in a KRB_AP_REQ message. This address type
6060       SHOULD only be used in situations where the sending party knows
6061       that the receiving party supports the address type. This generally
6062       means that directional addresses may only be used when the
6063       application protocol requires their support. Directional addresses
6064       are type (3).
6065
6066 7.2. KDC messaging - IP Transports
6067
6068    Kerberos defines two IP transport mechanisms for communication
6069    between clients and servers: UDP/IP and TCP/IP.
6070
6071 7.2.1. UDP/IP transport
6072
6073    Kerberos servers (KDCs) supporting IP transports MUST accept UDP
6074    requests and SHOULD listen for such requests on port 88 (decimal)
6075    unless specifically configured to listen on an alternative UDP port.
6076    Alternate ports MAY be used when running multiple KDCs for multiple
6077    realms on the same host.
6078
6079    Kerberos clients supporting IP transports SHOULD support the sending
6080    of UDP requests. Clients SHOULD use KDC discovery [7.2.3] to identify
6081    the IP address and port to which they will send their request.
6082
6083    When contacting a KDC for a KRB_KDC_REQ request using UDP/IP
6084    transport, the client shall send a UDP datagram containing only an
6085    encoding of the request to the KDC. The KDC will respond with a reply
6086    datagram containing only an encoding of the reply message (either a
6087    KRB_ERROR or a KRB_KDC_REP) to the sending port at the sender's IP
6088    address. The response to a request made through UDP/IP transport MUST
6089    also use UDP/IP transport. If the response can not be handled using
6090    UDP (for example because it is too large), the KDC MUST return
6091    KRB_ERR_RESPONSE_TOO_BIG, forcing the client to retry the request
6092    using the TCP transport.
6093
6094 7.2.2. TCP/IP transport
6095
6096    Kerberos servers (KDCs) supporting IP transports MUST accept TCP
6097    requests and SHOULD listen for such requests on port 88 (decimal)
6098    unless specifically configured to listen on an alternate TCP port.
6099    Alternate ports MAY be used when running multiple KDCs for multiple
6100    realms on the same host.
6101
6102    Clients MUST support the sending of TCP requests, but MAY choose to
6103    initially try a request using the UDP transport. Clients SHOULD use
6104    KDC discovery [7.2.3] to identify the IP address and port to which
6105
6106
6107
6108 September 2004                                                [Page 102]\f
6109
6110
6111
6112
6113
6114 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
6115
6116
6117    they will send their request.
6118
6119    Implementation note: Some extensions to the Kerberos protocol will
6120    not succeed if any client or KDC not supporting the TCP transport is
6121    involved.  Implementations of RFC 1510 were not required to support
6122    TCP/IP transports.
6123
6124    When the KRB_KDC_REQ message is sent to the KDC over a TCP stream,
6125    the response (KRB_KDC_REP or KRB_ERROR message) MUST be returned to
6126    the client on the same TCP stream that was established for the
6127    request. The KDC MAY close the TCP stream after sending a response,
6128    but MAY leave the stream open for a reasonable period of time if it
6129    expects a followup. Care must be taken in managing TCP/IP connections
6130    on the KDC to prevent denial of service attacks based on the number
6131    of open TCP/IP connections.
6132
6133    The client MUST be prepared to have the stream closed by the KDC at
6134    anytime after the receipt of a response. A stream closure SHOULD NOT
6135    be treated as a fatal error. Instead, if multiple exchanges are
6136    required (e.g., certain forms of pre-authentication) the client may
6137    need to establish a new connection when it is ready to send
6138    subsequent messages. A client MAY close the stream after receiving a
6139    response, and SHOULD close the stream if it does not expect to send
6140    followup messages.
6141
6142    A client MAY send multiple requests before receiving responses,
6143    though it must be prepared to handle the connection being closed
6144    after the first response.
6145
6146    Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR)
6147    sent over the TCP stream is preceded by the length of the request as
6148    4 octets in network byte order. The high bit of the length is
6149    reserved for future expansion and MUST currently be set to zero.  If
6150    a KDC that does not understand how to interpret a set high bit of the
6151    length encoding receives a request with the high order bit of the
6152    length set, it MUST return a KRB-ERROR message with the error
6153    KRB_ERR_FIELD_TOOLONG and MUST close the TCP stream.
6154
6155    If multiple requests are sent over a single TCP connection, and the
6156    KDC sends multiple responses, the KDC is not required to send the
6157    responses in the order of the corresponding requests. This may permit
6158    some implementations to send each response as soon as it is ready
6159    even if earlier requests are still being processed (for example,
6160    waiting for a response from an external device or database).
6161
6162 7.2.3. KDC Discovery on IP Networks
6163
6164    Kerberos client implementations MUST provide a means for the client
6165
6166
6167
6168 September 2004                                                [Page 103]\f
6169
6170
6171
6172
6173
6174 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
6175
6176
6177    to determine the location of the Kerberos Key Distribution Centers
6178    (KDCs).  Traditionally, Kerberos implementations have stored such
6179    configuration information in a file on each client machine.
6180    Experience has shown this method of storing configuration information
6181    presents problems with out-of-date information and scaling problems,
6182    especially when using cross-realm authentication. This section
6183    describes a method for using the Domain Name System [RFC 1035] for
6184    storing KDC location information.
6185
6186 7.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names
6187
6188    In Kerberos, realm names are case sensitive. While it is strongly
6189    encouraged that all realm names be all upper case this recommendation
6190    has not been adopted by all sites. Some sites use all lower case
6191    names and other use mixed case. DNS on the other hand is case
6192    insensitive for queries. Since the realm names "MYREALM", "myrealm",
6193    and "MyRealm" are all different, but resolve the same in the domain
6194    name system, it is necessary that only one of the possible
6195    combinations of upper and lower case characters be used in realm
6196    names.
6197
6198 7.2.3.2. Specifying KDC Location information with DNS SRV records
6199
6200    KDC location information is to be stored using the DNS SRV RR [RFC
6201    2782].  The format of this RR is as follows:
6202
6203       _Service._Proto.Realm TTL Class SRV Priority Weight Port Target
6204
6205    The Service name for Kerberos is always "kerberos".
6206
6207    The Proto can be one of "udp", "tcp". If these SRV records are to be
6208    used, both "udp" and "tcp" records MUST be specified for all KDC
6209    deployments.
6210
6211    The Realm is the Kerberos realm that this record corresponds to.  The
6212    realm MUST be a domain style realm name.
6213
6214    TTL, Class, SRV, Priority, Weight, and Target have the standard
6215    meaning as defined in RFC 2782.
6216
6217    As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV
6218    records SHOULD be the value assigned to "kerberos" by the Internet
6219    Assigned Number Authority: 88 (decimal) unless the KDC is configured
6220    to listen on an alternate TCP port.
6221
6222    Implementation note: Many existing client implementations do not
6223    support KDC Discovery and are configured to send requests to the IANA
6224    assigned port (88 decimal), so it is strongly recommended that KDCs
6225
6226
6227
6228 September 2004                                                [Page 104]\f
6229
6230
6231
6232
6233
6234 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
6235
6236
6237    be configured to listen on that port.
6238
6239 7.2.3.3. KDC Discovery for Domain Style Realm Names on IP Networks
6240
6241    These are DNS records for a Kerberos realm EXAMPLE.COM. It has two
6242    Kerberos servers, kdc1.example.com and kdc2.example.com. Queries
6243    should be directed to kdc1.example.com first as per the specified
6244    priority. Weights are not used in these sample records.
6245
6246      _kerberos._udp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
6247      _kerberos._udp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.
6248      _kerberos._tcp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
6249      _kerberos._tcp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.
6250
6251 7.3. Name of the TGS
6252
6253    The principal identifier of the ticket-granting service shall be
6254    composed of three parts: (1) the realm of the KDC issuing the TGS
6255    ticket (2) a two-part name of type NT-SRV-INST, with the first part
6256    "krbtgt" and the second part the name of the realm which will accept
6257    the ticket-granting ticket. For example, a ticket-granting ticket
6258    issued by the ATHENA.MIT.EDU realm to be used to get tickets from the
6259    ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU"
6260    (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting
6261    ticket issued by the ATHENA.MIT.EDU realm to be used to get tickets
6262    from the MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU"
6263    (realm), ("krbtgt", "MIT.EDU") (name).
6264
6265 7.4. OID arc for KerberosV5
6266
6267    This OID MAY be used to identify Kerberos protocol messages
6268    encapsulated in other protocols. It also designates the OID arc for
6269    KerberosV5-related OIDs assigned by future IETF action.
6270    Implementation note:: RFC 1510 had an incorrect value (5) for "dod"
6271    in its OID.
6272
6273    id-krb5         OBJECT IDENTIFIER ::= {
6274            iso(1) identified-organization(3) dod(6) internet(1)
6275            security(5) kerberosV5(2)
6276    }
6277
6278
6279    Assignment of OIDs beneath the id-krb5 arc must be obtained by
6280    contacting the registrar for the id-krb5 arc, or its designee.  At
6281    the time of the issuance of this RFC, such registrations can be
6282    obtained by contacting krb5-oid-registrar@mit.edu.
6283
6284 7.5. Protocol constants and associated values
6285
6286
6287
6288 September 2004                                                [Page 105]\f
6289
6290
6291
6292
6293
6294 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
6295
6296
6297    The following tables list constants used in the protocol and define
6298    their meanings. Ranges are specified in the "specification" section
6299    that limit the values of constants for which values are defined here.
6300    This allows implementations to make assumptions about the maximum
6301    values that will be received for these constants. Implementation
6302    receiving values outside the range specified in the "specification"
6303    section MAY reject the request, but they MUST recover cleanly.
6304
6305 7.5.1. Key usage numbers
6306
6307    The encryption and checksum specifications in [@KCRYPTO] require as
6308    input a "key usage number", to alter the encryption key used in any
6309    specific message, to make certain types of cryptographic attack more
6310    difficult. These are the key usage values assigned in this document:
6311
6312            1.          AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted
6313                        with the client key (section 5.2.7.2)
6314            2.          AS-REP Ticket and TGS-REP Ticket (includes TGS session
6315                        key or application session key), encrypted with the
6316                        service key (section 5.3)
6317            3.          AS-REP encrypted part (includes TGS session key or
6318                        application session key), encrypted with the client key
6319                        (section 5.4.2)
6320            4.          TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with
6321                        the TGS session key (section 5.4.1)
6322            5.          TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with
6323                        the TGS authenticator subkey (section 5.4.1)
6324            6.          TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum,
6325                        keyed with the TGS session key (sections 5.5.1)
6326            7.          TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator
6327                        (includes TGS authenticator subkey), encrypted with the
6328                        TGS session key (section 5.5.1)
6329            8.          TGS-REP encrypted part (includes application session
6330                        key), encrypted with the TGS session key (section
6331                        5.4.2)
6332            9.          TGS-REP encrypted part (includes application session
6333                        key), encrypted with the TGS authenticator subkey
6334                        (section 5.4.2)
6335            10.         AP-REQ Authenticator cksum, keyed with the application
6336                        session key (section 5.5.1)
6337            11.         AP-REQ Authenticator (includes application
6338                        authenticator subkey), encrypted with the application
6339                        session key (section 5.5.1)
6340            12.         AP-REP encrypted part (includes application session
6341                        subkey), encrypted with the application session key
6342                        (section 5.5.2)
6343            13.         KRB-PRIV encrypted part, encrypted with a key chosen by
6344                        the application (section 5.7.1)
6345
6346
6347
6348 September 2004                                                [Page 106]\f
6349
6350
6351
6352
6353
6354 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
6355
6356
6357            14.         KRB-CRED encrypted part, encrypted with a key chosen by
6358                        the application (section 5.8.1)
6359            15.         KRB-SAFE cksum, keyed with a key chosen by the
6360                        application (section 5.6.1)
6361         16-18.         Reserved for future use in Kerberos and related
6362                        protocols.
6363            19.         AD-KDC-ISSUED checksum (ad-checksum in 5.2.6.4)
6364         20-21.         Reserved for future use in Kerberos and related
6365                        protocols.
6366         22-25.         Reserved for use in the Kerberos Verson 5 GSSAPI
6367                        mechanisms [@GSSAPI-CFX].
6368        26-511.         Reserved for future use in Kerberos and related
6369                        protocols.
6370      512-1023.         Reserved for uses internal to a Kerberos
6371                        implementation.
6372          1024.         Encryption for application use in protocols that
6373                        do not specify key usage values
6374          1025.         Checksums for application use in protocols that
6375                        do not specify key usage values
6376     1026-2047.      Reserved for application use.
6377
6378
6379 7.5.2. PreAuthentication Data Types
6380
6381    padata and data types           padata-type value  comment
6382
6383    PA-TGS-REQ                      1
6384    PA-ENC-TIMESTAMP                2
6385    PA-PW-SALT                      3
6386    [reserved]                      4
6387    PA-ENC-UNIX-TIME                5        (deprecated)
6388    PA-SANDIA-SECUREID              6
6389    PA-SESAME                       7
6390    PA-OSF-DCE                      8
6391    PA-CYBERSAFE-SECUREID           9
6392    PA-AFS3-SALT                    10
6393    PA-ETYPE-INFO                   11
6394    PA-SAM-CHALLENGE                12       (sam/otp)
6395    PA-SAM-RESPONSE                 13       (sam/otp)
6396    PA-PK-AS-REQ                    14       (pkinit)
6397    PA-PK-AS-REP                    15       (pkinit)
6398    PA-ETYPE-INFO2                  19       (replaces pa-etype-info)
6399    PA-USE-SPECIFIED-KVNO           20
6400    PA-SAM-REDIRECT                 21       (sam/otp)
6401    PA-GET-FROM-TYPED-DATA          22       (embedded in typed data)
6402    TD-PADATA                       22       (embeds padata)
6403    PA-SAM-ETYPE-INFO               23       (sam/otp)
6404    PA-ALT-PRINC                    24       (crawdad@fnal.gov)
6405
6406
6407
6408 September 2004                                                [Page 107]\f
6409
6410
6411
6412
6413
6414 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
6415
6416
6417    PA-SAM-CHALLENGE2               30       (kenh@pobox.com)
6418    PA-SAM-RESPONSE2                31       (kenh@pobox.com)
6419    PA-EXTRA-TGT                    41       Reserved extra TGT
6420    TD-PKINIT-CMS-CERTIFICATES      101      CertificateSet from CMS
6421    TD-KRB-PRINCIPAL                102      PrincipalName
6422    TD-KRB-REALM                    103      Realm
6423    TD-TRUSTED-CERTIFIERS           104      from PKINIT
6424    TD-CERTIFICATE-INDEX            105      from PKINIT
6425    TD-APP-DEFINED-ERROR            106      application specific
6426    TD-REQ-NONCE                    107      INTEGER
6427    TD-REQ-SEQ                      108      INTEGER
6428    PA-PAC-REQUEST                  128      (jbrezak@exchange.microsoft.com)
6429
6430 7.5.3. Address Types
6431
6432    Address type                   value
6433
6434    IPv4                             2
6435    Directional                      3
6436    ChaosNet                         5
6437    XNS                              6
6438    ISO                              7
6439    DECNET Phase IV                 12
6440    AppleTalk DDP                   16
6441    NetBios                         20
6442    IPv6                            24
6443
6444 7.5.4. Authorization Data Types
6445
6446    authorization data type         ad-type value
6447    AD-IF-RELEVANT                     1
6448    AD-INTENDED-FOR-SERVER             2
6449    AD-INTENDED-FOR-APPLICATION-CLASS  3
6450    AD-KDC-ISSUED                      4
6451    AD-AND-OR                          5
6452    AD-MANDATORY-TICKET-EXTENSIONS     6
6453    AD-IN-TICKET-EXTENSIONS            7
6454    AD-MANDATORY-FOR-KDC               8
6455    reserved values                    9-63
6456    OSF-DCE                            64
6457    SESAME                             65
6458    AD-OSF-DCE-PKI-CERTID              66      (hemsath@us.ibm.com)
6459    AD-WIN2K-PAC                      128      (jbrezak@exchange.microsoft.com)
6460
6461 7.5.5. Transited Encoding Types
6462
6463    transited encoding type         tr-type value
6464    DOMAIN-X500-COMPRESS            1
6465
6466
6467
6468 September 2004                                                [Page 108]\f
6469
6470
6471
6472
6473
6474 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
6475
6476
6477    reserved values                 all others
6478
6479 7.5.6. Protocol Version Number
6480
6481    Label               Value   Meaning or MIT code
6482
6483    pvno                    5   current Kerberos protocol version number
6484
6485 7.5.7. Kerberos Message Types
6486
6487    message types
6488
6489    KRB_AS_REQ         10   Request for initial authentication
6490    KRB_AS_REP         11   Response to KRB_AS_REQ request
6491    KRB_TGS_REQ        12   Request for authentication based on TGT
6492    KRB_TGS_REP        13   Response to KRB_TGS_REQ request
6493    KRB_AP_REQ         14   application request to server
6494    KRB_AP_REP         15   Response to KRB_AP_REQ_MUTUAL
6495    KRB_RESERVED16     16   Reserved for user-to-user krb_tgt_request
6496    KRB_RESERVED17     17   Reserved for user-to-user krb_tgt_reply
6497    KRB_SAFE           20   Safe (checksummed) application message
6498    KRB_PRIV           21   Private (encrypted) application message
6499    KRB_CRED           22   Private (encrypted) message to forward credentials
6500    KRB_ERROR          30   Error response
6501
6502 7.5.8. Name Types
6503
6504    name types
6505
6506    KRB_NT_UNKNOWN    0  Name type not known
6507    KRB_NT_PRINCIPAL  1  Just the name of the principal as in DCE, or for users
6508    KRB_NT_SRV_INST   2  Service and other unique instance (krbtgt)
6509    KRB_NT_SRV_HST    3  Service with host name as instance (telnet, rcommands)
6510    KRB_NT_SRV_XHST   4  Service with host as remaining components
6511    KRB_NT_UID        5  Unique ID
6512    KRB_NT_X500_PRINCIPAL 6  Encoded X.509 Distingished name [RFC 2253]
6513    KRB_NT_SMTP_NAME      7  Name in form of SMTP email name (e.g. user@foo.com)
6514    KRB_NT_ENTERPRISE    10   Enterprise name - may be mapped to principal name
6515
6516 7.5.9. Error Codes
6517
6518    error codes
6519
6520    KDC_ERR_NONE                    0   No error
6521    KDC_ERR_NAME_EXP                1   Client's entry in database has expired
6522    KDC_ERR_SERVICE_EXP             2   Server's entry in database has expired
6523    KDC_ERR_BAD_PVNO                3   Requested protocol version number
6524                                           not supported
6525
6526
6527
6528 September 2004                                                [Page 109]\f
6529
6530
6531
6532
6533
6534 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
6535
6536
6537    KDC_ERR_C_OLD_MAST_KVNO         4   Client's key encrypted in old master key
6538    KDC_ERR_S_OLD_MAST_KVNO         5   Server's key encrypted in old master key
6539    KDC_ERR_C_PRINCIPAL_UNKNOWN     6   Client not found in Kerberos database
6540    KDC_ERR_S_PRINCIPAL_UNKNOWN     7   Server not found in Kerberos database
6541    KDC_ERR_PRINCIPAL_NOT_UNIQUE    8   Multiple principal entries in database
6542    KDC_ERR_NULL_KEY                9   The client or server has a null key
6543    KDC_ERR_CANNOT_POSTDATE     10   Ticket not eligible for postdating
6544    KDC_ERR_NEVER_VALID         11   Requested start time is later than end time
6545    KDC_ERR_POLICY              12   KDC policy rejects request
6546    KDC_ERR_BADOPTION           13   KDC cannot accommodate requested option
6547    KDC_ERR_ETYPE_NOSUPP        14   KDC has no support for encryption type
6548    KDC_ERR_SUMTYPE_NOSUPP      15   KDC has no support for checksum type
6549    KDC_ERR_PADATA_TYPE_NOSUPP  16   KDC has no support for padata type
6550    KDC_ERR_TRTYPE_NOSUPP       17   KDC has no support for transited type
6551    KDC_ERR_CLIENT_REVOKED      18   Clients credentials have been revoked
6552    KDC_ERR_SERVICE_REVOKED     19   Credentials for server have been revoked
6553    KDC_ERR_TGT_REVOKED         20   TGT has been revoked
6554    KDC_ERR_CLIENT_NOTYET       21   Client not yet valid - try again later
6555    KDC_ERR_SERVICE_NOTYET      22   Server not yet valid - try again later
6556    KDC_ERR_KEY_EXPIRED         23   Password has expired
6557                                              - change password to reset
6558    KDC_ERR_PREAUTH_FAILED      24   Pre-authentication information was invalid
6559    KDC_ERR_PREAUTH_REQUIRED    25   Additional pre-authenticationrequired
6560    KDC_ERR_SERVER_NOMATCH      26   Requested server and ticket don't match
6561    KDC_ERR_MUST_USE_USER2USER  27   Server principal valid for user2user only
6562    KDC_ERR_PATH_NOT_ACCPETED   28   KDC Policy rejects transited path
6563    KDC_ERR_SVC_UNAVAILABLE     29   A service is not available
6564    KRB_AP_ERR_BAD_INTEGRITY    31   Integrity check on decrypted field failed
6565    KRB_AP_ERR_TKT_EXPIRED      32   Ticket expired
6566    KRB_AP_ERR_TKT_NYV          33   Ticket not yet valid
6567    KRB_AP_ERR_REPEAT           34   Request is a replay
6568    KRB_AP_ERR_NOT_US           35   The ticket isn't for us
6569    KRB_AP_ERR_BADMATCH         36   Ticket and authenticator don't match
6570    KRB_AP_ERR_SKEW             37   Clock skew too great
6571    KRB_AP_ERR_BADADDR          38   Incorrect net address
6572    KRB_AP_ERR_BADVERSION       39   Protocol version mismatch
6573    KRB_AP_ERR_MSG_TYPE         40   Invalid msg type
6574    KRB_AP_ERR_MODIFIED         41   Message stream modified
6575    KRB_AP_ERR_BADORDER         42   Message out of order
6576    KRB_AP_ERR_BADKEYVER        44   Specified version of key is not available
6577    KRB_AP_ERR_NOKEY            45   Service key not available
6578    KRB_AP_ERR_MUT_FAIL         46   Mutual authentication failed
6579    KRB_AP_ERR_BADDIRECTION     47   Incorrect message direction
6580    KRB_AP_ERR_METHOD           48   Alternative authentication method required
6581    KRB_AP_ERR_BADSEQ           49   Incorrect sequence number in message
6582    KRB_AP_ERR_INAPP_CKSUM      50   Inappropriate type of checksum in message
6583    KRB_AP_PATH_NOT_ACCEPTED    51   Policy rejects transited path
6584    KRB_ERR_RESPONSE_TOO_BIG    52   Response too big for UDP, retry with TCP
6585
6586
6587
6588 September 2004                                                [Page 110]\f
6589
6590
6591
6592
6593
6594 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
6595
6596
6597    KRB_ERR_GENERIC              60   Generic error (description in e-text)
6598    KRB_ERR_FIELD_TOOLONG        61   Field is too long for this implementation
6599    KDC_ERROR_CLIENT_NOT_TRUSTED    62 Reserved for PKINIT
6600    KDC_ERROR_KDC_NOT_TRUSTED       63 Reserved for PKINIT
6601    KDC_ERROR_INVALID_SIG           64 Reserved for PKINIT
6602    KDC_ERR_KEY_TOO_WEAK            65 Reserved for PKINIT
6603    KDC_ERR_CERTIFICATE_MISMATCH    66 Reserved for PKINIT
6604    KRB_AP_ERR_NO_TGT               67 No TGT available to validate USER-TO-USER
6605    KDC_ERR_WRONG_REALM             68 Reserved for future use
6606    KRB_AP_ERR_USER_TO_USER_REQUIRED  69 Ticket must be for USER-TO-USER
6607    KDC_ERR_CANT_VERIFY_CERTIFICATE   70 Reserved for PKINIT
6608    KDC_ERR_INVALID_CERTIFICATE       71 Reserved for PKINIT
6609    KDC_ERR_REVOKED_CERTIFICATE       72 Reserved for PKINIT
6610    KDC_ERR_REVOCATION_STATUS_UNKNOWN       73 Reserved for PKINIT
6611    KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74 Reserved for PKINIT
6612    KDC_ERR_CLIENT_NAME_MISMATCH            75 Reserved for PKINIT
6613    KDC_ERR_KDC_NAME_MISMATCH               76 Reserved for PKINIT
6614
6615 8. Interoperability requirements
6616
6617    Version 5 of the Kerberos protocol supports a myriad of options.
6618    Among these are multiple encryption and checksum types, alternative
6619    encoding schemes for the transited field, optional mechanisms for
6620    pre-authentication, the handling of tickets with no addresses,
6621    options for mutual authentication, user-to-user authentication,
6622    support for proxies, forwarding, postdating, and renewing tickets,
6623    the format of realm names, and the handling of authorization data.
6624
6625    In order to ensure the interoperability of realms, it is necessary to
6626    define a minimal configuration which must be supported by all
6627    implementations. This minimal configuration is subject to change as
6628    technology does. For example, if at some later date it is discovered
6629    that one of the required encryption or checksum algorithms is not
6630    secure, it will be replaced.
6631
6632 8.1. Specification 2
6633
6634    This section defines the second specification of these options.
6635    Implementations which are configured in this way can be said to
6636    support Kerberos Version 5 Specification 2 (5.2). Specification 1
6637    (deprecated) may be found in RFC1510.
6638
6639    Transport
6640
6641       TCP/IP and UDP/IP transport MUST be supported by clients and KDCs
6642       claiming conformance to specification 2.
6643
6644    Encryption and checksum methods
6645
6646
6647
6648 September 2004                                                [Page 111]\f
6649
6650
6651
6652
6653
6654 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
6655
6656
6657       The following encryption and checksum mechanisms MUST be
6658       supported.
6659
6660       Encryption: AES256-CTS-HMAC-SHA1-96
6661       Checksums: HMAC-SHA1-96-AES256
6662
6663       Implementations SHOULD support other mechanisms as well, but the
6664       additional mechanisms may only be used when communicating with
6665       principals known to also support them. The mechanisms that SHOULD
6666       be supported are:
6667
6668       Encryption:  AES128-CTS-HMAC-SHA1-96, DES-CBC-MD5, DES3-CBC-SHA1-KD
6669       Checksums:   DES-MD5, HMAC-SHA1-DES3-KD, HMAC-SHA1-96-AES128
6670
6671       Implementations MAY support other mechanisms as well, but the
6672       additional mechanisms may only be used when communicating with
6673       principals known to also support them.
6674
6675       Implementation note: earlier implementations of Kerberos generate
6676       messages using the CRC-32, RSA-MD5 checksum methods. For
6677       interoperability with these earlier releases implementors MAY
6678       consider supporting these checksum methods but should carefully
6679       analyze the security impplications to limit the situations within
6680       which these methods are accepted.
6681
6682    Realm Names
6683
6684       All implementations MUST understand hierarchical realms in both
6685       the Internet Domain and the X.500 style. When a ticket-granting
6686       ticket for an unknown realm is requested, the KDC MUST be able to
6687       determine the names of the intermediate realms between the KDCs
6688       realm and the requested realm.
6689
6690    Transited field encoding
6691
6692       DOMAIN-X500-COMPRESS (described in section 3.3.3.2) MUST be
6693       supported.  Alternative encodings MAY be supported, but they may
6694       be used only when that encoding is supported by ALL intermediate
6695       realms.
6696
6697    Pre-authentication methods
6698
6699       The TGS-REQ method MUST be supported. The TGS-REQ method is not
6700       used on the initial request. The PA-ENC-TIMESTAMP method MUST be
6701       supported by clients but whether it is enabled by default MAY be
6702       determined on a realm by realm basis. If not used in the initial
6703       request and the error KDC_ERR_PREAUTH_REQUIRED is returned
6704       specifying PA-ENC-TIMESTAMP as an acceptable method, the client
6705
6706
6707
6708 September 2004                                                [Page 112]\f
6709
6710
6711
6712
6713
6714 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
6715
6716
6717       SHOULD retry the initial request using the PA-ENC-TIMESTAMP pre-
6718       authentication method. Servers need not support the PA-ENC-
6719       TIMESTAMP method, but if not supported the server SHOULD ignore
6720       the presence of PA-ENC-TIMESTAMP pre-authentication in a request.
6721
6722       The ETYPE-INFO2 method MUST be supported; this method is used to
6723       communicate the set of supported encryption types, and
6724       corresponding salt and string to key paramters. The ETYPE-INFO
6725       method SHOULD be supported for interoperability with older
6726       implementation.
6727
6728    Mutual authentication
6729
6730       Mutual authentication (via the KRB_AP_REP message) MUST be
6731       supported.
6732
6733    Ticket addresses and flags
6734
6735       All KDCs MUST pass through tickets that carry no addresses (i.e.
6736       if a TGT contains no addresses, the KDC will return derivative
6737       tickets).  Implementations SHOULD default to requesting
6738       addressless tickets as this significantly increases
6739       interoperability with network address translation.  In some cases
6740       realms or application servers MAY require that tickets have an
6741       address.
6742
6743       Implementations SHOULD accept directional address type for the
6744       KRB_SAFE and KRB_PRIV message and SHOULD include directional
6745       addresses in these messages when other address types are not
6746       available.
6747
6748       Proxies and forwarded tickets MUST be supported. Individual realms
6749       and application servers can set their own policy on when such
6750       tickets will be accepted.
6751
6752       All implementations MUST recognize renewable and postdated
6753       tickets, but need not actually implement them. If these options
6754       are not supported, the starttime and endtime in the ticket shall
6755       specify a ticket's entire useful life. When a postdated ticket is
6756       decoded by a server, all implementations shall make the presence
6757       of the postdated flag visible to the calling server.
6758
6759    User-to-user authentication
6760
6761       Support for user-to-user authentication (via the ENC-TKT-IN-SKEY
6762       KDC option) MUST be provided by implementations, but individual
6763       realms MAY decide as a matter of policy to reject such requests on
6764       a per-principal or realm-wide basis.
6765
6766
6767
6768 September 2004                                                [Page 113]\f
6769
6770
6771
6772
6773
6774 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
6775
6776
6777    Authorization data
6778
6779       Implementations MUST pass all authorization data subfields from
6780       ticket-granting tickets to any derivative tickets unless directed
6781       to suppress a subfield as part of the definition of that
6782       registered subfield type (it is never incorrect to pass on a
6783       subfield, and no registered subfield types presently specify
6784       suppression at the KDC).
6785
6786       Implementations MUST make the contents of any authorization data
6787       subfields available to the server when a ticket is used.
6788       Implementations are not required to allow clients to specify the
6789       contents of the authorization data fields.
6790
6791    Constant ranges
6792
6793       All protocol constants are constrained to 32 bit (signed) values
6794       unless further constrained by the protocol definition. This limit
6795       is provided to allow implementations to make assumptions about the
6796       maximum values that will be received for these constants.
6797       Implementation receiving values outside this range MAY reject the
6798       request, but they MUST recover cleanly.
6799
6800 8.2. Recommended KDC values
6801
6802    Following is a list of recommended values for a KDC configuration.
6803
6804    minimum lifetime              5 minutes
6805    maximum renewable lifetime    1 week
6806    maximum ticket lifetime       1 day
6807    acceptable clock skew         5 minutes
6808    empty addresses               Allowed.
6809    proxiable, etc.               Allowed.
6810
6811 9. IANA considerations
6812
6813    Section 7 of this document specifies protocol constants and other
6814    defined values required for the interoperability of multiple
6815    implementations. Until otherwise specified in a subsequent RFC, or
6816    upon disbanding of the Kerberos working group, allocations of
6817    additional protocol constants and other defined values required for
6818    extensions to the Kerberos protocol will be administered by the
6819    kerberos working group.  Following the recomendations outlined in
6820    [RFC 2434], guidance is provided to the IANA as follows:
6821
6822    "reserved" realm name types in section 6.1 and "other" realm types
6823    except those beginning with "X-" or "x-" will not be registered
6824    without IETF standards action, at which point guidlines for further
6825
6826
6827
6828 September 2004                                                [Page 114]\f
6829
6830
6831
6832
6833
6834 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
6835
6836
6837    assignment will be specified.  Realm name types beginning with "X-"
6838    or "x-" are for private use.
6839
6840    For host address types described in section 7.1, negative values are
6841    for private use.  Assignment of additional positive numbers is
6842    subject to review by the kerberos working group or other expert
6843    review.
6844
6845    Additional key usage numbers as defined in section 7.5.1 will be
6846    assigned subject to review by the kerberos working group or other
6847    expert review.
6848
6849    Additional preauthentciation data type values as defined in section
6850    7.5.2 will be assigned subject to review by the kerberos working
6851    group or other expert review.
6852
6853    Additional Authorization Data Types as defined in section 7.5.4 will
6854    be assigned subject to review by the kerberos working group or other
6855    expert review.  Although it is anticipated that there may be
6856    significant demand for private use types, provision is intentionaly
6857    not made for a private use portion of the namespace because conficts
6858    between privately assigned values coule have detrimental security
6859    implications.
6860
6861    Additional Transited Encoding Types as defined in section 7.5.5
6862    present special concerns for interoperability with existing
6863    implementations.  As such, such assignments will only be made by
6864    standards action, except that the Kerberos working group or another
6865    other working group with competent jurisdiction may make preliminary
6866    assignments for documents which are moving through the standards
6867    process.
6868
6869    Additional Kerberos Message Types as described in section 7.5.7 will
6870    be assigned subject to review by the kerberos working group or other
6871    expert review.
6872
6873    Additional Name Types as described in section 7.5.8 will be assigned
6874    subject to review by the kerberos working group or other expert
6875    review.
6876
6877    Additional error codes described in section 7.5.9 will be assigned
6878    subject to review by the kerberos working group or other expert
6879    review.
6880
6881 10. Security Considerations
6882
6883    As an authentication service, Kerberos provides a means of verifying
6884    the identity of principals on a network. Kerberos does not, by
6885
6886
6887
6888 September 2004                                                [Page 115]\f
6889
6890
6891
6892
6893
6894 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
6895
6896
6897    itself, provide authorization. Applications should not accept the
6898    issuance of a service ticket by the Kerberos server as granting
6899    authority to use the service, since such applications may become
6900    vulnerable to the bypass of this authorization check in an
6901    environment if they inter-operate with other KDCs or where other
6902    options for application authentication are provided.
6903
6904    Denial of service attacks are not solved with Kerberos. There are
6905    places in the protocols where an intruder can prevent an application
6906    from participating in the proper authentication steps. Because
6907    authentication is a required step for the use of many services,
6908    successful denial of service attacks on a Kerberos server might
6909    result in the denial of other network services that rely on Kerberos
6910    for authentication. Kerberos is vulnerable to many kinds of denial of
6911    service attacks: denial of service attacks on the network which would
6912    prevent clients from contacting the KDC; denial of service attacks on
6913    the domain name system which could prevent a client from finding the
6914    IP address of the Kerberos server; and denial of service attack by
6915    overloading the Kerberos KDC itself with repeated requests.
6916
6917    Interoperability conflicts caused by incompatible character-set usage
6918    (see 5.2.1) can result in denial of service for clients that utilize
6919    character-sets in Kerberos strings other than those stored in the KDC
6920    database.
6921
6922    Authentication servers maintain a database of principals (i.e., users
6923    and servers) and their secret keys. The security of the
6924    authentication server machines is critical. The breach of security of
6925    an authentication server will compromise the security of all servers
6926    that rely upon the compromised KDC, and will compromise the
6927    authentication of any principals registered in the realm of the
6928    compromised KDC.
6929
6930    Principals must keep their secret keys secret. If an intruder somehow
6931    steals a principal's key, it will be able to masquerade as that
6932    principal or impersonate any server to the legitimate principal.
6933
6934    Password guessing attacks are not solved by Kerberos. If a user
6935    chooses a poor password, it is possible for an attacker to
6936    successfully mount an off-line dictionary attack by repeatedly
6937    attempting to decrypt, with successive entries from a dictionary,
6938    messages obtained which are encrypted under a key derived from the
6939    user's password.
6940
6941    Unless pre-authentication options are required by the policy of a
6942    realm, the KDC will not know whether a request for authentication
6943    succeeds. An attacker can request a reply with credentials for any
6944    principal. These credentials will likely not be of much use to the
6945
6946
6947
6948 September 2004                                                [Page 116]\f
6949
6950
6951
6952
6953
6954 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
6955
6956
6957    attacker unless it knows the client's secret key, but the
6958    availability of the response encrypted in the client's secret key
6959    provides the attacker with ciphertext that may be used to mount brute
6960    force or dictionary attacks to decrypt the credentials, by guessing
6961    the user's password. For this reason it is strongly encouraged that
6962    Kerberos realms require the use of pre-authentication. Even with pre-
6963    authentication, attackers may try brute force or dictionary attacks
6964    against credentials that are observed by eavesdropping on the
6965    network.
6966
6967    Because a client can request a ticket for any server principal and
6968    can attempt a brute force or dictionary attack against the server
6969    principal's key using that ticket, it is strongly encouraged that
6970    keys be randomly generated (rather than generated from passwords) for
6971    any principals that are usable as the target principal for a
6972    KRB_TGS_REQ or KRB_AS_REQ messages. [RFC1750]
6973
6974    Although the DES-CBC-MD5 encryption method and DES-MD5 checksum
6975    methods are listed as SHOULD be implemented for backward
6976    compatibility, the single DES encryption algorithm on which these are
6977    based is weak and stronger algorithms should be used whenever
6978    possible.
6979
6980    Each host on the network must have a clock which is loosely
6981    synchronized to the time of the other hosts; this synchronization is
6982    used to reduce the bookkeeping needs of application servers when they
6983    do replay detection. The degree of "looseness" can be configured on a
6984    per-server basis, but is typically on the order of 5 minutes. If the
6985    clocks are synchronized over the network, the clock synchronization
6986    protocol MUST itself be secured from network attackers.
6987
6988    Principal identifiers must not recycled on a short-term basis. A
6989    typical mode of access control will use access control lists (ACLs)
6990    to grant permissions to particular principals. If a stale ACL entry
6991    remains for a deleted principal and the principal identifier is
6992    reused, the new principal will inherit rights specified in the stale
6993    ACL entry. By not reusing principal identifiers, the danger of
6994    inadvertent access is removed.
6995
6996    Proper decryption of an KRB_AS_REP message from the KDC is not
6997    sufficient for the host to verify the identity of the user; the user
6998    and an attacker could cooperate to generate a KRB_AS_REP format
6999    message which decrypts properly but is not from the proper KDC. To
7000    authenticate a user logging on to a local system, the credentials
7001    obtained in the AS exchange may first be used in a TGS exchange to
7002    obtain credentials for a local server. Those credentials must then be
7003    verified by a local server through successful completion of the
7004    Client/Server exchange.
7005
7006
7007
7008 September 2004                                                [Page 117]\f
7009
7010
7011
7012
7013
7014 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
7015
7016
7017    Many RFC 1510 compliant implementations ignore unknown authorization
7018    data elements. Depending on these implementations to honor
7019    authorization data restrictions may create a security weakness.
7020
7021    Kerberos credentials contain clear-text information identifying the
7022    principals to which they apply. If privacy of this information is
7023    needed, this exchange should itself be encapsulated in a protocol
7024    providing for confidentiality on the exchange of these credentials.
7025
7026    Applications must take care to protect communications subsequent to
7027    authentication either by using the KRB_PRIV or KRB_SAFE messages as
7028    appropriate, or by applying their own confidentiality or integrity
7029    mechanisms on such communications. Completion of the KRB_AP_REQ and
7030    KRB_AP_REP exchange without subsequent use of confidentiality and
7031    integrity mechanisms provides only for authentication of the parties
7032    to the communication and not confidentiality and integrity of the
7033    subsequent communication. Application applying confidentiality and
7034    integrity protection mechanisms other than KRB_PRIV and KRB_SAFE must
7035    make sure that the authentication step is appropriately linked with
7036    the protected communication channel that is established by the
7037    application.
7038
7039    Unless the application server provides its own suitable means to
7040    protect against replay (for example, a challenge-response sequence
7041    initiated by the server after authentication, or use of a server-
7042    generated encryption subkey), the server must utilize a replay cache
7043    to remember any authenticator presented within the allowable clock
7044    skew. All services sharing a key need to use the same replay cache.
7045    If separate replay caches are used, then and authenticator used with
7046    one such service could later be replayed to a different service with
7047    the same service principal.
7048
7049    If a server loses track of authenticators presented within the
7050    allowable clock skew, it must reject all requests until the clock
7051    skew interval has passed, providing assurance that any lost or
7052    replayed authenticators will fall outside the allowable clock skew
7053    and can no longer be successfully replayed.
7054
7055    Implementations of Kerberos should not use untrusted directory
7056    servers to determine the realm of a host. To allow such would allow
7057    the compromise of the directory server to enable an attacker to
7058    direct the client to accept authentication with the wrong principal
7059    (i.e. one with a similar name, but in a realm with which the
7060    legitimate host was not registered).
7061
7062    Implementations of Kerberos must not use DNS to map one name to
7063    another (canonicalize) to determine the host part of the principal
7064    name with which one is to communicate.  To allow such
7065
7066
7067
7068 September 2004                                                [Page 118]\f
7069
7070
7071
7072
7073
7074 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
7075
7076
7077    canonicalization would allow a compromise of the DNS to result in a
7078    client obtaining credentials and correctly authenticating to the
7079    wrong principal. Though the client will know who it is communicating
7080    with, it will not be the principal with which it intended to
7081    communicate.
7082
7083    If the Kerberos server returns a TGT for a 'closer' realm other than
7084    the desired realm, the client may use local policy configuration to
7085    verify that the authentication path used is an acceptable one.
7086    Alternatively, a client may choose its own authentication path,
7087    rather than relying on the Kerberos server to select one. In either
7088    case, any policy or configuration information used to choose or
7089    validate authentication paths, whether by the Kerberos server or
7090    client, must be obtained from a trusted source.
7091
7092    The Kerberos protocol in its basic form does not provide perfect
7093    forward secrecy for communications. If traffic has been recorded by
7094    an eavesdropper, then messages encrypted using the KRB_PRIV message,
7095    or messages encrypted using application specific encryption under
7096    keys exchanged using Kerberos can be decrypted if any of the user's,
7097    application server's, or KDC's key is subsequently discovered. This
7098    is because the session key use to encrypt such messages is
7099    transmitted over the network encrypted in the key of the application
7100    server, and also encrypted under the session key from the user's
7101    ticket-granting ticket when returned to the user in the KRB_TGS_REP
7102    message. The session key from the ticket-granting ticket was sent to
7103    the user in the KRB_AS_REP message encrypted in the user's secret
7104    key, and embedded in the ticket-granting ticket, which was encrypted
7105    in the key of the KDC. Application requiring perfect forward secrecy
7106    must exchange keys through mechanisms that provide such assurance,
7107    but may use Kerberos for authentication of the encrypted channel
7108    established through such other means.
7109
7110 11. Author's Addresses
7111
7112
7113        Clifford Neuman
7114        Information Sciences Institute
7115        University of Southern California
7116        4676 Admiralty Way
7117        Marina del Rey, CA 90292, USA
7118        Email: bcn@isi.edu
7119
7120        Tom Yu
7121        Massachusetts Institute of Technology
7122        77 Massachusetts Avenue
7123        Cambridge, MA 02139, USA
7124        Email: tlyu@mit.edu
7125
7126
7127
7128 September 2004                                                [Page 119]\f
7129
7130
7131
7132
7133
7134 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
7135
7136
7137        Sam Hartman
7138        Massachusetts Institute of Technology
7139        77 Massachusetts Avenue
7140        Cambridge, MA 02139, USA
7141        Email: hartmans@mit.edu
7142
7143        Kenneth Raeburn
7144        Massachusetts Institute of Technology
7145        77 Massachusetts Avenue
7146        Cambridge, MA 02139, USA
7147        Email: raeburn@MIT.EDU
7148
7149
7150 12. Acknowledgements
7151
7152    This document is a revision to RFC1510 which was co-authored with
7153    John Kohl.  The specification of the Kerberos protocol described in
7154    this document is the result of many years of effort.  Over this
7155    period many individuals have contributed to the definition of the
7156    protocol and to the writing of the specification. Unfortunately it is
7157    not possible to list all contributors as authors of this document,
7158    though there are many not listed who are authors in spirit, because
7159    they contributed text for parts of some sections, because they
7160    contributed to the design of parts of the protocol, or because they
7161    contributed significantly to the discussion of the protocol in the
7162    IETF common authentication technology (CAT) and Kerberos working
7163    groups.
7164
7165    Among those contributing to the development and specification of
7166    Kerberos were Jeffrey Altman, John Brezak, Marc Colan, Johan
7167    Danielsson, Don Davis, Doug Engert, Dan Geer, Paul Hill, John Kohl,
7168    Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John Linn,
7169    Ari Medvinsky, Sasha Medvinsky, Steve Miller, Jon Rochlis, Jerome
7170    Saltzer, Jeffrey Schiller, Jennifer Steiner, Ralph Swick, Mike Swift,
7171    Jonathan Trostle, Theodore Ts'o, Brian Tung, Jacques Vidrine, Assar
7172    Westerlund, and Nicolas Williams. Many other members of MIT Project
7173    Athena, the MIT networking group, and the Kerberos and CAT working
7174    groups of the IETF contributed but are not listed.
7175
7176    Funding for the RFC Editor function is currently provided by the
7177    Internet Society.
7178
7179 13. REFERENCES
7180
7181 13.1 NORMATIVE REFERENCES
7182
7183    [@KCRYPTO]
7184       RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg-
7185
7186
7187
7188 September 2004                                                [Page 120]\f
7189
7190
7191
7192
7193
7194 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
7195
7196
7197       crypto.
7198
7199    [@AES]
7200       RFC-Editor: To be replaced by RFC number for draft-raeburn-krb-
7201       rijndael-krb.
7202
7203    [@GSSAPI-CFX]
7204       RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg-
7205       gssapi-cfx
7206
7207    [ISO-646/ECMA-6]
7208       7-bit Coded Character Set
7209
7210    [ISO-2022/ECMA-35]
7211       Character Code Structure and Extension Techniques
7212
7213    [RFC1035]
7214       P.V. Mockapetris, RFC1035: "Domain Names - Implementations and
7215       Specification," November 1, 1987, Obsoletes - RFC973, RFC882,
7216       RFC883. Updated by RFC1101, RFC1183, RFC1348, RFCRFC1876, RFC1982,
7217       RFC1995, RFC1996, RFC2065, RFC2136, RFC2137, RFC2181, RFC2308,
7218       RFC2535, RFC2845, and RFC3425. Status: Standard.
7219
7220    [RFC2119]
7221
7222       S. Bradner, RFC2119: "Key words for use in RFC's to Indicate
7223       Requirement Levels", March 1997.
7224
7225    [RFC2434]
7226       T. Narten, H. Alvestrand, RFC2434: "Guidelines for writing IANA
7227       Consideration Secionts in RFCs" October, 1998.
7228
7229    [RFC2782]
7230       A. Gulbrandsen,  P. Vixie and L. Esibov., RFC2782: "A DNS RR for
7231       Specifying the Location of Services (DNS SRV)," February 2000.
7232
7233    [RFC2253]
7234       M. Wahl, S. Killie, and T. Howes, RFC2253: "Lightweight Directory
7235       Access Protocol (v3): UTF-8 String Representation or Distinguished
7236       Names," December 1997, Obsoletes - RFC1779, Updated by RFC3377,
7237       Status: Proposed Standard.
7238
7239    [RFC2373]
7240       R. Hinden, S. Deering, RFC2373: "IP Version 6 Addressing
7241       Architecture," July 1998, Status: Proposed Standard.
7242
7243    [X680]
7244       Abstract Syntax Notation One (ASN.1): Specification of Basic
7245
7246
7247
7248 September 2004                                                [Page 121]\f
7249
7250
7251
7252
7253
7254 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
7255
7256
7257       Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC
7258       International Standard 8824-1:1998.
7259
7260    [X690]
7261       ASN.1 encoding rules: Specification of Basic Encoding Rules (BER),
7262       Canonical Encoding Rules (CER) and Distinguished Encoding Rules
7263       (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International
7264       Standard 8825-1:1998.
7265
7266 13.2 INFORMATIVE REFERENCES
7267
7268    [DGT96]
7269       Don Davis, Daniel Geer, and Theodore Ts'o, "Kerberos With Clocks
7270       Adrift: History, Protocols, and Implementation", USENIX Computing
7271       Systems 9:1 (January 1996).
7272
7273    [DS81]
7274       Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key
7275       Distribution Protocols," Communications of the ACM, Vol. 24(8),
7276       pp.  533-536 (August 1981).
7277
7278    [KNT94]
7279
7280       John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
7281       Evolution of the Kerberos Authentication System". In Distributed
7282       Open Systems, pages 78-94. IEEE Computer Society Press, 1994.
7283
7284    [MNSS87]
7285       S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer,
7286       Section E.2.1: Kerberos Authentication and Authorization System,
7287       M.I.T. Project Athena, Cambridge, Massachusetts (December 21,
7288       1987).
7289
7290    [NS78]
7291       Roger M. Needham and Michael D. Schroeder, "Using Encryption for
7292       Authentication in Large Networks of Computers," Communications of
7293       the ACM, Vol. 21(12), pp. 993-999 (December, 1978).
7294
7295    [Neu93]
7296       B. Clifford Neuman, "Proxy-Based Authorization and Accounting for
7297       Distributed Systems," in Proceedings of the 13th International
7298       Conference on Distributed Computing Systems, Pittsburgh, PA (May,
7299       1993).
7300
7301    [NT94]
7302       B. Clifford Neuman and Theodore Y. Ts'o, "An Authentication
7303       Service for Computer Networks," IEEE Communications Magazine, Vol.
7304       32(9), pp.  33-38 (September 1994).
7305
7306
7307
7308 September 2004                                                [Page 122]\f
7309
7310
7311
7312
7313
7314 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
7315
7316
7317    [Pat92].
7318       J. Pato, Using Pre-Authentication to Avoid Password Guessing
7319       Attacks, Open Software Foundation DCE Request for Comments 26
7320       (December 1992).
7321
7322    [RFC1510]
7323       J. Kohl and  B. C. Neuman, RFC1510: "The Kerberos Network
7324       Authentication Service (v5)," September 1993, Status: Proposed
7325       Standard.
7326
7327    [RFC1750]
7328       D. Eastlake, S. Crocker, and J. Schiller "Randomness
7329       Recommendation for Security" December 1994, Status: Informational.
7330
7331    [RFC2026]
7332       S. Bradner, RFC2026:  "The Internet Standard Process - Revision
7333       3," October 1996, Obsoletes - RFC 1602, Status: Best Current
7334       Practice.
7335
7336    [SNS88]
7337       J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Kerberos: An
7338       Authentication Service for Open Network Systems," pp. 191-202 in
7339       Usenix Conference Proceedings, Dallas, Texas (February, 1988).
7340
7341
7342 14. Copyright Statement
7343
7344       Copyright (C) The Internet Society (2004).  This document is
7345       subject to the rights, licenses and restrictions contained in BCP
7346       78 and except as set forth therein, the authors retain all their
7347       rights.
7348
7349       This document and the information contained herein are provided on
7350       an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
7351       REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
7352       THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
7353       EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
7354       THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
7355       ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
7356       PARTICULAR PURPOSE.
7357
7358 15. Intellectual Property
7359
7360       The IETF takes no position regarding the validity or scope of any
7361       Intellectual Property Rights or other rights that might be claimed
7362       to pertain to the implementation or use of the technology
7363       described in this document or the extent to which any license
7364       under such rights might or might not be available; nor does it
7365
7366
7367
7368 September 2004                                                [Page 123]\f
7369
7370
7371
7372
7373
7374 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
7375
7376
7377       represent that it has made any independent effort to identify any
7378       such rights.  Information on the procedures with respect to rights
7379       in RFC documents can be found in BCP 78 and BCP 79.
7380
7381       Copies of IPR disclosures made to the IETF Secretariat and any
7382       assurances of licenses to be made available, or the result of an
7383       attempt made to obtain a general license or permission for the use
7384       of such proprietary rights by implementers or users of this
7385       specification can be obtained from the IETF on-line IPR repository
7386       at http://www.ietf.org/ipr.
7387
7388       The IETF invites any interested party to bring to its attention
7389       any copyrights, patents or patent applications, or other
7390       proprietary rights that may cover technology that may be required
7391       to implement this standard.  Please address the information to the
7392       IETF at ietf-ipr@ietf.org.
7393
7394 A. ASN.1 module
7395
7396    KerberosV5Spec2 {
7397            iso(1) identified-organization(3) dod(6) internet(1)
7398            security(5) kerberosV5(2) modules(4) krb5spec2(2)
7399    } DEFINITIONS EXPLICIT TAGS ::= BEGIN
7400
7401    -- OID arc for KerberosV5
7402    --
7403    -- This OID may be used to identify Kerberos protocol messages
7404    -- encapsulated in other protocols.
7405    --
7406    -- This OID also designates the OID arc for KerberosV5-related OIDs.
7407    --
7408    -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its OID.
7409    id-krb5         OBJECT IDENTIFIER ::= {
7410            iso(1) identified-organization(3) dod(6) internet(1)
7411            security(5) kerberosV5(2)
7412    }
7413
7414    Int32           ::= INTEGER (-2147483648..2147483647)
7415                        -- signed values representable in 32 bits
7416
7417    UInt32          ::= INTEGER (0..4294967295)
7418                        -- unsigned 32 bit values
7419
7420    Microseconds    ::= INTEGER (0..999999)
7421                        -- microseconds
7422
7423    KerberosString  ::= GeneralString (IA5String)
7424
7425
7426
7427
7428 September 2004                                                [Page 124]\f
7429
7430
7431
7432
7433
7434 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
7435
7436
7437    Realm           ::= KerberosString
7438
7439    PrincipalName   ::= SEQUENCE {
7440            name-type       [0] Int32,
7441            name-string     [1] SEQUENCE OF KerberosString
7442    }
7443
7444    KerberosTime    ::= GeneralizedTime -- with no fractional seconds
7445
7446    HostAddress     ::= SEQUENCE  {
7447            addr-type       [0] Int32,
7448            address         [1] OCTET STRING
7449    }
7450
7451    -- NOTE: HostAddresses is always used as an OPTIONAL field and
7452    -- should not be empty.
7453    HostAddresses   -- NOTE: subtly different from rfc1510,
7454                    -- but has a value mapping and encodes the same
7455            ::= SEQUENCE OF HostAddress
7456
7457    -- NOTE: AuthorizationData is always used as an OPTIONAL field and
7458    -- should not be empty.
7459    AuthorizationData       ::= SEQUENCE OF SEQUENCE {
7460            ad-type         [0] Int32,
7461            ad-data         [1] OCTET STRING
7462    }
7463
7464    PA-DATA         ::= SEQUENCE {
7465            -- NOTE: first tag is [1], not [0]
7466            padata-type     [1] Int32,
7467            padata-value    [2] OCTET STRING -- might be encoded AP-REQ
7468    }
7469
7470    KerberosFlags   ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits
7471                        -- shall be sent, but no fewer than 32
7472
7473    EncryptedData   ::= SEQUENCE {
7474            etype   [0] Int32 -- EncryptionType --,
7475            kvno    [1] UInt32 OPTIONAL,
7476            cipher  [2] OCTET STRING -- ciphertext
7477    }
7478
7479    EncryptionKey   ::= SEQUENCE {
7480            keytype         [0] Int32 -- actually encryption type --,
7481            keyvalue        [1] OCTET STRING
7482    }
7483
7484    Checksum        ::= SEQUENCE {
7485
7486
7487
7488 September 2004                                                [Page 125]\f
7489
7490
7491
7492
7493
7494 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
7495
7496
7497            cksumtype       [0] Int32,
7498            checksum        [1] OCTET STRING
7499    }
7500
7501    Ticket          ::= [APPLICATION 1] SEQUENCE {
7502            tkt-vno         [0] INTEGER (5),
7503            realm           [1] Realm,
7504            sname           [2] PrincipalName,
7505            enc-part        [3] EncryptedData -- EncTicketPart
7506    }
7507
7508    -- Encrypted part of ticket
7509    EncTicketPart   ::= [APPLICATION 3] SEQUENCE {
7510            flags                   [0] TicketFlags,
7511            key                     [1] EncryptionKey,
7512            crealm                  [2] Realm,
7513            cname                   [3] PrincipalName,
7514            transited               [4] TransitedEncoding,
7515            authtime                [5] KerberosTime,
7516            starttime               [6] KerberosTime OPTIONAL,
7517            endtime                 [7] KerberosTime,
7518            renew-till              [8] KerberosTime OPTIONAL,
7519            caddr                   [9] HostAddresses OPTIONAL,
7520            authorization-data      [10] AuthorizationData OPTIONAL
7521    }
7522
7523    -- encoded Transited field
7524    TransitedEncoding       ::= SEQUENCE {
7525            tr-type         [0] Int32 -- must be registered --,
7526            contents        [1] OCTET STRING
7527    }
7528
7529    TicketFlags     ::= KerberosFlags
7530            -- reserved(0),
7531            -- forwardable(1),
7532            -- forwarded(2),
7533            -- proxiable(3),
7534            -- proxy(4),
7535            -- may-postdate(5),
7536            -- postdated(6),
7537            -- invalid(7),
7538            -- renewable(8),
7539            -- initial(9),
7540            -- pre-authent(10),
7541            -- hw-authent(11),
7542    -- the following are new since 1510
7543            -- transited-policy-checked(12),
7544            -- ok-as-delegate(13)
7545
7546
7547
7548 September 2004                                                [Page 126]\f
7549
7550
7551
7552
7553
7554 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
7555
7556
7557    AS-REQ          ::= [APPLICATION 10] KDC-REQ
7558
7559    TGS-REQ         ::= [APPLICATION 12] KDC-REQ
7560
7561    KDC-REQ         ::= SEQUENCE {
7562            -- NOTE: first tag is [1], not [0]
7563            pvno            [1] INTEGER (5) ,
7564            msg-type        [2] INTEGER (10 -- AS -- | 12 -- TGS --),
7565            padata          [3] SEQUENCE OF PA-DATA OPTIONAL
7566                                -- NOTE: not empty --,
7567            req-body        [4] KDC-REQ-BODY
7568    }
7569
7570    KDC-REQ-BODY    ::= SEQUENCE {
7571            kdc-options             [0] KDCOptions,
7572            cname                   [1] PrincipalName OPTIONAL
7573                                        -- Used only in AS-REQ --,
7574            realm                   [2] Realm
7575                                        -- Server's realm
7576                                        -- Also client's in AS-REQ --,
7577            sname                   [3] PrincipalName OPTIONAL,
7578            from                    [4] KerberosTime OPTIONAL,
7579            till                    [5] KerberosTime,
7580            rtime                   [6] KerberosTime OPTIONAL,
7581            nonce                   [7] UInt32,
7582            etype                   [8] SEQUENCE OF Int32 -- EncryptionType
7583                                        -- in preference order --,
7584            addresses               [9] HostAddresses OPTIONAL,
7585            enc-authorization-data  [10] EncryptedData OPTIONAL
7586                                        -- AuthorizationData --,
7587            additional-tickets      [11] SEQUENCE OF Ticket OPTIONAL
7588                                            -- NOTE: not empty
7589    }
7590
7591    KDCOptions      ::= KerberosFlags
7592            -- reserved(0),
7593            -- forwardable(1),
7594            -- forwarded(2),
7595            -- proxiable(3),
7596            -- proxy(4),
7597            -- allow-postdate(5),
7598            -- postdated(6),
7599            -- unused7(7),
7600            -- renewable(8),
7601            -- unused9(9),
7602            -- unused10(10),
7603            -- opt-hardware-auth(11),
7604            -- unused12(12),
7605
7606
7607
7608 September 2004                                                [Page 127]\f
7609
7610
7611
7612
7613
7614 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
7615
7616
7617            -- unused13(13),
7618    -- 15 is reserved for canonicalize
7619            -- unused15(15),
7620    -- 26 was unused in 1510
7621            -- disable-transited-check(26),
7622    --
7623            -- renewable-ok(27),
7624            -- enc-tkt-in-skey(28),
7625            -- renew(30),
7626            -- validate(31)
7627
7628    AS-REP          ::= [APPLICATION 11] KDC-REP
7629
7630    TGS-REP         ::= [APPLICATION 13] KDC-REP
7631
7632    KDC-REP         ::= SEQUENCE {
7633            pvno            [0] INTEGER (5),
7634            msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
7635            padata          [2] SEQUENCE OF PA-DATA OPTIONAL
7636                                    -- NOTE: not empty --,
7637            crealm          [3] Realm,
7638            cname           [4] PrincipalName,
7639            ticket          [5] Ticket,
7640            enc-part        [6] EncryptedData
7641                                    -- EncASRepPart or EncTGSRepPart,
7642                                    -- as appropriate
7643    }
7644
7645    EncASRepPart    ::= [APPLICATION 25] EncKDCRepPart
7646
7647    EncTGSRepPart   ::= [APPLICATION 26] EncKDCRepPart
7648
7649    EncKDCRepPart   ::= SEQUENCE {
7650            key             [0] EncryptionKey,
7651            last-req        [1] LastReq,
7652            nonce           [2] UInt32,
7653            key-expiration  [3] KerberosTime OPTIONAL,
7654            flags           [4] TicketFlags,
7655            authtime        [5] KerberosTime,
7656            starttime       [6] KerberosTime OPTIONAL,
7657            endtime         [7] KerberosTime,
7658            renew-till      [8] KerberosTime OPTIONAL,
7659            srealm          [9] Realm,
7660            sname           [10] PrincipalName,
7661            caddr           [11] HostAddresses OPTIONAL
7662    }
7663
7664    LastReq         ::=     SEQUENCE OF SEQUENCE {
7665
7666
7667
7668 September 2004                                                [Page 128]\f
7669
7670
7671
7672
7673
7674 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
7675
7676
7677            lr-type         [0] Int32,
7678            lr-value        [1] KerberosTime
7679    }
7680
7681    AP-REQ          ::= [APPLICATION 14] SEQUENCE {
7682            pvno            [0] INTEGER (5),
7683            msg-type        [1] INTEGER (14),
7684            ap-options      [2] APOptions,
7685            ticket          [3] Ticket,
7686            authenticator   [4] EncryptedData -- Authenticator
7687    }
7688
7689    APOptions       ::= KerberosFlags
7690            -- reserved(0),
7691            -- use-session-key(1),
7692            -- mutual-required(2)
7693
7694    -- Unencrypted authenticator
7695    Authenticator   ::= [APPLICATION 2] SEQUENCE  {
7696            authenticator-vno       [0] INTEGER (5),
7697            crealm                  [1] Realm,
7698            cname                   [2] PrincipalName,
7699            cksum                   [3] Checksum OPTIONAL,
7700            cusec                   [4] Microseconds,
7701            ctime                   [5] KerberosTime,
7702            subkey                  [6] EncryptionKey OPTIONAL,
7703            seq-number              [7] UInt32 OPTIONAL,
7704            authorization-data      [8] AuthorizationData OPTIONAL
7705    }
7706
7707    AP-REP          ::= [APPLICATION 15] SEQUENCE {
7708            pvno            [0] INTEGER (5),
7709            msg-type        [1] INTEGER (15),
7710            enc-part        [2] EncryptedData -- EncAPRepPart
7711    }
7712
7713    EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
7714            ctime           [0] KerberosTime,
7715            cusec           [1] Microseconds,
7716            subkey          [2] EncryptionKey OPTIONAL,
7717            seq-number      [3] UInt32 OPTIONAL
7718    }
7719
7720    KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
7721            pvno            [0] INTEGER (5),
7722            msg-type        [1] INTEGER (20),
7723            safe-body       [2] KRB-SAFE-BODY,
7724            cksum           [3] Checksum
7725
7726
7727
7728 September 2004                                                [Page 129]\f
7729
7730
7731
7732
7733
7734 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
7735
7736
7737    }
7738
7739    KRB-SAFE-BODY   ::= SEQUENCE {
7740            user-data       [0] OCTET STRING,
7741            timestamp       [1] KerberosTime OPTIONAL,
7742            usec            [2] Microseconds OPTIONAL,
7743            seq-number      [3] UInt32 OPTIONAL,
7744            s-address       [4] HostAddress,
7745            r-address       [5] HostAddress OPTIONAL
7746    }
7747
7748    KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
7749            pvno            [0] INTEGER (5),
7750            msg-type        [1] INTEGER (21),
7751                            -- NOTE: there is no [2] tag
7752            enc-part        [3] EncryptedData -- EncKrbPrivPart
7753    }
7754
7755    EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
7756            user-data       [0] OCTET STRING,
7757            timestamp       [1] KerberosTime OPTIONAL,
7758            usec            [2] Microseconds OPTIONAL,
7759            seq-number      [3] UInt32 OPTIONAL,
7760            s-address       [4] HostAddress -- sender's addr --,
7761            r-address       [5] HostAddress OPTIONAL -- recip's addr
7762    }
7763
7764    KRB-CRED        ::= [APPLICATION 22] SEQUENCE {
7765            pvno            [0] INTEGER (5),
7766            msg-type        [1] INTEGER (22),
7767            tickets         [2] SEQUENCE OF Ticket,
7768            enc-part        [3] EncryptedData -- EncKrbCredPart
7769    }
7770
7771    EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
7772            ticket-info     [0] SEQUENCE OF KrbCredInfo,
7773            nonce           [1] UInt32 OPTIONAL,
7774            timestamp       [2] KerberosTime OPTIONAL,
7775            usec            [3] Microseconds OPTIONAL,
7776            s-address       [4] HostAddress OPTIONAL,
7777            r-address       [5] HostAddress OPTIONAL
7778    }
7779
7780    KrbCredInfo     ::= SEQUENCE {
7781            key             [0] EncryptionKey,
7782            prealm          [1] Realm OPTIONAL,
7783            pname           [2] PrincipalName OPTIONAL,
7784            flags           [3] TicketFlags OPTIONAL,
7785
7786
7787
7788 September 2004                                                [Page 130]\f
7789
7790
7791
7792
7793
7794 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
7795
7796
7797            authtime        [4] KerberosTime OPTIONAL,
7798            starttime       [5] KerberosTime OPTIONAL,
7799            endtime         [6] KerberosTime OPTIONAL,
7800            renew-till      [7] KerberosTime OPTIONAL,
7801            srealm          [8] Realm OPTIONAL,
7802            sname           [9] PrincipalName OPTIONAL,
7803            caddr           [10] HostAddresses OPTIONAL
7804    }
7805
7806    KRB-ERROR       ::= [APPLICATION 30] SEQUENCE {
7807            pvno            [0] INTEGER (5),
7808            msg-type        [1] INTEGER (30),
7809            ctime           [2] KerberosTime OPTIONAL,
7810            cusec           [3] Microseconds OPTIONAL,
7811            stime           [4] KerberosTime,
7812            susec           [5] Microseconds,
7813            error-code      [6] Int32,
7814            crealm          [7] Realm OPTIONAL,
7815            cname           [8] PrincipalName OPTIONAL,
7816            realm           [9] Realm -- service realm --,
7817            sname           [10] PrincipalName -- service name --,
7818            e-text          [11] KerberosString OPTIONAL,
7819            e-data          [12] OCTET STRING OPTIONAL
7820    }
7821
7822    METHOD-DATA     ::= SEQUENCE OF PA-DATA
7823
7824    TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
7825            data-type       [0] INTEGER,
7826            data-value      [1] OCTET STRING OPTIONAL
7827    }
7828
7829    -- preauth stuff follows
7830
7831    PA-ENC-TIMESTAMP        ::= EncryptedData -- PA-ENC-TS-ENC
7832
7833    PA-ENC-TS-ENC           ::= SEQUENCE {
7834            patimestamp     [0] KerberosTime -- client's time --,
7835            pausec          [1] Microseconds OPTIONAL
7836    }
7837
7838    ETYPE-INFO-ENTRY        ::= SEQUENCE {
7839            etype           [0] Int32,
7840            salt            [1] OCTET STRING OPTIONAL
7841    }
7842
7843    ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
7844
7845
7846
7847
7848 September 2004                                                [Page 131]\f
7849
7850
7851
7852
7853
7854 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
7855
7856
7857    ETYPE-INFO2-ENTRY       ::= SEQUENCE {
7858            etype           [0] Int32,
7859            salt            [1] KerberosString OPTIONAL,
7860            s2kparams       [2] OCTET STRING OPTIONAL
7861    }
7862
7863    ETYPE-INFO2             ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY
7864
7865    AD-IF-RELEVANT          ::= AuthorizationData
7866
7867    AD-KDCIssued            ::= SEQUENCE {
7868            ad-checksum     [0] Checksum,
7869            i-realm         [1] Realm OPTIONAL,
7870            i-sname         [2] PrincipalName OPTIONAL,
7871            elements        [3] AuthorizationData
7872    }
7873
7874    AD-AND-OR               ::= SEQUENCE {
7875            condition-count [0] INTEGER,
7876            elements        [1] AuthorizationData
7877    }
7878
7879    AD-MANDATORY-FOR-KDC    ::= AuthorizationData
7880
7881    END
7882
7883 B. Changes since RFC-1510
7884
7885    This document replaces RFC-1510 and clarifies specification of items
7886    that were not completely specified. Where changes to recommended
7887    implementation choices were made, or where new options were added,
7888    those changes are described within the document and listed in this
7889    section. More significantly, "Specification 2" in section 8 changes
7890    the required encryption and checksum methods to bring them in line
7891    with the best current practices and to deprecate methods that are no
7892    longer considered sufficiently strong.
7893
7894    Discussion was added to section 1 regarding the ability to rely on
7895    the KDC to check the transited field, and on the inclusion of a flag
7896    in a ticket indicating that this check has occurred. This is a new
7897    capability not present in RFC1510. Pre-existing implementations may
7898    ignore or not set this flag without negative security implications.
7899
7900    The definition of the secret key says that in the case of a user the
7901    key may be derived from a password. In 1510, it said that the key was
7902    derived from the password. This change was made to accommodate
7903    situations where the user key might be stored on a smart-card, or
7904    otherwise obtained independent of a password.
7905
7906
7907
7908 September 2004                                                [Page 132]\f
7909
7910
7911
7912
7913
7914 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
7915
7916
7917    The introduction mentions the use of public key cryptography for
7918    initial authentication in Kerberos by reference. RFC1510 did not
7919    include such a reference.
7920
7921    Section 1.2 was added to explain that while Kerberos provides
7922    authentication of a named principal, it is still the responsibility
7923    of the application to ensure that the authenticated name is the
7924    entity with which the application wishes to communicate.
7925
7926    Discussion of extensibility has been added to the introduction.
7927
7928    Discussion of how extensibility affects ticket flags and KDC options
7929    was added to the introduction of section 2. No changes were made to
7930    existing options and flags specified in RFC1510, though some of the
7931    sections in the specification were renumbered, and text was revised
7932    to make the description and intent of existing options clearer,
7933    especially with respect to the ENC-TKT-IN-SKEY option (now section
7934    2.9.2) which is used for user-to-user authentication.  The new option
7935    and ticket flag transited policy checking (section 2.7) was added.
7936
7937    A warning regarding generation of session keys for application use
7938    was added to section 3, urging the inclusion of key entropy from the
7939    KDC generated session key in the ticket. An example regarding use of
7940    the sub-session key was added to section 3.2.6. Descriptions of the
7941    pa-etype-info, pa-etype-info2, and pa-pw-salt pre-authentication data
7942    items were added. The recommendation for use of pre-authentication
7943    was changed from "may" to "should" and a note was added regarding
7944    known plaintext attacks.
7945
7946    In RFC 1510, section 4 described the database in the KDC. This
7947    discussion was not necessary for interoperability and unnecessarily
7948    constrained implementation. The old section 4 was removed.
7949
7950    The current section 4 was formerly section 6 on encryption and
7951    checksum specifications. The major part of this section was brought
7952    up to date to support new encryption methods, and move to a separate
7953    document. Those few remaining aspects of the encryption and checksum
7954    specification specific to Kerberos are now specified in section 4.
7955
7956    Significant changes were made to the layout of section 5 to clarify
7957    the correct behavior for optional fields. Many of these changes were
7958    made necessary because of improper ASN.1 description in the original
7959    Kerberos specification which left the correct behavior
7960    underspecified. Additionally, the wording in this section was
7961    tightened wherever possible to ensure that implementations conforming
7962    to this specification will be extensible with the addition of new
7963    fields in future specifications.
7964
7965
7966
7967
7968 September 2004                                                [Page 133]\f
7969
7970
7971
7972
7973
7974 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
7975
7976
7977    Text was added describing time_t=0 issues in the ASN.1. Text was also
7978    added, clarifying issues with implementations treating omitted
7979    optional integers as zero. Text was added clarifying behavior for
7980    optional SEQUENCE or SEQUENCE OF that may be empty. Discussion was
7981    added regarding sequence numbers and behavior of some
7982    implementations, including "zero" behavior and negative numbers. A
7983    compatibility note was added regarding the unconditional sending of
7984    EncTGSRepPart regardless of the enclosing reply type. Minor changes
7985    were made to the description of the HostAddresses type. Integer types
7986    were constrained. KerberosString was defined as a (significantly)
7987    constrained GeneralString. KerberosFlags was defined to reflect
7988    existing implementation behavior that departs from the definition in
7989    RFC 1510. The transited-policy-checked(12) and the ok-as-delegate(13)
7990    ticket flags were added. The disable-transited-check(26) KDC option
7991    was added.
7992
7993    Descriptions of commonly implemented PA-DATA were added to section 5.
7994    The description of KRB-SAFE has been updated to note the existing
7995    implementation behavior of double-encoding.
7996
7997    There were two definitions of METHOD-DATA in RFC 1510. The second
7998    one, intended for use with KRB_AP_ERR_METHOD was removed leaving the
7999    SEQUENCE OF PA-DATA definition.
8000
8001    Section 7, naming constraints, from RFC1510 was moved to section 6.
8002
8003    Words were added describing the convention that domain based realm
8004    names for newly created realms should be specified as upper case.
8005    This recommendation does not make lower case realm names illegal.
8006    Words were added highlighting that the slash separated components in
8007    the X500 style of realm names is consistent with existing RFC1510
8008    based implementations, but that it conflicts with the general
8009    recommendation of X.500 name representation specified in RFC2253.
8010
8011    Section 8, network transport, constants and defined values, from
8012    RFC1510 was moved to section 7.  Since RFC1510, the definition of the
8013    TCP transport for Kerberos messages was added, and the encryption and
8014    checksum number assignments have been moved into a separate document.
8015
8016    "Specification 2" in section 8 of the current document changes the
8017    required encryption and checksum methods to bring them in line with
8018    the best current practices and to deprecate methods that are no
8019    longer considered sufficiently strong.
8020
8021    Two new sections, on IANA considerations and security considerations
8022    were added.
8023
8024    The pseudo-code has been removed from the appendix. The pseudo-code
8025
8026
8027
8028 September 2004                                                [Page 134]\f
8029
8030
8031
8032
8033
8034 Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-07.txt DRAFT
8035
8036
8037    was sometimes misinterpreted to limit implementation choices and in
8038    RFC 1510, it was not always consistent with the words in the
8039    specification. Effort was made to clear up any ambiguities in the
8040    specification, rather than to rely on the pseudo-code.
8041
8042    An appendix was added containing the complete ASN.1 module drawn from
8043    the discussion in section 5 of the current document.
8044
8045 END NOTES
8046
8047    (*TM) Project Athena, Athena, and Kerberos are trademarks of the
8048    Massachusetts Institute of Technology (MIT).
8049
8050
8051
8052
8053
8054
8055
8056
8057
8058
8059
8060
8061
8062
8063
8064
8065
8066
8067
8068
8069
8070
8071
8072
8073
8074
8075
8076
8077
8078
8079
8080
8081
8082
8083
8084
8085
8086
8087
8088 September 2004                                                [Page 135]
8089