2 INTERNET-DRAFT Clifford Neuman
9 Expires 2 September, 2003
11 The Kerberos Network Authentication Service (V5)
12 draft-ietf-krb-wg-kerberos-clarifications-03.txt
16 This document is an Internet-Draft and is in full conformance with
17 all provisions of Section 10 of RFC 2026. Internet-Drafts are working
18 documents of the Internet Engineering Task Force (IETF), its areas,
19 and its working groups. Note that other groups may also distribute
20 working documents as Internet-Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 To learn the current status of any Internet-Draft, please check the
34 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
35 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
36 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
38 The distribution of this memo is unlimited. It is filed as draft-
39 ietf-krb-wg-kerberos-clarifications-03.txt, and expires 2 September
40 2003. Please send comments to: ietf-krb-wg@anl.gov
44 This document provides an overview and specification of Version 5 of
45 the Kerberos protocol, and updates RFC1510 to clarify aspects of the
46 protocol and its intended use that require more detailed or clearer
47 explanation than was provided in RFC1510. This document is intended
48 to provide a detailed description of the protocol, suitable for
49 implementation, together with descriptions of the appropriate use of
50 protocol messages and fields within those messages.
60 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
63 This document contains a subset of the changes considered and
64 discussed in the Kerberos working group and is intended as an interim
65 description of Kerberos. Additional changes to the Kerberos protocol
66 have been proposed and will appear in a subsequent extensions
69 This document is not intended to describe Kerberos to the end user,
70 system administrator, or application developer. Higher level papers
71 describing Version 5 of the Kerberos system [NT94] and documenting
72 version 4 [SNS88], are available elsewhere.
76 This INTERNET-DRAFT describes the concepts and model upon which the
77 Kerberos network authentication system is based. It also specifies
78 Version 5 of the Kerberos protocol.
80 The motivations, goals, assumptions, and rationale behind most design
81 decisions are treated cursorily; they are more fully described in a
82 paper available in IEEE communications [NT94] and earlier in the
83 Kerberos portion of the Athena Technical Plan [MNSS87]. The protocols
84 have been a proposed standard and are being considered for
85 advancement for draft standard through the IETF standard process.
86 Comments are encouraged on the presentation, but only minor
87 refinements to the protocol as implemented or extensions that fit
88 within current protocol framework will be considered at this time.
90 Requests for addition to an electronic mailing list for discussion of
91 Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-
92 request@MIT.EDU. This mailing list is gatewayed onto the Usenet as
93 the group comp.protocols.kerberos. Requests for further information,
94 including documents and code availability, may be sent to info-
99 The Kerberos model is based in part on Needham and Schroeder's
100 trusted third-party authentication protocol [NS78] and on
101 modifications suggested by Denning and Sacco [DS81]. The original
102 design and implementation of Kerberos Versions 1 through 4 was the
103 work of two former Project Athena staff members, Steve Miller of
104 Digital Equipment Corporation and Clifford Neuman (now at the
105 Information Sciences Institute of the University of Southern
106 California), along with Jerome Saltzer, Technical Director of Project
107 Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other
108 members of Project Athena have also contributed to the work on
120 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
123 Version 5 of the Kerberos protocol (described in this document) has
124 evolved from Version 4 based on new requirements and desires for
125 features not available in Version 4. The design of Version 5 of the
126 Kerberos protocol was led by Clifford Neuman and John Kohl with much
127 input from the community. The development of the MIT reference
128 implementation was led at MIT by John Kohl and Theodore Ts'o, with
129 help and contributed code from many others. Since RFC1510 was issued,
130 extensions and revisions to the protocol have been proposed by many
131 individuals. Some of these proposals are reflected in this document.
132 Where such changes involved significant effort, the document cites
133 the contribution of the proposer.
135 Reference implementations of both version 4 and version 5 of Kerberos
136 are publicly available and commercial implementations have been
137 developed and are widely used. Details on the differences between
138 Kerberos Versions 4 and 5 can be found in [KNT94].
180 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
183 T
\bTa
\bab
\bbl
\ble
\be o
\bof
\bf C
\bCo
\bon
\bnt
\bte
\ben
\bnt
\bts
\bs
186 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 7
187 1.1. Cross-realm operation . . . . . . . . . . . . . . . . . . . . . 9
188 1.2. Choosing a principal with which to communicate . . . . . . . . 10
189 1.3. Authorization . . . . . . . . . . . . . . . . . . . . . . . . . 11
190 1.4. Extending Kerberos Without Breaking Interoperability . . . . . 11
191 1.4.1. Compatibility with RFC 1510 . . . . . . . . . . . . . . . . . 12
192 1.4.2. Sending Extensible Messages . . . . . . . . . . . . . . . . . 13
193 1.5. Environmental assumptions . . . . . . . . . . . . . . . . . . . 13
194 1.6. Glossary of terms . . . . . . . . . . . . . . . . . . . . . . . 14
195 2. Ticket flag uses and requests . . . . . . . . . . . . . . . . . . 16
196 2.1. Initial, pre-authenticated, and hardware authenticated
197 tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
198 2.2. Invalid tickets . . . . . . . . . . . . . . . . . . . . . . . . 17
199 2.3. Renewable tickets . . . . . . . . . . . . . . . . . . . . . . . 18
200 2.4. Postdated tickets . . . . . . . . . . . . . . . . . . . . . . . 18
201 2.5. Proxiable and proxy tickets . . . . . . . . . . . . . . . . . . 19
202 2.6. Forwardable tickets . . . . . . . . . . . . . . . . . . . . . . 20
203 2.7. Transited Policy Checking . . . . . . . . . . . . . . . . . . . 21
204 2.8. OK as Delegate . . . . . . . . . . . . . . . . . . . . . . . . 21
205 2.9. Other KDC options . . . . . . . . . . . . . . . . . . . . . . . 22
206 2.9.1. Renewable-OK . . . . . . . . . . . . . . . . . . . . . . . . 22
207 2.9.2. ENC-TKT-IN-SKEY . . . . . . . . . . . . . . . . . . . . . . . 22
208 2.9.3. Passwordless Hardware Authentication . . . . . . . . . . . . 22
209 3. Message Exchanges . . . . . . . . . . . . . . . . . . . . . . . . 23
210 3.1. The Authentication Service Exchange . . . . . . . . . . . . . . 23
211 3.1.1. Generation of KRB_AS_REQ message . . . . . . . . . . . . . . 24
212 3.1.2. Receipt of KRB_AS_REQ message . . . . . . . . . . . . . . . . 24
213 3.1.3. Generation of KRB_AS_REP message . . . . . . . . . . . . . . 25
214 3.1.4. Generation of KRB_ERROR message . . . . . . . . . . . . . . . 27
215 3.1.5. Receipt of KRB_AS_REP message . . . . . . . . . . . . . . . . 28
216 3.1.6. Receipt of KRB_ERROR message . . . . . . . . . . . . . . . . 29
217 3.2. The Client/Server Authentication Exchange . . . . . . . . . . . 29
218 3.2.1. The KRB_AP_REQ message . . . . . . . . . . . . . . . . . . . 29
219 3.2.2. Generation of a KRB_AP_REQ message . . . . . . . . . . . . . 29
220 3.2.3. Receipt of KRB_AP_REQ message . . . . . . . . . . . . . . . . 30
221 3.2.4. Generation of a KRB_AP_REP message . . . . . . . . . . . . . 32
222 3.2.5. Receipt of KRB_AP_REP message . . . . . . . . . . . . . . . . 33
223 3.2.6. Using the encryption key . . . . . . . . . . . . . . . . . . 33
224 3.3. The Ticket-Granting Service (TGS) Exchange . . . . . . . . . . 34
225 3.3.1. Generation of KRB_TGS_REQ message . . . . . . . . . . . . . . 35
226 3.3.2. Receipt of KRB_TGS_REQ message . . . . . . . . . . . . . . . 37
227 3.3.3. Generation of KRB_TGS_REP message . . . . . . . . . . . . . . 37
228 3.3.3.1. Checking for revoked tickets . . . . . . . . . . . . . . . 40
229 3.3.3.2. Encoding the transited field . . . . . . . . . . . . . . . 40
230 3.3.4. Receipt of KRB_TGS_REP message . . . . . . . . . . . . . . . 42
240 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
243 3.4. The KRB_SAFE Exchange . . . . . . . . . . . . . . . . . . . . . 42
244 3.4.1. Generation of a KRB_SAFE message . . . . . . . . . . . . . . 42
245 3.4.2. Receipt of KRB_SAFE message . . . . . . . . . . . . . . . . . 43
246 3.5. The KRB_PRIV Exchange . . . . . . . . . . . . . . . . . . . . . 44
247 3.5.1. Generation of a KRB_PRIV message . . . . . . . . . . . . . . 44
248 3.5.2. Receipt of KRB_PRIV message . . . . . . . . . . . . . . . . . 44
249 3.6. The KRB_CRED Exchange . . . . . . . . . . . . . . . . . . . . . 45
250 3.6.1. Generation of a KRB_CRED message . . . . . . . . . . . . . . 45
251 3.6.2. Receipt of KRB_CRED message . . . . . . . . . . . . . . . . . 46
252 3.7. User to User Authentication Exchanges . . . . . . . . . . . . . 46
253 4. Encryption and Checksum Specifications . . . . . . . . . . . . . 48
254 5. Message Specifications . . . . . . . . . . . . . . . . . . . . . 49
255 5.1. Specific Compatibility Notes on ASN.1 . . . . . . . . . . . . . 51
256 5.1.1. ASN.1 Distinguished Encoding Rules . . . . . . . . . . . . . 51
257 5.1.2. Optional Integer Fields . . . . . . . . . . . . . . . . . . . 51
258 5.1.3. Empty SEQUENCE OF Types . . . . . . . . . . . . . . . . . . . 51
259 5.1.4. Unrecognized Tag Numbers . . . . . . . . . . . . . . . . . . 52
260 5.1.5. Tag Numbers Greater Than 30 . . . . . . . . . . . . . . . . . 52
261 5.2. Basic Kerberos Types . . . . . . . . . . . . . . . . . . . . . 52
262 5.2.1. KerberosString . . . . . . . . . . . . . . . . . . . . . . . 52
263 5.2.2. Realm and PrincipalName . . . . . . . . . . . . . . . . . . . 54
264 5.2.3. KerberosTime . . . . . . . . . . . . . . . . . . . . . . . . 54
265 5.2.4. Constrained Integer types . . . . . . . . . . . . . . . . . . 55
266 5.2.5. HostAddress and HostAddresses . . . . . . . . . . . . . . . . 55
267 5.2.6. AuthorizationData . . . . . . . . . . . . . . . . . . . . . . 56
268 5.2.6.1. IF-RELEVANT . . . . . . . . . . . . . . . . . . . . . . . . 57
269 5.2.6.2. KDCIssued . . . . . . . . . . . . . . . . . . . . . . . . . 57
270 5.2.6.3. AND-OR . . . . . . . . . . . . . . . . . . . . . . . . . . 59
271 5.2.6.4. MANDATORY-FOR-KDC . . . . . . . . . . . . . . . . . . . . . 59
272 5.2.7. PA-DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
273 5.2.7.1. PA-TGS-REQ . . . . . . . . . . . . . . . . . . . . . . . . 60
274 5.2.7.2. Encrypted Timestamp Pre-authentication . . . . . . . . . . 60
275 5.2.7.3. PA-PW-SALT . . . . . . . . . . . . . . . . . . . . . . . . 61
276 5.2.7.4. PA-ETYPE-INFO . . . . . . . . . . . . . . . . . . . . . . . 61
277 5.2.7.5. PA-ETYPE-INFO2 . . . . . . . . . . . . . . . . . . . . . . 62
278 5.2.8. KerberosFlags . . . . . . . . . . . . . . . . . . . . . . . . 63
279 5.2.9. Cryptosystem-related Types . . . . . . . . . . . . . . . . . 64
280 5.3. Tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
281 5.4. Specifications for the AS and TGS exchanges . . . . . . . . . . 73
282 5.4.1. KRB_KDC_REQ definition . . . . . . . . . . . . . . . . . . . 73
283 5.4.2. KRB_KDC_REP definition . . . . . . . . . . . . . . . . . . . 80
284 5.5. Client/Server (CS) message specifications . . . . . . . . . . . 84
285 5.5.1. KRB_AP_REQ definition . . . . . . . . . . . . . . . . . . . . 84
286 5.5.2. KRB_AP_REP definition . . . . . . . . . . . . . . . . . . . . 87
287 5.5.3. Error message reply . . . . . . . . . . . . . . . . . . . . . 88
288 5.6. KRB_SAFE message specification . . . . . . . . . . . . . . . . 88
289 5.6.1. KRB_SAFE definition . . . . . . . . . . . . . . . . . . . . . 88
290 5.7. KRB_PRIV message specification . . . . . . . . . . . . . . . . 90
300 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
303 5.7.1. KRB_PRIV definition . . . . . . . . . . . . . . . . . . . . . 90
304 5.8. KRB_CRED message specification . . . . . . . . . . . . . . . . 91
305 5.8.1. KRB_CRED definition . . . . . . . . . . . . . . . . . . . . . 91
306 5.9. Error message specification . . . . . . . . . . . . . . . . . . 93
307 5.9.1. KRB_ERROR definition . . . . . . . . . . . . . . . . . . . . 93
308 5.10. Application Tag Numbers . . . . . . . . . . . . . . . . . . . 95
309 6. Naming Constraints . . . . . . . . . . . . . . . . . . . . . . . 96
310 6.1. Realm Names . . . . . . . . . . . . . . . . . . . . . . . . . . 96
311 6.2. Principal Names . . . . . . . . . . . . . . . . . . . . . . . . 98
312 6.2.1. Name of server principals . . . . . . . . . . . . . . . . . . 99
313 7. Constants and other defined values . . . . . . . . . . . . . . . 100
314 7.1. Host address types . . . . . . . . . . . . . . . . . . . . . . 100
315 7.2. KDC messaging - IP Transports . . . . . . . . . . . . . . . . . 101
316 7.2.1. UDP/IP transport . . . . . . . . . . . . . . . . . . . . . . 101
317 7.2.2. TCP/IP transport . . . . . . . . . . . . . . . . . . . . . . 101
318 7.2.3. KDC Discovery on IP Networks . . . . . . . . . . . . . . . . 103
319 7.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names . . . . 103
320 7.2.3.2. Specifying KDC Location information with DNS SRV
321 records . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
322 7.2.3.3. KDC Discovery for Domain Style Realm Names on IP
323 Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
324 7.3. Name of the TGS . . . . . . . . . . . . . . . . . . . . . . . . 104
325 7.4. OID arc for KerberosV5 . . . . . . . . . . . . . . . . . . . . 104
326 7.5. Protocol constants and associated values . . . . . . . . . . . 104
327 7.5.1. Key usage numbers . . . . . . . . . . . . . . . . . . . . . . 105
328 7.5.2. PreAuthentication Data Types . . . . . . . . . . . . . . . . 106
329 7.5.3. Address Types . . . . . . . . . . . . . . . . . . . . . . . . 107
330 7.5.4. Authorization Data Types . . . . . . . . . . . . . . . . . . 107
331 7.5.5. Transited Encoding Types . . . . . . . . . . . . . . . . . . 107
332 7.5.6. Protocol Version Number . . . . . . . . . . . . . . . . . . . 107
333 7.5.7. Kerberos Message Types . . . . . . . . . . . . . . . . . . . 108
334 7.5.8. Name Types . . . . . . . . . . . . . . . . . . . . . . . . . 108
335 7.5.9. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 108
336 8. Interoperability requirements . . . . . . . . . . . . . . . . . . 110
337 8.1. Specification 2 . . . . . . . . . . . . . . . . . . . . . . . . 110
338 8.2. Recommended KDC values . . . . . . . . . . . . . . . . . . . . 113
339 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . . . 113
340 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 113
341 11. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 117
342 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 117
343 13. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
344 A. ASN.1 module . . . . . . . . . . . . . . . . . . . . . . . . . . 120
345 B. Changes since RFC-1510 . . . . . . . . . . . . . . . . . . . . . 129
346 END NOTES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
360 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
365 Kerberos provides a means of verifying the identities of principals,
366 (e.g. a workstation user or a network server) on an open
367 (unprotected) network. This is accomplished without relying on
368 assertions by the host operating system, without basing trust on host
369 addresses, without requiring physical security of all the hosts on
370 the network, and under the assumption that packets traveling along
371 the network can be read, modified, and inserted at will[1]. Kerberos
372 performs authentication under these conditions as a trusted third-
373 party authentication service by using conventional (shared secret key
374 [2]) cryptography. Kerberos extensions (outside the scope of this
375 document) can provide for the use of public key cryptography during
376 certain phases of the authentication protocol [@RFCE: if PKINIT
377 advances concurrently include reference to the RFC here]. Such
378 extensions support Kerberos authentication for users registered with
379 public key certification authorities and provide certain benefits of
380 public key cryptography in situations where they are needed.
382 The basic Kerberos authentication process proceeds as follows: A
383 client sends a request to the authentication server (AS) requesting
384 "credentials" for a given server. The AS responds with these
385 credentials, encrypted in the client's key. The credentials consist
386 of a "ticket" for the server and a temporary encryption key (often
387 called a "session key"). The client transmits the ticket (which
388 contains the client's identity and a copy of the session key, all
389 encrypted in the server's key) to the server. The session key (now
390 shared by the client and server) is used to authenticate the client,
391 and may optionally be used to authenticate the server. It may also be
392 used to encrypt further communication between the two parties or to
393 exchange a separate sub-session key to be used to encrypt further
396 Implementation of the basic protocol consists of one or more
397 authentication servers running on physically secure hosts. The
398 authentication servers maintain a database of principals (i.e., users
399 and servers) and their secret keys. Code libraries provide encryption
400 and implement the Kerberos protocol. In order to add authentication
401 to its transactions, a typical network application adds one or two
402 calls to the Kerberos library directly or through the Generic
403 Security Services Application Programming Interface, GSSAPI,
404 described in separate document [ref to GSSAPI RFC]. These calls
405 result in the transmission of the necessary messages to achieve
408 The Kerberos protocol consists of several sub-protocols (or
409 exchanges). There are two basic methods by which a client can ask a
410 Kerberos server for credentials. In the first approach, the client
420 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
423 sends a cleartext request for a ticket for the desired server to the
424 AS. The reply is sent encrypted in the client's secret key. Usually
425 this request is for a ticket-granting ticket (TGT) which can later be
426 used with the ticket-granting server (TGS). In the second method,
427 the client sends a request to the TGS. The client uses the TGT to
428 authenticate itself to the TGS in the same manner as if it were
429 contacting any other application server that requires Kerberos
430 authentication. The reply is encrypted in the session key from the
431 TGT. Though the protocol specification describes the AS and the TGS
432 as separate servers, they are implemented in practice as different
433 protocol entry points within a single Kerberos server.
435 Once obtained, credentials may be used to verify the identity of the
436 principals in a transaction, to ensure the integrity of messages
437 exchanged between them, or to preserve privacy of the messages. The
438 application is free to choose whatever protection may be necessary.
440 To verify the identities of the principals in a transaction, the
441 client transmits the ticket to the application server. Since the
442 ticket is sent "in the clear" (parts of it are encrypted, but this
443 encryption doesn't thwart replay) and might be intercepted and reused
444 by an attacker, additional information is sent to prove that the
445 message originated with the principal to whom the ticket was issued.
446 This information (called the authenticator) is encrypted in the
447 session key, and includes a timestamp. The timestamp proves that the
448 message was recently generated and is not a replay. Encrypting the
449 authenticator in the session key proves that it was generated by a
450 party possessing the session key. Since no one except the requesting
451 principal and the server know the session key (it is never sent over
452 the network in the clear) this guarantees the identity of the client.
454 The integrity of the messages exchanged between principals can also
455 be guaranteed using the session key (passed in the ticket and
456 contained in the credentials). This approach provides detection of
457 both replay attacks and message stream modification attacks. It is
458 accomplished by generating and transmitting a collision-proof
459 checksum (elsewhere called a hash or digest function) of the client's
460 message, keyed with the session key. Privacy and integrity of the
461 messages exchanged between principals can be secured by encrypting
462 the data to be passed using the session key contained in the ticket
463 or the sub-session key found in the authenticator.
465 The authentication exchanges mentioned above require read-only access
466 to the Kerberos database. Sometimes, however, the entries in the
467 database must be modified, such as when adding new principals or
468 changing a principal's key. This is done using a protocol between a
469 client and a third Kerberos server, the Kerberos Administration
470 Server (KADM). There is also a protocol for maintaining multiple
480 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
483 copies of the Kerberos database. Neither of these protocols are
484 described in this document.
486 1.1. Cross-realm operation
488 The Kerberos protocol is designed to operate across organizational
489 boundaries. A client in one organization can be authenticated to a
490 server in another. Each organization wishing to run a Kerberos server
491 establishes its own "realm". The name of the realm in which a client
492 is registered is part of the client's name, and can be used by the
493 end-service to decide whether to honor a request.
495 By establishing "inter-realm" keys, the administrators of two realms
496 can allow a client authenticated in the local realm to prove its
497 identity to servers in other realms[3]. The exchange of inter-realm
498 keys (a separate key may be used for each direction) registers the
499 ticket-granting service of each realm as a principal in the other
500 realm. A client is then able to obtain a ticket-granting ticket for
501 the remote realm's ticket-granting service from its local realm. When
502 that ticket-granting ticket is used, the remote ticket-granting
503 service uses the inter-realm key (which usually differs from its own
504 normal TGS key) to decrypt the ticket-granting ticket, and is thus
505 certain that it was issued by the client's own TGS. Tickets issued by
506 the remote ticket-granting service will indicate to the end-service
507 that the client was authenticated from another realm.
509 A realm is said to communicate with another realm if the two realms
510 share an inter-realm key, or if the local realm shares an inter-realm
511 key with an intermediate realm that communicates with the remote
512 realm. An authentication path is the sequence of intermediate realms
513 that are transited in communicating from one realm to another.
515 Realms may be organized hierarchically. Each realm shares a key with
516 its parent and a different key with each child. If an inter-realm key
517 is not directly shared by two realms, the hierarchical organization
518 allows an authentication path to be easily constructed. If a
519 hierarchical organization is not used, it may be necessary to consult
520 a database in order to construct an authentication path between
523 Although realms are typically hierarchical, intermediate realms may
524 be bypassed to achieve cross-realm authentication through alternate
525 authentication paths (these might be established to make
526 communication between two realms more efficient). It is important for
527 the end-service to know which realms were transited when deciding how
528 much faith to place in the authentication process. To facilitate this
529 decision, a field in each ticket contains the names of the realms
530 that were involved in authenticating the client.
540 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
543 The application server is ultimately responsible for accepting or
544 rejecting authentication and SHOULD check the transited field. The
545 application server may choose to rely on the KDC for the application
546 server's realm to check the transited field. The application server's
547 KDC will set the TRANSITED-POLICY-CHECKED flag in this case. The KDCs
548 for intermediate realms may also check the transited field as they
549 issue ticket-granting tickets for other realms, but they are
550 encouraged not to do so. A client may request that the KDCs not check
551 the transited field by setting the DISABLE-TRANSITED-CHECK flag. KDCs
552 are encouraged but not required to honor this flag.
554 1.2. Choosing a principal with which to communicate
556 The Kerberos protocol provides the means for verifying (subject to
557 the assumptions in 1.5) that the entity with which one communicates
558 is the same entity that was registered with the KDC using the claimed
559 identity (principal name). It is still necessary to determine whether
560 that identity corresponds to the entity with which one intends to
563 When appropriate data has been exchanged in advance, this
564 determination may be performed syntactically by the application based
565 on the application protocol specification, information provided by
566 the user, and configuration files. For example, the server principal
567 name (including realm) for a telnet server might be derived from the
568 user specified host name (from the telnet command line), the "host/"
569 prefix specified in the application protocol specification, and a
570 mapping to a Kerberos realm derived syntactically from the domain
571 part of the specified hostname and information from the local
572 Kerberos realms database.
574 One can also rely on trusted third parties to make this
575 determination, but only when the data obtained from the third party
576 is suitably integrity protected while resident on the third party
577 server and when transmitted. Thus, for example, one should not rely
578 on an unprotected domain name system record to map a host alias to
579 the primary name of a server, accepting the primary name as the party
580 one intends to contact, since an attacker can modify the mapping and
581 impersonate the party with which one intended to communicate.
583 Implementations of Kerberos and protocols based on Kerberos MUST NOT
584 use insecure DNS queries to canonicalize the hostname components of
585 the service principal names. In an environment without secure name
586 service, application authors MAY append a statically configured
587 domain name to unqualified hostnames before passing the name to the
588 security mechanisms, but should do no more than that. Secure name
589 service facilities, if available, might be trusted for hostname
590 canonicalization, but such canonicalization by the client SHOULD NOT
600 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
603 be required by an KDC implementation.
605 Implementation note: Many current implementations do some degree of
606 canonicalization of the provided service name, often using DNS even
607 though it creates security problems. However there is no consistency
608 among implementations about whether the service name is case folded
609 to lower case or whether reverse resolution is used. To maximize
610 interoperability and security, applications SHOULD provide security
611 mechanisms with names which result from folding the user-entered name
612 to lower case, without performing any other modifications or
617 As an authentication service, Kerberos provides a means of verifying
618 the identity of principals on a network. Authentication is usually
619 useful primarily as a first step in the process of authorization,
620 determining whether a client may use a service, which objects the
621 client is allowed to access, and the type of access allowed for each.
622 Kerberos does not, by itself, provide authorization. Possession of a
623 client ticket for a service provides only for authentication of the
624 client to that service, and in the absence of a separate
625 authorization procedure, it should not be considered by an
626 application as authorizing the use of that service.
628 Such separate authorization methods MAY be implemented as application
629 specific access control functions and may utilize files on the
630 application server, or on separately issued authorization credentials
631 such as those based on proxies [Neu93], or on other authorization
632 services. Separately authenticated authorization credentials MAY be
633 embedded in a ticket's authorization data when encapsulated by the
634 KDC-issued authorization data element.
636 Applications should not accept the mere issuance of a service ticket
637 by the Kerberos server (even by a modified Kerberos server) as
638 granting authority to use the service, since such applications may
639 become vulnerable to the bypass of this authorization check in an
640 environment if they interoperate with other KDCs or where other
641 options for application authentication (e.g. the PKTAPP proposal)
644 1.4. Extending Kerberos Without Breaking Interoperability
646 As the deployed base of Kerberos implementations grows, extending
647 Kerberos becomes more important. Unfortunately some extensions to the
648 existing Kerberos protocol create interoperability issues because of
649 uncertainty regarding the treatment of certain extensibility options
650 by some implementations. This section includes guidelines that will
660 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
663 enable future implementations to maintain interoperability.
665 Kerberos provides a general mechanism for protocol extensibility.
666 Some protocol messages contain typed holes -- sub-messages that
667 contain an octet-string along with an integer that defines how to
668 interpret the octet-string. The integer types are registered
669 centrally, but can be used both for vendor extensions and for
670 extensions standardized through the IETF.
672 1.4.1. Compatibility with RFC 1510
674 It is important to note that existing Kerberos message formats can
675 not be readily extended by adding fields to the ASN.1 types. Sending
676 additional fields often results in the entire message being discarded
677 without an error indication. Future versions of this specification
678 will provide guidelines to ensure that ASN.1 fields can be added
679 without creating an interoperability problem.
681 In the meantime, all new or modified implementations of Kerberos that
682 receive an unknown message extension SHOULD preserve the encoding of
683 the extension but otherwise ignore the presence of the extension.
684 Recipients MUST NOT decline a request simply because an extension is
687 There is one exception to this rule. If an unknown authorization data
688 element type is received by a server other than the ticket granting
689 service either in an AP-REQ or in a ticket contained in an AP-REQ,
690 then authentication MUST fail. One of the primary uses of
691 authorization data is to restrict the use of the ticket. If the
692 service cannot determine whether the restriction applies to that
693 service then a security weakness may result if the ticket can be used
694 for that service. Authorization elements that are optional SHOULD be
695 enclosed in the AD-IF-RELEVANT element.
697 The ticket granting service MUST ignore but propagate to derivative
698 tickets any unknown authorization data types, unless those data types
699 are embedded in a MANDATORY-FOR-KDC element, in which case the
700 request will be rejected. This behavior is appropriate because
701 requiring that the ticket granting service understand unknown
702 authorization data types would require that KDC software be upgraded
703 to understand new application-level restrictions before applications
704 used these restrictions, decreasing the utility of authorization data
705 as a mechanism for restricting the use of tickets. No security
706 problem is created because services to which the tickets are issued
707 will verify the authorization data.
709 Implementation note: Many RFC 1510 implementations ignore unknown
710 authorization data elements. Depending on these implementations to
720 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
723 honor authorization data restrictions may create a security weakness.
725 1.4.2. Sending Extensible Messages
727 Care must be taken to ensure that old implementations can understand
728 messages sent to them even if they do not understand an extension
729 that is used. Unless the sender knows an extension is supported, the
730 extension cannot change the semantics of the core message or
731 previously defined extensions.
733 For example, an extension including key information necessary to
734 decrypt the encrypted part of a KDC-REP could only be used in
735 situations where the recipient was known to support the extension.
736 Thus when designing such extensions it is important to provide a way
737 for the recipient to notify the sender of support for the extension.
738 For example in the case of an extension that changes the KDC-REP
739 reply key, the client could indicate support for the extension by
740 including a padata element in the AS-REQ sequence. The KDC should
741 only use the extension if this padata element is present in the AS-
742 REQ. Even if policy requires the use of the extension, it is better
743 to return an error indicating that the extension is required than to
744 use the extension when the recipient may not support it; debugging
745 why implementations do not interoperate is easier when errors are
748 1.5. Environmental assumptions
750 Kerberos imposes a few assumptions on the environment in which it can
753 * "Denial of service" attacks are not solved with Kerberos. There
754 are places in the protocols where an intruder can prevent an
755 application from participating in the proper authentication steps.
756 Detection and solution of such attacks (some of which can appear
757 to be not-uncommon "normal" failure modes for the system) is
758 usually best left to the human administrators and users.
760 * Principals MUST keep their secret keys secret. If an intruder
761 somehow steals a principal's key, it will be able to masquerade as
762 that principal or impersonate any server to the legitimate
765 * "Password guessing" attacks are not solved by Kerberos. If a user
766 chooses a poor password, it is possible for an attacker to
767 successfully mount an offline dictionary attack by repeatedly
768 attempting to decrypt, with successive entries from a dictionary,
769 messages obtained which are encrypted under a key derived from the
780 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
783 * Each host on the network MUST have a clock which is "loosely
784 synchronized" to the time of the other hosts; this synchronization
785 is used to reduce the bookkeeping needs of application servers
786 when they do replay detection. The degree of "looseness" can be
787 configured on a per-server basis, but is typically on the order of
788 5 minutes. If the clocks are synchronized over the network, the
789 clock synchronization protocol MUST itself be secured from network
792 * Principal identifiers are not recycled on a short-term basis. A
793 typical mode of access control will use access control lists
794 (ACLs) to grant permissions to particular principals. If a stale
795 ACL entry remains for a deleted principal and the principal
796 identifier is reused, the new principal will inherit rights
797 specified in the stale ACL entry. By not re-using principal
798 identifiers, the danger of inadvertent access is removed.
800 1.6. Glossary of terms
802 Below is a list of terms used throughout this document.
805 Verifying the claimed identity of a principal.
807 Authentication header
808 A record containing a Ticket and an Authenticator to be presented
809 to a server as part of the authentication process.
812 A sequence of intermediate realms transited in the authentication
813 process when communicating from one realm to another.
816 A record containing information that can be shown to have been
817 recently generated using the session key known only by the client
821 The process of determining whether a client may use a service,
822 which objects the client is allowed to access, and the type of
823 access allowed for each.
826 A token that grants the bearer permission to access an object or
827 service. In Kerberos, this might be a ticket whose use is
828 restricted by the contents of the authorization data field, but
829 which lists no network addresses, together with the session key
830 necessary to use the ticket.
840 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
844 The output of an encryption function. Encryption transforms
845 plaintext into ciphertext.
848 A process that makes use of a network service on behalf of a user.
849 Note that in some cases a Server may itself be a client of some
850 other server (e.g. a print server may be a client of a file
854 A ticket plus the secret session key necessary to successfully use
855 that ticket in an authentication exchange.
857 Encryption Type (etype)
858 When associated with encrypted data, an encryption type identifies
859 the algorithm used to encrypt the data and is used to select the
860 appropriate algorithm for decrypting the data. Encryption type
861 tags are communicated in other messages to enumerate algorithms
862 that are desired, supported, preferred, or allowed to be used for
863 encryption of data between parties. This preference is combined
864 with local information and policy to select an algorithm to be
868 Key Distribution Center, a network service that supplies tickets
869 and temporary session keys; or an instance of that service or the
870 host on which it runs. The KDC services both initial ticket and
871 ticket-granting ticket requests. The initial ticket portion is
872 sometimes referred to as the Authentication Server (or service).
873 The ticket-granting ticket portion is sometimes referred to as the
874 ticket-granting server (or service).
877 The name given to the Project Athena's authentication service, the
878 protocol used by that service, or the code used to implement the
879 authentication service. The name is adopted from the three-headed
880 dog which guards Hades.
882 Key Version Number (kvno)
883 A tag associated with encrypted data identifies which key was used
884 for encryption when a long lived key associated with a principal
885 changes over time. It is used during the transition to a new key
886 so that the party decrypting a message can tell whether the data
887 was encrypted using the old or the new key.
890 The input to an encryption function or the output of a decryption
900 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
903 function. Decryption transforms ciphertext into plaintext.
906 A named client or server entity that participates in a network
907 communication, with one name that is considered canonical.
910 The canonical name used to uniquely identify each different
914 To encipher a record containing several fields in such a way that
915 the fields cannot be individually replaced without either
916 knowledge of the encryption key or leaving evidence of tampering.
919 An encryption key shared by a principal and the KDC, distributed
920 outside the bounds of the system, with a long lifetime. In the
921 case of a human user's principal, the secret key MAY be derived
925 A particular Principal which provides a resource to network
926 clients. The server is sometimes referred to as the Application
930 A resource provided to network clients; often provided by more
931 than one server (for example, remote file service).
934 A temporary encryption key used between two principals, with a
935 lifetime limited to the duration of a single login "session".
938 A temporary encryption key used between two principals, selected
939 and exchanged by the principals using the session key, and with a
940 lifetime limited to the duration of a single association.
943 A record that helps a client authenticate itself to a server; it
944 contains the client's identity, a session key, a timestamp, and
945 other information, all sealed using the server's secret key. It
946 only serves to authenticate a client when presented along with a
950 2. Ticket flag uses and requests
960 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
963 Each Kerberos ticket contains a set of flags which are used to
964 indicate attributes of that ticket. Most flags may be requested by a
965 client when the ticket is obtained; some are automatically turned on
966 and off by a Kerberos server as required. The following sections
967 explain what the various flags mean and give examples of reasons to
968 use them. With the exception of the INVALID flag clients MUST ignore
969 ticket flags that are not recognized. KDCs MUST ignore KDC options
970 that are not recognized. Some implementations of RFC 1510 are known
971 to reject unknown KDC options, so clients may need to resend a
972 request without KDC new options absent if the request was rejected
973 when sent with option added since RFC 1510. Since new KDCs will
974 ignore unknown options, clients MUST confirm that the ticket returned
975 by the KDC meets their needs.
977 Note that it is not, in general, possible to determine whether an
978 option was not honored because it was not understood or because it
979 was rejected either through configuration or policy. When adding a
980 new option to the Kerberos protocol, designers should consider
981 whether the distinction is important for their option. In cases where
982 it is, a mechanism for the KDC to return an indication that the
983 option was understood but rejected needs to be provided in the
984 specification of the option. Often in such cases, the mechanism needs
985 to be broad enough to permit an error or reason to be returned.
987 2.1. Initial, pre-authenticated, and hardware authenticated tickets
989 The INITIAL flag indicates that a ticket was issued using the AS
990 protocol, rather than issued based on a ticket-granting ticket.
991 Application servers that want to require the demonstrated knowledge
992 of a client's secret key (e.g. a password-changing program) can
993 insist that this flag be set in any tickets they accept, and thus be
994 assured that the client's key was recently presented to the
997 The PRE-AUTHENT and HW-AUTHENT flags provide additional information
998 about the initial authentication, regardless of whether the current
999 ticket was issued directly (in which case INITIAL will also be set)
1000 or issued on the basis of a ticket-granting ticket (in which case the
1001 INITIAL flag is clear, but the PRE-AUTHENT and HW-AUTHENT flags are
1002 carried forward from the ticket-granting ticket).
1004 2.2. Invalid tickets
1006 The INVALID flag indicates that a ticket is invalid. Application
1007 servers MUST reject tickets which have this flag set. A postdated
1008 ticket will be issued in this form. Invalid tickets MUST be validated
1009 by the KDC before use, by presenting them to the KDC in a TGS request
1010 with the VALIDATE option specified. The KDC will only validate
1014 March 2003 [Page 17]
1020 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
1023 tickets after their starttime has passed. The validation is required
1024 so that postdated tickets which have been stolen before their
1025 starttime can be rendered permanently invalid (through a hot-list
1026 mechanism) (see section 3.3.3.1).
1028 2.3. Renewable tickets
1030 Applications may desire to hold tickets which can be valid for long
1031 periods of time. However, this can expose their credentials to
1032 potential theft for equally long periods, and those stolen
1033 credentials would be valid until the expiration time of the
1034 ticket(s). Simply using short-lived tickets and obtaining new ones
1035 periodically would require the client to have long-term access to its
1036 secret key, an even greater risk. Renewable tickets can be used to
1037 mitigate the consequences of theft. Renewable tickets have two
1038 "expiration times": the first is when the current instance of the
1039 ticket expires, and the second is the latest permissible value for an
1040 individual expiration time. An application client must periodically
1041 (i.e. before it expires) present a renewable ticket to the KDC, with
1042 the RENEW option set in the KDC request. The KDC will issue a new
1043 ticket with a new session key and a later expiration time. All other
1044 fields of the ticket are left unmodified by the renewal process. When
1045 the latest permissible expiration time arrives, the ticket expires
1046 permanently. At each renewal, the KDC MAY consult a hot-list to
1047 determine if the ticket had been reported stolen since its last
1048 renewal; it will refuse to renew such stolen tickets, and thus the
1049 usable lifetime of stolen tickets is reduced.
1051 The RENEWABLE flag in a ticket is normally only interpreted by the
1052 ticket-granting service (discussed below in section 3.3). It can
1053 usually be ignored by application servers. However, some particularly
1054 careful application servers MAY disallow renewable tickets.
1056 If a renewable ticket is not renewed by its expiration time, the KDC
1057 will not renew the ticket. The RENEWABLE flag is reset by default,
1058 but a client MAY request it be set by setting the RENEWABLE option in
1059 the KRB_AS_REQ message. If it is set, then the renew-till field in
1060 the ticket contains the time after which the ticket may not be
1063 2.4. Postdated tickets
1065 Applications may occasionally need to obtain tickets for use much
1066 later, e.g. a batch submission system would need tickets to be valid
1067 at the time the batch job is serviced. However, it is dangerous to
1068 hold valid tickets in a batch queue, since they will be on-line
1069 longer and more prone to theft. Postdated tickets provide a way to
1070 obtain these tickets from the KDC at job submission time, but to
1074 March 2003 [Page 18]
1080 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
1083 leave them "dormant" until they are activated and validated by a
1084 further request of the KDC. If a ticket theft were reported in the
1085 interim, the KDC would refuse to validate the ticket, and the thief
1088 The MAY-POSTDATE flag in a ticket is normally only interpreted by the
1089 ticket-granting service. It can be ignored by application servers.
1090 This flag MUST be set in a ticket-granting ticket in order to issue a
1091 postdated ticket based on the presented ticket. It is reset by
1092 default; it MAY be requested by a client by setting the ALLOW-
1093 POSTDATE option in the KRB_AS_REQ message. This flag does not allow
1094 a client to obtain a postdated ticket-granting ticket; postdated
1095 ticket-granting tickets can only by obtained by requesting the
1096 postdating in the KRB_AS_REQ message. The life (endtime-starttime) of
1097 a postdated ticket will be the remaining life of the ticket-granting
1098 ticket at the time of the request, unless the RENEWABLE option is
1099 also set, in which case it can be the full life (endtime-starttime)
1100 of the ticket-granting ticket. The KDC MAY limit how far in the
1101 future a ticket may be postdated.
1103 The POSTDATED flag indicates that a ticket has been postdated. The
1104 application server can check the authtime field in the ticket to see
1105 when the original authentication occurred. Some services MAY choose
1106 to reject postdated tickets, or they may only accept them within a
1107 certain period after the original authentication. When the KDC issues
1108 a POSTDATED ticket, it will also be marked as INVALID, so that the
1109 application client MUST present the ticket to the KDC to be validated
1112 2.5. Proxiable and proxy tickets
1114 At times it may be necessary for a principal to allow a service to
1115 perform an operation on its behalf. The service must be able to take
1116 on the identity of the client, but only for a particular purpose. A
1117 principal can allow a service to take on the principal's identity for
1118 a particular purpose by granting it a proxy.
1120 The process of granting a proxy using the proxy and proxiable flags
1121 is used to provide credentials for use with specific services. Though
1122 conceptually also a proxy, users wishing to delegate their identity
1123 in a form usable for all purpose MUST use the ticket forwarding
1124 mechanism described in the next section to forward a ticket-granting
1127 The PROXIABLE flag in a ticket is normally only interpreted by the
1128 ticket-granting service. It can be ignored by application servers.
1129 When set, this flag tells the ticket-granting server that it is OK to
1130 issue a new ticket (but not a ticket-granting ticket) with a
1134 March 2003 [Page 19]
1140 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
1143 different network address based on this ticket. This flag is set if
1144 requested by the client on initial authentication. By default, the
1145 client will request that it be set when requesting a ticket-granting
1146 ticket, and reset when requesting any other ticket.
1148 This flag allows a client to pass a proxy to a server to perform a
1149 remote request on its behalf (e.g. a print service client can give
1150 the print server a proxy to access the client's files on a particular
1151 file server in order to satisfy a print request).
1153 In order to complicate the use of stolen credentials, Kerberos
1154 tickets are usually valid from only those network addresses
1155 specifically included in the ticket[4]. When granting a proxy, the
1156 client MUST specify the new network address from which the proxy is
1157 to be used, or indicate that the proxy is to be issued for use from
1160 The PROXY flag is set in a ticket by the TGS when it issues a proxy
1161 ticket. Application servers MAY check this flag and at their option
1162 they MAY require additional authentication from the agent presenting
1163 the proxy in order to provide an audit trail.
1165 2.6. Forwardable tickets
1167 Authentication forwarding is an instance of a proxy where the service
1168 granted is complete use of the client's identity. An example where it
1169 might be used is when a user logs in to a remote system and wants
1170 authentication to work from that system as if the login were local.
1172 The FORWARDABLE flag in a ticket is normally only interpreted by the
1173 ticket-granting service. It can be ignored by application servers.
1174 The FORWARDABLE flag has an interpretation similar to that of the
1175 PROXIABLE flag, except ticket-granting tickets may also be issued
1176 with different network addresses. This flag is reset by default, but
1177 users MAY request that it be set by setting the FORWARDABLE option in
1178 the AS request when they request their initial ticket-granting
1181 This flag allows for authentication forwarding without requiring the
1182 user to enter a password again. If the flag is not set, then
1183 authentication forwarding is not permitted, but the same result can
1184 still be achieved if the user engages in the AS exchange specifying
1185 the requested network addresses and supplies a password.
1187 The FORWARDED flag is set by the TGS when a client presents a ticket
1188 with the FORWARDABLE flag set and requests a forwarded ticket by
1189 specifying the FORWARDED KDC option and supplying a set of addresses
1190 for the new ticket. It is also set in all tickets issued based on
1194 March 2003 [Page 20]
1200 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
1203 tickets with the FORWARDED flag set. Application servers may choose
1204 to process FORWARDED tickets differently than non-FORWARDED tickets.
1206 If addressless tickets are forwarded from one system to another,
1207 clients SHOULD still use this option to obtain a new TGT in order to
1208 have different session keys on the different systems.
1210 2.7. Transited Policy Checking
1212 In Kerberos, the application server is ultimately responsible for
1213 accepting or rejecting authentication and SHOULD check that only
1214 suitably trusted KDCs are relied upon to authenticate a principal.
1215 The transited field in the ticket identifies which realms (and thus
1216 which KDCs) were involved in the authentication process and an
1217 application server would normally check this field. If any of these
1218 are untrusted to authenticate the indicated client principal
1219 (probably determined by a realm-based policy), the authentication
1220 attempt MUST be rejected. The presence of trusted KDCs in this list
1221 does not provide any guarantee; an untrusted KDC may have fabricated
1224 While the end server ultimately decides whether authentication is
1225 valid, the KDC for the end server's realm MAY apply a realm specific
1226 policy for validating the transited field and accepting credentials
1227 for cross-realm authentication. When the KDC applies such checks and
1228 accepts such cross-realm authentication it will set the TRANSITED-
1229 POLICY-CHECKED flag in the service tickets it issues based on the
1230 cross-realm TGT. A client MAY request that the KDCs not check the
1231 transited field by setting the DISABLE-TRANSITED-CHECK flag. KDCs are
1232 encouraged but not required to honor this flag.
1234 Application servers MUST either do the transited-realm checks
1235 themselves, or reject cross-realm tickets without TRANSITED-POLICY-
1240 For some applications a client may need to delegate authority to a
1241 server to act on its behalf in contacting other services. This
1242 requires that the client forward credentials to an intermediate
1243 server. The ability for a client to obtain a service ticket to a
1244 server conveys no information to the client about whether the server
1245 should be trusted to accept delegated credentials. The OK-AS-
1246 DELEGATE provides a way for a KDC to communicate local realm policy
1247 to a client regarding whether an intermediate server is trusted to
1248 accept such credentials.
1250 The OK-AS-DELEGATE flag from the copy of the ticket flags in the
1254 March 2003 [Page 21]
1260 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
1263 encrypted part of the KDC reply indicates to the client that the
1264 server (not the client) specified in the ticket has been determined
1265 by policy of the realm to be a suitable recipient of delegation. A
1266 client can use the presence of this flag to help it make a decision
1267 whether to delegate credentials (either grant a proxy or a forwarded
1268 ticket-granting ticket) to this server. Ignore the value of this
1269 flag. When setting this flag, an administrator should consider the
1270 Security and placement of the server on which the service will run,
1271 as well as whether the service requires the use of delegated
1274 2.9. Other KDC options
1276 There are three additional options which MAY be set in a client's
1281 The RENEWABLE-OK option indicates that the client will accept a
1282 renewable ticket if a ticket with the requested life cannot otherwise
1283 be provided. If a ticket with the requested life cannot be provided,
1284 then the KDC MAY issue a renewable ticket with a renew-till equal to
1285 the requested endtime. The value of the renew-till field MAY still be
1286 adjusted by site-determined limits or limits imposed by the
1287 individual principal or server.
1289 2.9.2. ENC-TKT-IN-SKEY
1291 In its basic form the Kerberos protocol supports authentication in a
1293 setting and is not well suited to authentication in a peer-to-peer
1294 environment because the long term key of the user does not remain on
1295 the workstation after initial login. Authentication of such peers may
1296 be supported by Kerberos in its user-to-user variant. The ENC-TKT-IN-
1297 SKEY option supports user-to-user authentication by allowing the KDC
1298 to issue a service ticket encrypted using the session key from
1299 another ticket-granting ticket issued to another user. The ENC-TKT-
1300 IN-SKEY option is honored only by the ticket-granting service. It
1301 indicates that the ticket to be issued for the end server is to be
1302 encrypted in the session key from the additional second ticket-
1303 granting ticket provided with the request. See section 3.3.3 for
1306 2.9.3. Passwordless Hardware Authentication
1308 The OPT-HARDWARE-AUTH option indicates that the client wishes to use
1309 some form of hardware authentication instead of or in addition to the
1310 client's password or other long-lived encryption key. OPT-HARDWARE-
1314 March 2003 [Page 22]
1320 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
1323 AUTH is honored only by the authentication service. If supported and
1324 allowed by policy, the KDC will return an errorcode
1325 KDC_ERR_PREAUTH_REQUIRED and include the required METHOD-DATA to
1326 perform such authentication.
1328 3. Message Exchanges
1330 The following sections describe the interactions between network
1331 clients and servers and the messages involved in those exchanges.
1333 3.1. The Authentication Service Exchange
1337 Message direction Message type Section
1338 1. Client to Kerberos KRB_AS_REQ 5.4.1
1339 2. Kerberos to client KRB_AS_REP or 5.4.2
1342 The Authentication Service (AS) Exchange between the client and the
1343 Kerberos Authentication Server is initiated by a client when it
1344 wishes to obtain authentication credentials for a given server but
1345 currently holds no credentials. In its basic form, the client's
1346 secret key is used for encryption and decryption. This exchange is
1347 typically used at the initiation of a login session to obtain
1348 credentials for a Ticket-Granting Server which will subsequently be
1349 used to obtain credentials for other servers (see section 3.3)
1350 without requiring further use of the client's secret key. This
1351 exchange is also used to request credentials for services which must
1352 not be mediated through the Ticket-Granting Service, but rather
1353 require a principal's secret key, such as the password-changing
1354 service[5]. This exchange does not by itself provide any assurance of
1355 the identity of the user[6].
1357 The exchange consists of two messages: KRB_AS_REQ from the client to
1358 Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these
1359 messages are described in sections 5.4.1, 5.4.2, and 5.9.1.
1361 In the request, the client sends (in cleartext) its own identity and
1362 the identity of the server for which it is requesting credentials,
1363 other information about the credentials it is requesting, and a
1364 randomly generated nonce which can be used to detect replays, and to
1365 associate replies with the matching requests. This nonce MUST be
1366 generated randomly by the client and remembered for checking against
1367 the nonce in the expected reply. The response, KRB_AS_REP, contains a
1368 ticket for the client to present to the server, and a session key
1369 that will be shared by the client and the server. The session key
1370 and additional information are encrypted in the client's secret key.
1374 March 2003 [Page 23]
1380 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
1383 The encrypted part of the KRB_AS_REP message also contains the nonce
1384 which MUST be matched with the nonce from the KRB_AS_REQ message.
1386 Without pre-authentication, the authentication server does not know
1387 whether the client is actually the principal named in the request. It
1388 simply sends a reply without knowing or caring whether they are the
1389 same. This is acceptable because nobody but the principal whose
1390 identity was given in the request will be able to use the reply. Its
1391 critical information is encrypted in that principal's key. However,
1392 an attacker can send a KRB_AS_REQ message to get known plaintext in
1393 order to attack the principal's key. Especially if the key is based
1394 on a password, this may create a security exposure. So, the initial
1395 request supports an optional field that can be used to pass
1396 additional information that might be needed for the initial exchange.
1397 This field SHOULD be used for pre-authentication as described in
1398 sections 3.1.1 and 5.2.7.
1400 Various errors can occur; these are indicated by an error response
1401 (KRB_ERROR) instead of the KRB_AS_REP response. The error message is
1402 not encrypted. The KRB_ERROR message contains information which can
1403 be used to associate it with the message to which it replies. The
1404 contents of the KRB_ERROR message are not integrity-protected. As
1405 such, the client cannot detect replays, fabrications or
1406 modifications. A solution to this problem will be included in a
1407 future version of the protocol.
1409 3.1.1. Generation of KRB_AS_REQ message
1411 The client may specify a number of options in the initial request.
1412 Among these options are whether pre-authentication is to be
1413 performed; whether the requested ticket is to be renewable,
1414 proxiable, or forwardable; whether it should be postdated or allow
1415 postdating of derivative tickets; and whether a renewable ticket will
1416 be accepted in lieu of a non-renewable ticket if the requested ticket
1417 expiration date cannot be satisfied by a non-renewable ticket (due to
1418 configuration constraints).
1420 The client prepares the KRB_AS_REQ message and sends it to the KDC.
1422 3.1.2. Receipt of KRB_AS_REQ message
1424 If all goes well, processing the KRB_AS_REQ message will result in
1425 the creation of a ticket for the client to present to the server. The
1426 format for the ticket is described in section 5.3. The contents of
1427 the ticket are determined as follows.
1429 Because Kerberos can run over unreliable transports such as UDP, the
1430 KDC MUST be prepared to retransmit responses in case they are lost.
1434 March 2003 [Page 24]
1440 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
1443 If a KDC receives a request identical to one it has recently
1444 successfully processed, the KDC MUST respond with a KRB_AS_REP
1445 message rather than a replay error. In order to reduce ciphertext
1446 given to a potential attacker, KDCs MAY send the same response
1447 generated when the request was first handled. KDCs MUST obey this
1448 replay behavior even if the actual transport in use is reliable.
1450 3.1.3. Generation of KRB_AS_REP message
1452 The authentication server looks up the client and server principals
1453 named in the KRB_AS_REQ in its database, extracting their respective
1454 keys. If the requested client principal named in the request is not
1455 known because it doesn't exist in the KDC's principal database, then
1456 an error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is returned.
1458 If required, the server pre-authenticates the request, and if the
1459 pre-authentication check fails, an error message with the code
1460 KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is
1461 required, but was not present in the request, an error message with
1462 the code KDC_ERR_PREAUTH_REQUIRED is returned and a METHOD-DATA
1463 object will be stored in the e-data field of the KRB-ERROR message to
1464 specify which pre-authentication mechanisms are acceptable. Usually
1465 this will include PA-ETYPE-INFO and/or PA-ETYPE-INFO2 elements as
1466 described below. If the server cannot accommodate any encryption type
1467 requested by the client, an error message with code
1468 KDC_ERR_ETYPE_NOSUPP is returned. Otherwise the KDC generates a
1469 'random' session key[7].
1471 When responding to an AS request, if there are multiple encryption
1472 keys registered for a client in the Kerberos database, then the etype
1473 field from the AS request is used by the KDC to select the encryption
1474 method to be used to protect the encrypted part of the KRB_AS_REP
1475 message which is sent to the client. If there is more than one
1476 supported strong encryption type in the etype list, the KDC SHOULD
1477 use the first valid strong etype for which an encryption key is
1480 When the user's key is generated from a password or pass phrase, the
1481 string-to-key function for the particular encryption key type is
1482 used, as specified in [@KCRYPTO]. The salt value and additional
1483 parameters for the string-to-key function have default values
1484 (specified by section 4 and by the encryption mechanism
1485 specification, respectively) that may be overridden by pre-
1486 authentication data (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA-
1487 ETYPE-INFO2, etc). Since the KDC is presumed to store a copy of the
1488 resulting key only, these values should not be changed for password-
1489 based keys except when changing the principal's key.
1494 March 2003 [Page 25]
1500 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
1503 When the AS server is to include pre-authentication data in a KRB-
1504 ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE-INFO,
1505 if the etype field of the client's AS-REQ lists at least one "newer"
1506 encryption type. Otherwise (when the etype field of the client's AS-
1507 REQ does not list any "newer" encryption types) it MUST send both,
1508 PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an entry for each
1509 enctype). A "newer" enctype is any enctype first officially
1510 specified concurrently with or subsequent to the issue of this RFC.
1511 The enctypes DES, 3DES or RC4 and any defined in [RFC1510] are not
1514 It is not possible to reliably generate a user's key given a pass
1515 phrase without contacting the KDC, since it will not be known whether
1516 alternate salt or parameter values are required.
1518 The KDC will attempt to assign the type of the random session key
1519 from the list of methods in the etype field. The KDC will select the
1520 appropriate type using the list of methods provided together with
1521 information from the Kerberos database indicating acceptable
1522 encryption methods for the application server. The KDC will not issue
1523 tickets with a weak session key encryption type.
1525 If the requested start time is absent, indicates a time in the past,
1526 or is within the window of acceptable clock skew for the KDC and the
1527 POSTDATE option has not been specified, then the start time of the
1528 ticket is set to the authentication server's current time. If it
1529 indicates a time in the future beyond the acceptable clock skew, but
1530 the POSTDATED option has not been specified then the error
1531 KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the requested start
1532 time is checked against the policy of the local realm (the
1533 administrator might decide to prohibit certain types or ranges of
1534 postdated tickets), and if acceptable, the ticket's start time is set
1535 as requested and the INVALID flag is set in the new ticket. The
1536 postdated ticket MUST be validated before use by presenting it to the
1537 KDC after the start time has been reached.
1539 The expiration time of the ticket will be set to the earlier of the
1540 requested endtime and a time determined by local policy, possibly
1541 determined using realm or principal specific factors. For example,
1542 the expiration time MAY be set to the earliest of the following:
1544 * The expiration time (endtime) requested in the KRB_AS_REQ
1547 * The ticket's start time plus the maximum allowable lifetime
1548 associated with the client principal from the authentication
1554 March 2003 [Page 26]
1560 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
1563 * The ticket's start time plus the maximum allowable lifetime
1564 associated with the server principal.
1566 * The ticket's start time plus the maximum lifetime set by the
1567 policy of the local realm.
1569 If the requested expiration time minus the start time (as determined
1570 above) is less than a site-determined minimum lifetime, an error
1571 message with code KDC_ERR_NEVER_VALID is returned. If the requested
1572 expiration time for the ticket exceeds what was determined as above,
1573 and if the 'RENEWABLE-OK' option was requested, then the 'RENEWABLE'
1574 flag is set in the new ticket, and the renew-till value is set as if
1575 the 'RENEWABLE' option were requested (the field and option names are
1576 described fully in section 5.4.1).
1578 If the RENEWABLE option has been requested or if the RENEWABLE-OK
1579 option has been set and a renewable ticket is to be issued, then the
1580 renew-till field MAY be set to the earliest of:
1582 * Its requested value.
1584 * The start time of the ticket plus the minimum of the two
1585 maximum renewable lifetimes associated with the principals'
1588 * The start time of the ticket plus the maximum renewable
1589 lifetime set by the policy of the local realm.
1591 The flags field of the new ticket will have the following options set
1592 if they have been requested and if the policy of the local realm
1593 allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE.
1594 If the new ticket is postdated (the start time is in the future), its
1595 INVALID flag will also be set.
1597 If all of the above succeed, the server will encrypt the ciphertext
1598 part of the ticket using the encryption key extracted from the server
1599 principal's record in the Kerberos database using the encryption type
1600 associated with the server principal's key (this choice is NOT
1601 affected by the etype field in the request). It then formats a
1602 KRB_AS_REP message (see section 5.4.2), copying the addresses in the
1603 request into the caddr of the response, placing any required pre-
1604 authentication data into the padata of the response, and encrypts the
1605 ciphertext part in the client's key using an acceptable encryption
1606 method requested in the etype field of the request, or in some key
1607 specified by pre-authentication mechanisms being used.
1609 3.1.4. Generation of KRB_ERROR message
1614 March 2003 [Page 27]
1620 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
1623 Several errors can occur, and the Authentication Server responds by
1624 returning an error message, KRB_ERROR, to the client, with the error-
1625 code and e-text fields set to appropriate values. The error message
1626 contents and details are described in Section 5.9.1.
1628 3.1.5. Receipt of KRB_AS_REP message
1630 If the reply message type is KRB_AS_REP, then the client verifies
1631 that the cname and crealm fields in the cleartext portion of the
1632 reply match what it requested. If any padata fields are present, they
1633 may be used to derive the proper secret key to decrypt the message.
1634 The client decrypts the encrypted part of the response using its
1635 secret key, verifies that the nonce in the encrypted part matches the
1636 nonce it supplied in its request (to detect replays). It also
1637 verifies that the sname and srealm in the response match those in the
1638 request (or are otherwise expected values), and that the host address
1639 field is also correct. It then stores the ticket, session key, start
1640 and expiration times, and other information for later use. The last-
1641 req field (and the deprecated key-expiration field) from the
1642 encrypted part of the response MAY be checked to notify the user of
1643 impending key expiration. This enables the client program to suggest
1644 remedial action, such as a password change.
1646 Upon validation of the KRB_AS_REP message (by checking the returned
1647 nonce against that sent in the KRB_AS_REQ message) the client knows
1648 that the current time on the KDC is that read from the authtime field
1649 of the encrypted part of the reply. The client can optionally use
1650 this value for clock synchronization in subsequent messages by
1651 recording with the ticket the difference (offset) between the
1652 authtime value and the local clock. This offset can then be used by
1653 the same user to adjust the time read from the system clock when
1654 generating messages [DGT96].
1656 This technique MUST be used when adjusting for clock skew instead of
1657 directly changing the system clock because the KDC reply is only
1658 authenticated to the user whose secret key was used, but not to the
1659 system or workstation. If the clock were adjusted, an attacker
1660 colluding with a user logging into a workstation could agree on a
1661 password, resulting in a KDC reply that would be correctly validated
1662 even though it did not originate from a KDC trusted by the
1665 Proper decryption of the KRB_AS_REP message is not sufficient for the
1666 host to verify the identity of the user; the user and an attacker
1667 could cooperate to generate a KRB_AS_REP format message which
1668 decrypts properly but is not from the proper KDC. If the host wishes
1669 to verify the identity of the user, it MUST require the user to
1670 present application credentials which can be verified using a
1674 March 2003 [Page 28]
1680 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
1683 securely-stored secret key for the host. If those credentials can be
1684 verified, then the identity of the user can be assured.
1686 3.1.6. Receipt of KRB_ERROR message
1688 If the reply message type is KRB_ERROR, then the client interprets it
1689 as an error and performs whatever application-specific tasks are
1690 necessary to recover.
1692 3.2. The Client/Server Authentication Exchange
1695 Message direction Message type Section
1696 Client to Application server KRB_AP_REQ 5.5.1
1697 [optional] Application server to client KRB_AP_REP or 5.5.2
1700 The client/server authentication (CS) exchange is used by network
1701 applications to authenticate the client to the server and vice versa.
1702 The client MUST have already acquired credentials for the server
1703 using the AS or TGS exchange.
1705 3.2.1. The KRB_AP_REQ message
1707 The KRB_AP_REQ contains authentication information which SHOULD be
1708 part of the first message in an authenticated transaction. It
1709 contains a ticket, an authenticator, and some additional bookkeeping
1710 information (see section 5.5.1 for the exact format). The ticket by
1711 itself is insufficient to authenticate a client, since tickets are
1712 passed across the network in cleartext[8], so the authenticator is
1713 used to prevent invalid replay of tickets by proving to the server
1714 that the client knows the session key of the ticket and thus is
1715 entitled to use the ticket. The KRB_AP_REQ message is referred to
1716 elsewhere as the 'authentication header.'
1718 3.2.2. Generation of a KRB_AP_REQ message
1720 When a client wishes to initiate authentication to a server, it
1721 obtains (either through a credentials cache, the AS exchange, or the
1722 TGS exchange) a ticket and session key for the desired service. The
1723 client MAY re-use any tickets it holds until they expire. To use a
1724 ticket the client constructs a new Authenticator from the system
1725 time, its name, and optionally an application specific checksum, an
1726 initial sequence number to be used in KRB_SAFE or KRB_PRIV messages,
1727 and/or a session subkey to be used in negotiations for a session key
1728 unique to this particular session. Authenticators MAY NOT be re-used
1729 and will be rejected if replayed to a server[9]. If a sequence number
1730 is to be included, it SHOULD be randomly chosen so that even after
1734 March 2003 [Page 29]
1740 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
1743 many messages have been exchanged it is not likely to collide with
1744 other sequence numbers in use.
1746 The client MAY indicate a requirement of mutual authentication or the
1747 use of a session-key based ticket (for user to user authentication -
1748 see section 3.7) by setting the appropriate flag(s) in the ap-options
1749 field of the message.
1751 The Authenticator is encrypted in the session key and combined with
1752 the ticket to form the KRB_AP_REQ message which is then sent to the
1753 end server along with any additional application-specific
1756 3.2.3. Receipt of KRB_AP_REQ message
1758 Authentication is based on the server's current time of day (clocks
1759 MUST be loosely synchronized), the authenticator, and the ticket.
1760 Several errors are possible. If an error occurs, the server is
1761 expected to reply to the client with a KRB_ERROR message. This
1762 message MAY be encapsulated in the application protocol if its 'raw'
1763 form is not acceptable to the protocol. The format of error messages
1764 is described in section 5.9.1.
1766 The algorithm for verifying authentication information is as follows.
1767 If the message type is not KRB_AP_REQ, the server returns the
1768 KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the Ticket
1769 in the KRB_AP_REQ is not one the server can use (e.g., it indicates
1770 an old key, and the server no longer possesses a copy of the old
1771 key), the KRB_AP_ERR_BADKEYVER error is returned. If the USE-SESSION-
1772 KEY flag is set in the ap-options field, it indicates to the server
1773 that user-to-user authentication is in use, and that the ticket is
1774 encrypted in the session key from the server's ticket-granting ticket
1775 rather than in the server's secret key. See section 3.7 for a more
1776 complete description of the affect of user to user authentication on
1777 all messages in the Kerberos protocol.
1779 Since it is possible for the server to be registered in multiple
1780 realms, with different keys in each, the srealm field in the
1781 unencrypted portion of the ticket in the KRB_AP_REQ is used to
1782 specify which secret key the server should use to decrypt that
1783 ticket. The KRB_AP_ERR_NOKEY error code is returned if the server
1784 doesn't have the proper key to decipher the ticket.
1786 The ticket is decrypted using the version of the server's key
1787 specified by the ticket. If the decryption routines detect a
1788 modification of the ticket (each encryption system MUST provide
1789 safeguards to detect modified ciphertext; see section 6), the
1790 KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that
1794 March 2003 [Page 30]
1800 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
1803 different keys were used to encrypt and decrypt).
1805 The authenticator is decrypted using the session key extracted from
1806 the decrypted ticket. If decryption shows it to have been modified,
1807 the KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of
1808 the client from the ticket are compared against the same fields in
1809 the authenticator. If they don't match, the KRB_AP_ERR_BADMATCH
1810 error is returned; this normally is caused by a client error or
1811 attempted attack. The addresses in the ticket (if any) are then
1812 searched for an address matching the operating-system reported
1813 address of the client. If no match is found or the server insists on
1814 ticket addresses but none are present in the ticket, the
1815 KRB_AP_ERR_BADADDR error is returned. If the local (server) time and
1816 the client time in the authenticator differ by more than the
1817 allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW error is
1820 Unless the application server provides its own suitable means to
1821 protect against replay (for example, a challenge-response sequence
1822 initiated by the server after authentication, or use of a server-
1823 generated encryption subkey), the server MUST utilize a replay cache
1824 to remember any authenticator presented within the allowable clock
1825 skew. Careful analysis of the application protocol and implementation
1826 is recommended before eliminating this cache. The replay cache will
1827 store at least the server name, along with the client name, time and
1828 microsecond fields from the recently-seen authenticators and if a
1829 matching tuple is found, the KRB_AP_ERR_REPEAT error is returned
1830 [10]. If a server loses track of authenticators presented within the
1831 allowable clock skew, it MUST reject all requests until the clock
1832 skew interval has passed, providing assurance that any lost or
1833 replayed authenticators will fall outside the allowable clock skew
1834 and can no longer be successfully replayed [11].
1836 Implementation note: If a client generates multiple requests to the
1837 KDC with the same timestamp, including the microsecond field, all but
1838 the first of the requests received will be rejected as replays. This
1839 might happen, for example, if the resolution of the client's clock is
1840 too coarse. Implementations SHOULD ensure that the timestamps are
1841 not reused, possibly by incrementing the microseconds field in the
1842 time stamp when the clock returns the same time for multiple
1845 If multiple servers (for example, different services on one machine,
1846 or a single service implemented on multiple machines) share a service
1847 principal (a practice we do not recommend in general, but acknowledge
1848 will be used in some cases), they should also share this replay
1849 cache, or the application protocol should be designed so as to
1850 eliminate the need for it. Note that this applies to all of the
1854 March 2003 [Page 31]
1860 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
1863 services, if any of the application protocols does not have replay
1864 protection built in; an authenticator used with such a service could
1865 later be replayed to a different service with the same service
1866 principal but no replay protection, if the former doesn't record the
1867 authenticator information in the common replay cache.
1869 If a sequence number is provided in the authenticator, the server
1870 saves it for later use in processing KRB_SAFE and/or KRB_PRIV
1871 messages. If a subkey is present, the server either saves it for
1872 later use or uses it to help generate its own choice for a subkey to
1873 be returned in a KRB_AP_REP message.
1875 The server computes the age of the ticket: local (server) time minus
1876 the start time inside the Ticket. If the start time is later than the
1877 current time by more than the allowable clock skew or if the INVALID
1878 flag is set in the ticket, the KRB_AP_ERR_TKT_NYV error is returned.
1879 Otherwise, if the current time is later than end time by more than
1880 the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error is
1883 If all these checks succeed without an error, the server is assured
1884 that the client possesses the credentials of the principal named in
1885 the ticket and thus, the client has been authenticated to the server.
1887 Passing these checks provides only authentication of the named
1888 principal; it does not imply authorization to use the named service.
1889 Applications MUST make a separate authorization decisions based upon
1890 the authenticated name of the user, the requested operation, local
1891 access control information such as that contained in a .k5login or
1892 .k5users file, and possibly a separate distributed authorization
1895 3.2.4. Generation of a KRB_AP_REP message
1897 Typically, a client's request will include both the authentication
1898 information and its initial request in the same message, and the
1899 server need not explicitly reply to the KRB_AP_REQ. However, if
1900 mutual authentication (not only authenticating the client to the
1901 server, but also the server to the client) is being performed, the
1902 KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options
1903 field, and a KRB_AP_REP message is required in response. As with the
1904 error message, this message MAY be encapsulated in the application
1905 protocol if its "raw" form is not acceptable to the application's
1906 protocol. The timestamp and microsecond field used in the reply MUST
1907 be the client's timestamp and microsecond field (as provided in the
1908 authenticator) [12]. If a sequence number is to be included, it
1909 SHOULD be randomly chosen as described above for the authenticator. A
1910 subkey MAY be included if the server desires to negotiate a different
1914 March 2003 [Page 32]
1920 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
1923 subkey. The KRB_AP_REP message is encrypted in the session key
1924 extracted from the ticket.
1926 3.2.5. Receipt of KRB_AP_REP message
1928 If a KRB_AP_REP message is returned, the client uses the session key
1929 from the credentials obtained for the server [13] to decrypt the
1930 message, and verifies that the timestamp and microsecond fields match
1931 those in the Authenticator it sent to the server. If they match, then
1932 the client is assured that the server is genuine. The sequence number
1933 and subkey (if present) are retained for later use.
1935 3.2.6. Using the encryption key
1937 After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and
1938 server share an encryption key which can be used by the application.
1939 In some cases, the use of this session key will be implicit in the
1940 protocol; in others the method of use must be chosen from several
1941 alternatives. The 'true session key' to be used for KRB_PRIV,
1942 KRB_SAFE, or other application-specific uses MAY be chosen by the
1943 application based on the session key from the ticket and subkeys in
1944 the KRB_AP_REP message and the authenticator [14]. To mitigate the
1945 effect of failures in random number generation on the client it is
1946 strongly encouraged that any key derived by an application for
1947 subsequent use include the full key entropy derived from the KDC
1948 generated session key carried in the ticket. We leave the protocol
1949 negotiations of how to use the key (e.g. selecting an encryption or
1950 checksum type) to the application programmer; the Kerberos protocol
1951 does not constrain the implementation options, but an example of how
1952 this might be done follows.
1954 One way that an application may choose to negotiate a key to be used
1955 for subsequent integrity and privacy protection is for the client to
1956 propose a key in the subkey field of the authenticator. The server
1957 can then choose a key using the proposed key from the client as
1958 input, returning the new subkey in the subkey field of the
1959 application reply. This key could then be used for subsequent
1962 To make this example more concrete, if the communication patterns of
1963 an application dictates the use of encryption modes of operation
1964 incompatible with the encryption system used for the authenticator,
1965 then a key compatible with the required encryption system may be
1966 generated by either the client, the server, or collaboratively by
1967 both and exchanged using the subkey field. This generation might
1968 involve the use of a random number as a pre-key, initially generated
1969 by either party, which could then be encrypted using the session key
1970 from the ticket, and the result exchanged and used for subsequent
1974 March 2003 [Page 33]
1980 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
1983 encryption. By encrypting the pre-key with the session key from the
1984 ticket, randomness from the KDC generated key is assured of being
1985 present in the negotiated key. Application developers must be careful
1986 however, to use a means of introducing this entropy that does not
1987 allow an attacker to learn the session key from the ticket if it
1988 learns the key generated and used for subsequent communication. The
1989 reader should note that this is only an example, and that an analysis
1990 of the particular cryptosystem to be used, must be made before
1991 deciding how to generate values for the subkey fields, and the key to
1992 be used for subsequent communication.
1994 With both the one-way and mutual authentication exchanges, the peers
1995 should take care not to send sensitive information to each other
1996 without proper assurances. In particular, applications that require
1997 privacy or integrity SHOULD use the KRB_AP_REP response from the
1998 server to client to assure both client and server of their peer's
1999 identity. If an application protocol requires privacy of its
2000 messages, it can use the KRB_PRIV message (section 3.5). The KRB_SAFE
2001 message (section 3.4) can be used to assure integrity.
2003 3.3. The Ticket-Granting Service (TGS) Exchange
2006 Message direction Message type Section
2007 1. Client to Kerberos KRB_TGS_REQ 5.4.1
2008 2. Kerberos to client KRB_TGS_REP or 5.4.2
2011 The TGS exchange between a client and the Kerberos Ticket-Granting
2012 Server is initiated by a client when it wishes to obtain
2013 authentication credentials for a given server (which might be
2014 registered in a remote realm), when it wishes to renew or validate an
2015 existing ticket, or when it wishes to obtain a proxy ticket. In the
2016 first case, the client must already have acquired a ticket for the
2017 Ticket-Granting Service using the AS exchange (the ticket-granting
2018 ticket is usually obtained when a client initially authenticates to
2019 the system, such as when a user logs in). The message format for the
2020 TGS exchange is almost identical to that for the AS exchange. The
2021 primary difference is that encryption and decryption in the TGS
2022 exchange does not take place under the client's key. Instead, the
2023 session key from the ticket-granting ticket or renewable ticket, or
2024 sub-session key from an Authenticator is used. As is the case for all
2025 application servers, expired tickets are not accepted by the TGS, so
2026 once a renewable or ticket-granting ticket expires, the client must
2027 use a separate exchange to obtain valid tickets.
2029 The TGS exchange consists of two messages: A request (KRB_TGS_REQ)
2030 from the client to the Kerberos Ticket-Granting Server, and a reply
2034 March 2003 [Page 34]
2040 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
2043 (KRB_TGS_REP or KRB_ERROR). The KRB_TGS_REQ message includes
2044 information authenticating the client plus a request for credentials.
2045 The authentication information consists of the authentication header
2046 (KRB_AP_REQ) which includes the client's previously obtained ticket-
2047 granting, renewable, or invalid ticket. In the ticket-granting
2048 ticket and proxy cases, the request MAY include one or more of: a
2049 list of network addresses, a collection of typed authorization data
2050 to be sealed in the ticket for authorization use by the application
2051 server, or additional tickets (the use of which are described later).
2052 The TGS reply (KRB_TGS_REP) contains the requested credentials,
2053 encrypted in the session key from the ticket-granting ticket or
2054 renewable ticket, or if present, in the sub-session key from the
2055 Authenticator (part of the authentication header). The KRB_ERROR
2056 message contains an error code and text explaining what went wrong.
2057 The KRB_ERROR message is not encrypted. The KRB_TGS_REP message
2058 contains information which can be used to detect replays, and to
2059 associate it with the message to which it replies. The KRB_ERROR
2060 message also contains information which can be used to associate it
2061 with the message to which it replies. The same comments about
2062 integrity protection of KRB_ERROR messages mentioned in section 3.1
2063 apply to the TGS exchange.
2065 3.3.1. Generation of KRB_TGS_REQ message
2067 Before sending a request to the ticket-granting service, the client
2068 MUST determine in which realm the application server is believed to
2069 be registered [15]. If the client knows the service principal name
2070 and realm and it does not already possess a ticket-granting ticket
2071 for the appropriate realm, then one must be obtained. This is first
2072 attempted by requesting a ticket-granting ticket for the destination
2073 realm from a Kerberos server for which the client possesses a ticket-
2074 granting ticket (using the KRB_TGS_REQ message recursively). The
2075 Kerberos server MAY return a TGT for the desired realm in which case
2076 one can proceed. Alternatively, the Kerberos server MAY return a TGT
2077 for a realm which is 'closer' to the desired realm (further along the
2078 standard hierarchical path between the client's realm and the
2079 requested realm server's realm). It should be noted in this case that
2080 misconfiguration of the Kerberos servers may cause loops in the
2081 resulting authentication path, which the client should be careful to
2084 If the Kerberos server returns a TGT for a 'closer' realm other than
2085 the desired realm, the client MAY use local policy configuration to
2086 verify that the authentication path used is an acceptable one.
2087 Alternatively, a client MAY choose its own authentication path,
2088 rather than relying on the Kerberos server to select one. In either
2089 case, any policy or configuration information used to choose or
2090 validate authentication paths, whether by the Kerberos server or
2094 March 2003 [Page 35]
2100 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
2103 client, MUST be obtained from a trusted source.
2105 When a client obtains a ticket-granting ticket that is 'closer' to
2106 the destination realm, the client MAY cache this ticket and reuse it
2107 in future KRB-TGS exchanges with services in the 'closer' realm.
2108 However, if the client were to obtain a ticket-granting ticket for
2109 the 'closer' realm by starting at the initial KDC rather than as part
2110 of obtaining another ticket, then a shorter path to the 'closer'
2111 realm might be used. This shorter path may be desirable because fewer
2112 intermediate KDCs would know the session key of the ticket involved.
2113 For this reason, clients SHOULD evaluate whether they trust the
2114 realms transited in obtaining the 'closer' ticket when making a
2115 decision to use the ticket in future.
2117 Once the client obtains a ticket-granting ticket for the appropriate
2118 realm, it determines which Kerberos servers serve that realm, and
2119 contacts one. The list might be obtained through a configuration file
2120 or network service or it MAY be generated from the name of the realm;
2121 as long as the secret keys exchanged by realms are kept secret, only
2122 denial of service results from using a false Kerberos server.
2124 (This paragraph changed) As in the AS exchange, the client MAY
2125 specify a number of options in the KRB_TGS_REQ message. One of these
2126 options is the ENC-TKT-IN-SKEY option used for user-to-user
2127 authentication. An overview of user to user authentication can be
2128 found in section 3.7. When generating the KRB_TGS_REQ message, this
2129 option indicates that the client is including a ticket-granting
2130 ticket obtained from the application server in the additional tickets
2131 field of the request and that the KDC SHOULD encrypt the ticket for
2132 the application server using the session key from this additional
2133 ticket, instead of using a server key from the principal database.
2135 The client prepares the KRB_TGS_REQ message, providing an
2136 authentication header as an element of the padata field, and
2137 including the same fields as used in the KRB_AS_REQ message along
2138 with several optional fields: the enc-authorizatfion-data field for
2139 application server use and additional tickets required by some
2142 In preparing the authentication header, the client can select a sub-
2143 session key under which the response from the Kerberos server will be
2144 encrypted [16]. If the sub-session key is not specified, the session
2145 key from the ticket-granting ticket will be used. If the enc-
2146 authorization-data is present, it MUST be encrypted in the sub-
2147 session key, if present, from the authenticator portion of the
2148 authentication header, or if not present, using the session key from
2149 the ticket-granting ticket.
2154 March 2003 [Page 36]
2160 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
2163 Once prepared, the message is sent to a Kerberos server for the
2166 3.3.2. Receipt of KRB_TGS_REQ message
2168 The KRB_TGS_REQ message is processed in a manner similar to the
2169 KRB_AS_REQ message, but there are many additional checks to be
2170 performed. First, the Kerberos server MUST determine which server the
2171 accompanying ticket is for and it MUST select the appropriate key to
2172 decrypt it. For a normal KRB_TGS_REQ message, it will be for the
2173 ticket granting service, and the TGS's key will be used. If the TGT
2174 was issued by another realm, then the appropriate inter-realm key
2175 MUST be used. If the accompanying ticket is not a ticket-granting
2176 ticket for the current realm, but is for an application server in the
2177 current realm, the RENEW, VALIDATE, or PROXY options are specified in
2178 the request, and the server for which a ticket is requested is the
2179 server named in the accompanying ticket, then the KDC will decrypt
2180 the ticket in the authentication header using the key of the server
2181 for which it was issued. If no ticket can be found in the padata
2182 field, the KDC_ERR_PADATA_TYPE_NOSUPP error is returned.
2184 Once the accompanying ticket has been decrypted, the user-supplied
2185 checksum in the Authenticator MUST be verified against the contents
2186 of the request, and the message rejected if the checksums do not
2187 match (with an error code of KRB_AP_ERR_MODIFIED) or if the checksum
2188 is not keyed or not collision-proof (with an error code of
2189 KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported, the
2190 KDC_ERR_SUMTYPE_NOSUPP error is returned. If the authorization-data
2191 are present, they are decrypted using the sub-session key from the
2194 If any of the decryptions indicate failed integrity checks, the
2195 KRB_AP_ERR_BAD_INTEGRITY error is returned.
2197 As discussed in section 3.1.2, the KDC MUST send a valid KRB_TGS_REP
2198 message if it receives a KRB_TGS_REQ message identical to one it has
2199 recently processed. However, if the authenticator is a replay, but
2200 the rest of the request is not identical, then the KDC SHOULD return
2203 3.3.3. Generation of KRB_TGS_REP message
2205 The KRB_TGS_REP message shares its format with the KRB_AS_REP
2206 (KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The
2207 detailed specification is in section 5.4.2.
2209 The response will include a ticket for the requested server or for a
2210 ticket granting server of an intermediate KDC to be contacted to
2214 March 2003 [Page 37]
2220 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
2223 obtain the requested ticket. The Kerberos database is queried to
2224 retrieve the record for the appropriate server (including the key
2225 with which the ticket will be encrypted). If the request is for a
2226 ticket-granting ticket for a remote realm, and if no key is shared
2227 with the requested realm, then the Kerberos server will select the
2228 realm 'closest' to the requested realm with which it does share a
2229 key, and use that realm instead. If the requested server cannot be
2230 found in the TGS database, then a TGT for another trusted realm MAY
2231 be returned instead of a ticket for the service. This TGT is a
2232 referral mechanism to cause the client to retry the request to the
2233 realm of the TGT. These are the only cases where the response for
2234 the KDC will be for a different server than that requested by the
2237 By default, the address field, the client's name and realm, the list
2238 of transited realms, the time of initial authentication, the
2239 expiration time, and the authorization data of the newly-issued
2240 ticket will be copied from the ticket-granting ticket (TGT) or
2241 renewable ticket. If the transited field needs to be updated, but the
2242 transited type is not supported, the KDC_ERR_TRTYPE_NOSUPP error is
2245 If the request specifies an endtime, then the endtime of the new
2246 ticket is set to the minimum of (a) that request, (b) the endtime
2247 from the TGT, and (c) the starttime of the TGT plus the minimum of
2248 the maximum life for the application server and the maximum life for
2249 the local realm (the maximum life for the requesting principal was
2250 already applied when the TGT was issued). If the new ticket is to be
2251 a renewal, then the endtime above is replaced by the minimum of (a)
2252 the value of the renew_till field of the ticket and (b) the starttime
2253 for the new ticket plus the life (endtime-starttime) of the old
2256 If the FORWARDED option has been requested, then the resulting ticket
2257 will contain the addresses specified by the client. This option will
2258 only be honored if the FORWARDABLE flag is set in the TGT. The PROXY
2259 option is similar; the resulting ticket will contain the addresses
2260 specified by the client. It will be honored only if the PROXIABLE
2261 flag in the TGT is set. The PROXY option will not be honored on
2262 requests for additional ticket-granting tickets.
2264 If the requested start time is absent, indicates a time in the past,
2265 or is within the window of acceptable clock skew for the KDC and the
2266 POSTDATE option has not been specified, then the start time of the
2267 ticket is set to the authentication server's current time. If it
2268 indicates a time in the future beyond the acceptable clock skew, but
2269 the POSTDATED option has not been specified or the MAY-POSTDATE flag
2270 is not set in the TGT, then the error KDC_ERR_CANNOT_POSTDATE is
2274 March 2003 [Page 38]
2280 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
2283 returned. Otherwise, if the ticket-granting ticket has the MAY-
2284 POSTDATE flag set, then the resulting ticket will be postdated and
2285 the requested starttime is checked against the policy of the local
2286 realm. If acceptable, the ticket's start time is set as requested,
2287 and the INVALID flag is set. The postdated ticket MUST be validated
2288 before use by presenting it to the KDC after the starttime has been
2289 reached. However, in no case may the starttime, endtime, or renew-
2290 till time of a newly-issued postdated ticket extend beyond the renew-
2291 till time of the ticket-granting ticket.
2293 If the ENC-TKT-IN-SKEY option has been specified and an additional
2294 ticket has been included in the request, it indicates that the client
2295 is using user- to-user authentication to prove its identity to a
2296 server that does not have access to a persistent key. Section 3.7
2297 describes the affect of this option on the entire Kerberos protocol.
2298 When generating the KRB_TGS_REP message, this option in the
2299 KRB_TGS_REQ message tells the KDC to decrypt the additional ticket
2300 using the key for the server to which the additional ticket was
2301 issued and verify that it is a ticket-granting ticket. If the name of
2302 the requested server is missing from the request, the name of the
2303 client in the additional ticket will be used. Otherwise the name of
2304 the requested server will be compared to the name of the client in
2305 the additional ticket and if different, the request will be rejected.
2306 If the request succeeds, the session key from the additional ticket
2307 will be used to encrypt the new ticket that is issued instead of
2308 using the key of the server for which the new ticket will be used.
2310 If the name of the server in the ticket that is presented to the KDC
2311 as part of the authentication header is not that of the ticket-
2312 granting server itself, the server is registered in the realm of the
2313 KDC, and the RENEW option is requested, then the KDC will verify that
2314 the RENEWABLE flag is set in the ticket, that the INVALID flag is not
2315 set in the ticket, and that the renew_till time is still in the
2316 future. If the VALIDATE option is requested, the KDC will check that
2317 the starttime has passed and the INVALID flag is set. If the PROXY
2318 option is requested, then the KDC will check that the PROXIABLE flag
2319 is set in the ticket. If the tests succeed, and the ticket passes the
2320 hotlist check described in the next section, the KDC will issue the
2321 appropriate new ticket.
2323 The ciphertext part of the response in the KRB_TGS_REP message is
2324 encrypted in the sub-session key from the Authenticator, if present,
2325 or the session key from the ticket-granting ticket. It is not
2326 encrypted using the client's secret key. Furthermore, the client's
2327 key's expiration date and the key version number fields are left out
2328 since these values are stored along with the client's database
2329 record, and that record is not needed to satisfy a request based on a
2330 ticket-granting ticket.
2334 March 2003 [Page 39]
2340 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
2343 3.3.3.1. Checking for revoked tickets
2345 Whenever a request is made to the ticket-granting server, the
2346 presented ticket(s) is(are) checked against a hot-list of tickets
2347 which have been canceled. This hot-list might be implemented by
2348 storing a range of issue timestamps for 'suspect tickets'; if a
2349 presented ticket had an authtime in that range, it would be rejected.
2350 In this way, a stolen ticket-granting ticket or renewable ticket
2351 cannot be used to gain additional tickets (renewals or otherwise)
2352 once the theft has been reported to the KDC for the realm in which
2353 the server resides. Any normal ticket obtained before it was reported
2354 stolen will still be valid (because they require no interaction with
2355 the KDC), but only until their normal expiration time. If TGT's have
2356 been issued for cross-realm authentication, use of the cross-realm
2357 TGT will not be affected unless the hot-list is propagated to the
2358 KDCs for the realms for which such cross-realm tickets were issued.
2360 3.3.3.2. Encoding the transited field
2362 If the identity of the server in the TGT that is presented to the KDC
2363 as part of the authentication header is that of the ticket-granting
2364 service, but the TGT was issued from another realm, the KDC will look
2365 up the inter-realm key shared with that realm and use that key to
2366 decrypt the ticket. If the ticket is valid, then the KDC will honor
2367 the request, subject to the constraints outlined above in the section
2368 describing the AS exchange. The realm part of the client's identity
2369 will be taken from the ticket-granting ticket. The name of the realm
2370 that issued the ticket-granting ticket, if it is not the realm of the
2371 client principal, will be added to the transited field of the ticket
2372 to be issued. This is accomplished by reading the transited field
2373 from the ticket-granting ticket (which is treated as an unordered set
2374 of realm names), adding the new realm to the set, then constructing
2375 and writing out its encoded (shorthand) form (this may involve a
2376 rearrangement of the existing encoding).
2378 Note that the ticket-granting service does not add the name of its
2379 own realm. Instead, its responsibility is to add the name of the
2380 previous realm. This prevents a malicious Kerberos server from
2381 intentionally leaving out its own name (it could, however, omit other
2384 The names of neither the local realm nor the principal's realm are to
2385 be included in the transited field. They appear elsewhere in the
2386 ticket and both are known to have taken part in authenticating the
2387 principal. Since the endpoints are not included, both local and
2388 single-hop inter-realm authentication result in a transited field
2394 March 2003 [Page 40]
2400 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
2403 Because the name of each realm transited is added to this field, it
2404 might potentially be very long. To decrease the length of this field,
2405 its contents are encoded. The initially supported encoding is
2406 optimized for the normal case of inter-realm communication: a
2407 hierarchical arrangement of realms using either domain or X.500 style
2408 realm names. This encoding (called DOMAIN-X500-COMPRESS) is now
2411 Realm names in the transited field are separated by a ",". The ",",
2412 "\", trailing "."s, and leading spaces (" ") are special characters,
2413 and if they are part of a realm name, they MUST be quoted in the
2414 transited field by preceding them with a "\".
2416 A realm name ending with a "." is interpreted as being prepended to
2417 the previous realm. For example, we can encode traversal of EDU,
2418 MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as:
2420 "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
2422 Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points,
2423 that they would not be included in this field, and we would have:
2425 "EDU,MIT.,WASHINGTON.EDU"
2427 A realm name beginning with a "/" is interpreted as being appended to
2428 the previous realm. For the purpose of appending, the realm
2429 preceding the first listed realm is considered to be the null realm
2430 (""). If a realm name beginning with a "/" is to stand by itself,
2431 then it SHOULD be preceded by a space (" "). For example, we can
2432 encode traversal of /COM/HP/APOLLO, /COM/HP, /COM, and /COM/DEC as:
2434 "/COM,/HP,/APOLLO, /COM/DEC".
2436 Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints,
2437 they would not be included in this field, and we would have:
2441 A null subfield preceding or following a "," indicates that all
2442 realms between the previous realm and the next realm have been
2443 traversed. For the purpose of interpreting null subfields, the
2444 client's realm is considered to precede those in the transited field,
2445 and the server's realm is considered to follow them. Thus, "," means
2446 that all realms along the path between the client and the server have
2447 been traversed. ",EDU, /COM," means that all realms from the client's
2448 realm up to EDU (in a domain style hierarchy) have been traversed,
2449 and that everything from /COM down to the server's realm in an X.500
2450 style has also been traversed. This could occur if the EDU realm in
2454 March 2003 [Page 41]
2460 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
2463 one hierarchy shares an inter-realm key directly with the /COM realm
2464 in another hierarchy.
2466 3.3.4. Receipt of KRB_TGS_REP message
2468 When the KRB_TGS_REP is received by the client, it is processed in
2469 the same manner as the KRB_AS_REP processing described above. The
2470 primary difference is that the ciphertext part of the response must
2471 be decrypted using the sub-session key from the Authenticator, if it
2472 was specified in the request, or the session key from the ticket-
2473 granting ticket, rather than the client's secret key. The server name
2474 returned in the reply is the true principal name of the service.
2476 3.4. The KRB_SAFE Exchange
2478 The KRB_SAFE message MAY be used by clients requiring the ability to
2479 detect modifications of messages they exchange. It achieves this by
2480 including a keyed collision-proof checksum of the user data and some
2481 control information. The checksum is keyed with an encryption key
2482 (usually the last key negotiated via subkeys, or the session key if
2483 no negotiation has occurred).
2485 3.4.1. Generation of a KRB_SAFE message
2487 When an application wishes to send a KRB_SAFE message, it collects
2488 its data and the appropriate control information and computes a
2489 checksum over them. The checksum algorithm should be the keyed
2490 checksum mandated to be implemented along with the crypto system used
2491 for the sub-session or session key. The checksum is generated using
2492 the sub-session key if present, and the session key. Some
2493 implementations use a different checksum algorithm for the KRB_SAFE
2494 messages but doing so in a interoperable manner is not always
2497 Implementations SHOULD accept any checksum algorithm they implement
2498 that both have adequate security and that have keys compatible with
2499 the sub-session or session key. Unkeyed or non-collision-proof
2500 checksums are not suitable for this use.
2502 The control information for the KRB_SAFE message includes both a
2503 timestamp and a sequence number. The designer of an application using
2504 the KRB_SAFE message MUST choose at least one of the two mechanisms.
2505 This choice SHOULD be based on the needs of the application protocol.
2507 Sequence numbers are useful when all messages sent will be received
2508 by one's peer. Connection state is presently required to maintain the
2509 session key, so maintaining the next sequence number should not
2510 present an additional problem.
2514 March 2003 [Page 42]
2520 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
2523 If the application protocol is expected to tolerate lost messages
2524 without them being resent, the use of the timestamp is the
2525 appropriate replay detection mechanism. Using timestamps is also the
2526 appropriate mechanism for multi-cast protocols where all of one's
2527 peers share a common sub-session key, but some messages will be sent
2528 to a subset of one's peers.
2530 After computing the checksum, the client then transmits the
2531 information and checksum to the recipient in the message format
2532 specified in section 5.6.1.
2534 3.4.2. Receipt of KRB_SAFE message
2536 When an application receives a KRB_SAFE message, it verifies it as
2537 follows. If any error occurs, an error code is reported for use by
2540 The message is first checked by verifying that the protocol version
2541 and type fields match the current version and KRB_SAFE, respectively.
2542 A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE
2543 error. The application verifies that the checksum used is a
2544 collision-proof keyed checksum that uses keys compatible with the
2545 sub-session or session key as appropriate (or with the application
2546 key derived from the session or sub-session keys), and if it is not,
2547 a KRB_AP_ERR_INAPP_CKSUM error is generated. The sender's address
2548 MUST be included in the control information; the recipient verifies
2549 that the operating system's report of the sender's address matches
2550 the sender's address in the message, and (if a recipient address is
2551 specified or the recipient requires an address) that one of the
2552 recipient's addresses appears as the recipient's address in the
2553 message. To work with network address translation, senders MAY use
2554 the directional address type specified in section 8.1 for the sender
2555 address and not include recipient addresses. A failed match for
2556 either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp
2557 and usec and/or the sequence number fields are checked. If timestamp
2558 and usec are expected and not present, or they are present but not
2559 current, the KRB_AP_ERR_SKEW error is generated. If the server name,
2560 along with the client name, time and microsecond fields from the
2561 Authenticator match any recently-seen (sent or received) such tuples,
2562 the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence
2563 number is included, or a sequence number is expected but not present,
2564 the KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp
2565 and usec or a sequence number is present, a KRB_AP_ERR_MODIFIED error
2566 is generated. Finally, the checksum is computed over the data and
2567 control information, and if it doesn't match the received checksum, a
2568 KRB_AP_ERR_MODIFIED error is generated.
2570 If all the checks succeed, the application is assured that the
2574 March 2003 [Page 43]
2580 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
2583 message was generated by its peer and was not modified in transit.
2585 3.5. The KRB_PRIV Exchange
2587 The KRB_PRIV message MAY be used by clients requiring confidentiality
2588 and the ability to detect modifications of exchanged messages. It
2589 achieves this by encrypting the messages and adding control
2592 3.5.1. Generation of a KRB_PRIV message
2594 When an application wishes to send a KRB_PRIV message, it collects
2595 its data and the appropriate control information (specified in
2596 section 5.7.1) and encrypts them under an encryption key (usually the
2597 last key negotiated via subkeys, or the session key if no negotiation
2598 has occurred). As part of the control information, the client MUST
2599 choose to use either a timestamp or a sequence number (or both); see
2600 the discussion in section 3.4.1 for guidelines on which to use. After
2601 the user data and control information are encrypted, the client
2602 transmits the ciphertext and some 'envelope' information to the
2605 3.5.2. Receipt of KRB_PRIV message
2607 When an application receives a KRB_PRIV message, it verifies it as
2608 follows. If any error occurs, an error code is reported for use by
2611 The message is first checked by verifying that the protocol version
2612 and type fields match the current version and KRB_PRIV, respectively.
2613 A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE
2614 error. The application then decrypts the ciphertext and processes the
2615 resultant plaintext. If decryption shows the data to have been
2616 modified, a KRB_AP_ERR_BAD_INTEGRITY error is generated.
2618 The sender's address MUST be included in the control information; the
2619 recipient verifies that the operating system's report of the sender's
2620 address matches the sender's address in the message. If a recipient
2621 address is specified or the recipient requires an address then one of
2622 the recipient's addresses MUST also appear as the recipient's address
2623 in the message. Where a sender's or receiver's address might not
2624 otherwise match the address in a message because of network address
2625 translation, an application MAY be written to use addresses of the
2626 directional address type in place of the actual network address.
2628 A failed match for either case generates a KRB_AP_ERR_BADADDR error.
2629 To work with network address translation, implementations MAY use the
2630 directional address type defined in section 7.1 for the sender
2634 March 2003 [Page 44]
2640 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
2643 address and include no recipient address. Then the timestamp and usec
2644 and/or the sequence number fields are checked. If timestamp and usec
2645 are expected and not present, or they are present but not current,
2646 the KRB_AP_ERR_SKEW error is generated. If the server name, along
2647 with the client name, time and microsecond fields from the
2648 Authenticator match any recently-seen such tuples, the
2649 KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence number
2650 is included, or a sequence number is expected but not present, the
2651 KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and
2652 usec or a sequence number is present, a KRB_AP_ERR_MODIFIED error is
2655 If all the checks succeed, the application can assume the message was
2656 generated by its peer, and was securely transmitted (without
2657 intruders able to see the unencrypted contents).
2659 3.6. The KRB_CRED Exchange
2661 The KRB_CRED message MAY be used by clients requiring the ability to
2662 send Kerberos credentials from one host to another. It achieves this
2663 by sending the tickets together with encrypted data containing the
2664 session keys and other information associated with the tickets.
2666 3.6.1. Generation of a KRB_CRED message
2668 When an application wishes to send a KRB_CRED message it first (using
2669 the KRB_TGS exchange) obtains credentials to be sent to the remote
2670 host. It then constructs a KRB_CRED message using the ticket or
2671 tickets so obtained, placing the session key needed to use each
2672 ticket in the key field of the corresponding KrbCredInfo sequence of
2673 the encrypted part of the KRB_CRED message.
2675 Other information associated with each ticket and obtained during the
2676 KRB_TGS exchange is also placed in the corresponding KrbCredInfo
2677 sequence in the encrypted part of the KRB_CRED message. The current
2678 time and, if specifically required by the application (and
2679 communicated from the recipient to the sender by application specific
2680 means) the nonce, s-address, and r-address fields, are placed in the
2681 encrypted part of the KRB_CRED message which is then encrypted under
2682 an encryption key previously exchanged in the KRB_AP exchange
2683 (usually the last key negotiated via subkeys, or the session key if
2684 no negotiation has occurred).
2686 Implementation note: When constructing a KRB_CRED message for
2687 inclusion in a GSSAPI initial context token, the MIT implementation
2688 of Kerberos will not encrypt the KRB_CRED message if the session key
2689 is a DES or triple DES key. For interoperability with MIT, the
2690 Microsoft implementation will not encrypt the KRB_CRED in a GSSAPI
2694 March 2003 [Page 45]
2700 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
2703 token if it is using a DES session key. Starting at version 1.2.5,
2704 MIT Kerberos can receive and decode either encrypted or unencrypted
2705 KRB_CRED tokens in the GSSAPI exchange. The Heimdal implementation of
2706 Kerberos can also accept either encrypted or unencrypted KRB_CRED
2707 messages. Since the KRB_CRED message in a GSSAPI token is encrypted
2708 in the authenticator, the MIT behavior does not present a security
2709 problem, although it is a violation of the Kerberos specification.
2711 3.6.2. Receipt of KRB_CRED message
2713 When an application receives a KRB_CRED message, it verifies it. If
2714 any error occurs, an error code is reported for use by the
2715 application. The message is verified by checking that the protocol
2716 version and type fields match the current version and KRB_CRED,
2717 respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or
2718 KRB_AP_ERR_MSG_TYPE error. The application then decrypts the
2719 ciphertext and processes the resultant plaintext. If decryption shows
2720 the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is
2723 If present or required, the recipient MAY verify that the operating
2724 system's report of the sender's address matches the sender's address
2725 in the message, and that one of the recipient's addresses appears as
2726 the recipient's address in the message. The address check does not
2727 provide any added security, since the address if present has already
2728 been checked in the KRB_AP_REQ message and there is not any benefit
2729 to be gained by an attacker in reflecting a KRB_CRED message back to
2730 its originator. Thus, the recipient MAY ignore the address even if
2731 present in order to work better in NAT environments. A failed match
2732 for either case generates a KRB_AP_ERR_BADADDR error. Recipients MAY
2733 skip the address check as the KRB_CRED message cannot generally be
2734 reflected back to the originator. The timestamp and usec fields (and
2735 the nonce field if required) are checked next. If the timestamp and
2736 usec are not present, or they are present but not current, the
2737 KRB_AP_ERR_SKEW error is generated.
2739 If all the checks succeed, the application stores each of the new
2740 tickets in its credentials cache together with the session key and
2741 other information in the corresponding KrbCredInfo sequence from the
2742 encrypted part of the KRB_CRED message.
2744 3.7. User to User Authentication Exchanges
2746 User to User authentication provides a method to perform
2747 authentication when the verifier does not have a access to long term
2748 service key. This might be the case when running a server (for
2749 example a window server) as a user on a workstation. In such cases,
2750 the server may have access to the ticket-granting ticket obtained
2754 March 2003 [Page 46]
2760 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
2763 when the user logged in to the workstation, but because the server is
2764 running as an unprivileged user it might not have access to system
2765 keys. Similar situations may arise when running peer-to-peer
2769 Message direction Message type Sections
2770 0. Message from application server Not Specified
2771 1. Client to Kerberos KRB_TGS_REQ 3.3 + 5.4.1
2772 2. Kerberos to client KRB_TGS_REP or 3.3 + 5.4.2
2774 3. Client to Application server KRB_AP_REQ 3.2 + 5.5.1
2776 To address this problem, the Kerberos protocol allows the client to
2777 request that the ticket issued by the KDC be encrypted using a
2778 session key from a ticket-granting ticket issued to the party that
2779 will verify the authentication. This ticket-granting ticket must be
2780 obtained from the verifier by means of an exchange external to the
2781 Kerberos protocol, usually as part of the application protocol. This
2782 message is shown in the summary above as message 0. Note that because
2783 the ticket-granting ticket is encrypted in the KDC's secret key, it
2784 can not be used for authentication without posession of the
2785 corresponding secret key. Furthermore, because the verifier does not
2786 reveal the corresponding secret key, providing a copy of the
2787 verifier's ticket-granting ticket does not allow impersonation of the
2790 Message 0 in the table above represents an application specific
2791 negotation between the client and server, at the end of which both
2792 have determined that they will use user to user authentication and
2793 the client has obtained the server's TGT.
2795 Next, the client includes the server's TGT as an additional ticket in
2796 its KRB_TGS_REQ request to the KDC (message 1 in the table above) and
2797 specifyies the ENC-TKT-IN-SKEY option in its request.
2799 If validated according to the instructions in 3.3.3, the application
2800 ticket returned to the client (message 2 in the table above) will be
2801 encrypted using the session key from the additional ticket and the
2802 client will note this when it uses or stores the application ticket.
2804 When contacting the server using a ticket obtained for user to user
2805 authentication (message 3 in the table above), the client MUST
2806 specify the USE-SESSION-KEY flag in the ap-options field. This tells
2807 the application server to use the session key associated with its
2808 ticket-granting ticket to decrypt the server ticket provided in the
2809 application request.
2814 March 2003 [Page 47]
2820 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
2823 4. Encryption and Checksum Specifications
2825 The Kerberos protocols described in this document are designed to
2826 encrypt messages of arbitrary sizes, using stream or block encryption
2827 ciphers. Encryption is used to prove the identities of the network
2828 entities participating in message exchanges. The Key Distribution
2829 Center for each realm is trusted by all principals registered in that
2830 realm to store a secret key in confidence. Proof of knowledge of this
2831 secret key is used to verify the authenticity of a principal.
2833 The KDC uses the principal's secret key (in the AS exchange) or a
2834 shared session key (in the TGS exchange) to encrypt responses to
2835 ticket requests; the ability to obtain the secret key or session key
2836 implies the knowledge of the appropriate keys and the identity of the
2837 KDC. The ability of a principal to decrypt the KDC response and
2838 present a Ticket and a properly formed Authenticator (generated with
2839 the session key from the KDC response) to a service verifies the
2840 identity of the principal; likewise the ability of the service to
2841 extract the session key from the Ticket and prove its knowledge
2842 thereof in a response verifies the identity of the service.
2844 [@KCRYPTO] defines a framework for defining encryption and checksum
2845 mechanisms for use with Kerberos. It also defines several such
2846 mechanisms, and more may be added in future updates to that document.
2848 The string-to-key operation provided by [@KCRYPTO] is used to produce
2849 a long-term key for a principal (generally for a user). The default
2850 salt string, if none is provided via pre-authentication data, is the
2851 concatenation of the principal's realm and name components, in order,
2852 with no separators. Unless otherwise indicated, the default string-
2853 to-key opaque parameter set as defined in [@KCRYPTO] is used.
2855 Encrypted data, keys and checksums are transmitted using the
2856 EncryptedData, EncryptionKey and Checksum data objects defined in
2857 section 5.2.9. The encryption, decryption, and checksum operations
2858 described in this document use the corresponding encryption,
2859 decryption, and get_mic operations described in [@KCRYPTO], with
2860 implicit "specific key" generation using the "key usage" values
2861 specified in the description of each EncryptedData or Checksum object
2862 to vary the key for each operation. Note that in some cases, the
2863 value to be used is dependent on the method of choosing the key or
2864 the context of the message.
2866 Key usages are unsigned 32 bit integers; zero is not permitted. The
2867 key usage values for encrypting or checksumming Kerberos messages are
2868 indicated in section 5 along with the message definitions. Key usage
2869 values 512-1023 are reserved for uses internal to a Kerberos
2870 implementation. (For example, seeding a pseudo-random number
2874 March 2003 [Page 48]
2880 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
2883 generator with a value produced by encrypting something with a
2884 session key and a key usage value not used for any other purpose.)
2885 Key usage values between 1024 and 2047 (inclusive) are reserved for
2886 application use; applications SHOULD use even values for encryption
2887 and odd values for checksums within this range. Key usage values are
2888 also summarized in a table in section 7.5.1.
2890 There might exist other documents which define protocols in terms of
2891 the RFC1510 encryption types or checksum types. Such documents would
2892 not know about key usages. In order that these specifications
2893 continue to be meaningful until they are updated, if not key usage
2894 values are specified then key usages 1024 and 1025 must be used to
2895 derive keys for encryption and checksums, respectively (this does not
2896 apply to protocols that do their own encryption independent of this
2897 framework, directly using the key resulting from the Kerberos
2898 authentication exchange.) New protocols defined in terms of the
2899 Kerberos encryption and checksum types SHOULD use their own key usage
2902 Unless otherwise indicated, no cipher state chaining is done from one
2903 encryption operation to another.
2905 Implementation note: While not recommended, some application
2906 protocols will continue to use the key data directly, even if only in
2907 currently existing protocol specifications. An implementation
2908 intended to support general Kerberos applications may therefore need
2909 to make key data available, as well as the attributes and operations
2910 described in [@KCRYPTO]. One of the more common reasons for directly
2911 performing encryption is direct control over negotiation and
2912 selection of a "sufficiently strong" encryption algorithm (in the
2913 context of a given application). While Kerberos does not directly
2914 provide a facility for negotiating encryption types between the
2915 application client and server, there are approaches for using
2916 Kerberos to facilitate this negotiation - for example, a client may
2917 request only "sufficiently strong" session key types from the KDC and
2918 expect that any type returned by the KDC will be understood and
2919 supported by the application server.
2921 5. Message Specifications
2923 NOTE: The ASN.1 collected here should be identical to the contents of
2924 Appendix A. In case of conflict, the contents of Appendix A shall
2927 The Kerberos protocol is defined here in terms of Abstract Syntax
2928 Notation One (ASN.1) [X680], which provides a syntax for specifying
2929 both the abstract layout of protocol messages as well as their
2930 encodings. Implementors not utilizing an existing ASN.1 compiler or
2934 March 2003 [Page 49]
2940 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
2943 support library are cautioned to thoroughly understand the actual
2944 ASN.1 specification to ensure correct implementation behavior, as
2945 there is more complexity in the notation than is immediately obvious,
2946 and some tutorials and guides to ASN.1 are misleading or erroneous.
2948 Note that in several places, there have been changes here from RFC
2949 1510 that change the abstract types. This is in part to address
2950 widespread assumptions that various implementors have made, in some
2951 cases resulting in unintentional violations of the ASN.1 standard.
2952 These are clearly flagged where they occur. The differences between
2953 the abstract types in RFC 1510 and abstract types in this document
2954 can cause incompatible encodings to be emitted when certain encoding
2955 rules, e.g. the Packed Encoding Rules (PER), are used. This
2956 theoretical incompatibility should not be relevant for Kerberos,
2957 since Kerberos explicitly specifies the use of the Distinguished
2958 Encoding Rules (DER). It might be an issue for protocols wishing to
2959 use Kerberos types with other encoding rules. (This practice is not
2960 recommended.) With very few exceptions (most notably the usages of
2961 BIT STRING), the encodings resulting from using the DER remain
2962 identical between the types defined in RFC 1510 and the types defined
2965 The type definitions in this section assume an ASN.1 module
2966 definition of the following form:
2969 iso(1) identified-organization(3) dod(6) internet(1)
2970 security(5) kerberosV5(2) modules(4) krb5spec2(2)
2971 } DEFINITIONS EXPLICIT TAGS ::= BEGIN
2973 -- rest of definitions here
2977 This specifies that the tagging context for the module will be
2978 explicit and non-automatic.
2980 Note that in some other publications [RFC1510] [RFC1964], the "dod"
2981 portion of the object identifier is erroneously specified as having
2982 the value "5". In the case of RFC 1964, use of the "correct" OID
2983 value would result in a change in the wire protocol; therefore, it
2984 remains unchanged for now.
2986 Note that elsewhere in this document, nomenclature for various
2987 message types is inconsistent, but seems to largely follow C language
2988 conventions, including use of underscore (_) characters and all-caps
2989 spelling of names intended to be numeric constants. Also, in some
2990 places, identifiers (especially ones refering to constants) are
2994 March 2003 [Page 50]
3000 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
3003 written in all-caps in order to distinguish them from surrounding
3006 The ASN.1 notation does not permit underscores in identifiers, so in
3007 actual ASN.1 definitions, underscores are replaced with hyphens (-).
3008 Additionally, structure member names and defined values in ASN.1 MUST
3009 begin with a lowercase letter, while type names MUST begin with an
3012 5.1. Specific Compatibility Notes on ASN.1
3014 For compatibility purposes, implementors should heed the following
3015 specific notes regarding the use of ASN.1 in Kerberos. These notes do
3016 not describe deviations from standard usage of ASN.1. The purpose of
3017 these notes is to instead describe some historical quirks and non-
3018 compliance of various implementations, as well as historical
3019 ambiguities, which, while being valid ASN.1, can lead to confusion
3020 during implementation.
3022 5.1.1. ASN.1 Distinguished Encoding Rules
3024 The encoding of Kerberos protocol messages shall obey the
3025 Distinguished Encoding Rules (DER) of ASN.1 as described in [X690].
3026 Some implementations (believed to be primarly ones derived from DCE
3027 1.1 and earlier) are known to use the more general Basic Encoding
3028 Rules (BER); in particular, these implementations send indefinite
3029 encodings of lengths. Implementations MAY accept such encodings in
3030 the interests of backwards compatibility, though implementors are
3031 warned that decoding fully-general BER is fraught with peril.
3033 5.1.2. Optional Integer Fields
3035 Some implementations do not internally distinguish between an omitted
3036 optional integer value and a transmitted value of zero. The places in
3037 the protocol where this is relevant include various microseconds
3038 fields, nonces, and sequence numbers. Implementations SHOULD treat
3039 omitted optional integer values as having been transmitted with a
3040 value of zero, if the application is expecting this.
3042 5.1.3. Empty SEQUENCE OF Types
3044 There are places in the protocol where a message contains a SEQUENCE
3045 OF type as an optional member. This can result in an encoding that
3046 contains an empty SEQUENCE OF encoding. The Kerberos protocol does
3047 not semantically distinguish between an absent optional SEQUENCE OF
3048 type and a present optional but empty SEQUENCE OF type.
3049 Implementations SHOULD NOT send empty SEQUENCE OF encodings that are
3050 marked OPTIONAL, but SHOULD accept them as being equivalent to an
3054 March 2003 [Page 51]
3060 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
3063 omitted OPTIONAL type. In the ASN.1 syntax describing Kerberos
3064 messages, instances of these problematic optional SEQUENCE OF types
3065 are indicated with a comment.
3067 5.1.4. Unrecognized Tag Numbers
3069 Future revisions to this protocol may include new message types with
3070 different APPLICATION class tag numbers. Such revisions should
3071 protect older implementations by only sending the message types to
3072 parties that are known to understand them, e.g. by means of a flag
3073 bit set by the receiver in a preceding request. In the interest of
3074 robust error handling, implementations SHOULD gracefully handle
3075 receiving a message with an unrecognized tag anyway, and return an
3076 error message if appropriate.
3078 5.1.5. Tag Numbers Greater Than 30
3080 A naive implementation of a DER ASN.1 decoder may experience problems
3081 with ASN.1 tag numbers greater than 30, due to such tag numbers being
3082 encoded using more than one byte. Future revisions of this protocol
3083 may utilize tag numbers greater than 30, and implementations SHOULD
3084 be prepared to gracefully return an error, if appropriate, if they do
3085 not recognize the tag.
3087 5.2. Basic Kerberos Types
3089 This section defines a number of basic types that are potentially
3090 used in multiple Kerberos protocol messages.
3092 5.2.1. KerberosString
3094 The original specification of the Kerberos protocol in RFC 1510 uses
3095 GeneralString in numerous places for human-readable string data.
3096 Historical implementations of Kerberos cannot utilize the full power
3097 of GeneralString. This ASN.1 type requires the use of designation
3098 and invocation escape sequences as specified in ISO-2022/ECMA-35
3099 [ISO-2022/ECMA-35] to switch character sets, and the default
3100 character set that is designated as G0 is the ISO-646/ECMA-6
3101 [ISO-646,ECMA-6] International Reference Version (IRV) (aka U.S.
3102 ASCII), which mostly works.
3104 ISO-2022/ECMA-35 defines four character-set code elements (G0..G3)
3105 and two Control-function code elements (C0..C1). DER prohibits the
3106 designation of character sets as any but the G0 and C0 sets.
3107 Unfortunately, this seems to have the side effect of prohibiting the
3108 use of ISO-8859 (ISO Latin) [ISO-8859] character-sets or any other
3109 character-sets that utilize a 96-character set, since it is
3110 prohibited by ISO-2022/ECMA-35 to designate them as the G0 code
3114 March 2003 [Page 52]
3120 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
3123 element. This side effect is being investigated in the ASN.1
3124 standards community.
3126 In practice, many implementations treat GeneralStrings as if they
3127 were 8-bit strings of whichever character set the implementation
3128 defaults to, without regard for correct usage of character-set
3129 designation escape sequences. The default character set is often
3130 determined by the current user's operating system dependent locale.
3131 At least one major implementation places unescaped UTF-8 encoded
3132 Unicode characters in the GeneralString. This failure to adhere to
3133 the GeneralString specifications results in interoperability issues
3134 when conflicting character encodings are utilized by the Kerberos
3135 clients, services, and KDC.
3137 This unfortunate situation is the result of improper documentation of
3138 the restrictions of the ASN.1 GeneralString type in prior Kerberos
3141 The new (post-RFC 1510) type KerberosString, defined below, is a
3142 GeneralString that is constrained to only contain characters in
3145 KerberosString ::= GeneralString (IA5String)
3147 US-ASCII control characters should in general not be used in
3148 KerberosString, except for cases such as newlines in lengthy error
3149 messages. Control characters SHOULD NOT be used in principal names or
3152 For compatibility, implementations MAY choose to accept GeneralString
3153 values that contain characters other than those permitted by
3154 IA5String, but they should be aware that character set designation
3155 codes will likely be absent, and that the encoding should probably be
3156 treated as locale-specific in almost every way. Implementations MAY
3157 also choose to emit GeneralString values that are beyond those
3158 permitted by IA5String, but should be aware that doing so is
3159 extraordinarily risky from an interoperability perspective.
3161 Some existing implementations use GeneralString to encode unescaped
3162 locale-specific characters. This is a violation of the ASN.1
3163 standard. Most of these implementations encode US-ASCII in the left-
3164 hand half, so as long the implementation transmits only US-ASCII, the
3165 ASN.1 standard is not violated in this regard. As soon as such an
3166 implementation encodes unescaped locale-specific characters with the
3167 high bit set, it violates the ASN.1 standard.
3169 Other implementations have been known to use GeneralString to contain
3170 a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8
3174 March 2003 [Page 53]
3180 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
3183 is a different encoding, not a 94 or 96 character "G" set as defined
3184 by ISO 2022. It is believed that these implementations do not even
3185 use the ISO 2022 escape sequence to change the character encoding.
3186 Even if implementations were to announce the change of encoding by
3187 using that escape sequence, the ASN.1 standard prohibits the use of
3188 any escape sequences other than those used to designate/invoke "G" or
3189 "C" sets allowed by GeneralString.
3191 Future revisions to this protocol will almost certainly allow for a
3192 more interoperable representation of principal names, probably
3193 including UTF8String.
3195 Note that applying a new constraint to a previously unconstrained
3196 type constitutes creation of a new ASN.1 type. In this particular
3197 case, the change does not result in a changed encoding under DER.
3199 5.2.2. Realm and PrincipalName
3201 Realm ::= KerberosString
3203 PrincipalName ::= SEQUENCE {
3204 name-type [0] Int32,
3205 name-string [1] SEQUENCE OF KerberosString
3208 Kerberos realm names are encoded as KerberosStrings. Realms shall not
3209 contain a character with the code 0 (the US-ASCII NUL). Most realms
3210 will usually consist of several components separated by periods (.),
3211 in the style of Internet Domain Names, or separated by slashes (/) in
3212 the style of X.500 names. Acceptable forms for realm names are
3213 specified in section 6.1.. A PrincipalName is a typed sequence of
3214 components consisting of the following sub-fields:
3217 This field specifies the type of name that follows. Pre-defined
3218 values for this field are specified in section 6.2. The name-type
3219 SHOULD be treated as a hint. Ignoring the name type, no two names
3220 can be the same (i.e. at least one of the components, or the
3221 realm, must be different).
3224 This field encodes a sequence of components that form a name, each
3225 component encoded as a KerberosString. Taken together, a
3226 PrincipalName and a Realm form a principal identifier. Most
3227 PrincipalNames will have only a few components (typically one or
3234 March 2003 [Page 54]
3240 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
3243 KerberosTime ::= GeneralizedTime -- with no fractional seconds
3245 The timestamps used in Kerberos are encoded as GeneralizedTimes. A
3246 KerberosTime value shall not include any fractional portions of the
3247 seconds. As required by the DER, it further shall not include any
3248 separators, and it shall specify the UTC time zone (Z). Example: The
3249 only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
3250 November 1985 is 19851106210627Z.
3252 5.2.4. Constrained Integer types
3254 Some integer members of types SHOULD be constrained to values
3255 representable in 32 bits, for compatibility with reasonable
3256 implementation limits.
3258 Int32 ::= INTEGER (-2147483648..2147483647)
3259 -- signed values representable in 32 bits
3261 UInt32 ::= INTEGER (0..4294967295)
3262 -- unsigned 32 bit values
3264 Microseconds ::= INTEGER (0..999999)
3267 While this results in changes to the abstract types from the RFC 1510
3268 version, the encoding in DER should be unaltered. Historical
3269 implementations were typically limited to 32-bit integer values
3270 anyway, and assigned numbers SHOULD fall in the space of integer
3271 values representable in 32 bits in order to promote interoperability
3274 There are several integer fields in messages that are constrained to
3278 also TKT-VNO or AUTHENTICATOR-VNO, this recurring field is always
3279 the constant integer 5. There is no easy way to make this field
3280 into a useful protocol version number, so its value is fixed.
3283 this integer field is usually identical to the application tag
3284 number of the containing message type.
3286 5.2.5. HostAddress and HostAddresses
3288 HostAddress ::= SEQUENCE {
3289 addr-type [0] Int32,
3290 address [1] OCTET STRING
3294 March 2003 [Page 55]
3300 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
3305 -- NOTE: HostAddresses is always used as an OPTIONAL field and
3306 -- should not be empty.
3307 HostAddresses -- NOTE: subtly different from rfc1510,
3308 -- but has a value mapping and encodes the same
3309 ::= SEQUENCE OF HostAddress
3311 The host address encodings consists of two fields:
3314 This field specifies the type of address that follows. Pre-defined
3315 values for this field are specified in section 7.5.3.
3318 This field encodes a single address of type addr-type.
3320 5.2.6. AuthorizationData
3322 -- NOTE: AuthorizationData is always used as an OPTIONAL field and
3323 -- should not be empty.
3324 AuthorizationData ::= SEQUENCE OF SEQUENCE {
3326 ad-data [1] OCTET STRING
3330 This field contains authorization data to be interpreted according
3331 to the value of the corresponding ad-type field.
3334 This field specifies the format for the ad-data subfield. All
3335 negative values are reserved for local use. Non-negative values
3336 are reserved for registered use.
3338 Each sequence of type and data is referred to as an authorization
3339 element. Elements MAY be application specific, however, there is a
3340 common set of recursive elements that should be understood by all
3341 implementations. These elements contain other elements embedded
3342 within them, and the interpretation of the encapsulating element
3343 determines which of the embedded elements must be interpreted, and
3344 which may be ignored.
3346 These common authorization data elements are recursively defined,
3347 meaning the ad-data for these types will itself contain a sequence of
3348 authorization data whose interpretation is affected by the
3349 encapsulating element. Depending on the meaning of the encapsulating
3350 element, the encapsulated elements may be ignored, might be
3354 March 2003 [Page 56]
3360 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
3363 interpreted as issued directly by the KDC, or they might be stored in
3364 a separate plaintext part of the ticket. The types of the
3365 encapsulating elements are specified as part of the Kerberos
3366 specification because the behavior based on these values should be
3367 understood across implementations whereas other elements need only be
3368 understood by the applications which they affect.
3370 Authorization data elements are considered critical if present in a
3371 ticket or authenticator. Unless encapsulated in a known authorization
3372 data element amending the criticality of the elements it contains, if
3373 an unknown authorization data element type is received by a server
3374 either in an AP-REQ or in a ticket contained in an AP-REQ, then
3375 authentication MUST fail. Authorization data is intended to restrict
3376 the use of a ticket. If the service cannot determine whether the
3377 restriction applies to that service then a security weakness may
3378 result if the ticket can be used for that service. Authorization
3379 elements that are optional can be enclosed in AD-IF-RELEVANT element.
3381 In the definitions that follow, the value of the ad-type for the
3382 element will be specified as the least significant part of the
3383 subsection number, and the value of the ad-data will be as shown in
3384 the ASN.1 structure that follows the subsection heading.
3386 contents of ad-data ad-type
3388 DER encoding of AD-IF-RELEVANT 1
3390 DER encoding of AD-KDCIssued 4
3392 DER encoding of AD-AND-OR 5
3394 DER encoding of AD-MANDATORY-FOR-KDC 8
3396 5.2.6.1. IF-RELEVANT
3398 AD-IF-RELEVANT ::= AuthorizationData
3400 AD elements encapsulated within the if-relevant element are intended
3401 for interpretation only by application servers that understand the
3402 particular ad-type of the embedded element. Application servers that
3403 do not understand the type of an element embedded within the if-
3404 relevant element MAY ignore the uninterpretable element. This element
3405 promotes interoperability across implementations which may have local
3406 extensions for authorization. The ad-type for AD-IF-RELEVANT is (1).
3410 AD-KDCIssued ::= SEQUENCE {
3414 March 2003 [Page 57]
3420 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
3423 ad-checksum [0] Checksum,
3424 i-realm [1] Realm OPTIONAL,
3425 i-sname [2] PrincipalName OPTIONAL,
3426 elements [3] AuthorizationData
3430 A checksum over the elements field using a cryptographic checksum
3431 method that is identical to the checksum used to protect the
3432 ticket itself (i.e. using the same hash function and the same
3433 encryption algorithm used to encrypt the ticket) using the key
3434 used to protect the ticket, and a key usage value of 19.
3437 The name of the issuing principal if different from the KDC
3438 itself. This field would be used when the KDC can verify the
3439 authenticity of elements signed by the issuing principal and it
3440 allows this KDC to notify the application server of the validity
3444 A sequence of authorization data elements issued by the KDC.
3446 The KDC-issued ad-data field is intended to provide a means for
3447 Kerberos principal credentials to embed within themselves privilege
3448 attributes and other mechanisms for positive authorization,
3449 amplifying the privileges of the principal beyond what can be done
3450 using a credentials without such an a-data element.
3452 This can not be provided without this element because the definition
3453 of the authorization-data field allows elements to be added at will
3454 by the bearer of a TGT at the time that they request service tickets
3455 and elements may also be added to a delegated ticket by inclusion in
3458 For KDC-issued elements this is prevented because the elements are
3459 signed by the KDC by including a checksum encrypted using the
3460 server's key (the same key used to encrypt the ticket - or a key
3461 derived from that key). Elements encapsulated with in the KDC-issued
3462 element will be ignored by the application server if this "signature"
3463 is not present. Further, elements encapsulated within this element
3464 from a ticket-granting ticket MAY be interpreted by the KDC, and used
3465 as a basis according to policy for including new signed elements
3466 within derivative tickets, but they will not be copied to a
3467 derivative ticket directly. If they are copied directly to a
3468 derivative ticket by a KDC that is not aware of this element, the
3469 signature will not be correct for the application ticket elements,
3470 and the field will be ignored by the application server.
3474 March 2003 [Page 58]
3480 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
3483 This element and the elements it encapulates MAY be safely ignored by
3484 applications, application servers, and KDCs that do not implement
3487 The ad-type for AD-KDC-ISSUED is (4).
3491 AD-AND-OR ::= SEQUENCE {
3492 condition-count [0] INTEGER,
3493 elements [1] AuthorizationData
3497 When restrictive AD elements are encapsulated within the and-or
3498 element, the and-or element is considered satisfied if and only if at
3499 least the number of encapsulated elements specified in condition-
3500 count are satisifed. Therefore, this element MAY be used to
3501 implement an "or" operation by setting the condition-count field to
3502 1, and it MAY specify an "and" operation by setting the condition
3503 count to the number of embedded elements. Application servers that do
3504 not implement this element MUST reject tickets that contain
3505 authorization data elements of this type.
3507 The ad-type for AD-AND-OR is (5).
3509 5.2.6.4. MANDATORY-FOR-KDC
3511 AD-MANDATORY-FOR-KDC ::= AuthorizationData
3513 AD elements encapsulated within the mandatory-for-kdc element are to
3514 be interpreted by the KDC. KDCs that do not understand the type of an
3515 element embedded within the mandatory-for-kdc element MUST reject the
3518 The ad-type for AD-MANDATORY-FOR-KDC is (8).
3522 Historically, PA-DATA have been known as "pre-authentication data",
3523 meaning that they were used to augment the initial authentication
3524 with the KDC. Since that time, they have also been used as a typed
3525 hole with which to extend protocol exchanges with the KDC.
3527 PA-DATA ::= SEQUENCE {
3528 -- NOTE: first tag is [1], not [0]
3529 padata-type [1] Int32,
3530 padata-value [2] OCTET STRING -- might be encoded AP-REQ
3534 March 2003 [Page 59]
3540 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
3546 indicates the way that the padata-value element is to be
3547 interpreted. Negative values of padata-type are reserved for
3548 unregistered use; non-negative values are used for a registered
3549 interpretation of the element type.
3552 Usually contains the DER encoding of another type; the padata-type
3553 field identifies which type is encoded here.
3555 padata-type name contents of padata-value
3557 1 pa-tgs-req DER encoding of AP-REQ
3559 2 pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP
3561 3 pa-pw-salt salt (not ASN.1 encoded)
3563 11 pa-etype-info DER encoding of ETYPE-INFO
3565 19 pa-etype-info2 DER encoding of ETYPE-INFO2
3567 This field MAY also contain information needed by certain
3568 extensions to the Kerberos protocol. For example, it might be used
3569 to initially verify the identity of a client before any response
3572 The padata field can also contain information needed to help the
3573 KDC or the client select the key needed for generating or
3574 decrypting the response. This form of the padata is useful for
3575 supporting the use of certain token cards with Kerberos. The
3576 details of such extensions are specified in separate documents.
3577 See [Pat92] for additional uses of this field.
3581 In the case of requests for additional tickets (KRB_TGS_REQ), padata-
3582 value will contain an encoded AP-REQ. The checksum in the
3583 authenticator (which MUST be collision-proof) is to be computed over
3584 the KDC-REQ-BODY encoding.
3586 5.2.7.2. Encrypted Timestamp Pre-authentication
3588 There are pre-authentication types that may be used to pre-
3589 authenticate a client by means of an encrypted timestamp.
3594 March 2003 [Page 60]
3600 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
3603 PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC
3605 PA-ENC-TS-ENC ::= SEQUENCE {
3606 patimestamp [0] KerberosTime -- client's time --,
3607 pausec [1] Microseconds OPTIONAL
3610 Patimestamp contains the client's time, and pausec contains the
3611 microseconds, which MAY be omitted if a client will not generate more
3612 than one request per second. The ciphertext (padata-value) consists
3613 of the PA-ENC-TS-ENC encoding, encrypted using the client's secret
3614 key and a key usage value of 1.
3616 This pre-authentication type was not present in RFC 1510, but many
3617 implementations support it.
3621 The padata-value for this pre-authentication type contains the salt
3622 for the string-to-key to be used by the client to obtain the key for
3623 decrypting the encrypted part of an AS-REP message. Unfortunately,
3624 for historical reasons, the character set to be used is unspecified
3625 and probably locale-specific.
3627 This pre-authentication type was not present in RFC 1510, but many
3628 implementations support it. It is necessary in any case where the
3629 salt for the string-to-key algorithm is not the default.
3631 In the trivial example, a zero-length salt string is very commonplace
3632 for realms that have converted their principal databases from
3635 A KDC SHOULD NOT send PA-PW-SALT when issuing a KRB-ERROR message
3636 that requests additional pre-authentication. Implementation note:
3637 some KDC implementations issue an erroneous PA-PW-SALT when issuing a
3638 KRB-ERROR message that requests additional pre-authentication.
3639 Therefore, clients SHOULD ignore a PA-PW-SALT accompanying a KRB-
3640 ERROR message that requests additional pre-authentication.
3642 5.2.7.4. PA-ETYPE-INFO
3644 The ETYPE-INFO pre-authentication type is sent by the KDC in a KRB-
3645 ERROR indicating a requirement for additional pre-authentication. It
3646 is usually used to notify a client of which key to use for the
3647 encryption of an encrypted timestamp for the purposes of sending a
3648 PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an
3649 AS-REP to provide information to the client about which key salt to
3650 use for the string-to-key to be used by the client to obtain the key
3654 March 2003 [Page 61]
3660 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
3663 for decrypting the encrypted part the AS-REP.
3665 ETYPE-INFO-ENTRY ::= SEQUENCE {
3667 salt [1] OCTET STRING OPTIONAL
3670 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY
3672 The salt, like that of PA-PW-SALT, is also completely unspecified
3673 with respect to character set and is probably locale-specific.
3675 If ETYPE-INFO is sent in an AS-REP, there shall be exactly one ETYPE-
3676 INFO-ENTRY, and its etype shall match that of the enc-part in the AS-
3679 This pre-authentication type was not present in RFC 1510, but many
3680 implementations that support encrypted timestamps for pre-
3681 authentication need to support ETYPE-INFO as well.
3683 5.2.7.5. PA-ETYPE-INFO2
3685 The ETYPE-INFO2 pre-authentication type is sent by the KDC in a KRB-
3686 ERROR indicating a requirement for additional pre-authentication. It
3687 is usually used to notify a client of which key to use for the
3688 encryption of an encrypted timestamp for the purposes of sending a
3689 PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an
3690 AS-REP to provide information to the client about which key salt to
3691 use for the string-to-key to be used by the client to obtain the key
3692 for decrypting the encrypted part the AS-REP.
3694 ETYPE-INFO2-ENTRY ::= SEQUENCE {
3696 salt [1] KerberosString OPTIONAL,
3697 s2kparams [2] OCTET STRING OPTIONAL
3700 ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO-ENTRY
3702 The type of the salt is KerberosString, but existing installations
3703 might have locale-specific characters stored in salt strings, and
3704 implementors MAY choose to handle them.
3706 The interpretation of s2kparams is specified in the cryptosystem
3707 description associated with the etype. Each cryptosystem has a
3708 default interpretation of s2kparams that will hold if that element is
3709 omitted from the encoding of ETYPE-INFO2-ENTRY.
3714 March 2003 [Page 62]
3720 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
3723 If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one
3724 ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part in
3727 The preferred ordering of pre-authentication data that modify client
3728 key selection is: ETYPE-INFO2, followed by ETYPE-INFO, followed by
3729 PW-SALT. A KDC shall send all of these pre-authentication data that
3730 it supports, in the preferred ordering, when issuing an AS-REP or
3731 when issuing a KRB-ERROR requesting additional pre-authentication.
3733 The ETYPE-INFO2 pre-authentication type was not present in RFC 1510.
3735 5.2.8. KerberosFlags
3737 For several message types, a specific constrained bit string type,
3738 KerberosFlags, is used.
3740 KerberosFlags ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits
3741 -- shall be sent, but no fewer than 32
3743 Compatibility note: the following paragraphs describe a change from
3744 the RFC1510 description of bit strings that would result in
3745 incompatility in the case of an implementation that strictly
3746 conformed to ASN.1 DER and RFC1510.
3748 ASN.1 bit strings have multiple uses. The simplest use of a bit
3749 string is to contain a vector of bits, with no particular meaning
3750 attached to individual bits. This vector of bits is not necessarily a
3751 multiple of eight bits long. The use in Kerberos of a bit string as
3752 a compact boolean vector wherein each element has a distinct meaning
3753 poses some problems. The natural notation for a compact boolean
3754 vector is the ASN.1 "NamedBit" notation, and the DER require that
3755 encodings of a bit string using "NamedBit" notation exclude any
3756 trailing zero bits. This truncation is easy to neglect, especially
3757 given C language implementations that naturally choose to store
3758 boolean vectors as 32 bit integers.
3760 For example, if the notation for KDCOptions were to include the
3761 "NamedBit" notation, as in RFC 1510, and a KDCOptions value to be
3762 encoded had only the "forwardable" (bit number one) bit set, the DER
3763 encoding MUST include only two bits: the first reserved bit
3764 ("reserved", bit number zero, value zero) and the one-valued bit (bit
3765 number one) for "forwardable".
3767 Most existing implementations of Kerberos unconditionally send 32
3768 bits on the wire when encoding bit strings used as boolean vectors.
3769 This behavior violates the ASN.1 syntax used for flag values in RFC
3770 1510, but occurs on such a widely installed base that the protocol
3774 March 2003 [Page 63]
3780 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
3783 description is being modified to accomodate it.
3785 Consequently, this document removes the "NamedBit" notations for
3786 individual bits, relegating them to comments. The size constraint on
3787 the KerberosFlags type requires that at least 32 bits be encoded at
3788 all times, though a lenient implementation MAY choose to accept fewer
3789 than 32 bits and to treat the missing bits as set to zero.
3791 Currently, no uses of KerberosFlags specify more than 32 bits worth
3792 of flags, although future revisions of this document may do so. When
3793 more than 32 bits are to be transmitted in a KerberosFlags value,
3794 future revisions to this document will likely specify that the
3795 smallest number of bits needed to encode the highest-numbered one-
3796 valued bit should be sent. This is somewhat similar to the DER
3797 encoding of a bit string that is declared with the "NamedBit"
3800 5.2.9. Cryptosystem-related Types
3802 Many Kerberos protocol messages contain an EncryptedData as a
3803 container for arbitrary encrypted data, which is often the encrypted
3804 encoding of another data type. Fields within EncryptedData assist the
3805 recipient in selecting a key with which to decrypt the enclosed data.
3807 EncryptedData ::= SEQUENCE {
3808 etype [0] Int32 -- EncryptionType --,
3809 kvno [1] UInt32 OPTIONAL,
3810 cipher [2] OCTET STRING -- ciphertext
3814 This field identifies which encryption algorithm was used to
3815 encipher the cipher.
3818 This field contains the version number of the key under which data
3819 is encrypted. It is only present in messages encrypted under long
3820 lasting keys, such as principals' secret keys.
3823 This field contains the enciphered text, encoded as an OCTET
3824 STRING. (Note that the encryption mechanisms defined in
3825 [@KCRYPTO] MUST incorporate integrity protection as well, so no
3826 additional checksum is required.)
3828 The EncryptionKey type is the means by which cryptographic keys used
3829 for encryption are transfered.
3834 March 2003 [Page 64]
3840 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
3843 EncryptionKey ::= SEQUENCE {
3844 keytype [0] Int32 -- actually encryption type --,
3845 keyvalue [1] OCTET STRING
3849 This field specifies the encryption type of the encryption key
3850 that follows in the keyvalue field. While its name is "keytype",
3851 it actually specifies an encryption type. Previously, multiple
3852 cryptosystems that performed encryption differently but were
3853 capable of using keys with the same characteristics were permitted
3854 to share an assigned number to designate the type of key; this
3855 usage is now deprecated.
3858 This field contains the key itself, encoded as an octet string.
3860 Messages containing cleartext data to be authenticated will usually
3861 do so by using a member of type Checksum. Most instances of Checksum
3862 use a keyed hash, though exceptions will be noted.
3864 Checksum ::= SEQUENCE {
3865 cksumtype [0] Int32,
3866 checksum [1] OCTET STRING
3870 This field indicates the algorithm used to generate the
3871 accompanying checksum.
3874 This field contains the checksum itself, encoded as an octet
3877 See section 4 for a brief description of the use of encryption and
3878 checksums in Kerberos.
3882 This section describes the format and encryption parameters for
3883 tickets and authenticators. When a ticket or authenticator is
3884 included in a protocol message it is treated as an opaque object. A
3885 ticket is a record that helps a client authenticate to a service. A
3886 Ticket contains the following information:
3888 Ticket ::= [APPLICATION 1] SEQUENCE {
3889 tkt-vno [0] INTEGER (5),
3894 March 2003 [Page 65]
3900 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
3903 sname [2] PrincipalName,
3904 enc-part [3] EncryptedData -- EncTicketPart
3907 -- Encrypted part of ticket
3908 EncTicketPart ::= [APPLICATION 3] SEQUENCE {
3909 flags [0] TicketFlags,
3910 key [1] EncryptionKey,
3912 cname [3] PrincipalName,
3913 transited [4] TransitedEncoding,
3914 authtime [5] KerberosTime,
3915 starttime [6] KerberosTime OPTIONAL,
3916 endtime [7] KerberosTime,
3917 renew-till [8] KerberosTime OPTIONAL,
3918 caddr [9] HostAddresses OPTIONAL,
3919 authorization-data [10] AuthorizationData OPTIONAL
3922 -- encoded Transited field
3923 TransitedEncoding ::= SEQUENCE {
3924 tr-type [0] Int32 -- must be registered --,
3925 contents [1] OCTET STRING
3928 TicketFlags ::= KerberosFlags
3941 -- the following are new since 1510
3942 -- transited-policy-checked(12),
3943 -- ok-as-delegate(13)
3946 This field specifies the version number for the ticket format.
3947 This document describes version number 5.
3950 This field specifies the realm that issued a ticket. It also
3954 March 2003 [Page 66]
3960 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
3963 serves to identify the realm part of the server's principal
3964 identifier. Since a Kerberos server can only issue tickets for
3965 servers within its realm, the two will always be identical.
3968 This field specifies all components of the name part of the
3969 server's identity, including those parts that identify a specific
3970 instance of a service.
3973 This field holds the encrypted encoding of the EncTicketPart
3974 sequence. It is encrypted in the key shared by Kerberos and the
3975 end server (the server's secret key), using a key usage value of
3979 This field indicates which of various options were used or
3980 requested when the ticket was issued. The meanings of the flags
3983 Bit(s) Name Description
3985 0 reserved Reserved for future expansion of this
3988 The FORWARDABLE flag is normally only
3989 interpreted by the TGS, and can be
3990 ignored by end servers. When set, this
3991 1 forwardable flag tells the ticket-granting server
3992 that it is OK to issue a new
3993 ticket-granting ticket with a
3994 different network address based on the
3997 When set, this flag indicates that the
3998 ticket has either been forwarded or
3999 2 forwarded was issued based on authentication
4000 involving a forwarded ticket-granting
4003 The PROXIABLE flag is normally only
4004 interpreted by the TGS, and can be
4005 ignored by end servers. The PROXIABLE
4006 flag has an interpretation identical
4007 3 proxiable to that of the FORWARDABLE flag,
4008 except that the PROXIABLE flag tells
4009 the ticket-granting server that only
4010 non-ticket-granting tickets may be
4014 March 2003 [Page 67]
4020 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
4023 issued with different network
4026 4 proxy When set, this flag indicates that a
4029 The MAY-POSTDATE flag is normally only
4030 interpreted by the TGS, and can be
4031 5 may-postdate ignored by end servers. This flag
4032 tells the ticket-granting server that
4033 a post-dated ticket MAY be issued
4034 based on this ticket-granting ticket.
4036 This flag indicates that this ticket
4037 has been postdated. The end-service
4038 6 postdated can check the authtime field to see
4039 when the original authentication
4042 This flag indicates that a ticket is
4043 invalid, and it must be validated by
4044 7 invalid the KDC before use. Application
4045 servers must reject tickets which have
4048 The RENEWABLE flag is normally only
4049 interpreted by the TGS, and can
4050 usually be ignored by end servers
4051 8 renewable (some particularly careful servers MAY
4052 disallow renewable tickets). A
4053 renewable ticket can be used to obtain
4054 a replacement ticket that expires at a
4057 This flag indicates that this ticket
4058 9 initial was issued using the AS protocol, and
4059 not issued based on a ticket-granting
4062 This flag indicates that during
4063 initial authentication, the client was
4064 authenticated by the KDC before a
4065 10 pre-authent ticket was issued. The strength of the
4066 pre-authentication method is not
4067 indicated, but is acceptable to the
4070 This flag indicates that the protocol
4074 March 2003 [Page 68]
4080 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
4083 employed for initial authentication
4084 required the use of hardware expected
4085 11 hw-authent to be possessed solely by the named
4086 client. The hardware authentication
4087 method is selected by the KDC and the
4088 strength of the method is not
4091 This flag indicates that the KDC for
4092 the realm has checked the transited
4093 field against a realm defined policy
4094 for trusted certifiers. If this flag
4095 is reset (0), then the application
4096 server must check the transited field
4097 itself, and if unable to do so it must
4098 reject the authentication. If the flag
4099 12 transited- is set (1) then the application server
4100 policy-checked MAY skip its own validation of the
4101 transited field, relying on the
4102 validation performed by the KDC. At
4103 its option the application server MAY
4104 still apply its own validation based
4105 on a separate policy for acceptance.
4107 This flag is new since RFC 1510.
4109 This flag indicates that the server
4110 (not the client) specified in the
4111 ticket has been determined by policy
4112 of the realm to be a suitable
4113 recipient of delegation. A client can
4114 use the presence of this flag to help
4115 it make a decision whether to delegate
4116 credentials (either grant a proxy or a
4117 forwarded ticket-granting ticket) to
4118 13 ok-as-delegate this server. The client is free to
4119 ignore the value of this flag. When
4120 setting this flag, an administrator
4121 should consider the Security and
4122 placement of the server on which the
4123 service will run, as well as whether
4124 the service requires the use of
4125 delegated credentials.
4127 This flag is new since RFC 1510.
4129 14-31 reserved Reserved for future use.
4134 March 2003 [Page 69]
4140 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
4144 This field exists in the ticket and the KDC response and is used
4145 to pass the session key from Kerberos to the application server
4149 This field contains the name of the realm in which the client is
4150 registered and in which initial authentication took place.
4153 This field contains the name part of the client's principal
4157 This field lists the names of the Kerberos realms that took part
4158 in authenticating the user to whom this ticket was issued. It does
4159 not specify the order in which the realms were transited. See
4160 section 3.3.3.2 for details on how this field encodes the
4161 traversed realms. When the names of CA's are to be embedded in
4162 the transited field (as specified for some extensions to the
4163 protocol), the X.500 names of the CA's SHOULD be mapped into items
4164 in the transited field using the mapping defined by RFC2253.
4167 This field indicates the time of initial authentication for the
4168 named principal. It is the time of issue for the original ticket
4169 on which this ticket is based. It is included in the ticket to
4170 provide additional information to the end service, and to provide
4171 the necessary information for implementation of a `hot list'
4172 service at the KDC. An end service that is particularly paranoid
4173 could refuse to accept tickets for which the initial
4174 authentication occurred "too far" in the past. This field is also
4175 returned as part of the response from the KDC. When returned as
4176 part of the response to initial authentication (KRB_AS_REP), this
4177 is the current time on the Kerberos server. It is NOT recommended
4178 that this time value be used to adjust the workstation's clock
4179 since the workstation cannot reliably determine that such a
4180 KRB_AS_REP actually came from the proper KDC in a timely manner.
4185 This field in the ticket specifies the time after which the ticket
4186 is valid. Together with endtime, this field specifies the life of
4187 the ticket. If the starttime field is absent from the ticket, then
4188 the authtime field SHOULD be used in its place to determine the
4194 March 2003 [Page 70]
4200 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
4204 This field contains the time after which the ticket will not be
4205 honored (its expiration time). Note that individual services MAY
4206 place their own limits on the life of a ticket and MAY reject
4207 tickets which have not yet expired. As such, this is really an
4208 upper bound on the expiration time for the ticket.
4211 This field is only present in tickets that have the RENEWABLE flag
4212 set in the flags field. It indicates the maximum endtime that may
4213 be included in a renewal. It can be thought of as the absolute
4214 expiration time for the ticket, including all renewals.
4217 This field in a ticket contains zero (if omitted) or more (if
4218 present) host addresses. These are the addresses from which the
4219 ticket can be used. If there are no addresses, the ticket can be
4220 used from any location. The decision by the KDC to issue or by the
4221 end server to accept addressless tickets is a policy decision and
4222 is left to the Kerberos and end-service administrators; they MAY
4223 refuse to issue or accept such tickets. Because of the wide
4224 deployment of network address translation, it is recommended that
4225 policy allow the issue and acceptance of such tickets.
4227 Network addresses are included in the ticket to make it harder for
4228 an attacker to use stolen credentials. Because the session key is
4229 not sent over the network in cleartext, credentials can't be
4230 stolen simply by listening to the network; an attacker has to gain
4231 access to the session key (perhaps through operating system
4232 security breaches or a careless user's unattended session) to make
4233 use of stolen tickets.
4235 It is important to note that the network address from which a
4236 connection is received cannot be reliably determined. Even if it
4237 could be, an attacker who has compromised the client's workstation
4238 could use the credentials from there. Including the network
4239 addresses only makes it more difficult, not impossible, for an
4240 attacker to walk off with stolen credentials and then use them
4241 from a "safe" location.
4244 The authorization-data field is used to pass authorization data
4245 from the principal on whose behalf a ticket was issued to the
4246 application service. If no authorization data is included, this
4247 field will be left out. Experience has shown that the name of this
4248 field is confusing, and that a better name for this field would be
4249 restrictions. Unfortunately, it is not possible to change the name
4250 of this field at this time.
4254 March 2003 [Page 71]
4260 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
4263 This field contains restrictions on any authority obtained on the
4264 basis of authentication using the ticket. It is possible for any
4265 principal in posession of credentials to add entries to the
4266 authorization data field since these entries further restrict what
4267 can be done with the ticket. Such additions can be made by
4268 specifying the additional entries when a new ticket is obtained
4269 during the TGS exchange, or they MAY be added during chained
4270 delegation using the authorization data field of the
4273 Because entries may be added to this field by the holder of
4274 credentials, except when an entry is separately authenticated by
4275 encapsulation in the KDC-issued element, it is not allowable for
4276 the presence of an entry in the authorization data field of a
4277 ticket to amplify the privileges one would obtain from using a
4280 The data in this field may be specific to the end service; the
4281 field will contain the names of service specific objects, and the
4282 rights to those objects. The format for this field is described in
4283 section 5.2.6. Although Kerberos is not concerned with the format
4284 of the contents of the sub-fields, it does carry type information
4287 By using the authorization_data field, a principal is able to
4288 issue a proxy that is valid for a specific purpose. For example, a
4289 client wishing to print a file can obtain a file server proxy to
4290 be passed to the print server. By specifying the name of the file
4291 in the authorization_data field, the file server knows that the
4292 print server can only use the client's rights when accessing the
4293 particular file to be printed.
4295 A separate service providing authorization or certifying group
4296 membership may be built using the authorization-data field. In
4297 this case, the entity granting authorization (not the authorized
4298 entity), may obtain a ticket in its own name (e.g. the ticket is
4299 issued in the name of a privilege server), and this entity adds
4300 restrictions on its own authority and delegates the restricted
4301 authority through a proxy to the client. The client would then
4302 present this authorization credential to the application server
4303 separately from the authentication exchange. Alternatively, such
4304 authorization credentials MAY be embedded in the ticket
4305 authenticating the authorized entity, when the authorization is
4306 separately authenticated using the KDC-issued authorization data
4307 element (see 5.2.6.2).
4309 Similarly, if one specifies the authorization-data field of a
4310 proxy and leaves the host addresses blank, the resulting ticket
4314 March 2003 [Page 72]
4320 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
4323 and session key can be treated as a capability. See [Neu93] for
4324 some suggested uses of this field.
4326 The authorization-data field is optional and does not have to be
4327 included in a ticket.
4329 5.4. Specifications for the AS and TGS exchanges
4331 This section specifies the format of the messages used in the
4332 exchange between the client and the Kerberos server. The format of
4333 possible error messages appears in section 5.9.1.
4335 5.4.1. KRB_KDC_REQ definition
4337 The KRB_KDC_REQ message has no application tag number of its own.
4338 Instead, it is incorporated into one of KRB_AS_REQ or KRB_TGS_REQ,
4339 which each have an application tag, depending on whether the request
4340 is for an initial ticket or an additional ticket. In either case, the
4341 message is sent from the client to the KDC to request credentials for
4344 The message fields are:
4346 AS-REQ ::= [APPLICATION 10] KDC-REQ
4348 TGS-REQ ::= [APPLICATION 12] KDC-REQ
4350 KDC-REQ ::= SEQUENCE {
4351 -- NOTE: first tag is [1], not [0]
4352 pvno [1] INTEGER (5) ,
4353 msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --),
4354 padata [3] SEQUENCE OF PA-DATA OPTIONAL
4355 -- NOTE: not empty --,
4356 req-body [4] KDC-REQ-BODY
4359 KDC-REQ-BODY ::= SEQUENCE {
4360 kdc-options [0] KDCOptions,
4361 cname [1] PrincipalName OPTIONAL
4362 -- Used only in AS-REQ --,
4365 -- Also client's in AS-REQ --,
4366 sname [3] PrincipalName OPTIONAL,
4367 from [4] KerberosTime OPTIONAL,
4368 till [5] KerberosTime,
4369 rtime [6] KerberosTime OPTIONAL,
4374 March 2003 [Page 73]
4380 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
4383 etype [8] SEQUENCE OF Int32 -- EncryptionType
4384 -- in preference order --,
4385 addresses [9] HostAddresses OPTIONAL,
4386 enc-authorization-data [10] EncryptedData -- AuthorizationData --,
4387 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
4391 KDCOptions ::= KerberosFlags
4397 -- allow-postdate(5),
4403 -- opt-hardware-auth(11),
4406 -- 15 is reserved for canonicalize
4408 -- 26 was unused in 1510
4409 -- disable-transited-check(26),
4411 -- renewable-ok(27),
4412 -- enc-tkt-in-skey(28),
4416 The fields in this message are:
4419 This field is included in each message, and specifies the protocol
4420 version number. This document specifies protocol version 5.
4423 This field indicates the type of a protocol message. It will
4424 almost always be the same as the application identifier associated
4425 with a message. It is included to make the identifier more readily
4426 accessible to the application. For the KDC-REQ message, this type
4427 will be KRB_AS_REQ or KRB_TGS_REQ.
4430 Contains pre-authentication data. Requests for additional tickets
4434 March 2003 [Page 74]
4440 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
4443 (KRB_TGS_REQ) MUST contain a padata of PA-TGS-REQ.
4445 The padata (pre-authentication data) field contains a sequence of
4446 authentication information which may be needed before credentials
4447 can be issued or decrypted.
4450 This field is a placeholder delimiting the extent of the remaining
4451 fields. If a checksum is to be calculated over the request, it is
4452 calculated over an encoding of the KDC-REQ-BODY sequence which is
4453 enclosed within the req-body field.
4456 This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to
4457 the KDC and indicates the flags that the client wants set on the
4458 tickets as well as other information that is to modify the
4459 behavior of the KDC. Where appropriate, the name of an option may
4460 be the same as the flag that is set by that option. Although in
4461 most case, the bit in the options field will be the same as that
4462 in the flags field, this is not guaranteed, so it is not
4463 acceptable to simply copy the options field to the flags field.
4464 There are various checks that must be made before honoring an
4467 The kdc_options field is a bit-field, where the selected options
4468 are indicated by the bit being set (1), and the unselected options
4469 and reserved fields being reset (0). The encoding of the bits is
4470 specified in section 5.2. The options are described in more detail
4471 above in section 2. The meanings of the options are:
4473 Bits Name Description
4475 0 RESERVED Reserved for future expansion of
4478 The FORWARDABLE option indicates
4479 that the ticket to be issued is to
4480 have its forwardable flag set. It
4481 1 FORWARDABLE may only be set on the initial
4482 request, or in a subsequent request
4483 if the ticket-granting ticket on
4484 which it is based is also
4487 The FORWARDED option is only
4488 specified in a request to the
4489 ticket-granting server and will only
4490 be honored if the ticket-granting
4494 March 2003 [Page 75]
4500 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
4503 ticket in the request has its
4504 2 FORWARDED FORWARDABLE bit set. This option
4505 indicates that this is a request for
4506 forwarding. The address(es) of the
4507 host from which the resulting ticket
4508 is to be valid are included in the
4509 addresses field of the request.
4511 The PROXIABLE option indicates that
4512 the ticket to be issued is to have
4513 its proxiable flag set. It may only
4514 3 PROXIABLE be set on the initial request, or in
4515 a subsequent request if the
4516 ticket-granting ticket on which it
4517 is based is also proxiable.
4519 The PROXY option indicates that this
4520 is a request for a proxy. This
4521 option will only be honored if the
4522 ticket-granting ticket in the
4523 4 PROXY request has its PROXIABLE bit set.
4524 The address(es) of the host from
4525 which the resulting ticket is to be
4526 valid are included in the addresses
4527 field of the request.
4529 The ALLOW-POSTDATE option indicates
4530 that the ticket to be issued is to
4531 have its MAY-POSTDATE flag set. It
4532 5 ALLOW-POSTDATE may only be set on the initial
4533 request, or in a subsequent request
4534 if the ticket-granting ticket on
4535 which it is based also has its
4536 MAY-POSTDATE flag set.
4538 The POSTDATED option indicates that
4539 this is a request for a postdated
4540 ticket. This option will only be
4541 honored if the ticket-granting
4542 ticket on which it is based has its
4543 6 POSTDATED MAY-POSTDATE flag set. The resulting
4544 ticket will also have its INVALID
4545 flag set, and that flag may be reset
4546 by a subsequent request to the KDC
4547 after the starttime in the ticket
4550 7 RESERVED This option is presently unused.
4554 March 2003 [Page 76]
4560 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
4563 The RENEWABLE option indicates that
4564 the ticket to be issued is to have
4565 its RENEWABLE flag set. It may only
4566 be set on the initial request, or
4567 when the ticket-granting ticket on
4568 8 RENEWABLE which the request is based is also
4569 renewable. If this option is
4570 requested, then the rtime field in
4571 the request contains the desired
4572 absolute expiration time for the
4575 9 RESERVED Reserved for PK-Cross
4577 10 RESERVED Reserved for future use.
4579 11 RESERVED Reserved for opt-hardware-auth.
4581 12-25 RESERVED Reserved for future use.
4583 By default the KDC will check the
4584 transited field of a
4585 ticket-granting-ticket against the
4586 policy of the local realm before it
4587 will issue derivative tickets based
4588 on the ticket-granting ticket. If
4589 this flag is set in the request,
4590 checking of the transited field is
4591 disabled. Tickets issued without the
4592 26 DISABLE-TRANSITED-CHECK performance of this check will be
4593 noted by the reset (0) value of the
4594 TRANSITED-POLICY-CHECKED flag,
4595 indicating to the application server
4596 that the tranisted field must be
4597 checked locally. KDCs are
4598 encouraged but not required to honor
4599 the DISABLE-TRANSITED-CHECK option.
4601 This flag is new since RFC 1510
4603 The RENEWABLE-OK option indicates
4604 that a renewable ticket will be
4605 acceptable if a ticket with the
4606 requested life cannot otherwise be
4607 provided. If a ticket with the
4608 requested life cannot be provided,
4609 27 RENEWABLE-OK then a renewable ticket may be
4610 issued with a renew-till equal to
4614 March 2003 [Page 77]
4620 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
4623 the requested endtime. The value
4624 of the renew-till field may still be
4625 limited by local limits, or limits
4626 selected by the individual principal
4629 This option is used only by the
4630 ticket-granting service. The
4631 ENC-TKT-IN-SKEY option indicates
4632 28 ENC-TKT-IN-SKEY that the ticket for the end server
4633 is to be encrypted in the session
4634 key from the additional
4635 ticket-granting ticket provided.
4637 29 RESERVED Reserved for future use.
4639 This option is used only by the
4640 ticket-granting service. The RENEW
4641 option indicates that the present
4642 request is for a renewal. The ticket
4643 provided is encrypted in the secret
4644 key for the server on which it is
4645 30 RENEW valid. This option will only be
4646 honored if the ticket to be renewed
4647 has its RENEWABLE flag set and if
4648 the time in its renew-till field has
4649 not passed. The ticket to be renewed
4650 is passed in the padata field as
4651 part of the authentication header.
4653 This option is used only by the
4654 ticket-granting service. The
4655 VALIDATE option indicates that the
4656 request is to validate a postdated
4657 ticket. It will only be honored if
4658 the ticket presented is postdated,
4659 presently has its INVALID flag set,
4660 31 VALIDATE and would be otherwise usable at
4661 this time. A ticket cannot be
4662 validated before its starttime. The
4663 ticket presented for validation is
4664 encrypted in the key of the server
4665 for which it is valid and is passed
4666 in the padata field as part of the
4667 authentication header.
4669 These fields are the same as those described for the ticket in
4670 section 5.3. The sname may only be absent when the ENC-TKT-IN-SKEY
4674 March 2003 [Page 78]
4680 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
4683 option is specified. If absent, the name of the server is taken
4684 from the name of the client in the ticket passed as additional-
4687 enc-authorization-data
4688 The enc-authorization-data, if present (and it can only be present
4689 in the TGS_REQ form), is an encoding of the desired authorization-
4690 data encrypted under the sub-session key if present in the
4691 Authenticator, or alternatively from the session key in the
4692 ticket-granting ticket (both the Authenticator and ticket-granting
4693 ticket come from the padata field in the KRB_TGS_REQ). The key
4694 usage value used when encrypting is 5 if a sub-session key is
4695 used, or 4 if the session key is used.
4698 This field specifies the realm part of the server's principal
4699 identifier. In the AS exchange, this is also the realm part of the
4700 client's principal identifier.
4703 This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket
4704 requests when the requested ticket is to be postdated. It
4705 specifies the desired start time for the requested ticket. If this
4706 field is omitted then the KDC SHOULD use the current time instead.
4709 This field contains the expiration date requested by the client in
4710 a ticket request. It is not optional, but if the requested endtime
4711 is "19700101000000Z", the requested ticket is to have the maximum
4712 endtime permitted according to KDC policy. Implementation note:
4713 This special timestamp corresponds to a UNIX time_t value of zero
4717 This field is the requested renew-till time sent from a client to
4718 the KDC in a ticket request. It is optional.
4721 This field is part of the KDC request and response. It is intended
4722 to hold a random number generated by the client. If the same
4723 number is included in the encrypted response from the KDC, it
4724 provides evidence that the response is fresh and has not been
4725 replayed by an attacker. Nonces MUST NEVER be reused.
4728 This field specifies the desired encryption algorithm to be used
4734 March 2003 [Page 79]
4740 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
4744 This field is included in the initial request for tickets, and
4745 optionally included in requests for additional tickets from the
4746 ticket-granting server. It specifies the addresses from which the
4747 requested ticket is to be valid. Normally it includes the
4748 addresses for the client's host. If a proxy is requested, this
4749 field will contain other addresses. The contents of this field are
4750 usually copied by the KDC into the caddr field of the resulting
4754 Additional tickets MAY be optionally included in a request to the
4755 ticket-granting server. If the ENC-TKT-IN-SKEY option has been
4756 specified, then the session key from the additional ticket will be
4757 used in place of the server's key to encrypt the new ticket. When
4758 the ENC-TKT-IN-SKEY option is used for user-to-user
4759 authentication, this addional ticket MAY be a TGT issued by the
4760 local realm or an inter-realm TGT issued for the current KDC's
4761 realm by a remote KDC. If more than one option which requires
4762 additional tickets has been specified, then the additional tickets
4763 are used in the order specified by the ordering of the options
4764 bits (see kdc-options, above).
4766 The application tag number will be either ten (10) or twelve (12)
4767 depending on whether the request is for an initial ticket (AS-REQ) or
4768 for an additional ticket (TGS-REQ).
4770 The optional fields (addresses, authorization-data and additional-
4771 tickets) are only included if necessary to perform the operation
4772 specified in the kdc-options field.
4774 It should be noted that in KRB_TGS_REQ, the protocol version number
4775 appears twice and two different message types appear: the KRB_TGS_REQ
4776 message contains these fields as does the authentication header
4777 (KRB_AP_REQ) that is passed in the padata field.
4779 5.4.2. KRB_KDC_REP definition
4781 The KRB_KDC_REP message format is used for the reply from the KDC for
4782 either an initial (AS) request or a subsequent (TGS) request. There
4783 is no message type for KRB_KDC_REP. Instead, the type will be either
4784 KRB_AS_REP or KRB_TGS_REP. The key used to encrypt the ciphertext
4785 part of the reply depends on the message type. For KRB_AS_REP, the
4786 ciphertext is encrypted in the client's secret key, and the client's
4787 key version number is included in the key version number for the
4788 encrypted data. For KRB_TGS_REP, the ciphertext is encrypted in the
4789 sub-session key from the Authenticator, or if absent, the session key
4790 from the ticket-granting ticket used in the request. In that case,
4794 March 2003 [Page 80]
4800 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
4803 no version number will be present in the EncryptedData sequence.
4805 The KRB_KDC_REP message contains the following fields:
4807 AS-REP ::= [APPLICATION 11] KDC-REP
4809 TGS-REP ::= [APPLICATION 13] KDC-REP
4811 KDC-REP ::= SEQUENCE {
4812 pvno [0] INTEGER (5),
4813 msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --),
4814 padata [2] SEQUENCE OF PA-DATA OPTIONAL
4815 -- NOTE: not empty --,
4817 cname [4] PrincipalName,
4819 enc-part [6] EncryptedData
4820 -- EncASRepPart or EncTGSRepPart,
4824 EncASRepPart ::= [APPLICATION 25] EncKDCRepPart
4826 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart
4828 EncKDCRepPart ::= SEQUENCE {
4829 key [0] EncryptionKey,
4830 last-req [1] LastReq,
4832 key-expiration [3] KerberosTime OPTIONAL,
4833 flags [4] TicketFlags,
4834 authtime [5] KerberosTime,
4835 starttime [6] KerberosTime OPTIONAL,
4836 endtime [7] KerberosTime,
4837 renew-till [8] KerberosTime OPTIONAL,
4839 sname [10] PrincipalName,
4840 caddr [11] HostAddresses OPTIONAL
4843 LastReq ::= SEQUENCE OF SEQUENCE {
4845 lr-value [1] KerberosTime
4849 These fields are described above in section 5.4.1. msg-type is
4850 either KRB_AS_REP or KRB_TGS_REP.
4854 March 2003 [Page 81]
4860 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
4864 This field is described in detail in section 5.4.1. One possible
4865 use for this field is to encode an alternate "salt" string to be
4866 used with a string-to-key algorithm. This ability is useful to
4867 ease transitions if a realm name needs to change (e.g. when a
4868 company is acquired); in such a case all existing password-derived
4869 entries in the KDC database would be flagged as needing a special
4870 salt string until the next password change.
4872 crealm, cname, srealm and sname
4873 These fields are the same as those described for the ticket in
4877 The newly-issued ticket, from section 5.3.
4880 This field is a place holder for the ciphertext and related
4881 information that forms the encrypted part of a message. The
4882 description of the encrypted part of the message follows each
4883 appearance of this field.
4885 The key usage value for encrypting this field is 3 in an AS-REP
4886 message, using the client's long-term key or another key selected
4887 via pre-authentication mechanisms. In a TGS-REP message, the key
4888 usage value is 8 if the TGS session key is used, or 9 if a TGS
4889 authenticator subkey is used.
4891 Compatibility note: Some implementations unconditionally send an
4892 encrypted EncTGSRepPart (application tag number 26) in this field
4893 regardless of whether the reply is a AS-REP or a TGS-REP. In the
4894 interests of compatibility, implementors MAY relax the check on
4895 the tag number of the decrypted ENC-PART.
4898 This field is the same as described for the ticket in section 5.3.
4901 This field is returned by the KDC and specifies the time(s) of the
4902 last request by a principal. Depending on what information is
4903 available, this might be the last time that a request for a
4904 ticket-granting ticket was made, or the last time that a request
4905 based on a ticket-granting ticket was successful. It also might
4906 cover all servers for a realm, or just the particular server. Some
4907 implementations MAY display this information to the user to aid in
4908 discovering unauthorized use of one's identity. It is similar in
4909 spirit to the last login time displayed when logging into
4910 timesharing systems.
4914 March 2003 [Page 82]
4920 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
4924 This field indicates how the following lr-value field is to be
4925 interpreted. Negative values indicate that the information
4926 pertains only to the responding server. Non-negative values
4927 pertain to all servers for the realm.
4929 If the lr-type field is zero (0), then no information is
4930 conveyed by the lr-value subfield. If the absolute value of the
4931 lr-type field is one (1), then the lr-value subfield is the
4932 time of last initial request for a TGT. If it is two (2), then
4933 the lr-value subfield is the time of last initial request. If
4934 it is three (3), then the lr-value subfield is the time of
4935 issue for the newest ticket-granting ticket used. If it is four
4936 (4), then the lr-value subfield is the time of the last
4937 renewal. If it is five (5), then the lr-value subfield is the
4938 time of last request (of any type). If it is (6), then the lr-
4939 value subfield is the time when the password will expire. If
4940 it is (7), then the lr-value subfield is the time when the
4941 account will expire.
4944 This field contains the time of the last request. The time MUST
4945 be interpreted according to the contents of the accompanying
4949 This field is described above in section 5.4.1.
4952 The key-expiration field is part of the response from the KDC and
4953 specifies the time that the client's secret key is due to expire.
4954 The expiration might be the result of password aging or an account
4955 expiration. If present, it SHOULD be set to the earliest of the
4956 user's key expiration and account expiration. The use of this
4957 field is deprecated and the last-req field SHOULD be used to
4958 convey this information instead. This field will usually be left
4959 out of the TGS reply since the response to the TGS request is
4960 encrypted in a session key and no client information need be
4961 retrieved from the KDC database. It is up to the application
4962 client (usually the login program) to take appropriate action
4963 (such as notifying the user) if the expiration time is imminent.
4965 flags, authtime, starttime, endtime, renew-till and caddr
4966 These fields are duplicates of those found in the encrypted
4967 portion of the attached ticket (see section 5.3), provided so the
4968 client MAY verify they match the intended request and to assist in
4969 proper ticket caching. If the message is of type KRB_TGS_REP, the
4970 caddr field will only be filled in if the request was for a proxy
4974 March 2003 [Page 83]
4980 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
4983 or forwarded ticket, or if the user is substituting a subset of
4984 the addresses from the ticket-granting ticket. If the client-
4985 requested addresses are not present or not used, then the
4986 addresses contained in the ticket will be the same as those
4987 included in the ticket-granting ticket.
4989 5.5. Client/Server (CS) message specifications
4991 This section specifies the format of the messages used for the
4992 authentication of the client to the application server.
4994 5.5.1. KRB_AP_REQ definition
4996 The KRB_AP_REQ message contains the Kerberos protocol version number,
4997 the message type KRB_AP_REQ, an options field to indicate any options
4998 in use, and the ticket and authenticator themselves. The KRB_AP_REQ
4999 message is often referred to as the 'authentication header'.
5001 AP-REQ ::= [APPLICATION 14] SEQUENCE {
5002 pvno [0] INTEGER (5),
5003 msg-type [1] INTEGER (14),
5004 ap-options [2] APOptions,
5006 authenticator [4] EncryptedData -- Authenticator
5009 APOptions ::= KerberosFlags
5011 -- use-session-key(1),
5012 -- mutual-required(2)
5015 These fields are described above in section 5.4.1. msg-type is
5019 This field appears in the application request (KRB_AP_REQ) and
5020 affects the way the request is processed. It is a bit-field, where
5021 the selected options are indicated by the bit being set (1), and
5022 the unselected options and reserved fields being reset (0). The
5023 encoding of the bits is specified in section 5.2. The meanings of
5026 Bit(s) Name Description
5028 0 reserved Reserved for future expansion of this field.
5030 The USE-SESSION-KEY option indicates that the
5034 March 2003 [Page 84]
5040 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
5043 ticket the client is presenting to a server
5044 1 use-session-key is encrypted in the session key from the
5045 server's ticket-granting ticket. When this
5046 option is not specified, the ticket is
5047 encrypted in the server's secret key.
5049 The MUTUAL-REQUIRED option tells the server
5050 2 mutual-required that the client requires mutual
5051 authentication, and that it must respond with
5052 a KRB_AP_REP message.
5054 3-31 reserved Reserved for future use.
5057 This field is a ticket authenticating the client to the server.
5060 This contains the encrypted authenticator, which includes the
5061 client's choice of a subkey.
5063 The encrypted authenticator is included in the AP-REQ; it certifies
5064 to a server that the sender has recent knowledge of the encryption
5065 key in the accompanying ticket, to help the server detect replays. It
5066 also assists in the selection of a "true session key" to use with the
5067 particular session. The DER encoding of the following is encrypted
5068 in the ticket's session key, with a key usage value of 11 in normal
5069 application exchanges, or 7 when used as the PA-TGS-REQ PA-DATA field
5070 of a TGS-REQ exchange (see section 5.4.1):
5072 -- Unencrypted authenticator
5073 Authenticator ::= [APPLICATION 2] SEQUENCE {
5074 authenticator-vno [0] INTEGER (5),
5076 cname [2] PrincipalName,
5077 cksum [3] Checksum OPTIONAL,
5078 cusec [4] Microseconds,
5079 ctime [5] KerberosTime,
5080 subkey [6] EncryptionKey OPTIONAL,
5081 seq-number [7] UInt32 OPTIONAL,
5082 authorization-data [8] AuthorizationData OPTIONAL
5086 This field specifies the version number for the format of the
5087 authenticator. This document specifies version 5.
5090 These fields are the same as those described for the ticket in
5094 March 2003 [Page 85]
5100 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
5106 This field contains a checksum of the application data that
5107 accompanies the KRB_AP_REQ, computed using a key usage value of 10
5108 in normal application exchanges, or 6 when used in the TGS-REQ PA-
5109 TGS-REQ AP-DATA field.
5112 This field contains the microsecond part of the client's
5113 timestamp. Its value (before encryption) ranges from 0 to 999999.
5114 It often appears along with ctime. The two fields are used
5115 together to specify a reasonably accurate timestamp.
5118 This field contains the current time on the client's host.
5121 This field contains the client's choice for an encryption key
5122 which is to be used to protect this specific application session.
5123 Unless an application specifies otherwise, if this field is left
5124 out the session key from the ticket will be used.
5127 This optional field includes the initial sequence number to be
5128 used by the KRB_PRIV or KRB_SAFE messages when sequence numbers
5129 are used to detect replays (It may also be used by application
5130 specific messages). When included in the authenticator this field
5131 specifies the initial sequence number for messages from the client
5132 to the server. When included in the AP-REP message, the initial
5133 sequence number is that for messages from the server to the
5134 client. When used in KRB_PRIV or KRB_SAFE messages, it is
5135 incremented by one after each message is sent. Sequence numbers
5136 fall in the range of 0 through 2^32 - 1 and wrap to zero following
5139 For sequence numbers to adequately support the detection of
5140 replays they SHOULD be non-repeating, even across connection
5141 boundaries. The initial sequence number SHOULD be random and
5142 uniformly distributed across the full space of possible sequence
5143 numbers, so that it cannot be guessed by an attacker and so that
5144 it and the successive sequence numbers do not repeat other
5147 Implmentation note: historically, some implementations transmit
5148 signed twos-complement numbers for sequence numbers. In the
5149 interests of compatibility, implementations MAY accept the
5150 equivalent negative number where a positive number greater than
5154 March 2003 [Page 86]
5160 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
5163 2^31 - 1 is expected.
5165 Implementation note: as noted before, some implementations omit
5166 the optional sequence number when its value would be zero.
5167 Implementations MAY accept an omitted sequence number when
5168 expecting a value of zero, and SHOULD NOT transmit an
5169 Authenticator with a initial sequence number of zero.
5172 This field is the same as described for the ticket in section 5.3.
5173 It is optional and will only appear when additional restrictions
5174 are to be placed on the use of a ticket, beyond those carried in
5177 5.5.2. KRB_AP_REP definition
5179 The KRB_AP_REP message contains the Kerberos protocol version number,
5180 the message type, and an encrypted time-stamp. The message is sent in
5181 response to an application request (KRB_AP_REQ) where the mutual
5182 authentication option has been selected in the ap-options field.
5184 AP-REP ::= [APPLICATION 15] SEQUENCE {
5185 pvno [0] INTEGER (5),
5186 msg-type [1] INTEGER (15),
5187 enc-part [2] EncryptedData -- EncAPRepPart
5190 EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
5191 ctime [0] KerberosTime,
5192 cusec [1] Microseconds,
5193 subkey [2] EncryptionKey OPTIONAL,
5194 seq-number [3] UInt32 OPTIONAL
5197 The encoded EncAPRepPart is encrypted in the shared session key of
5198 the ticket. The optional subkey field can be used in an application-
5199 arranged negotiation to choose a per association session key.
5202 These fields are described above in section 5.4.1. msg-type is
5206 This field is described above in section 5.4.2. It is computed
5207 with a key usage value of 12.
5210 This field contains the current time on the client's host.
5214 March 2003 [Page 87]
5220 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
5224 This field contains the microsecond part of the client's
5228 This field contains an encryption key which is to be used to
5229 protect this specific application session. See section 3.2.6 for
5230 specifics on how this field is used to negotiate a key. Unless an
5231 application specifies otherwise, if this field is left out, the
5232 sub-session key from the authenticator, or if also left out, the
5233 session key from the ticket will be used.
5236 This field is described above in section 5.3.2.
5238 5.5.3. Error message reply
5240 If an error occurs while processing the application request, the
5241 KRB_ERROR message will be sent in response. See section 5.9.1 for the
5242 format of the error message. The cname and crealm fields MAY be left
5243 out if the server cannot determine their appropriate values from the
5244 corresponding KRB_AP_REQ message. If the authenticator was
5245 decipherable, the ctime and cusec fields will contain the values from
5248 5.6. KRB_SAFE message specification
5250 This section specifies the format of a message that can be used by
5251 either side (client or server) of an application to send a tamper-
5252 proof message to its peer. It presumes that a session key has
5253 previously been exchanged (for example, by using the
5254 KRB_AP_REQ/KRB_AP_REP messages).
5256 5.6.1. KRB_SAFE definition
5258 The KRB_SAFE message contains user data along with a collision-proof
5259 checksum keyed with the last encryption key negotiated via subkeys,
5260 or the session key if no negotiation has occurred. The message fields
5263 KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
5264 pvno [0] INTEGER (5),
5265 msg-type [1] INTEGER (20),
5266 safe-body [2] KRB-SAFE-BODY,
5270 KRB-SAFE-BODY ::= SEQUENCE {
5274 March 2003 [Page 88]
5280 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
5283 user-data [0] OCTET STRING,
5284 timestamp [1] KerberosTime OPTIONAL,
5285 usec [2] Microseconds OPTIONAL,
5286 seq-number [3] UInt32 OPTIONAL,
5287 s-address [4] HostAddress,
5288 r-address [5] HostAddress OPTIONAL
5292 These fields are described above in section 5.4.1. msg-type is
5296 This field is a placeholder for the body of the KRB-SAFE message.
5299 This field contains the checksum of the application data, computed
5300 with a key usage value of 15.
5302 The checksum is computed over the encoding of the KRB-SAFE
5303 sequence. First, the cksum is set to a type zero, zero-length
5304 value and the checksum is computed over the encoding of the KRB-
5305 SAFE sequence, then the checksum is set to the result of that
5306 computation, and finally the KRB-SAFE sequence is encoded again.
5307 This method, while different than the one specified in RFC 1510,
5308 corresponds to existing practice.
5311 This field is part of the KRB_SAFE and KRB_PRIV messages and
5312 contain the application specific data that is being passed from
5313 the sender to the recipient.
5316 This field is part of the KRB_SAFE and KRB_PRIV messages. Its
5317 contents are the current time as known by the sender of the
5318 message. By checking the timestamp, the recipient of the message
5319 is able to make sure that it was recently generated, and is not a
5323 This field is part of the KRB_SAFE and KRB_PRIV headers. It
5324 contains the microsecond part of the timestamp.
5327 This field is described above in section 5.3.2.
5334 March 2003 [Page 89]
5340 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
5343 This field specifies the address in use by the sender of the
5344 message. It MAY be omitted if not required by the application
5348 This field specifies the address in use by the recipient of the
5349 message. It MAY be omitted for some uses (such as broadcast
5350 protocols), but the recipient MAY arbitrarily reject such
5351 messages. This field, along with s-address, can be used to help
5352 detect messages which have been incorrectly or maliciously
5353 delivered to the wrong recipient.
5355 5.7. KRB_PRIV message specification
5357 This section specifies the format of a message that can be used by
5358 either side (client or server) of an application to securely and
5359 privately send a message to its peer. It presumes that a session key
5360 has previously been exchanged (for example, by using the
5361 KRB_AP_REQ/KRB_AP_REP messages).
5363 5.7.1. KRB_PRIV definition
5365 The KRB_PRIV message contains user data encrypted in the Session Key.
5366 The message fields are:
5368 KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
5369 pvno [0] INTEGER (5),
5370 msg-type [1] INTEGER (21),
5371 -- NOTE: there is no [2] tag
5372 enc-part [3] EncryptedData -- EncKrbPrivPart
5375 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
5376 user-data [0] OCTET STRING,
5377 timestamp [1] KerberosTime OPTIONAL,
5378 usec [2] Microseconds OPTIONAL,
5379 seq-number [3] UInt32 OPTIONAL,
5380 s-address [4] HostAddress -- sender's addr --,
5381 r-address [5] HostAddress OPTIONAL -- recip's addr
5385 These fields are described above in section 5.4.1. msg-type is
5389 This field holds an encoding of the EncKrbPrivPart sequence
5390 encrypted under the session key, with a key usage value of 13.
5394 March 2003 [Page 90]
5400 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
5403 This encrypted encoding is used for the enc-part field of the KRB-
5406 user-data, timestamp, usec, s-address and r-address
5407 These fields are described above in section 5.6.1.
5410 This field is described above in section 5.3.2.
5412 5.8. KRB_CRED message specification
5414 This section specifies the format of a message that can be used to
5415 send Kerberos credentials from one principal to another. It is
5416 presented here to encourage a common mechanism to be used by
5417 applications when forwarding tickets or providing proxies to
5418 subordinate servers. It presumes that a session key has already been
5419 exchanged perhaps by using the KRB_AP_REQ/KRB_AP_REP messages.
5421 5.8.1. KRB_CRED definition
5423 The KRB_CRED message contains a sequence of tickets to be sent and
5424 information needed to use the tickets, including the session key from
5425 each. The information needed to use the tickets is encrypted under
5426 an encryption key previously exchanged or transferred alongside the
5427 KRB_CRED message. The message fields are:
5429 KRB-CRED ::= [APPLICATION 22] SEQUENCE {
5430 pvno [0] INTEGER (5),
5431 msg-type [1] INTEGER (22),
5432 tickets [2] SEQUENCE OF Ticket,
5433 enc-part [3] EncryptedData -- EncKrbCredPart
5436 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
5437 ticket-info [0] SEQUENCE OF KrbCredInfo,
5438 nonce [1] UInt32 OPTIONAL,
5439 timestamp [2] KerberosTime OPTIONAL,
5440 usec [3] Microseconds OPTIONAL,
5441 s-address [4] HostAddress OPTIONAL,
5442 r-address [5] HostAddress OPTIONAL
5445 KrbCredInfo ::= SEQUENCE {
5446 key [0] EncryptionKey,
5447 prealm [1] Realm OPTIONAL,
5448 pname [2] PrincipalName OPTIONAL,
5449 flags [3] TicketFlags OPTIONAL,
5450 authtime [4] KerberosTime OPTIONAL,
5454 March 2003 [Page 91]
5460 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
5463 starttime [5] KerberosTime OPTIONAL,
5464 endtime [6] KerberosTime OPTIONAL,
5465 renew-till [7] KerberosTime OPTIONAL,
5466 srealm [8] Realm OPTIONAL,
5467 sname [9] PrincipalName OPTIONAL,
5468 caddr [10] HostAddresses OPTIONAL
5472 These fields are described above in section 5.4.1. msg-type is
5476 These are the tickets obtained from the KDC specifically for use
5477 by the intended recipient. Successive tickets are paired with the
5478 corresponding KrbCredInfo sequence from the enc-part of the KRB-
5482 This field holds an encoding of the EncKrbCredPart sequence
5483 encrypted under the session key shared between the sender and the
5484 intended recipient, with a key usage value of 14. This encrypted
5485 encoding is used for the enc-part field of the KRB-CRED message.
5487 Implementation note: implementations of certain applications, most
5488 notably certain implementations of the Kerberos GSS-API mechanism,
5489 do not separately encrypt the contents of the EncKrbCredPart of
5490 the KRB-CRED message when sending it. In the case of those GSS-
5491 API mechanisms, this is not a security vulnerability, as the
5492 entire KRB-CRED message is itself embedded in an encrypted
5496 If practical, an application MAY require the inclusion of a nonce
5497 generated by the recipient of the message. If the same value is
5498 included as the nonce in the message, it provides evidence that
5499 the message is fresh and has not been replayed by an attacker. A
5500 nonce MUST NEVER be reused; it SHOULD be generated randomly by the
5501 recipient of the message and provided to the sender of the message
5502 in an application specific manner.
5505 These fields specify the time that the KRB-CRED message was
5506 generated. The time is used to provide assurance that the message
5509 s-address and r-address
5510 These fields are described above in section 5.6.1. They are used
5514 March 2003 [Page 92]
5520 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
5523 optionally to provide additional assurance of the integrity of the
5527 This field exists in the corresponding ticket passed by the KRB-
5528 CRED message and is used to pass the session key from the sender
5529 to the intended recipient. The field's encoding is described in
5532 The following fields are optional. If present, they can be associated
5533 with the credentials in the remote ticket file. If left out, then it
5534 is assumed that the recipient of the credentials already knows their
5538 The name and realm of the delegated principal identity.
5540 flags, authtime, starttime, endtime, renew-till, srealm, sname, and
5542 These fields contain the values of the corresponding fields from
5543 the ticket found in the ticket field. Descriptions of the fields
5544 are identical to the descriptions in the KDC-REP message.
5546 5.9. Error message specification
5548 This section specifies the format for the KRB_ERROR message. The
5549 fields included in the message are intended to return as much
5550 information as possible about an error. It is not expected that all
5551 the information required by the fields will be available for all
5552 types of errors. If the appropriate information is not available when
5553 the message is composed, the corresponding field will be left out of
5556 Note that since the KRB_ERROR message is not integrity protected, it
5557 is quite possible for an intruder to synthesize or modify such a
5558 message. In particular, this means that the client SHOULD NOT use any
5559 fields in this message for security-critical purposes, such as
5560 setting a system clock or generating a fresh authenticator. The
5561 message can be useful, however, for advising a user on the reason for
5564 5.9.1. KRB_ERROR definition
5566 The KRB_ERROR message consists of the following fields:
5568 KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
5569 pvno [0] INTEGER (5),
5570 msg-type [1] INTEGER (30),
5574 March 2003 [Page 93]
5580 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
5583 ctime [2] KerberosTime OPTIONAL,
5584 cusec [3] Microseconds OPTIONAL,
5585 stime [4] KerberosTime,
5586 susec [5] Microseconds,
5587 error-code [6] Int32,
5588 crealm [7] Realm OPTIONAL,
5589 cname [8] PrincipalName OPTIONAL,
5590 realm [9] Realm -- service realm --,
5591 sname [10] PrincipalName -- service name --,
5592 e-text [11] KerberosString OPTIONAL,
5593 e-data [12] OCTET STRING OPTIONAL
5597 These fields are described above in section 5.4.1. +A msg-type is
5601 This field is described above in section 5.4.1.
5604 This field is described above in section 5.5.2.
5607 This field contains the current time on the server. It is of type
5611 This field contains the microsecond part of the server's
5612 timestamp. Its value ranges from 0 to 999999. It appears along
5613 with stime. The two fields are used in conjunction to specify a
5614 reasonably accurate timestamp.
5617 This field contains the error code returned by Kerberos or the
5618 server when a request fails. To interpret the value of this field
5619 see the list of error codes in section 7.5.9. Implementations are
5620 encouraged to provide for national language support in the display
5623 crealm, cname, srealm and sname
5624 These fields are described above in section 5.3.
5627 This field contains additional text to help explain the error code
5628 associated with the failed request (for example, it might include
5629 a principal name which was unknown).
5634 March 2003 [Page 94]
5640 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
5644 This field contains additional data about the error for use by the
5645 application to help it recover from or handle the error. If the
5646 errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will
5647 contain an encoding of a sequence of padata fields, each
5648 corresponding to an acceptable pre-authentication method and
5649 optionally containing data for the method:
5651 METHOD-DATA ::= SEQUENCE OF PA-DATA
5653 For error codes defined in this document other than
5654 KDC_ERR_PREAUTH_REQUIRED, the format and contents of the e-data field
5655 are implementation-defined. Similarly, for future error codes, the
5656 format and contents of the e-data field are implementation-defined
5657 unless specified. Whether defined by the implementation or in a
5658 future document, the e-data field MAY take the form of TYPED-DATA:
5660 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
5661 data-type [0] INTEGER,
5662 data-value [1] OCTET STRING OPTIONAL
5665 5.10. Application Tag Numbers
5667 The following table lists the application class tag numbers used by
5668 various data types defined in this section.
5670 Tag Number(s) Type Name Comments
5676 2 Authenticator non-PDU
5678 3 EncTicketPart non-PDU
5694 March 2003 [Page 95]
5700 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
5705 16 RESERVED16 TGT-REQ (for user-to-user)
5707 17 RESERVED17 TGT-REP (for user-to-user)
5719 25 EncASRepPart non-PDU
5721 26 EncTGSRepPart non-PDU
5723 27 EncApRepPart non-PDU
5725 28 EncKrbPrivPart non-PDU
5727 29 EncKrbCredPart non-PDU
5731 The ASN.1 types marked as "PDU" (Protocol Data Unit) in the above are
5732 the only ASN.1 types intended as top-level types of the Kerberos
5733 protcol, and are the only types that may be used as elements in
5734 another protocol that makes use of Kerberos.
5736 6. Naming Constraints
5740 Although realm names are encoded as GeneralStrings and although a
5741 realm can technically select any name it chooses, interoperability
5742 across realm boundaries requires agreement on how realm names are to
5743 be assigned, and what information they imply.
5745 To enforce these conventions, each realm MUST conform to the
5746 conventions itself, and it MUST require that any realms with which
5747 inter-realm keys are shared also conform to the conventions and
5748 require the same from its neighbors.
5750 Kerberos realm names are case sensitive. Realm names that differ only
5754 March 2003 [Page 96]
5760 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
5763 in the case of the characters are not equivalent. There are presently
5764 three styles of realm names: domain, X500, and other. Examples of
5767 domain: ATHENA.MIT.EDU
5769 other: NAMETYPE:rest/of.name=without-restrictions
5771 Domain syle realm names MUST look like domain names: they consist of
5772 components separated by periods (.) and they contain neither colons
5773 (:) nor slashes (/). Though domain names themselves are case
5774 insensitive, in order for realms to match, the case must match as
5775 well. When establishing a new realm name based on an internet domain
5776 name it is recommended by convention that the characters be converted
5779 X.500 names contain an equal (=) and cannot contain a colon (:)
5780 before the equal. The realm names for X.500 names will be string
5781 representations of the names with components separated by slashes.
5782 Leading and trailing slashes will not be included. Note that the
5783 slash separator is consistent with Kerberos implementations based on
5784 RFC1510, but it is different from the separator recommended in
5787 Names that fall into the other category MUST begin with a prefix that
5788 contains no equal (=) or period (.) and the prefix MUST be followed
5789 by a colon (:) and the rest of the name. All prefixes must be
5790 assigned before they may be used. Presently none are assigned.
5792 The reserved category includes strings which do not fall into the
5793 first three categories. All names in this category are reserved. It
5794 is unlikely that names will be assigned to this category unless there
5795 is a very strong argument for not using the 'other' category.
5797 These rules guarantee that there will be no conflicts between the
5798 various name styles. The following additional constraints apply to
5799 the assignment of realm names in the domain and X.500 categories: the
5800 name of a realm for the domain or X.500 formats must either be used
5801 by the organization owning (to whom it was assigned) an Internet
5802 domain name or X.500 name, or in the case that no such names are
5803 registered, authority to use a realm name MAY be derived from the
5804 authority of the parent realm. For example, if there is no domain
5805 name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can
5806 authorize the creation of a realm with that name.
5808 This is acceptable because the organization to which the parent is
5809 assigned is presumably the organization authorized to assign names to
5810 its children in the X.500 and domain name systems as well. If the
5814 March 2003 [Page 97]
5820 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
5823 parent assigns a realm name without also registering it in the domain
5824 name or X.500 hierarchy, it is the parent's responsibility to make
5825 sure that there will not in the future exist a name identical to the
5826 realm name of the child unless it is assigned to the same entity as
5829 6.2. Principal Names
5831 As was the case for realm names, conventions are needed to ensure
5832 that all agree on what information is implied by a principal name.
5833 The name-type field that is part of the principal name indicates the
5834 kind of information implied by the name. The name-type SHOULD be
5835 treated only as a hint to interpreting the meaning of a name. It is
5836 not significant when checking for equivalence. Principal names that
5837 differ only in the name-type identify the same principal. The name
5838 type does not partition the name space. Ignoring the name type, no
5839 two names can be the same (i.e. at least one of the components, or
5840 the realm, MUST be different). The following name types are defined:
5842 name-type value meaning
5846 NT-UNKNOWN 0 Name type not known
5847 NT-PRINCIPAL 1 Just the name of the principal as in DCE, or for users
5848 NT-SRV-INST 2 Service and other unique instance (krbtgt)
5849 NT-SRV-HST 3 Service with host name as instance (telnet, rcommands)
5850 NT-SRV-XHST 4 Service with host as remaining components
5852 NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253]
5853 NT-SMTP-NAME 7 Name in form of SMTP email name (e.g. user@foo.com)
5854 NT-ENTERPRISE 10 Enterprise name - may be mapped to principal name
5856 When a name implies no information other than its uniqueness at a
5857 particular time the name type PRINCIPAL SHOULD be used. The principal
5858 name type SHOULD be used for users, and it might also be used for a
5859 unique server. If the name is a unique machine generated ID that is
5860 guaranteed never to be reassigned then the name type of UID SHOULD be
5861 used (note that it is generally a bad idea to reassign names of any
5862 type since stale entries might remain in access control lists).
5864 If the first component of a name identifies a service and the
5865 remaining components identify an instance of the service in a server
5866 specified manner, then the name type of SRV-INST SHOULD be used. An
5867 example of this name type is the Kerberos ticket-granting service
5868 whose name has a first component of krbtgt and a second component
5869 identifying the realm for which the ticket is valid.
5874 March 2003 [Page 98]
5880 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
5883 If the first component of a name identifies a service and there is a
5884 single component following the service name identifying the instance
5885 as the host on which the server is running, then the name type SRV-
5886 HST SHOULD be used. This type is typically used for Internet services
5887 such as telnet and the Berkeley R commands. If the separate
5888 components of the host name appear as successive components following
5889 the name of the service, then the name type SRV-XHST SHOULD be used.
5890 This type might be used to identify servers on hosts with X.500 names
5891 where the slash (/) might otherwise be ambiguous.
5893 A name type of NT-X500-PRINCIPAL SHOULD be used when a name from an
5894 X.509 certificate is translated into a Kerberos name. The encoding of
5895 the X.509 name as a Kerberos principal shall conform to the encoding
5896 rules specified in RFC 2253.
5898 A name type of SMTP allows a name to be of a form that resembles a
5899 SMTP email name. This name, including an "@" and a domain name, is
5900 used as the one component of the principal name.
5902 A name type of UNKNOWN SHOULD be used when the form of the name is
5903 not known. When comparing names, a name of type UNKNOWN will match
5904 principals authenticated with names of any type. A principal
5905 authenticated with a name of type UNKNOWN, however, will only match
5906 other names of type UNKNOWN.
5908 Names of any type with an initial component of 'krbtgt' are reserved
5909 for the Kerberos ticket granting service. See section 7.5.8 for the
5912 6.2.1. Name of server principals
5914 The principal identifier for a server on a host will generally be
5915 composed of two parts: (1) the realm of the KDC with which the server
5916 is registered, and (2) a two-component name of type NT-SRV-HST if the
5917 host name is an Internet domain name or a multi-component name of
5918 type NT-SRV-XHST if the name of the host is of a form such as X.500
5919 that allows slash (/) separators. The first component of the two- or
5920 multi-component name will identify the service and the latter
5921 components will identify the host. Where the name of the host is not
5922 case sensitive (for example, with Internet domain names) the name of
5923 the host MUST be lower case. If specified by the application protocol
5924 for services such as telnet and the Berkeley R commands which run
5925 with system privileges, the first component MAY be the string 'host'
5926 instead of a service specific identifier. When a host has an official
5927 name and one or more aliases and the official name can be reliably
5928 determined, the official name of the host SHOULD be used when
5929 constructing the name of the server principal.
5934 March 2003 [Page 99]
5940 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
5943 7. Constants and other defined values
5945 7.1. Host address types
5947 All negative values for the host address type are reserved for local
5948 use. All non-negative values are reserved for officially assigned
5949 type fields and interpretations.
5951 Internet (IPv4) Addresses
5953 Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded
5954 in MSB order. The IPv4 loopback address SHOULD NOT appear in a
5955 Kerberos packet. The type of IPv4 addresses is two (2).
5957 Internet (IPv6) Addresses
5959 IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities,
5960 encoded in MSB order. The type of IPv6 addresses is twenty-four
5961 (24). The following addresses MUST NOT appear in any Kerberos
5964 * the Unspecified Address
5965 * the Loopback Address
5966 * Link-Local addresses
5968 IPv4-mapped IPv6 addresses MUST be represented as addresses of
5971 DECnet Phase IV addresses
5973 DECnet Phase IV addresses are 16-bit addresses, encoded in LSB
5974 order. The type of DECnet Phase IV addresses is twelve (12).
5978 Netbios addresses are 16-octet addresses typically composed of 1
5979 to 15 alphanumeric characters and padded with the US-ASCII SPC
5980 character (code 32). The 16th octet MUST be the US-ASCII NUL
5981 character (code 0). The type of Netbios addresses is twenty (20).
5983 Directional Addresses
5985 In many environments, including the sender address in KRB_SAFE and
5986 KRB_PRIV messages is undesirable because the addresses may be
5987 changed in transport by network address translators. However, if
5988 these addresses are removed, the messages may be subject to a
5989 reflection attack in which a message is reflected back to its
5990 originator. The directional address type provides a way to avoid
5994 March 2003 [Page 100]
6000 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
6003 transport addresses and reflection attacks. Directional addresses
6004 are encoded as four byte unsigned integers in network byte order.
6005 If the message is originated by the party sending the original
6006 KRB_AP_REQ message, then an address of 0 SHOULD be used. If the
6007 message is originated by the party to whom that KRB_AP_REQ was
6008 sent, then the address 1 SHOULD be used. Applications involving
6009 multiple parties can specify the use of other addresses.
6011 Directional addresses MUST only be used for the sender address
6012 field in the KRB_SAFE or KRB_PRIV messages. They MUST NOT be used
6013 as a ticket address or in a KRB_AP_REQ message. This address type
6014 SHOULD only be used in situations where the sending party knows
6015 that the receiving party supports the address type. This generally
6016 means that directional addresses may only be used when the
6017 application protocol requires their support. Directional addresses
6020 7.2. KDC messaging - IP Transports
6022 Kerberos defines two IP transport mechanisms for communication
6023 between clients and servers: UDP/IP and TCP/IP.
6025 7.2.1. UDP/IP transport
6027 Kerberos servers (KDCs) supporting IP transports MUST accept UDP
6028 requests and SHOULD listen for such requests on port 88 (decimal)
6029 unless specifically configured to listen on an alternative UDP port.
6030 Alternate ports MAY be used when running multiple KDCs for multiple
6031 realms on the same host.
6033 Kerberos clients supporting IP transports SHOULD support the sending
6034 of UDP requests. Clients SHOULD use KDC discovery [7.2.3] to identify
6035 the IP address and port to which they will send their request.
6037 When contacting a KDC for a KRB_KDC_REQ request using UDP/IP
6038 transport, the client shall send a UDP datagram containing only an
6039 encoding of the request to the KDC. The KDC will respond with a reply
6040 datagram containing only an encoding of the reply message (either a
6041 KRB_ERROR or a KRB_KDC_REP) to the sending port at the sender's IP
6042 address. The response to a request made through UDP/IP transport MUST
6043 also use UDP/IP transport. If the response can not be handled using
6044 UDP (for example because it is too large), the KDC MUST return
6045 KRB_ERR_RESPONSE_TOO_BIG, forcing the client to retry the request
6046 using the TCP transport.
6048 7.2.2. TCP/IP transport
6050 Kerberos servers (KDCs) supporting IP transports MUST accept TCP
6054 March 2003 [Page 101]
6060 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
6063 requests and SHOULD listen for such requests on port 88 (decimal)
6064 unless specifically configured to listen on an alternate TCP port.
6065 Alternate ports MAY be used when running multiple KDCs for multiple
6066 realms on the same host.
6068 Clients MUST support the sending of TCP requests, but MAY choose to
6069 intially try a request using the UDP transport. Clients SHOULD use
6070 KDC discovery [7.2.3] to identify the IP address and port to which
6071 they will send their request.
6073 Implementation note: Some extensions to the Kerberos protocol will
6074 not succeed if any client or KDC not supporting the TCP transport is
6075 involved. Implementations of RFC 1510 were not required to support
6078 When the KRB_KDC_REQ message is sent to the KDC over a TCP stream,
6079 the response (KRB_KDC_REP or KRB_ERROR message) MUST be returned to
6080 the client on the same TCP stream that was established for the
6081 request. The KDC MAY close the TCP stream after sending a response,
6082 but MAY leave the stream open for a reasonable period of time if it
6083 expects a followup. Care must be taken in managing TCP/IP connections
6084 on the KDC to prevent denial of service attacks based on the number
6085 of open TCP/IP connections.
6087 The client MUST be prepared to have the stream closed by the KDC at
6088 anytime after the receipt of a response. A stream closure SHOULD NOT
6089 be treated as a fatal error. Instead, if multiple exchanges are
6090 required (e.g., certain forms of pre-authentication) the client may
6091 need to establish a new connection when it is ready to send
6092 subsequent messages. A client MAY close the stream after receiving a
6093 response, and SHOULD close the stream if it does not expect to send
6096 A client MAY send multiple requests before receiving responses,
6097 though it must be prepared to handle the connection being closed
6098 after the first response.
6100 Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR)
6101 sent over the TCP stream is preceded by the length of the request as
6102 4 octets in network byte order. The high bit of the length is
6103 reserved for future expansion and MUST currently be set to zero.
6105 If multiple requests are sent over a single TCP connection, and the
6106 KDC sends multiple responses, the KDC is not required to send the
6107 responses in the order of the corresponding requests. This may permit
6108 some implementations to send each response as soon as it is ready
6109 even if earlier requests are still being processed (for example,
6110 waiting for a response from an external device or database).
6114 March 2003 [Page 102]
6120 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
6123 7.2.3. KDC Discovery on IP Networks
6125 Kerberos client implementations MUST provide a means for the client
6126 to determine the location of the Kerberos Key Distribution Centers
6127 (KDCs). Traditionally, Kerberos implementations have stored such
6128 configuration information in a file on each client machine.
6129 Experience has shown this method of storing configuration information
6130 presents problems with out-of-date information and scaling problems,
6131 especially when using cross-realm authentication. This section
6132 describes a method for using the Domain Name System [RFC 1035] for
6133 storing KDC location information.
6135 7.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names
6137 In Kerberos, realm names are case sensitive. While it is strongly
6138 encouraged that all realm names be all upper case this recommendation
6139 has not been adopted by all sites. Some sites use all lower case
6140 names and other use mixed case. DNS on the other hand is case
6141 insensitive for queries. Since "MYREALM", "myrealm", and "MyRealm"
6142 are all different it is necessary that only one of the possible
6143 combinations of upper and lower case characters be used. This
6144 restriction may be lifted in the future as the DNS naming scheme is
6145 expanded to support non-US-ASCII names.
6147 7.2.3.2. Specifying KDC Location information with DNS SRV records
6149 KDC location information is to be stored using the DNS SRV RR [RFC
6150 2052]. The format of this RR is as follows:
6152 Service.Proto.Realm TTL Class SRV Priority Weight Port Target
6154 The Service name for Kerberos is always "_kerberos".
6156 The Proto can be one of "_udp", "_tcp". If these SRV records are to
6157 be used, both "_udp" and "_tcp" records MUST be specified for all KDC
6160 The Realm is the Kerberos realm that this record corresponds to.
6162 TTL, Class, SRV, Priority, Weight, and Target have the standard
6163 meaning as defined in RFC 2052.
6165 As per RFC 2052 the Port number used for "_udp" and "_tcp" SRV
6166 records SHOULD be the value assigned to "kerberos" by the Internet
6167 Assigned Number Authority: 88 (decimal) unless the KDC is configured
6168 to listen on an alternate TCP port.
6170 Implementation note: Many existing client implementations do not
6174 March 2003 [Page 103]
6180 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
6183 support KDC Discovery and are configured to send requests to the IANA
6184 assigned port (88 decimal), so it is strongly recommended that KDCs
6185 be configured to listen on that port.
6187 7.2.3.3. KDC Discovery for Domain Style Realm Names on IP Networks
6189 These are DNS records for a Kerberos realm EXAMPLE.COM. It has two
6190 Kerberos servers, kdc1.example.com and kdc2.example.com. Queries
6191 should be directed to kdc1.example.com first as per the specified
6192 priority. Weights are not used in these sample records.
6194 _kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
6195 _kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
6196 _kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
6197 _kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
6199 7.3. Name of the TGS
6201 The principal identifier of the ticket-granting service shall be
6202 composed of three parts: (1) the realm of the KDC issuing the TGS
6203 ticket (2) a two-part name of type NT-SRV-INST, with the first part
6204 "krbtgt" and the second part the name of the realm which will accept
6205 the ticket-granting ticket. For example, a ticket-granting ticket
6206 issued by the ATHENA.MIT.EDU realm to be used to get tickets from the
6207 ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU"
6208 (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting
6209 ticket issued by the ATHENA.MIT.EDU realm to be used to get tickets
6210 from the MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU"
6211 (realm), ("krbtgt", "MIT.EDU") (name).
6213 7.4. OID arc for KerberosV5
6215 This OID MAY be used to identify Kerberos protocol messages
6216 encapsulated in other protocols. It also designates the OID arc for
6217 KerberosV5-related OIDs assigned by future IETF action.
6218 Implementation note:: RFC 1510 had an incorrect value (5) for "dod"
6221 id-krb5 OBJECT IDENTIFIER ::= {
6222 iso(1) identified-organization(3) dod(6) internet(1)
6223 security(5) kerberosV5(2)
6226 Assignment of OIDs beneath the id-krb5 arc must be obtained by
6227 contacting krb5-oid-registrar@mit.edu.
6229 7.5. Protocol constants and associated values
6234 March 2003 [Page 104]
6240 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
6243 The following tables list constants used in the protocol and define
6244 their meanings. Ranges are specified in the "specification" section
6245 that limit the values of constants for which values are defined here.
6246 This allows implementations to make assumptions about the maximum
6247 values that will be received for these constants. Implementation
6248 receiving values outside the range specified in the "specification"
6249 section MAY reject the request, but they MUST recover cleanly.
6251 7.5.1. Key usage numbers
6253 The encryption and checksum specifications in [@KCRYPTO] require as
6254 input a "key usage number", to alter the encryption key used in any
6255 specific message, to make certain types of cryptographic attack more
6256 difficult. These are the key usage values assigned in this document:
6258 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted
6259 with the client key (section 5.2.7.2)
6260 2. AS-REP Ticket and TGS-REP Ticket (includes TGS session
6261 key or application session key), encrypted with the
6262 service key (section 5.3)
6263 3. AS-REP encrypted part (includes TGS session key or
6264 application session key), encrypted with the client key
6266 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with
6267 the TGS session key (section 5.4.1)
6268 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with
6269 the TGS authenticator subkey (section 5.4.1)
6270 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum,
6271 keyed with the TGS session key (sections 5.5.1)
6272 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator
6273 (includes TGS authenticator subkey), encrypted with the
6274 TGS session key (section 5.5.1)
6275 8. TGS-REP encrypted part (includes application session
6276 key), encrypted with the TGS session key (section
6278 9. TGS-REP encrypted part (includes application session
6279 key), encrypted with the TGS authenticator subkey
6281 10. AP-REQ Authenticator cksum, keyed with the application
6282 session key (section 5.5.1)
6283 11. AP-REQ Authenticator (includes application
6284 authenticator subkey), encrypted with the application
6285 session key (section 5.5.1)
6286 12. AP-REP encrypted part (includes application session
6287 subkey), encrypted with the application session key
6289 13. KRB-PRIV encrypted part, encrypted with a key chosen by
6290 the application (section 5.7.1)
6294 March 2003 [Page 105]
6300 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
6303 14. KRB-CRED encrypted part, encrypted with a key chosen by
6304 the application (section 5.8.1)
6305 15. KRB-SAFE cksum, keyed with a key chosen by the
6306 application (section 5.6.1)
6307 19. AD-KDC-ISSUED checksum (ad-checksum in 5.2.6.4)
6308 22-24. Reserved for use in GSSAPI mechanisms derived from RFC
6310 16-18,20-21,25-511. Reserved for future use in Kerberos and related
6312 512-1023. Reserved for uses internal to a Kerberos
6314 1024. Encryption for application use in protocols that
6315 do not specify key usage values
6316 1025. Checksums for application use in protocols that
6317 do not specify key usage values
6318 1026-2047. Reserved for application use.
6321 7.5.2. PreAuthentication Data Types
6323 padata and data types padata-type value comment
6329 PA-ENC-UNIX-TIME 5 (deprecated)
6330 PA-SANDIA-SECUREID 6
6333 PA-CYBERSAFE-SECUREID 9
6336 PA-SAM-CHALLENGE 12 (sam/otp)
6337 PA-SAM-RESPONSE 13 (sam/otp)
6338 PA-PK-AS-REQ 14 (pkinit)
6339 PA-PK-AS-REP 15 (pkinit)
6340 PA-ETYPE-INFO2 19 (replaces pa-etype-info)
6341 PA-USE-SPECIFIED-KVNO 20
6342 PA-SAM-REDIRECT 21 (sam/otp)
6343 PA-GET-FROM-TYPED-DATA 22 (embedded in typed data)
6344 TD-PADATA 22 (embeds padata)
6345 PA-SAM-ETYPE-INFO 23 (sam/otp)
6346 PA-ALT-PRINC 24 (crawdad@fnal.gov)
6347 PA-SAM-CHALLENGE2 30 (kenh@pobox.com)
6348 PA-SAM-RESPONSE2 31 (kenh@pobox.com)
6349 PA-EXTRA-TGT 41 Reserved extra TGT
6350 TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS
6354 March 2003 [Page 106]
6360 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
6363 TD-KRB-PRINCIPAL 102 PrincipalName
6364 TD-KRB-REALM 103 Realm
6365 TD-TRUSTED-CERTIFIERS 104 from PKINIT
6366 TD-CERTIFICATE-INDEX 105 from PKINIT
6367 TD-APP-DEFINED-ERROR 106 application specific
6368 TD-REQ-NONCE 107 INTEGER
6369 TD-REQ-SEQ 108 INTEGER
6370 PA-PAC-REQUEST 128 (jbrezak@exchange.microsoft.com)
6372 7.5.3. Address Types
6386 7.5.4. Authorization Data Types
6388 authorization data type ad-type value
6390 AD-INTENDED-FOR-SERVER 2
6391 AD-INTENDED-FOR-APPLICATION-CLASS 3
6394 AD-MANDATORY-TICKET-EXTENSIONS 6
6395 AD-IN-TICKET-EXTENSIONS 7
6396 AD-MANDATORY-FOR-KDC 8
6397 reserved values 9-63
6400 AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com)
6401 AD-WIN2K-PAC 128 (jbrezak@exchange.microsoft.com)
6403 7.5.5. Transited Encoding Types
6405 transited encoding type tr-type value
6406 DOMAIN-X500-COMPRESS 1
6407 reserved values all others
6409 7.5.6. Protocol Version Number
6414 March 2003 [Page 107]
6420 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
6423 Label Value Meaning or MIT code
6425 pvno 5 current Kerberos protocol version number
6427 7.5.7. Kerberos Message Types
6431 KRB_AS_REQ 10 Request for initial authentication
6432 KRB_AS_REP 11 Response to KRB_AS_REQ request
6433 KRB_TGS_REQ 12 Request for authentication based on TGT
6434 KRB_TGS_REP 13 Response to KRB_TGS_REQ request
6435 KRB_AP_REQ 14 application request to server
6436 KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL
6437 KRB_RESERVED16 16 Reserved for user-to-user krb_tgt_request
6438 KRB_RESERVED17 17 Reserved for user-to-user krb_tgt_reply
6439 KRB_SAFE 20 Safe (checksummed) application message
6440 KRB_PRIV 21 Private (encrypted) application message
6441 KRB_CRED 22 Private (encrypted) message to forward credentials
6442 KRB_ERROR 30 Error response
6448 KRB_NT_UNKNOWN 0 Name type not known
6449 KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users
6450 KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt)
6451 KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands)
6452 KRB_NT_SRV_XHST 4 Service with host as remaining components
6453 KRB_NT_UID 5 Unique ID
6454 KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253]
6455 KRB_NT_SMTP_NAME 7 Name in form of SMTP email name (e.g. user@foo.com)
6456 KRB_NT_ENTERPRISE 10 Enterprise name - may be mapped to principal name
6462 KDC_ERR_NONE 0 No error
6463 KDC_ERR_NAME_EXP 1 Client's entry in database has expired
6464 KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired
6465 KDC_ERR_BAD_PVNO 3 Requested protocol version number
6467 KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key
6468 KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key
6469 KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database
6470 KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database
6474 March 2003 [Page 108]
6480 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
6483 KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database
6484 KDC_ERR_NULL_KEY 9 The client or server has a null key
6485 KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating
6486 KDC_ERR_NEVER_VALID 11 Requested start time is later than end time
6487 KDC_ERR_POLICY 12 KDC policy rejects request
6488 KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option
6489 KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type
6490 KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type
6491 KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type
6492 KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type
6493 KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked
6494 KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked
6495 KDC_ERR_TGT_REVOKED 20 TGT has been revoked
6496 KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later
6497 KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later
6498 KDC_ERR_KEY_EXPIRED 23 Password has expired
6499 - change password to reset
6500 KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid
6501 KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired
6502 KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match
6503 KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user only
6504 KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path
6505 KDC_ERR_SVC_UNAVAILABLE 29 A service is not available
6506 KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed
6507 KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired
6508 KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid
6509 KRB_AP_ERR_REPEAT 34 Request is a replay
6510 KRB_AP_ERR_NOT_US 35 The ticket isn't for us
6511 KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match
6512 KRB_AP_ERR_SKEW 37 Clock skew too great
6513 KRB_AP_ERR_BADADDR 38 Incorrect net address
6514 KRB_AP_ERR_BADVERSION 39 Protocol version mismatch
6515 KRB_AP_ERR_MSG_TYPE 40 Invalid msg type
6516 KRB_AP_ERR_MODIFIED 41 Message stream modified
6517 KRB_AP_ERR_BADORDER 42 Message out of order
6518 KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available
6519 KRB_AP_ERR_NOKEY 45 Service key not available
6520 KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed
6521 KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction
6522 KRB_AP_ERR_METHOD 48 Alternative authentication method required
6523 KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message
6524 KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message
6525 KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path
6526 KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP, retry with TCP
6527 KRB_ERR_GENERIC 60 Generic error (description in e-text)
6528 KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation
6529 KDC_ERROR_CLIENT_NOT_TRUSTED 62 Reserved for PKINIT
6530 KDC_ERROR_KDC_NOT_TRUSTED 63 Reserved for PKINIT
6534 March 2003 [Page 109]
6540 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
6543 KDC_ERROR_INVALID_SIG 64 Reserved for PKINIT
6544 KDC_ERR_KEY_TOO_WEAK 65 Reserved for PKINIT
6545 KDC_ERR_CERTIFICATE_MISMATCH 66 Reserved for PKINIT
6546 KRB_AP_ERR_NO_TGT 67 No TGT available to validate USER-TO-USER
6547 KDC_ERR_WRONG_REALM 68 USER-TO-USER TGT issued different KDC
6548 KRB_AP_ERR_USER_TO_USER_REQUIRED 69 Ticket must be for USER-TO-USER
6549 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 Reserved for PKINIT
6550 KDC_ERR_INVALID_CERTIFICATE 71 Reserved for PKINIT
6551 KDC_ERR_REVOKED_CERTIFICATE 72 Reserved for PKINIT
6552 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 Reserved for PKINIT
6553 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 Reserved for PKINIT
6554 KDC_ERR_CLIENT_NAME_MISMATCH 75 Reserved for PKINIT
6555 KDC_ERR_KDC_NAME_MISMATCH 76 Reserved for PKINIT
6557 8. Interoperability requirements
6559 Version 5 of the Kerberos protocol supports a myriad of options.
6560 Among these are multiple encryption and checksum types, alternative
6561 encoding schemes for the transited field, optional mechanisms for
6562 pre-authentication, the handling of tickets with no addresses,
6563 options for mutual authentication, user to user authentication,
6564 support for proxies, forwarding, postdating, and renewing tickets,
6565 the format of realm names, and the handling of authorization data.
6567 In order to ensure the interoperability of realms, it is necessary to
6568 define a minimal configuration which must be supported by all
6569 implementations. This minimal configuration is subject to change as
6570 technology does. For example, if at some later date it is discovered
6571 that one of the required encryption or checksum algorithms is not
6572 secure, it will be replaced.
6574 8.1. Specification 2
6576 This section defines the second specification of these options.
6577 Implementations which are configured in this way can be said to
6578 support Kerberos Version 5 Specification 2 (5.2). Specification 1
6579 (deprecated) may be found in RFC1510.
6583 TCP/IP and UDP/IP transport MUST be supported by clients and KDCs
6584 claiming conformance to specification 2.
6586 Encryption and checksum methods
6588 The following encryption and checksum mechanisms MUST be
6594 March 2003 [Page 110]
6600 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
6603 Encryption: AES256-CTS-HMAC-SHA1-96
6604 Checksums: HMAC-SHA1-96-AES256
6606 Implementations SHOULD support other mechanisms as well, but the
6607 additional mechanisms may only be used when communicating with
6608 principals known to also support them. The mechanisms that SHOULD
6611 Encryption: DES-CBC-MD5, DES3-CBC-SHA1-KD
6612 Checksums: DES-MD5, HMAC-SHA1-DES3-KD
6614 Implementations MAY support other mechanisms as well, but the
6615 additional mechanisms may only be used when communicating with
6616 principals known to also support them.
6618 Implementation note: earlier implementations of Kerberos generate
6619 messages using the CRC-32, RSA-MD5 checksum methods. For
6620 interoperability with these earlier releases implementors MAY
6621 consider supporting these checksum methods but should carefully
6622 analyze the security impplications to limit the situations within
6623 which these methods are accepted.
6627 All implementations MUST understand hierarchical realms in both
6628 the Internet Domain and the X.500 style. When a ticket-granting
6629 ticket for an unknown realm is requested, the KDC MUST be able to
6630 determine the names of the intermediate realms between the KDCs
6631 realm and the requested realm.
6633 Transited field encoding
6635 DOMAIN-X500-COMPRESS (described in section 3.3.3.2) MUST be
6636 supported. Alternative encodings MAY be supported, but they may
6637 be used only when that encoding is supported by ALL intermediate
6640 Pre-authentication methods
6642 The TGS-REQ method MUST be supported. The TGS-REQ method is not
6643 used on the initial request. The PA-ENC-TIMESTAMP method MUST be
6644 supported by clients but whether it is enabled by default MAY be
6645 determined on a realm by realm basis. If not used in the initial
6646 request and the error KDC_ERR_PREAUTH_REQUIRED is returned
6647 specifying PA-ENC-TIMESTAMP as an acceptable method, the client
6648 SHOULD retry the initial request using the PA-ENC-TIMESTAMP pre-
6649 authentication method. Servers need not support the PA-ENC-
6650 TIMESTAMP method, but if not supported the server SHOULD ignore
6654 March 2003 [Page 111]
6660 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
6663 the presence of PA-ENC-TIMESTAMP pre-authentication in a request.
6665 The ETYPE-INFO2 method MUST be supported; this method is used to
6666 communicate the set of supported encryption types, and
6667 corresponding salt and string to key paramters. The ETYPE-INFO
6668 method SHOULD be supported for interoperability with older
6671 Mutual authentication
6673 Mutual authentication (via the KRB_AP_REP message) MUST be
6676 Ticket addresses and flags
6678 All KDCs MUST pass through tickets that carry no addresses (i.e.
6679 if a TGT contains no addresses, the KDC will return derivative
6680 tickets). Implementations SHOULD default to requesting
6681 addressless tickets as this significantly increases
6682 interoperability with network address translation. In some cases
6683 realms or application servers MAY require that tickets have an
6686 Implementations SHOULD accept directional address type for the
6687 KRB_SAFE and KRB_PRIV message and SHOULD include directional
6688 addresses in these messages when other address types are not
6691 Proxies and forwarded tickets MUST be supported. Individual realms
6692 and application servers can set their own policy on when such
6693 tickets will be accepted.
6695 All implementations MUST recognize renewable and postdated
6696 tickets, but need not actually implement them. If these options
6697 are not supported, the starttime and endtime in the ticket shall
6698 specify a ticket's entire useful life. When a postdated ticket is
6699 decoded by a server, all implementations shall make the presence
6700 of the postdated flag visible to the calling server.
6702 User-to-user authentication
6704 Support for user to user authentication (via the ENC-TKT-IN-SKEY
6705 KDC option) MUST be provided by implementations, but individual
6706 realms MAY decide as a matter of policy to reject such requests on
6707 a per-principal or realm-wide basis.
6714 March 2003 [Page 112]
6720 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
6723 Implementations MUST pass all authorization data subfields from
6724 ticket-granting tickets to any derivative tickets unless directed
6725 to suppress a subfield as part of the definition of that
6726 registered subfield type (it is never incorrect to pass on a
6727 subfield, and no registered subfield types presently specify
6728 suppression at the KDC).
6730 Implementations MUST make the contents of any authorization data
6731 subfields available to the server when a ticket is used.
6732 Implementations are not required to allow clients to specify the
6733 contents of the authorization data fields.
6737 All protocol constants are constrained to 32 bit (signed) values
6738 unless further constrained by the protocol definition. This limit
6739 is provided to allow implementations to make assumptions about the
6740 maximum values that will be received for these constants.
6741 Implementation receiving values outside this range MAY reject the
6742 request, but they MUST recover cleanly.
6744 8.2. Recommended KDC values
6746 Following is a list of recommended values for a KDC configuration.
6748 minimum lifetime 5 minutes
6749 maximum renewable lifetime 1 week
6750 maximum ticket lifetime 1 day
6751 acceptable clock skew 5 minutes
6752 empty addresses Allowed.
6753 proxiable, etc. Allowed.
6755 9. IANA considerations
6757 Section 7 of this document specifies protocol constants and other
6758 defined values required for the interoperability of multiple
6759 implementations. Until otherwise specified in a subsequent RFC,
6760 allocations of additional protocol constants and other defined values
6761 required for extensions to the Kerberos protocol will be administered
6762 by the Kerberos Working Group.
6764 10. Security Considerations
6766 As an authentication service, Kerberos provides a means of verifying
6767 the identity of principals on a network. Kerberos does not, by
6768 itself, provide authorization. Applications should not accept the
6769 issuance of a service ticket by the Kerberos server as granting
6770 authority to use the service, since such applications may become
6774 March 2003 [Page 113]
6780 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
6783 vulnerable to the bypass of this authorization check in an
6784 environment if they inter-operate with other KDCs or where other
6785 options for application authentication are provided.
6787 Denial of service attacks are not solved with Kerberos. There are
6788 places in the protocols where an intruder can prevent an application
6789 from participating in the proper authentication steps. Because
6790 authentication is a required step for the use of many services,
6791 successful denial of service attacks on a Kerberos server might
6792 result in the denial of other network services that rely on Kerberos
6793 for authentication. Kerberos is vulnerable to many kinds of denial of
6794 service attacks: denial of service attacks on the network which would
6795 prevent clients from contacting the KDC; denial of service attacks on
6796 the domain name system which could prevent a client from finding the
6797 IP address of the Kerberos server; and denial of service attack by
6798 overloading the Kerberos KDC itself with repeated requests.
6800 Interoperability conflicts caused by incompatible character-set usage
6801 (see 5.2.1) can result in denial of service for clients that utilize
6802 character-sets in Kerberos strings other than those stored in the KDC
6805 Authentication servers maintain a database of principals (i.e., users
6806 and servers) and their secret keys. The security of the
6807 authentication server machines is critical. The breach of security of
6808 an authentication server will compromise the security of all servers
6809 that rely upon the compromised KDC, and will compromise the
6810 authentication of any principals registered in the realm of the
6813 Principals must keep their secret keys secret. If an intruder somehow
6814 steals a principal's key, it will be able to masquerade as that
6815 principal or impersonate any server to the legitimate principal.
6817 Password guessing attacks are not solved by Kerberos. If a user
6818 chooses a poor password, it is possible for an attacker to
6819 successfully mount an off-line dictionary attack by repeatedly
6820 attempting to decrypt, with successive entries from a dictionary,
6821 messages obtained which are encrypted under a key derived from the
6824 Unless pre-authentication options are required by the policy of a
6825 realm, the KDC will not know whether a request for authentication
6826 succeeds. An attacker can request a reply with credentials for any
6827 principal. These credentials will likely not be of much use to the
6828 attacker unless it knows the client's secret key, but the
6829 availability of the response encrypted in the client's secret key
6830 provides the attacker with ciphertext that may be used to mount brute
6834 March 2003 [Page 114]
6840 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
6843 force or dictionary attacks to decrypt the credentials, by guessing
6844 the user's password. For this reason it is strongly encouraged that
6845 Kerberos realms require the use of pre-authentication. Even with pre-
6846 authentication, attackers may try brute force or dictionary attacks
6847 against credentials that are observed by eavesdropping on the
6850 Because a client can request a ticket for any server principal and
6851 can attempt a brute force or dictionary attack against the server
6852 principal's key using that ticket, it is strongly encouraged that
6853 keys be randomly generated (rather than generated from passwords) for
6854 any principals that are usable as the target principal for a
6855 KRB_TGS_REQ or KRB_AS_REQ messages.
6857 Each host on the network must have a clock which is loosely
6858 synchronized to the time of the other hosts; this synchronization is
6859 used to reduce the bookkeeping needs of application servers when they
6860 do replay detection. The degree of "looseness" can be configured on a
6861 per-server basis, but is typically on the order of 5 minutes. If the
6862 clocks are synchronized over the network, the clock synchronization
6863 protocol must itself be secured from network attackers.
6865 Principal identifiers must not recycled on a short-term basis. A
6866 typical mode of access control will use access control lists (ACLs)
6867 to grant permissions to particular principals. If a stale ACL entry
6868 remains for a deleted principal and the principal identifier is
6869 reused, the new principal will inherit rights specified in the stale
6870 ACL entry. By not reusing principal identifiers, the danger of
6871 inadvertent access is removed.
6873 Proper decryption of an KRB_AS_REP message from the KDC is not
6874 sufficient for the host to verify the identity of the user; the user
6875 and an attacker could cooperate to generate a KRB_AS_REP format
6876 message which decrypts properly but is not from the proper KDC. To
6877 authenticate a user logging on to a local system, the credentials
6878 obtained in the AS exchange may first be used in a TGS exchange to
6879 obtain credentials for a local server. Those credentials must then be
6880 verified by a local server through successful completion of the
6881 Client/Server exchange.
6883 Kerberos credentials contain clear-text information identifying the
6884 principals to which they apply. If privacy of this information is
6885 needed, this exchange should itself be encapsulated in a protocol
6886 providing for confidentiality on the exchange of these credentials.
6888 Applications must take care to protect communications subsequent to
6889 authentication either by using the KRB_PRIV or KRB_SAFE messages as
6890 appropriate, or by applying their own confidentiality or integrity
6894 March 2003 [Page 115]
6900 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
6903 mechanisms on such communications. Completion of the KRB_AP_REQ and
6904 KRB_AP_REP exchange without subsequent use of confidentiality and
6905 integrity mechanisms provides only for authentication of the parties
6906 to the communication and not confidentiality and integrity of the
6907 subsequent communication. Application applying confidentiality and
6908 protections mechanisms other than KRB_PRIV and KRB_SAFE must make
6909 sure that the authentication step is appropriately linked with the
6910 protected communication channel that is established by the
6913 Unless the application server provides its own suitable means to
6914 protect against replay (for example, a challenge-response sequence
6915 initiated by the server after authentication, or use of a server-
6916 generated encryption subkey), the server must utilize a replay cache
6917 to remember any authenticator presented within the allowable clock
6918 skew. All services sharing a key need to use the same replay cache.
6919 If separate replay caches are used, then and authenticator used with
6920 one such service could later be replayed to a different service with
6921 the same service principal.
6923 If a server loses track of authenticators presented within the
6924 allowable clock skew, it must reject all requests until the clock
6925 skew interval has passed, providing assurance that any lost or
6926 replayed authenticators will fall outside the allowable clock skew
6927 and can no longer be successfully replayed.
6929 Implementations of Kerberos should not use untrusted directory
6930 servers to determine the realm of a host. To allow such would allow
6931 the compromise of the directory server to enable an attacker to
6932 direct the client to accept authentication with the wrong principal
6933 (i.e. one with a similar name, but in a realm with which the
6934 legitimate host was not registered).
6936 Implementations of Kerberos must not use DNS to canonicalize the host
6937 components of service principal names. To allow such canonicalization
6938 would allow a compromise of the DNS to result in a client obtaining
6939 credentials and correctly authenticating to the wrong principal.
6940 Though the client will know who it is communicating with, it will not
6941 be the principal with which it intended to communicate.
6943 If the Kerberos server returns a TGT for a 'closer' realm other than
6944 the desired realm, the client may use local policy configuration to
6945 verify that the authentication path used is an acceptable one.
6946 Alternatively, a client may choose its own authentication path,
6947 rather than relying on the Kerberos server to select one. In either
6948 case, any policy or configuration information used to choose or
6949 validate authentication paths, whether by the Kerberos server or
6950 client, must be obtained from a trusted source.
6954 March 2003 [Page 116]
6960 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
6963 The Kerberos protocol in its basic form does not provide perfect
6964 forward secrecy for communications. If traffic has been recorded by
6965 an eavesdropper, then messages encrypted using the KRB_PRIV message,
6966 or messages encrypted using application specific encryption under
6967 keys exchanged using Kerberos can be decrypted if any of the user's,
6968 application server's, or KDC's key is subsequently discovered. This
6969 is because the session key use to encrypt such messages is
6970 transmitted over the network encrypted in the key of the application
6971 server, and also encrypted under the session key from the user's
6972 ticket-granting ticket when returned to the user in the KRB_TGS_REP
6973 message. The session key from the ticket-granting ticket was sent to
6974 the user in the KRB_AS_REP message encrypted in the user's secret
6975 key, and embedded in the ticket-granting ticket, which was encrypted
6976 in the key of the KDC. Application requiring perfect forward secrecy
6977 must exchange keys through mechanisms that provide such assurance,
6978 but may use Kerberos for authentication of the encrypted channel
6979 established through such other means.
6981 11. Author's Addresses
6985 Information Sciences Institute
6986 University of Southern California
6988 Marina del Rey, CA 90292, USA
6992 Massachusetts Institute of Technology
6993 77 Massachusetts Avenue
6994 Cambridge, MA 02139, USA
6998 Massachusetts Institute of Technology
6999 77 Massachusetts Avenue
7000 Cambridge, MA 02139, USA
7001 Email: hartmans@mit.edu
7004 Massachusetts Institute of Technology
7005 77 Massachusetts Avenue
7006 Cambridge, MA 02139, USA
7007 Email: raeburn@MIT.EDU
7010 12. Acknowledgements
7014 March 2003 [Page 117]
7020 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
7023 This document is a revision to RFC1510 which was co-authored with
7024 John Kohl. The specification of the Kerberos protocol described in
7025 this document is the result of many years of effort. Over this
7026 period many individuals have contributed to the definition of the
7027 protocol and to the writing of the specification. Unfortunately it is
7028 not possible to list all contributors as authors of this document,
7029 though there are many not listed who are authors in spirit, because
7030 they contributed text for parts of some sections, because they
7031 contributed to the design of parts of the protocol, or because they
7032 contributed significantly to the discussion of the protocol in the
7033 IETF common authentication technology (CAT) and Kerberos working
7036 Among those contributing to the development and specification of
7037 Kerberos were Jeffrey Altman, John Brezak, Marc Colan, Johan
7038 Danielsson, Don Davis, Doug Engert, Dan Geer, Paul Hill, John Kohl,
7039 Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John Linn,
7040 Ari Medvinsky, Sasha Medvinsky, Steve Miller, Jon Rochlis, Jerome
7041 Saltzer, Jeffrey Schiller, Jennifer Steiner, Ralph Swick, Mike Swift,
7042 Jonathan Trostle, Theodore Ts'o, Brian Tung, Jacques Vidrine, Assar
7043 Westerlund, and Nicolas Williams. Many other members of MIT Project
7044 Athena, the MIT networking group, and the Kerberos and CAT working
7045 groups of the IETF contributed but are not listed.
7050 RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg-
7054 RFC-Editor: To be replaced by RFC number for draft-raeburn0krb-
7058 Don Davis, Daniel Geer, and Theodore Ts'0, "Kerberos With Clocks
7059 Adrift: History, Protocols, and Implementation", USENIX Computing
7060 Systems 9:1 (Januart 1996).
7063 Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key
7064 Distribution Protocols," Communications of the ACM, Vol. 24(8),
7065 pp. 533-536 (August 1981).
7068 7-bit Coded Character Set
7074 March 2003 [Page 118]
7080 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
7083 Character Code Structure and Extension Techniques
7086 8-bit Coded Character Set Structure and Rules
7090 John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
7091 Evolution of the Kerberos Authentication System". In Distributed
7092 Open Systems, pages 78-94. IEEE Computer Society Press, 1994.
7095 S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer,
7096 Section E.2.1: Kerberos Authentication and Authorization System,
7097 M.I.T. Project Athena, Cambridge, Massachusetts (December 21,
7101 B. Clifford Neuman, "Proxy-Based Authorization and Accounting for
7102 Distributed Systems," in Proceedings of the 13th International
7103 Conference on Distributed Computing Systems, Pittsburgh, PA (May,
7107 Roger M. Needham and Michael D. Schroeder, "Using Encryption for
7108 Authentication in Large Networks of Computers," Communications of
7109 the ACM, Vol. 21(12), pp. 993-999 (December, 1978).
7112 B. Clifford Neuman and Theodore Y. Ts'o, "An Authentication
7113 Service for Computer Networks," IEEE Communications Magazine, Vol.
7114 32(9), pp. 33-38 (September 1994).
7117 J. Pato, Using Pre-Authentication to Avoid Password Guessing
7118 Attacks, Open Software Foundation DCE Request for Comments 26
7122 P.V. Mockapetris, RFC1035: "Domain Names - Implementations and
7123 Specification," November 1, 1987, Obsoletes - RFC973, RFC882,
7124 RFC883. Updated by RFC1101, RFC1183, RFC1348, RFCRFC1876, RFC1982,
7125 RFC1995, RFC1996, RFC2065, RFC2136, RFC2137, RFC2181, RFC2308,
7126 RFC2535, RFC2845, and RFC3425. Status: Standard.
7129 J. Kohl and B. C. Neuman, RFC1510: "The Kerberos Network
7130 Authentication Service (v5)," September 1993, Status: Proposed
7134 March 2003 [Page 119]
7140 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
7146 S. Bradner, RFC2026: "The Internet Standard Process - Revision
7147 3," October 1996, Obsoletes - RFC 1602, Status: Best Current
7151 A. Gulbrandsen and P. Vixie, RFC2052: "A DNS RR for Specifying the
7152 Location of Services (DNS SRV)," October 1996, Obseleted by
7153 RFC2782, Status: Experimental
7156 M. Wahl, S. Killie, and T. Howes, RFC2253: "Lightweight Directory
7157 Access Protocol (v3): UTF-8 String Representation or Distinguished
7158 Names," December 1997, Obsoletes - RFC1779, Updated by RFC3377,
7159 Status: Proposed Standard.
7162 D. Levi, P. Meyer, and B. Stewart, RFC2273: "SNMPv3 Applications,"
7163 January 1998, Obsoletes - RFC2263, Obsoleted by RFC2573, Status:
7167 R. Hinden, S. Deering, RFC2373: "IP Version 6 Addressing
7168 Architecture," July 1998, Status: Proposed Standard.
7171 J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Kerberos: An
7172 Authentication Service for Open Network Systems," pp. 191-202 in
7173 Usenix Conference Proceedings, Dallas, Texas (February, 1988).
7176 Abstract Syntax Notation One (ASN.1): Specification of Basic
7177 Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC
7178 International Standard 8824-1:1998.
7181 ASN.1 encoding rules: Specification of Basic Encoding Rules (BER),
7182 Canonical Encoding Rules (CER) and Distinguished Encoding Rules
7183 (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International
7184 Standard 8825-1:1998.
7189 iso(1) identified-organization(3) dod(6) internet(1)
7190 security(5) kerberosV5(2) modules(4) krb5spec2(2)
7194 March 2003 [Page 120]
7200 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
7203 } DEFINITIONS EXPLICIT TAGS ::= BEGIN
7205 -- OID arc for KerberosV5
7207 -- This OID may be used to identify Kerberos protocol messages
7208 -- encapsulated in other protocols.
7210 -- This OID also designates the OID arc for KerberosV5-related OIDs.
7212 -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its OID.
7213 id-krb5 OBJECT IDENTIFIER ::= {
7214 iso(1) identified-organization(3) dod(6) internet(1)
7215 security(5) kerberosV5(2)
7218 Int32 ::= INTEGER (-2147483648..2147483647)
7219 -- signed values representable in 32 bits
7221 UInt32 ::= INTEGER (0..4294967295)
7222 -- unsigned 32 bit values
7224 Microseconds ::= INTEGER (0..999999)
7227 KerberosString ::= GeneralString (IA5String)
7229 Realm ::= KerberosString
7231 PrincipalName ::= SEQUENCE {
7232 name-type [0] Int32,
7233 name-string [1] SEQUENCE OF KerberosString
7236 KerberosTime ::= GeneralizedTime -- with no fractional seconds
7238 HostAddress ::= SEQUENCE {
7239 addr-type [0] Int32,
7240 address [1] OCTET STRING
7243 -- NOTE: HostAddresses is always used as an OPTIONAL field and
7244 -- should not be empty.
7245 HostAddresses -- NOTE: subtly different from rfc1510,
7246 -- but has a value mapping and encodes the same
7247 ::= SEQUENCE OF HostAddress
7249 -- NOTE: AuthorizationData is always used as an OPTIONAL field and
7250 -- should not be empty.
7254 March 2003 [Page 121]
7260 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
7263 AuthorizationData ::= SEQUENCE OF SEQUENCE {
7265 ad-data [1] OCTET STRING
7268 PA-DATA ::= SEQUENCE {
7269 -- NOTE: first tag is [1], not [0]
7270 padata-type [1] Int32,
7271 padata-value [2] OCTET STRING -- might be encoded AP-REQ
7274 KerberosFlags ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits
7275 -- shall be sent, but no fewer than 32
7277 EncryptedData ::= SEQUENCE {
7278 etype [0] Int32 -- EncryptionType --,
7279 kvno [1] UInt32 OPTIONAL,
7280 cipher [2] OCTET STRING -- ciphertext
7283 EncryptionKey ::= SEQUENCE {
7284 keytype [0] Int32 -- actually encryption type --,
7285 keyvalue [1] OCTET STRING
7288 Checksum ::= SEQUENCE {
7289 cksumtype [0] Int32,
7290 checksum [1] OCTET STRING
7293 Ticket ::= [APPLICATION 1] SEQUENCE {
7294 tkt-vno [0] INTEGER (5),
7296 sname [2] PrincipalName,
7297 enc-part [3] EncryptedData -- EncTicketPart
7300 -- Encrypted part of ticket
7301 EncTicketPart ::= [APPLICATION 3] SEQUENCE {
7302 flags [0] TicketFlags,
7303 key [1] EncryptionKey,
7305 cname [3] PrincipalName,
7306 transited [4] TransitedEncoding,
7307 authtime [5] KerberosTime,
7308 starttime [6] KerberosTime OPTIONAL,
7309 endtime [7] KerberosTime,
7310 renew-till [8] KerberosTime OPTIONAL,
7314 March 2003 [Page 122]
7320 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
7323 caddr [9] HostAddresses OPTIONAL,
7324 authorization-data [10] AuthorizationData OPTIONAL
7327 -- encoded Transited field
7328 TransitedEncoding ::= SEQUENCE {
7329 tr-type [0] Int32 -- must be registered --,
7330 contents [1] OCTET STRING
7333 TicketFlags ::= KerberosFlags
7346 -- the following are new since 1510
7347 -- transited-policy-checked(12),
7348 -- ok-as-delegate(13)
7350 AS-REQ ::= [APPLICATION 10] KDC-REQ
7352 TGS-REQ ::= [APPLICATION 12] KDC-REQ
7354 KDC-REQ ::= SEQUENCE {
7355 -- NOTE: first tag is [1], not [0]
7356 pvno [1] INTEGER (5) ,
7357 msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --),
7358 padata [3] SEQUENCE OF PA-DATA OPTIONAL
7359 -- NOTE: not empty --,
7360 req-body [4] KDC-REQ-BODY
7363 KDC-REQ-BODY ::= SEQUENCE {
7364 kdc-options [0] KDCOptions,
7365 cname [1] PrincipalName OPTIONAL
7366 -- Used only in AS-REQ --,
7369 -- Also client's in AS-REQ --,
7370 sname [3] PrincipalName OPTIONAL,
7374 March 2003 [Page 123]
7380 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
7383 from [4] KerberosTime OPTIONAL,
7384 till [5] KerberosTime,
7385 rtime [6] KerberosTime OPTIONAL,
7387 etype [8] SEQUENCE OF Int32 -- EncryptionType
7388 -- in preference order --,
7389 addresses [9] HostAddresses OPTIONAL,
7390 enc-authorization-data [10] EncryptedData -- AuthorizationData --,
7391 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
7395 KDCOptions ::= KerberosFlags
7401 -- allow-postdate(5),
7407 -- opt-hardware-auth(11),
7410 -- 15 is reserved for canonicalize
7412 -- 26 was unused in 1510
7413 -- disable-transited-check(26),
7415 -- renewable-ok(27),
7416 -- enc-tkt-in-skey(28),
7420 AS-REP ::= [APPLICATION 11] KDC-REP
7422 TGS-REP ::= [APPLICATION 13] KDC-REP
7424 KDC-REP ::= SEQUENCE {
7425 pvno [0] INTEGER (5),
7426 msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --),
7427 padata [2] SEQUENCE OF PA-DATA OPTIONAL
7428 -- NOTE: not empty --,
7430 cname [4] PrincipalName,
7434 March 2003 [Page 124]
7440 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
7444 enc-part [6] EncryptedData
7445 -- EncASRepPart or EncTGSRepPart,
7449 EncASRepPart ::= [APPLICATION 25] EncKDCRepPart
7451 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart
7453 EncKDCRepPart ::= SEQUENCE {
7454 key [0] EncryptionKey,
7455 last-req [1] LastReq,
7457 key-expiration [3] KerberosTime OPTIONAL,
7458 flags [4] TicketFlags,
7459 authtime [5] KerberosTime,
7460 starttime [6] KerberosTime OPTIONAL,
7461 endtime [7] KerberosTime,
7462 renew-till [8] KerberosTime OPTIONAL,
7464 sname [10] PrincipalName,
7465 caddr [11] HostAddresses OPTIONAL
7468 LastReq ::= SEQUENCE OF SEQUENCE {
7470 lr-value [1] KerberosTime
7473 AP-REQ ::= [APPLICATION 14] SEQUENCE {
7474 pvno [0] INTEGER (5),
7475 msg-type [1] INTEGER (14),
7476 ap-options [2] APOptions,
7478 authenticator [4] EncryptedData -- Authenticator
7481 APOptions ::= KerberosFlags
7483 -- use-session-key(1),
7484 -- mutual-required(2)
7486 -- Unencrypted authenticator
7487 Authenticator ::= [APPLICATION 2] SEQUENCE {
7488 authenticator-vno [0] INTEGER (5),
7490 cname [2] PrincipalName,
7494 March 2003 [Page 125]
7500 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
7503 cksum [3] Checksum OPTIONAL,
7504 cusec [4] Microseconds,
7505 ctime [5] KerberosTime,
7506 subkey [6] EncryptionKey OPTIONAL,
7507 seq-number [7] UInt32 OPTIONAL,
7508 authorization-data [8] AuthorizationData OPTIONAL
7511 AP-REP ::= [APPLICATION 15] SEQUENCE {
7512 pvno [0] INTEGER (5),
7513 msg-type [1] INTEGER (15),
7514 enc-part [2] EncryptedData -- EncAPRepPart
7517 EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
7518 ctime [0] KerberosTime,
7519 cusec [1] Microseconds,
7520 subkey [2] EncryptionKey OPTIONAL,
7521 seq-number [3] UInt32 OPTIONAL
7524 KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
7525 pvno [0] INTEGER (5),
7526 msg-type [1] INTEGER (20),
7527 safe-body [2] KRB-SAFE-BODY,
7531 KRB-SAFE-BODY ::= SEQUENCE {
7532 user-data [0] OCTET STRING,
7533 timestamp [1] KerberosTime OPTIONAL,
7534 usec [2] Microseconds OPTIONAL,
7535 seq-number [3] UInt32 OPTIONAL,
7536 s-address [4] HostAddress,
7537 r-address [5] HostAddress OPTIONAL
7540 KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
7541 pvno [0] INTEGER (5),
7542 msg-type [1] INTEGER (21),
7543 -- NOTE: there is no [2] tag
7544 enc-part [3] EncryptedData -- EncKrbPrivPart
7547 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
7548 user-data [0] OCTET STRING,
7549 timestamp [1] KerberosTime OPTIONAL,
7550 usec [2] Microseconds OPTIONAL,
7554 March 2003 [Page 126]
7560 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
7563 seq-number [3] UInt32 OPTIONAL,
7564 s-address [4] HostAddress -- sender's addr --,
7565 r-address [5] HostAddress OPTIONAL -- recip's addr
7568 KRB-CRED ::= [APPLICATION 22] SEQUENCE {
7569 pvno [0] INTEGER (5),
7570 msg-type [1] INTEGER (22),
7571 tickets [2] SEQUENCE OF Ticket,
7572 enc-part [3] EncryptedData -- EncKrbCredPart
7575 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
7576 ticket-info [0] SEQUENCE OF KrbCredInfo,
7577 nonce [1] UInt32 OPTIONAL,
7578 timestamp [2] KerberosTime OPTIONAL,
7579 usec [3] Microseconds OPTIONAL,
7580 s-address [4] HostAddress OPTIONAL,
7581 r-address [5] HostAddress OPTIONAL
7584 KrbCredInfo ::= SEQUENCE {
7585 key [0] EncryptionKey,
7586 prealm [1] Realm OPTIONAL,
7587 pname [2] PrincipalName OPTIONAL,
7588 flags [3] TicketFlags OPTIONAL,
7589 authtime [4] KerberosTime OPTIONAL,
7590 starttime [5] KerberosTime OPTIONAL,
7591 endtime [6] KerberosTime OPTIONAL,
7592 renew-till [7] KerberosTime OPTIONAL,
7593 srealm [8] Realm OPTIONAL,
7594 sname [9] PrincipalName OPTIONAL,
7595 caddr [10] HostAddresses OPTIONAL
7598 KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
7599 pvno [0] INTEGER (5),
7600 msg-type [1] INTEGER (30),
7601 ctime [2] KerberosTime OPTIONAL,
7602 cusec [3] Microseconds OPTIONAL,
7603 stime [4] KerberosTime,
7604 susec [5] Microseconds,
7605 error-code [6] Int32,
7606 crealm [7] Realm OPTIONAL,
7607 cname [8] PrincipalName OPTIONAL,
7608 realm [9] Realm -- service realm --,
7609 sname [10] PrincipalName -- service name --,
7610 e-text [11] KerberosString OPTIONAL,
7614 March 2003 [Page 127]
7620 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
7623 e-data [12] OCTET STRING OPTIONAL
7626 METHOD-DATA ::= SEQUENCE OF PA-DATA
7628 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
7629 data-type [0] INTEGER,
7630 data-value [1] OCTET STRING OPTIONAL
7633 -- preauth stuff follows
7635 PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC
7637 PA-ENC-TS-ENC ::= SEQUENCE {
7638 patimestamp [0] KerberosTime -- client's time --,
7639 pausec [1] Microseconds OPTIONAL
7642 ETYPE-INFO-ENTRY ::= SEQUENCE {
7644 salt [1] OCTET STRING OPTIONAL
7647 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY
7649 ETYPE-INFO2-ENTRY ::= SEQUENCE {
7651 salt [1] KerberosString OPTIONAL,
7652 s2kparams [2] OCTET STRING OPTIONAL
7655 ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO-ENTRY
7657 AD-IF-RELEVANT ::= AuthorizationData
7659 AD-KDCIssued ::= SEQUENCE {
7660 ad-checksum [0] Checksum,
7661 i-realm [1] Realm OPTIONAL,
7662 i-sname [2] PrincipalName OPTIONAL,
7663 elements [3] AuthorizationData
7666 AD-AND-OR ::= SEQUENCE {
7667 condition-count [0] INTEGER,
7668 elements [1] AuthorizationData
7674 March 2003 [Page 128]
7680 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
7683 AD-MANDATORY-FOR-KDC ::= AuthorizationData
7687 B. Changes since RFC-1510
7689 This document replaces RFC-1510 and clarifies specification of items
7690 that were not completely specified. Where changes to recommended
7691 implementation choices were made, or where new options were added,
7692 those changes are described within the document and listed in this
7693 section. More significantly, "Specification 2" in section 8 changes
7694 the required encryption and checksum methods to bring them in line
7695 with the best current practices and to deprecate methods that are no
7696 longer considered sufficiently strong.
7698 Discussion was added to section 1 regarding the ability to rely on
7699 the KDC to check the transited field, and on the inclusion of a flag
7700 in a ticket indicating that this check has occurred. This is a new
7701 capability not present in RFC1510. Pre-existing implementations may
7702 ignore or not set this flag without negative security implications.
7704 The definition of the secret key says that in the case of a user the
7705 key may be derived from a password. In 1510, it said that the key was
7706 derived from the password. This change was made to accommodate
7707 situations where the user key might be stored on a smart-card, or
7708 otherwise obtained independent of a password.
7710 The introduction mentions the use of public key cryptography for
7711 initial authentication in Kerberos by reference. RFC1510 did not
7712 include such a reference.
7714 Section 1.2 was added to explain that while Kerberos provides
7715 authentication of a named principal, it is still the responsibility
7716 of the application to ensure that the authenticated name is the
7717 entity with which the application wishes to communicate.
7719 Discussion of extensibility has been added to the introduction.
7721 Discussion of how extensibility affects ticket flags and KDC options
7722 was added to the introduction of section 2. No changes were made to
7723 existing options and flags specified in RFC1510, though some of the
7724 sections in the specification were renumbered, and text was revised
7725 to make the description and intent of existing options clearer,
7726 especially with respect to the ENC-TKT-IN-SKEY option (now section
7727 2.9.2) which is used for user-to-user authentication. The new option
7728 and ticket flag transited policy checking (section 2.7) was added.
7730 A warning regarding generation of session keys for application use
7734 March 2003 [Page 129]
7740 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
7743 was added to section 3, urging the inclusion of key entropy from the
7744 KDC generated session key in the ticket. An example regarding use of
7745 the sub-session key was added to section 3.2.6. Descriptions of the
7746 pa-etype-info, pa-etype-info2, and pa-pw-salt pre-authentication data
7747 items were added. The recommendation for use of pre-authentication
7748 was changed from "may" to "should" and a note was added regarding
7749 known plaintext attacks.
7751 In RFC 1510, section 4 described the database in the KDC. This
7752 discussion was not necessary for interoperability and unnecessarily
7753 constrained implementation. The old section 4 was removed.
7755 The current section 4 was formerly section 6 on encryption and
7756 checksum specifications. The major part of this section was brought
7757 up to date to support new encryption methods, and move to a separate
7758 document. Those few remaining aspects of the encryption and checksum
7759 specification specific to Kerberos are now specified in section 4.
7761 Significant changes were made to the layout of section 5 to clarify
7762 the correct behavior for optional fields. Many of these changes were
7763 made necessary because of improper ASN.1 description in the original
7764 Kerberos specification which left the correct behavior
7765 underspecified. Additionally, the wording in this section was
7766 tightened wherever possible to ensure that implementations conforming
7767 to this specification will be extensible with the addition of new
7768 fields in future specifications.
7770 Text was added describing time_t=0 issues in the ASN.1. Text was also
7771 added, clarifying issues with implementations treating omitted
7772 optional integers as zero. Text was added clarifying behavior for
7773 optional SEQUENCE or SEQUENCE OF that may be empty. Discussion was
7774 added regarding sequence numbers and behavior of some
7775 implementations, including "zero" behavior and negative numbers. A
7776 compatibility note was added regarding the unconditional sending of
7777 EncTGSRepPart regardless of the enclosing reply type. Minor changes
7778 were made to the description of the HostAddresses type. Integer types
7779 were constrained. KerberosString was defined as a (significantly)
7780 constrained GeneralString. KerberosFlags was defined to reflect
7781 existing implementation behavior that departs from the definition in
7782 RFC 1510. The transited-policy-checked(12) and the ok-as-delegate(13)
7783 ticket flags were added. The disable-transited-check(26) KDC option
7786 Descriptions of commonly implemented PA-DATA were added to section 5.
7787 The description of KRB-SAFE has been updated to note the existing
7788 implementation behavior of double-encoding.
7790 There were two definitions of METHOD-DATA in RFC 1510. The second
7794 March 2003 [Page 130]
7800 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
7803 one, intended for use with KRB_AP_ERR_METHOD was removed leaving the
7804 SEQUENCE OF PA-DATA definition.
7806 Section 7, naming constraints, from RFC1510 was moved to section 6.
7808 Words were added describing the convention that domain based realm
7809 names for newly created realms should be specified as upper case.
7810 This recommendation does not make lower case realm names illegal.
7811 Words were added highlighting that the slash separated components in
7812 the X500 style of realm names is consistent with existing RFC1510
7813 based implementations, but that it conflicts with the general
7814 recommendation of X.500 name representation specified in RFC2253.
7816 Section 8, network transport, constants and defined values, from
7817 RFC1510 was moved to section 7. Since RFC1510, the definition of the
7818 TCP transport for Kerberos messages was added, and the encryption and
7819 checksum number assignments have been moved into a separate document.
7821 "Specification 2" in section 8 of the current document changes the
7822 required encryption and checksum methods to bring them in line with
7823 the best current practices and to deprecate methods that are no
7824 longer considered sufficiently strong.
7826 Two new sections, on IANA considerations and security considerations
7829 The pseudo-code has been removed from the appendix. The pseudo-code
7830 was sometimes misinterpreted to limit implementation choices and in
7831 RFC 1510, it was not always consistent with the words in the
7832 specification. Effort was made to clear up any ambiguities in the
7833 specification, rather than to rely on the pseudo-code.
7835 An appendix was added containing the complete ASN.1 module drawn from
7836 the discussion in section 5 of the current document.
7838 An appendix was added defining those authorization data elements that
7839 must be understood by all Kerberos implementations.
7843 [TM] Project Athena, Athena, and Kerberos are trademarks of the
7844 Massachusetts Institute of Technology (MIT). No commercial use of
7845 these trademarks may be made without prior written permission of MIT.
7847 [1] Note, however, that many applications use Kerberos' functions
7848 only upon the initiation of a stream-based network connection. Unless
7849 an application subsequently provides integrity protection for the
7850 data stream, the identity verification applies only to the initiation
7854 March 2003 [Page 131]
7860 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
7863 of the connection, and does not guarantee that subsequent messages on
7864 the connection originate from the same principal.
7866 [2] Secret and private are often used interchangeably in the
7867 literature. In our usage, it takes two (or more) to share a secret,
7868 thus a shared DES key is a secret key. Something is only private when
7869 no one but its owner knows it. Thus, in public key cryptosystems, one
7870 has a public and a private key.
7872 [3] Of course, with appropriate permission the client could arrange
7873 registration of a separately-named principal in a remote realm, and
7874 engage in normal exchanges with that realm's services. However, for
7875 even small numbers of clients this becomes cumbersome, and more
7876 automatic methods as described here are necessary.
7878 [4] Though it is permissible to request or issue tickets with no
7879 network addresses specified.
7881 [5] The password-changing request must not be honored unless the
7882 requester can provide the old password (the user's current secret
7883 key). Otherwise, it would be possible for someone to walk up to an
7884 unattended session and change another user's password.
7886 [6] To authenticate a user logging on to a local system, the
7887 credentials obtained in the AS exchange may first be used in a TGS
7888 exchange to obtain credentials for a local server. Those credentials
7889 must then be verified by a local server through successful completion
7890 of the Client/Server exchange.
7892 [7] "Random" means that, among other things, it should be impossible
7893 to guess the next session key based on knowledge of past session
7894 keys. This can only be achieved in a pseudo-random number generator
7895 if it is based on cryptographic principles. It is more desirable to
7896 use a truly random number generator, such as one based on
7897 measurements of random physical phenomena.
7899 [8] Tickets contain both an encrypted and unencrypted portion, so
7900 cleartext here refers to the entire unit, which can be copied from
7901 one message and replayed in another without any cryptographic skill.
7903 [9] Note that this can make applications based on unreliable
7904 transports difficult to code correctly. If the transport might
7905 deliver duplicated messages, either a new authenticator must be
7906 generated for each retry, or the application server must match
7907 requests and replies and replay the first reply in response to a
7910 [10] Note also that the rejection here is restricted to
7914 March 2003 [Page 132]
7920 Neuman, et al. draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
7923 authenticators from the same principal to the same server. Other
7924 client principals communicating with the same server principal should
7925 not be have their authenticators rejected if the time and microsecond
7926 fields happen to match some other client's authenticator.
7928 [11] If this is not done, an attacker could subvert the
7929 authentication by recording the ticket and authenticator sent over
7930 the network to a server and replaying them following an event that
7931 caused the server to lose track of recently seen authenticators.
7933 [12] In the Kerberos version 4 protocol, the timestamp in the reply
7934 was the client's timestamp plus one. This is not necessary in version
7935 5 because version 5 messages are formatted in such a way that it is
7936 not possible to create the reply by judicious message surgery (even
7937 in encrypted form) without knowledge of the appropriate encryption
7940 [13] Note that for encrypting the KRB_AP_REP message, the sub-session
7941 key is not used, even if present in the Authenticator.
7943 [14] Implementations of the protocol may provide routines to choose
7944 subkeys based on session keys and random numbers and to generate a
7945 negotiated key to be returned in the KRB_AP_REP message.
7947 [15]This can be accomplished in several ways. It might be known
7948 beforehand (since the realm is part of the principal identifier), it
7949 might be stored in a nameserver, or it might be obtained from a
7950 configuration file. If the realm to be used is obtained from a
7951 nameserver, there is a danger of being spoofed if the nameservice
7952 providing the realm name is not authenticated. This might result in
7953 the use of a realm which has been compromised, and would result in an
7954 attacker's ability to compromise the authentication of the
7955 application server to the client.
7957 [16] If the client selects a sub-session key, care must be taken to
7958 ensure the randomness of the selected sub-session key. One approach
7959 would be to generate a random number and XOR it with the session key
7960 from the ticket-granting ticket.
7974 March 2003 [Page 133]