doc/standardisation/draft-ietf-krb-wg-kerberos-clarifications-06.txt

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