7 Network Working Group J. Kohl
8 Request for Comments: 1510 Digital Equipment Corporation
14 The Kerberos Network Authentication Service (V5)
18 This RFC specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" for the standardization state and status
22 of this protocol. Distribution of this memo is unlimited.
26 This document gives an overview and specification of Version 5 of the
27 protocol for the Kerberos network authentication system. Version 4,
28 described elsewhere [1,2], is presently in production use at MIT's
29 Project Athena, and at other Internet sites.
33 Project Athena, Athena, Athena MUSE, Discuss, Hesiod, Kerberos,
34 Moira, and Zephyr are trademarks of the Massachusetts Institute of
35 Technology (MIT). No commercial use of these trademarks may be made
36 without prior written permission of MIT.
38 This RFC describes the concepts and model upon which the Kerberos
39 network authentication system is based. It also specifies Version 5
40 of the Kerberos protocol.
42 The motivations, goals, assumptions, and rationale behind most design
43 decisions are treated cursorily; for Version 4 they are fully
44 described in the Kerberos portion of the Athena Technical Plan [1].
45 The protocols are under review, and are not being submitted for
46 consideration as an Internet standard at this time. Comments are
47 encouraged. Requests for addition to an electronic mailing list for
48 discussion of Kerberos, kerberos@MIT.EDU, may be addressed to
49 kerberos-request@MIT.EDU. This mailing list is gatewayed onto the
50 Usenet as the group comp.protocols.kerberos. Requests for further
51 information, including documents and code availability, may be sent
52 to info-kerberos@MIT.EDU.
58 Kohl & Neuman [Page 1]
60 RFC 1510 Kerberos September 1993
65 The Kerberos model is based in part on Needham and Schroeder's
66 trusted third-party authentication protocol [3] and on modifications
67 suggested by Denning and Sacco [4]. The original design and
68 implementation of Kerberos Versions 1 through 4 was the work of two
69 former Project Athena staff members, Steve Miller of Digital
70 Equipment Corporation and Clifford Neuman (now at the Information
71 Sciences Institute of the University of Southern California), along
72 with Jerome Saltzer, Technical Director of Project Athena, and
73 Jeffrey Schiller, MIT Campus Network Manager. Many other members of
74 Project Athena have also contributed to the work on Kerberos.
75 Version 4 is publicly available, and has seen wide use across the
78 Version 5 (described in this document) has evolved from Version 4
79 based on new requirements and desires for features not available in
80 Version 4. Details on the differences between Kerberos Versions 4
81 and 5 can be found in [5].
85 1. Introduction ....................................... 5
86 1.1. Cross-Realm Operation ............................ 7
87 1.2. Environmental assumptions ........................ 8
88 1.3. Glossary of terms ................................ 9
89 2. Ticket flag uses and requests ...................... 12
90 2.1. Initial and pre-authenticated tickets ............ 12
91 2.2. Invalid tickets .................................. 12
92 2.3. Renewable tickets ................................ 12
93 2.4. Postdated tickets ................................ 13
94 2.5. Proxiable and proxy tickets ...................... 14
95 2.6. Forwardable tickets .............................. 15
96 2.7. Other KDC options ................................ 15
97 3. Message Exchanges .................................. 16
98 3.1. The Authentication Service Exchange .............. 16
99 3.1.1. Generation of KRB_AS_REQ message ............... 17
100 3.1.2. Receipt of KRB_AS_REQ message .................. 17
101 3.1.3. Generation of KRB_AS_REP message ............... 17
102 3.1.4. Generation of KRB_ERROR message ................ 19
103 3.1.5. Receipt of KRB_AS_REP message .................. 19
104 3.1.6. Receipt of KRB_ERROR message ................... 20
105 3.2. The Client/Server Authentication Exchange ........ 20
106 3.2.1. The KRB_AP_REQ message ......................... 20
107 3.2.2. Generation of a KRB_AP_REQ message ............. 20
108 3.2.3. Receipt of KRB_AP_REQ message .................. 21
109 3.2.4. Generation of a KRB_AP_REP message ............. 23
110 3.2.5. Receipt of KRB_AP_REP message .................. 23
114 Kohl & Neuman [Page 2]
116 RFC 1510 Kerberos September 1993
119 3.2.6. Using the encryption key ....................... 24
120 3.3. The Ticket-Granting Service (TGS) Exchange ....... 24
121 3.3.1. Generation of KRB_TGS_REQ message .............. 25
122 3.3.2. Receipt of KRB_TGS_REQ message ................. 26
123 3.3.3. Generation of KRB_TGS_REP message .............. 27
124 3.3.3.1. Encoding the transited field ................. 29
125 3.3.4. Receipt of KRB_TGS_REP message ................. 31
126 3.4. The KRB_SAFE Exchange ............................ 31
127 3.4.1. Generation of a KRB_SAFE message ............... 31
128 3.4.2. Receipt of KRB_SAFE message .................... 32
129 3.5. The KRB_PRIV Exchange ............................ 33
130 3.5.1. Generation of a KRB_PRIV message ............... 33
131 3.5.2. Receipt of KRB_PRIV message .................... 33
132 3.6. The KRB_CRED Exchange ............................ 34
133 3.6.1. Generation of a KRB_CRED message ............... 34
134 3.6.2. Receipt of KRB_CRED message .................... 34
135 4. The Kerberos Database .............................. 35
136 4.1. Database contents ................................ 35
137 4.2. Additional fields ................................ 36
138 4.3. Frequently Changing Fields ....................... 37
139 4.4. Site Constants ................................... 37
140 5. Message Specifications ............................. 38
141 5.1. ASN.1 Distinguished Encoding Representation ...... 38
142 5.2. ASN.1 Base Definitions ........................... 38
143 5.3. Tickets and Authenticators ....................... 42
144 5.3.1. Tickets ........................................ 42
145 5.3.2. Authenticators ................................. 47
146 5.4. Specifications for the AS and TGS exchanges ...... 49
147 5.4.1. KRB_KDC_REQ definition ......................... 49
148 5.4.2. KRB_KDC_REP definition ......................... 56
149 5.5. Client/Server (CS) message specifications ........ 58
150 5.5.1. KRB_AP_REQ definition .......................... 58
151 5.5.2. KRB_AP_REP definition .......................... 60
152 5.5.3. Error message reply ............................ 61
153 5.6. KRB_SAFE message specification ................... 61
154 5.6.1. KRB_SAFE definition ............................ 61
155 5.7. KRB_PRIV message specification ................... 62
156 5.7.1. KRB_PRIV definition ............................ 62
157 5.8. KRB_CRED message specification ................... 63
158 5.8.1. KRB_CRED definition ............................ 63
159 5.9. Error message specification ...................... 65
160 5.9.1. KRB_ERROR definition ........................... 66
161 6. Encryption and Checksum Specifications ............. 67
162 6.1. Encryption Specifications ........................ 68
163 6.2. Encryption Keys .................................. 71
164 6.3. Encryption Systems ............................... 71
165 6.3.1. The NULL Encryption System (null) .............. 71
166 6.3.2. DES in CBC mode with a CRC-32 checksum (descbc-crc)71
170 Kohl & Neuman [Page 3]
172 RFC 1510 Kerberos September 1993
175 6.3.3. DES in CBC mode with an MD4 checksum (descbc-md4) 72
176 6.3.4. DES in CBC mode with an MD5 checksum (descbc-md5) 72
177 6.4. Checksums ........................................ 74
178 6.4.1. The CRC-32 Checksum (crc32) .................... 74
179 6.4.2. The RSA MD4 Checksum (rsa-md4) ................. 75
180 6.4.3. RSA MD4 Cryptographic Checksum Using DES
181 (rsa-md4-des) ......................................... 75
182 6.4.4. The RSA MD5 Checksum (rsa-md5) ................. 76
183 6.4.5. RSA MD5 Cryptographic Checksum Using DES
184 (rsa-md5-des) ......................................... 76
185 6.4.6. DES cipher-block chained checksum (des-mac)
186 6.4.7. RSA MD4 Cryptographic Checksum Using DES
187 alternative (rsa-md4-des-k) ........................... 77
188 6.4.8. DES cipher-block chained checksum alternative
189 (des-mac-k) ........................................... 77
190 7. Naming Constraints ................................. 78
191 7.1. Realm Names ...................................... 77
192 7.2. Principal Names .................................. 79
193 7.2.1. Name of server principals ...................... 80
194 8. Constants and other defined values ................. 80
195 8.1. Host address types ............................... 80
196 8.2. KDC messages ..................................... 81
197 8.2.1. IP transport ................................... 81
198 8.2.2. OSI transport .................................. 82
199 8.2.3. Name of the TGS ................................ 82
200 8.3. Protocol constants and associated values ......... 82
201 9. Interoperability requirements ...................... 86
202 9.1. Specification 1 .................................. 86
203 9.2. Recommended KDC values ........................... 88
204 10. Acknowledgments ................................... 88
205 11. References ........................................ 89
206 12. Security Considerations ........................... 90
207 13. Authors' Addresses ................................ 90
208 A. Pseudo-code for protocol processing ................ 91
209 A.1. KRB_AS_REQ generation ............................ 91
210 A.2. KRB_AS_REQ verification and KRB_AS_REP generation 92
211 A.3. KRB_AS_REP verification .......................... 95
212 A.4. KRB_AS_REP and KRB_TGS_REP common checks ......... 96
213 A.5. KRB_TGS_REQ generation ........................... 97
214 A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation 98
215 A.7. KRB_TGS_REP verification ......................... 104
216 A.8. Authenticator generation ......................... 104
217 A.9. KRB_AP_REQ generation ............................ 105
218 A.10. KRB_AP_REQ verification ......................... 105
219 A.11. KRB_AP_REP generation ........................... 106
220 A.12. KRB_AP_REP verification ......................... 107
221 A.13. KRB_SAFE generation ............................. 107
222 A.14. KRB_SAFE verification ........................... 108
226 Kohl & Neuman [Page 4]
228 RFC 1510 Kerberos September 1993
231 A.15. KRB_SAFE and KRB_PRIV common checks ............. 108
232 A.16. KRB_PRIV generation ............................. 109
233 A.17. KRB_PRIV verification ........................... 110
234 A.18. KRB_CRED generation ............................. 110
235 A.19. KRB_CRED verification ........................... 111
236 A.20. KRB_ERROR generation ............................ 112
240 Kerberos provides a means of verifying the identities of principals,
241 (e.g., a workstation user or a network server) on an open
242 (unprotected) network. This is accomplished without relying on
243 authentication by the host operating system, without basing trust on
244 host addresses, without requiring physical security of all the hosts
245 on the network, and under the assumption that packets traveling along
246 the network can be read, modified, and inserted at will. (Note,
247 however, that many applications use Kerberos' functions only upon the
248 initiation of a stream-based network connection, and assume the
249 absence of any "hijackers" who might subvert such a connection. Such
250 use implicitly trusts the host addresses involved.) Kerberos
251 performs authentication under these conditions as a trusted third-
252 party authentication service by using conventional cryptography,
253 i.e., shared secret key. (shared secret key - Secret and private are
254 often used interchangeably in the literature. In our usage, it takes
255 two (or more) to share a secret, thus a shared DES key is a secret
256 key. Something is only private when no one but its owner knows it.
257 Thus, in public key cryptosystems, one has a public and a private
260 The authentication process proceeds as follows: A client sends a
261 request to the authentication server (AS) requesting "credentials"
262 for a given server. The AS responds with these credentials,
263 encrypted in the client's key. The credentials consist of 1) a
264 "ticket" for the server and 2) a temporary encryption key (often
265 called a "session key"). The client transmits the ticket (which
266 contains the client's identity and a copy of the session key, all
267 encrypted in the server's key) to the server. The session key (now
268 shared by the client and server) is used to authenticate the client,
269 and may optionally be used to authenticate the server. It may also
270 be used to encrypt further communication between the two parties or
271 to exchange a separate sub-session key to be used to encrypt further
274 The implementation consists of one or more authentication servers
275 running on physically secure hosts. The authentication servers
276 maintain a database of principals (i.e., users and servers) and their
277 secret keys. Code libraries provide encryption and implement the
278 Kerberos protocol. In order to add authentication to its
282 Kohl & Neuman [Page 5]
284 RFC 1510 Kerberos September 1993
287 transactions, a typical network application adds one or two calls to
288 the Kerberos library, which results in the transmission of the
289 necessary messages to achieve authentication.
291 The Kerberos protocol consists of several sub-protocols (or
292 exchanges). There are two methods by which a client can ask a
293 Kerberos server for credentials. In the first approach, the client
294 sends a cleartext request for a ticket for the desired server to the
295 AS. The reply is sent encrypted in the client's secret key. Usually
296 this request is for a ticket-granting ticket (TGT) which can later be
297 used with the ticket-granting server (TGS). In the second method,
298 the client sends a request to the TGS. The client sends the TGT to
299 the TGS in the same manner as if it were contacting any other
300 application server which requires Kerberos credentials. The reply is
301 encrypted in the session key from the TGT.
303 Once obtained, credentials may be used to verify the identity of the
304 principals in a transaction, to ensure the integrity of messages
305 exchanged between them, or to preserve privacy of the messages. The
306 application is free to choose whatever protection may be necessary.
308 To verify the identities of the principals in a transaction, the
309 client transmits the ticket to the server. Since the ticket is sent
310 "in the clear" (parts of it are encrypted, but this encryption
311 doesn't thwart replay) and might be intercepted and reused by an
312 attacker, additional information is sent to prove that the message
313 was originated by the principal to whom the ticket was issued. This
314 information (called the authenticator) is encrypted in the session
315 key, and includes a timestamp. The timestamp proves that the message
316 was recently generated and is not a replay. Encrypting the
317 authenticator in the session key proves that it was generated by a
318 party possessing the session key. Since no one except the requesting
319 principal and the server know the session key (it is never sent over
320 the network in the clear) this guarantees the identity of the client.
322 The integrity of the messages exchanged between principals can also
323 be guaranteed using the session key (passed in the ticket and
324 contained in the credentials). This approach provides detection of
325 both replay attacks and message stream modification attacks. It is
326 accomplished by generating and transmitting a collision-proof
327 checksum (elsewhere called a hash or digest function) of the client's
328 message, keyed with the session key. Privacy and integrity of the
329 messages exchanged between principals can be secured by encrypting
330 the data to be passed using the session key passed in the ticket, and
331 contained in the credentials.
333 The authentication exchanges mentioned above require read-only access
334 to the Kerberos database. Sometimes, however, the entries in the
338 Kohl & Neuman [Page 6]
340 RFC 1510 Kerberos September 1993
343 database must be modified, such as when adding new principals or
344 changing a principal's key. This is done using a protocol between a
345 client and a third Kerberos server, the Kerberos Administration
346 Server (KADM). The administration protocol is not described in this
347 document. There is also a protocol for maintaining multiple copies of
348 the Kerberos database, but this can be considered an implementation
349 detail and may vary to support different database technologies.
351 1.1. Cross-Realm Operation
353 The Kerberos protocol is designed to operate across organizational
354 boundaries. A client in one organization can be authenticated to a
355 server in another. Each organization wishing to run a Kerberos
356 server establishes its own "realm". The name of the realm in which a
357 client is registered is part of the client's name, and can be used by
358 the end-service to decide whether to honor a request.
360 By establishing "inter-realm" keys, the administrators of two realms
361 can allow a client authenticated in the local realm to use its
362 authentication remotely (Of course, with appropriate permission the
363 client could arrange registration of a separately-named principal in
364 a remote realm, and engage in normal exchanges with that realm's
365 services. However, for even small numbers of clients this becomes
366 cumbersome, and more automatic methods as described here are
367 necessary). The exchange of inter-realm keys (a separate key may be
368 used for each direction) registers the ticket-granting service of
369 each realm as a principal in the other realm. A client is then able
370 to obtain a ticket-granting ticket for the remote realm's ticket-
371 granting service from its local realm. When that ticket-granting
372 ticket is used, the remote ticket-granting service uses the inter-
373 realm key (which usually differs from its own normal TGS key) to
374 decrypt the ticket-granting ticket, and is thus certain that it was
375 issued by the client's own TGS. Tickets issued by the remote ticket-
376 granting service will indicate to the end-service that the client was
377 authenticated from another realm.
379 A realm is said to communicate with another realm if the two realms
380 share an inter-realm key, or if the local realm shares an inter-realm
381 key with an intermediate realm that communicates with the remote
382 realm. An authentication path is the sequence of intermediate realms
383 that are transited in communicating from one realm to another.
385 Realms are typically organized hierarchically. Each realm shares a
386 key with its parent and a different key with each child. If an
387 inter-realm key is not directly shared by two realms, the
388 hierarchical organization allows an authentication path to be easily
389 constructed. If a hierarchical organization is not used, it may be
390 necessary to consult some database in order to construct an
394 Kohl & Neuman [Page 7]
396 RFC 1510 Kerberos September 1993
399 authentication path between realms.
401 Although realms are typically hierarchical, intermediate realms may
402 be bypassed to achieve cross-realm authentication through alternate
403 authentication paths (these might be established to make
404 communication between two realms more efficient). It is important
405 for the end-service to know which realms were transited when deciding
406 how much faith to place in the authentication process. To facilitate
407 this decision, a field in each ticket contains the names of the
408 realms that were involved in authenticating the client.
410 1.2. Environmental assumptions
412 Kerberos imposes a few assumptions on the environment in which it can
415 + "Denial of service" attacks are not solved with Kerberos. There
416 are places in these protocols where an intruder intruder can
417 prevent an application from participating in the proper
418 authentication steps. Detection and solution of such attacks
419 (some of which can appear to be not-uncommon "normal" failure
420 modes for the system) is usually best left to the human
421 administrators and users.
423 + Principals must keep their secret keys secret. If an intruder
424 somehow steals a principal's key, it will be able to masquerade
425 as that principal or impersonate any server to the legitimate
428 + "Password guessing" attacks are not solved by Kerberos. If a
429 user chooses a poor password, it is possible for an attacker to
430 successfully mount an offline dictionary attack by repeatedly
431 attempting to decrypt, with successive entries from a
432 dictionary, messages obtained which are encrypted under a key
433 derived from the user's password.
435 + Each host on the network must have a clock which is "loosely
436 synchronized" to the time of the other hosts; this
437 synchronization is used to reduce the bookkeeping needs of
438 application servers when they do replay detection. The degree
439 of "looseness" can be configured on a per-server basis. If the
440 clocks are synchronized over the network, the clock
441 synchronization protocol must itself be secured from network
444 + Principal identifiers are not recycled on a short-term basis. A
445 typical mode of access control will use access control lists
446 (ACLs) to grant permissions to particular principals. If a
450 Kohl & Neuman [Page 8]
452 RFC 1510 Kerberos September 1993
455 stale ACL entry remains for a deleted principal and the
456 principal identifier is reused, the new principal will inherit
457 rights specified in the stale ACL entry. By not re-using
458 principal identifiers, the danger of inadvertent access is
461 1.3. Glossary of terms
463 Below is a list of terms used throughout this document.
466 Authentication Verifying the claimed identity of a
470 Authentication header A record containing a Ticket and an
471 Authenticator to be presented to a
472 server as part of the authentication
476 Authentication path A sequence of intermediate realms transited
477 in the authentication process when
478 communicating from one realm to another.
480 Authenticator A record containing information that can
481 be shown to have been recently generated
482 using the session key known only by the
486 Authorization The process of determining whether a
487 client may use a service, which objects
488 the client is allowed to access, and the
489 type of access allowed for each.
492 Capability A token that grants the bearer permission
493 to access an object or service. In
494 Kerberos, this might be a ticket whose
495 use is restricted by the contents of the
496 authorization data field, but which
497 lists no network addresses, together
498 with the session key necessary to use
506 Kohl & Neuman [Page 9]
508 RFC 1510 Kerberos September 1993
511 Ciphertext The output of an encryption function.
512 Encryption transforms plaintext into
516 Client A process that makes use of a network
517 service on behalf of a user. Note that
518 in some cases a Server may itself be a
519 client of some other server (e.g., a
520 print server may be a client of a file
524 Credentials A ticket plus the secret session key
525 necessary to successfully use that
526 ticket in an authentication exchange.
529 KDC Key Distribution Center, a network service
530 that supplies tickets and temporary
531 session keys; or an instance of that
532 service or the host on which it runs.
533 The KDC services both initial ticket and
534 ticket-granting ticket requests. The
535 initial ticket portion is sometimes
536 referred to as the Authentication Server
537 (or service). The ticket-granting
538 ticket portion is sometimes referred to
539 as the ticket-granting server (or service).
541 Kerberos Aside from the 3-headed dog guarding
542 Hades, the name given to Project
543 Athena's authentication service, the
544 protocol used by that service, or the
545 code used to implement the authentication
549 Plaintext The input to an encryption function or
550 the output of a decryption function.
551 Decryption transforms ciphertext into
555 Principal A uniquely named client or server
556 instance that participates in a network
562 Kohl & Neuman [Page 10]
564 RFC 1510 Kerberos September 1993
567 Principal identifier The name used to uniquely identify each
571 Seal To encipher a record containing several
572 fields in such a way that the fields
573 cannot be individually replaced without
574 either knowledge of the encryption key
575 or leaving evidence of tampering.
578 Secret key An encryption key shared by a principal
579 and the KDC, distributed outside the
580 bounds of the system, with a long lifetime.
581 In the case of a human user's
582 principal, the secret key is derived
586 Server A particular Principal which provides a
587 resource to network clients.
590 Service A resource provided to network clients;
591 often provided by more than one server
592 (for example, remote file service).
595 Session key A temporary encryption key used between
596 two principals, with a lifetime limited
597 to the duration of a single login "session".
600 Sub-session key A temporary encryption key used between
601 two principals, selected and exchanged
602 by the principals using the session key,
603 and with a lifetime limited to the duration
604 of a single association.
607 Ticket A record that helps a client authenticate
608 itself to a server; it contains the
609 client's identity, a session key, a
610 timestamp, and other information, all
611 sealed using the server's secret key.
612 It only serves to authenticate a client
613 when presented along with a fresh
618 Kohl & Neuman [Page 11]
620 RFC 1510 Kerberos September 1993
623 2. Ticket flag uses and requests
625 Each Kerberos ticket contains a set of flags which are used to
626 indicate various attributes of that ticket. Most flags may be
627 requested by a client when the ticket is obtained; some are
628 automatically turned on and off by a Kerberos server as required.
629 The following sections explain what the various flags mean, and gives
630 examples of reasons to use such a flag.
632 2.1. Initial and pre-authenticated tickets
634 The INITIAL flag indicates that a ticket was issued using the AS
635 protocol and not issued based on a ticket-granting ticket.
636 Application servers that want to require the knowledge of a client's
637 secret key (e.g., a passwordchanging program) can insist that this
638 flag be set in any tickets they accept, and thus be assured that the
639 client's key was recently presented to the application client.
641 The PRE-AUTHENT and HW-AUTHENT flags provide addition information
642 about the initial authentication, regardless of whether the current
643 ticket was issued directly (in which case INITIAL will also be set)
644 or issued on the basis of a ticket-granting ticket (in which case the
645 INITIAL flag is clear, but the PRE-AUTHENT and HW-AUTHENT flags are
646 carried forward from the ticket-granting ticket).
650 The INVALID flag indicates that a ticket is invalid. Application
651 servers must reject tickets which have this flag set. A postdated
652 ticket will usually be issued in this form. Invalid tickets must be
653 validated by the KDC before use, by presenting them to the KDC in a
654 TGS request with the VALIDATE option specified. The KDC will only
655 validate tickets after their starttime has passed. The validation is
656 required so that postdated tickets which have been stolen before
657 their starttime can be rendered permanently invalid (through a hot-
660 2.3. Renewable tickets
662 Applications may desire to hold tickets which can be valid for long
663 periods of time. However, this can expose their credentials to
664 potential theft for equally long periods, and those stolen
665 credentials would be valid until the expiration time of the
666 ticket(s). Simply using shortlived tickets and obtaining new ones
667 periodically would require the client to have long-term access to its
668 secret key, an even greater risk. Renewable tickets can be used to
669 mitigate the consequences of theft. Renewable tickets have two
670 "expiration times": the first is when the current instance of the
674 Kohl & Neuman [Page 12]
676 RFC 1510 Kerberos September 1993
679 ticket expires, and the second is the latest permissible value for an
680 individual expiration time. An application client must periodically
681 (i.e., before it expires) present a renewable ticket to the KDC, with
682 the RENEW option set in the KDC request. The KDC will issue a new
683 ticket with a new session key and a later expiration time. All other
684 fields of the ticket are left unmodified by the renewal process.
685 When the latest permissible expiration time arrives, the ticket
686 expires permanently. At each renewal, the KDC may consult a hot-list
687 to determine if the ticket had been reported stolen since its last
688 renewal; it will refuse to renew such stolen tickets, and thus the
689 usable lifetime of stolen tickets is reduced.
691 The RENEWABLE flag in a ticket is normally only interpreted by the
692 ticket-granting service (discussed below in section 3.3). It can
693 usually be ignored by application servers. However, some
694 particularly careful application servers may wish to disallow
697 If a renewable ticket is not renewed by its expiration time, the KDC
698 will not renew the ticket. The RENEWABLE flag is reset by default,
699 but a client may request it be set by setting the RENEWABLE option
700 in the KRB_AS_REQ message. If it is set, then the renew-till field
701 in the ticket contains the time after which the ticket may not be
704 2.4. Postdated tickets
706 Applications may occasionally need to obtain tickets for use much
707 later, e.g., a batch submission system would need tickets to be valid
708 at the time the batch job is serviced. However, it is dangerous to
709 hold valid tickets in a batch queue, since they will be on-line
710 longer and more prone to theft. Postdated tickets provide a way to
711 obtain these tickets from the KDC at job submission time, but to
712 leave them "dormant" until they are activated and validated by a
713 further request of the KDC. If a ticket theft were reported in the
714 interim, the KDC would refuse to validate the ticket, and the thief
717 The MAY-POSTDATE flag in a ticket is normally only interpreted by the
718 ticket-granting service. It can be ignored by application servers.
719 This flag must be set in a ticket-granting ticket in order to issue a
720 postdated ticket based on the presented ticket. It is reset by
721 default; it may be requested by a client by setting the ALLOW-
722 POSTDATE option in the KRB_AS_REQ message. This flag does not allow
723 a client to obtain a postdated ticket-granting ticket; postdated
724 ticket-granting tickets can only by obtained by requesting the
725 postdating in the KRB_AS_REQ message. The life (endtime-starttime)
726 of a postdated ticket will be the remaining life of the ticket-
730 Kohl & Neuman [Page 13]
732 RFC 1510 Kerberos September 1993
735 granting ticket at the time of the request, unless the RENEWABLE
736 option is also set, in which case it can be the full life (endtime-
737 starttime) of the ticket-granting ticket. The KDC may limit how far
738 in the future a ticket may be postdated.
740 The POSTDATED flag indicates that a ticket has been postdated. The
741 application server can check the authtime field in the ticket to see
742 when the original authentication occurred. Some services may choose
743 to reject postdated tickets, or they may only accept them within a
744 certain period after the original authentication. When the KDC issues
745 a POSTDATED ticket, it will also be marked as INVALID, so that the
746 application client must present the ticket to the KDC to be validated
749 2.5. Proxiable and proxy tickets
751 At times it may be necessary for a principal to allow a service to
752 perform an operation on its behalf. The service must be able to take
753 on the identity of the client, but only for a particular purpose. A
754 principal can allow a service to take on the principal's identity for
755 a particular purpose by granting it a proxy.
757 The PROXIABLE flag in a ticket is normally only interpreted by the
758 ticket-granting service. It can be ignored by application servers.
759 When set, this flag tells the ticket-granting server that it is OK to
760 issue a new ticket (but not a ticket-granting ticket) with a
761 different network address based on this ticket. This flag is set by
764 This flag allows a client to pass a proxy to a server to perform a
765 remote request on its behalf, e.g., a print service client can give
766 the print server a proxy to access the client's files on a particular
767 file server in order to satisfy a print request.
769 In order to complicate the use of stolen credentials, Kerberos
770 tickets are usually valid from only those network addresses
771 specifically included in the ticket (It is permissible to request or
772 issue tickets with no network addresses specified, but we do not
773 recommend it). For this reason, a client wishing to grant a proxy
774 must request a new ticket valid for the network address of the
775 service to be granted the proxy.
777 The PROXY flag is set in a ticket by the TGS when it issues a
778 proxy ticket. Application servers may check this flag and require
779 additional authentication from the agent presenting the proxy in
780 order to provide an audit trail.
786 Kohl & Neuman [Page 14]
788 RFC 1510 Kerberos September 1993
791 2.6. Forwardable tickets
793 Authentication forwarding is an instance of the proxy case where the
794 service is granted complete use of the client's identity. An example
795 where it might be used is when a user logs in to a remote system and
796 wants authentication to work from that system as if the login were
799 The FORWARDABLE flag in a ticket is normally only interpreted by the
800 ticket-granting service. It can be ignored by application servers.
801 The FORWARDABLE flag has an interpretation similar to that of the
802 PROXIABLE flag, except ticket-granting tickets may also be issued
803 with different network addresses. This flag is reset by default, but
804 users may request that it be set by setting the FORWARDABLE option in
805 the AS request when they request their initial ticket-granting
808 This flag allows for authentication forwarding without requiring the
809 user to enter a password again. If the flag is not set, then
810 authentication forwarding is not permitted, but the same end result
811 can still be achieved if the user engages in the AS exchange with the
812 requested network addresses and supplies a password.
814 The FORWARDED flag is set by the TGS when a client presents a ticket
815 with the FORWARDABLE flag set and requests it be set by specifying
816 the FORWARDED KDC option and supplying a set of addresses for the new
817 ticket. It is also set in all tickets issued based on tickets with
818 the FORWARDED flag set. Application servers may wish to process
819 FORWARDED tickets differently than non-FORWARDED tickets.
821 2.7. Other KDC options
823 There are two additional options which may be set in a client's
824 request of the KDC. The RENEWABLE-OK option indicates that the
825 client will accept a renewable ticket if a ticket with the requested
826 life cannot otherwise be provided. If a ticket with the requested
827 life cannot be provided, then the KDC may issue a renewable ticket
828 with a renew-till equal to the the requested endtime. The value of
829 the renew-till field may still be adjusted by site-determined limits
830 or limits imposed by the individual principal or server.
832 The ENC-TKT-IN-SKEY option is honored only by the ticket-granting
833 service. It indicates that the to-be-issued ticket for the end
834 server is to be encrypted in the session key from the additional
835 ticket-granting ticket provided with the request. See section 3.3.3
836 for specific details.
842 Kohl & Neuman [Page 15]
844 RFC 1510 Kerberos September 1993
849 The following sections describe the interactions between network
850 clients and servers and the messages involved in those exchanges.
852 3.1. The Authentication Service Exchange
856 Message direction Message type Section
857 1. Client to Kerberos KRB_AS_REQ 5.4.1
858 2. Kerberos to client KRB_AS_REP or 5.4.2
861 The Authentication Service (AS) Exchange between the client and the
862 Kerberos Authentication Server is usually initiated by a client when
863 it wishes to obtain authentication credentials for a given server but
864 currently holds no credentials. The client's secret key is used for
865 encryption and decryption. This exchange is typically used at the
866 initiation of a login session, to obtain credentials for a Ticket-
867 Granting Server, which will subsequently be used to obtain
868 credentials for other servers (see section 3.3) without requiring
869 further use of the client's secret key. This exchange is also used
870 to request credentials for services which must not be mediated
871 through the Ticket-Granting Service, but rather require a principal's
872 secret key, such as the password-changing service. (The password-
873 changing request must not be honored unless the requester can provide
874 the old password (the user's current secret key). Otherwise, it
875 would be possible for someone to walk up to an unattended session and
876 change another user's password.) This exchange does not by itself
877 provide any assurance of the the identity of the user. (To
878 authenticate a user logging on to a local system, the credentials
879 obtained in the AS exchange may first be used in a TGS exchange to
880 obtain credentials for a local server. Those credentials must then
881 be verified by the local server through successful completion of the
882 Client/Server exchange.)
884 The exchange consists of two messages: KRB_AS_REQ from the client to
885 Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these
886 messages are described in sections 5.4.1, 5.4.2, and 5.9.1.
888 In the request, the client sends (in cleartext) its own identity and
889 the identity of the server for which it is requesting credentials.
890 The response, KRB_AS_REP, contains a ticket for the client to present
891 to the server, and a session key that will be shared by the client
892 and the server. The session key and additional information are
893 encrypted in the client's secret key. The KRB_AS_REP message
894 contains information which can be used to detect replays, and to
898 Kohl & Neuman [Page 16]
900 RFC 1510 Kerberos September 1993
903 associate it with the message to which it replies. Various errors
904 can occur; these are indicated by an error response (KRB_ERROR)
905 instead of the KRB_AS_REP response. The error message is not
906 encrypted. The KRB_ERROR message also contains information which can
907 be used to associate it with the message to which it replies. The
908 lack of encryption in the KRB_ERROR message precludes the ability to
909 detect replays or fabrications of such messages.
911 In the normal case the authentication server does not know whether
912 the client is actually the principal named in the request. It simply
913 sends a reply without knowing or caring whether they are the same.
914 This is acceptable because nobody but the principal whose identity
915 was given in the request will be able to use the reply. Its critical
916 information is encrypted in that principal's key. The initial
917 request supports an optional field that can be used to pass
918 additional information that might be needed for the initial exchange.
919 This field may be used for preauthentication if desired, but the
920 mechanism is not currently specified.
922 3.1.1. Generation of KRB_AS_REQ message
924 The client may specify a number of options in the initial request.
925 Among these options are whether preauthentication is to be performed;
926 whether the requested ticket is to be renewable, proxiable, or
927 forwardable; whether it should be postdated or allow postdating of
928 derivative tickets; and whether a renewable ticket will be accepted
929 in lieu of a non-renewable ticket if the requested ticket expiration
930 date cannot be satisfied by a nonrenewable ticket (due to
931 configuration constraints; see section 4). See section A.1 for
934 The client prepares the KRB_AS_REQ message and sends it to the KDC.
936 3.1.2. Receipt of KRB_AS_REQ message
938 If all goes well, processing the KRB_AS_REQ message will result in
939 the creation of a ticket for the client to present to the server.
940 The format for the ticket is described in section 5.3.1. The
941 contents of the ticket are determined as follows.
943 3.1.3. Generation of KRB_AS_REP message
945 The authentication server looks up the client and server principals
946 named in the KRB_AS_REQ in its database, extracting their respective
947 keys. If required, the server pre-authenticates the request, and if
948 the pre-authentication check fails, an error message with the code
949 KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate
950 the requested encryption type, an error message with code
954 Kohl & Neuman [Page 17]
956 RFC 1510 Kerberos September 1993
959 KDC_ERR_ETYPE_NOSUPP is returned. Otherwise it generates a "random"
960 session key ("Random" means that, among other things, it should be
961 impossible to guess the next session key based on knowledge of past
962 session keys. This can only be achieved in a pseudo-random number
963 generator if it is based on cryptographic principles. It would be
964 more desirable to use a truly random number generator, such as one
965 based on measurements of random physical phenomena.).
967 If the requested start time is absent or indicates a time in the
968 past, then the start time of the ticket is set to the authentication
969 server's current time. If it indicates a time in the future, but the
970 POSTDATED option has not been specified, then the error
971 KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the requested start
972 time is checked against the policy of the local realm (the
973 administrator might decide to prohibit certain types or ranges of
974 postdated tickets), and if acceptable, the ticket's start time is set
975 as requested and the INVALID flag is set in the new ticket. The
976 postdated ticket must be validated before use by presenting it to the
977 KDC after the start time has been reached.
979 The expiration time of the ticket will be set to the minimum of the
982 +The expiration time (endtime) requested in the KRB_AS_REQ
985 +The ticket's start time plus the maximum allowable lifetime
986 associated with the client principal (the authentication
987 server's database includes a maximum ticket lifetime field
988 in each principal's record; see section 4).
990 +The ticket's start time plus the maximum allowable lifetime
991 associated with the server principal.
993 +The ticket's start time plus the maximum lifetime set by
994 the policy of the local realm.
996 If the requested expiration time minus the start time (as determined
997 above) is less than a site-determined minimum lifetime, an error
998 message with code KDC_ERR_NEVER_VALID is returned. If the requested
999 expiration time for the ticket exceeds what was determined as above,
1000 and if the "RENEWABLE-OK" option was requested, then the "RENEWABLE"
1001 flag is set in the new ticket, and the renew-till value is set as if
1002 the "RENEWABLE" option were requested (the field and option names are
1003 described fully in section 5.4.1). If the RENEWABLE option has been
1004 requested or if the RENEWABLE-OK option has been set and a renewable
1005 ticket is to be issued, then the renew-till field is set to the
1010 Kohl & Neuman [Page 18]
1012 RFC 1510 Kerberos September 1993
1015 +Its requested value.
1017 +The start time of the ticket plus the minimum of the two
1018 maximum renewable lifetimes associated with the principals'
1021 +The start time of the ticket plus the maximum renewable
1022 lifetime set by the policy of the local realm.
1024 The flags field of the new ticket will have the following options set
1025 if they have been requested and if the policy of the local realm
1026 allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE.
1027 If the new ticket is postdated (the start time is in the future), its
1028 INVALID flag will also be set.
1030 If all of the above succeed, the server formats a KRB_AS_REP message
1031 (see section 5.4.2), copying the addresses in the request into the
1032 caddr of the response, placing any required pre-authentication data
1033 into the padata of the response, and encrypts the ciphertext part in
1034 the client's key using the requested encryption method, and sends it
1035 to the client. See section A.2 for pseudocode.
1037 3.1.4. Generation of KRB_ERROR message
1039 Several errors can occur, and the Authentication Server responds by
1040 returning an error message, KRB_ERROR, to the client, with the
1041 error-code and e-text fields set to appropriate values. The error
1042 message contents and details are described in Section 5.9.1.
1044 3.1.5. Receipt of KRB_AS_REP message
1046 If the reply message type is KRB_AS_REP, then the client verifies
1047 that the cname and crealm fields in the cleartext portion of the
1048 reply match what it requested. If any padata fields are present,
1049 they may be used to derive the proper secret key to decrypt the
1050 message. The client decrypts the encrypted part of the response
1051 using its secret key, verifies that the nonce in the encrypted part
1052 matches the nonce it supplied in its request (to detect replays). It
1053 also verifies that the sname and srealm in the response match those
1054 in the request, and that the host address field is also correct. It
1055 then stores the ticket, session key, start and expiration times, and
1056 other information for later use. The key-expiration field from the
1057 encrypted part of the response may be checked to notify the user of
1058 impending key expiration (the client program could then suggest
1059 remedial action, such as a password change). See section A.3 for
1062 Proper decryption of the KRB_AS_REP message is not sufficient to
1066 Kohl & Neuman [Page 19]
1068 RFC 1510 Kerberos September 1993
1071 verify the identity of the user; the user and an attacker could
1072 cooperate to generate a KRB_AS_REP format message which decrypts
1073 properly but is not from the proper KDC. If the host wishes to
1074 verify the identity of the user, it must require the user to present
1075 application credentials which can be verified using a securely-stored
1076 secret key. If those credentials can be verified, then the identity
1077 of the user can be assured.
1079 3.1.6. Receipt of KRB_ERROR message
1081 If the reply message type is KRB_ERROR, then the client interprets it
1082 as an error and performs whatever application-specific tasks are
1083 necessary to recover.
1085 3.2. The Client/Server Authentication Exchange
1089 Message direction Message type Section
1090 Client to Application server KRB_AP_REQ 5.5.1
1091 [optional] Application server to client KRB_AP_REP or 5.5.2
1094 The client/server authentication (CS) exchange is used by network
1095 applications to authenticate the client to the server and vice versa.
1096 The client must have already acquired credentials for the server
1097 using the AS or TGS exchange.
1099 3.2.1. The KRB_AP_REQ message
1101 The KRB_AP_REQ contains authentication information which should be
1102 part of the first message in an authenticated transaction. It
1103 contains a ticket, an authenticator, and some additional bookkeeping
1104 information (see section 5.5.1 for the exact format). The ticket by
1105 itself is insufficient to authenticate a client, since tickets are
1106 passed across the network in cleartext(Tickets contain both an
1107 encrypted and unencrypted portion, so cleartext here refers to the
1108 entire unit, which can be copied from one message and replayed in
1109 another without any cryptographic skill.), so the authenticator is
1110 used to prevent invalid replay of tickets by proving to the server
1111 that the client knows the session key of the ticket and thus is
1112 entitled to use it. The KRB_AP_REQ message is referred to elsewhere
1113 as the "authentication header."
1115 3.2.2. Generation of a KRB_AP_REQ message
1117 When a client wishes to initiate authentication to a server, it
1118 obtains (either through a credentials cache, the AS exchange, or the
1122 Kohl & Neuman [Page 20]
1124 RFC 1510 Kerberos September 1993
1127 TGS exchange) a ticket and session key for the desired service. The
1128 client may re-use any tickets it holds until they expire. The client
1129 then constructs a new Authenticator from the the system time, its
1130 name, and optionally an application specific checksum, an initial
1131 sequence number to be used in KRB_SAFE or KRB_PRIV messages, and/or a
1132 session subkey to be used in negotiations for a session key unique to
1133 this particular session. Authenticators may not be re-used and will
1134 be rejected if replayed to a server (Note that this can make
1135 applications based on unreliable transports difficult to code
1136 correctly, if the transport might deliver duplicated messages. In
1137 such cases, a new authenticator must be generated for each retry.).
1138 If a sequence number is to be included, it should be randomly chosen
1139 so that even after many messages have been exchanged it is not likely
1140 to collide with other sequence numbers in use.
1142 The client may indicate a requirement of mutual authentication or the
1143 use of a session-key based ticket by setting the appropriate flag(s)
1144 in the ap-options field of the message.
1146 The Authenticator is encrypted in the session key and combined with
1147 the ticket to form the KRB_AP_REQ message which is then sent to the
1148 end server along with any additional application-specific
1149 information. See section A.9 for pseudocode.
1151 3.2.3. Receipt of KRB_AP_REQ message
1153 Authentication is based on the server's current time of day (clocks
1154 must be loosely synchronized), the authenticator, and the ticket.
1155 Several errors are possible. If an error occurs, the server is
1156 expected to reply to the client with a KRB_ERROR message. This
1157 message may be encapsulated in the application protocol if its "raw"
1158 form is not acceptable to the protocol. The format of error messages
1159 is described in section 5.9.1.
1161 The algorithm for verifying authentication information is as follows.
1162 If the message type is not KRB_AP_REQ, the server returns the
1163 KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the Ticket
1164 in the KRB_AP_REQ is not one the server can use (e.g., it indicates
1165 an old key, and the server no longer possesses a copy of the old
1166 key), the KRB_AP_ERR_BADKEYVER error is returned. If the USE-
1167 SESSION-KEY flag is set in the ap-options field, it indicates to the
1168 server that the ticket is encrypted in the session key from the
1169 server's ticket-granting ticket rather than its secret key (This is
1170 used for user-to-user authentication as described in [6]). Since it
1171 is possible for the server to be registered in multiple realms, with
1172 different keys in each, the srealm field in the unencrypted portion
1173 of the ticket in the KRB_AP_REQ is used to specify which secret key
1174 the server should use to decrypt that ticket. The KRB_AP_ERR_NOKEY
1178 Kohl & Neuman [Page 21]
1180 RFC 1510 Kerberos September 1993
1183 error code is returned if the server doesn't have the proper key to
1184 decipher the ticket.
1186 The ticket is decrypted using the version of the server's key
1187 specified by the ticket. If the decryption routines detect a
1188 modification of the ticket (each encryption system must provide
1189 safeguards to detect modified ciphertext; see section 6), the
1190 KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that
1191 different keys were used to encrypt and decrypt).
1193 The authenticator is decrypted using the session key extracted from
1194 the decrypted ticket. If decryption shows it to have been modified,
1195 the KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm
1196 of the client from the ticket are compared against the same fields in
1197 the authenticator. If they don't match, the KRB_AP_ERR_BADMATCH
1198 error is returned (they might not match, for example, if the wrong
1199 session key was used to encrypt the authenticator). The addresses in
1200 the ticket (if any) are then searched for an address matching the
1201 operating-system reported address of the client. If no match is
1202 found or the server insists on ticket addresses but none are present
1203 in the ticket, the KRB_AP_ERR_BADADDR error is returned.
1205 If the local (server) time and the client time in the authenticator
1206 differ by more than the allowable clock skew (e.g., 5 minutes), the
1207 KRB_AP_ERR_SKEW error is returned. If the server name, along with
1208 the client name, time and microsecond fields from the Authenticator
1209 match any recently-seen such tuples, the KRB_AP_ERR_REPEAT error is
1210 returned (Note that the rejection here is restricted to
1211 authenticators from the same principal to the same server. Other
1212 client principals communicating with the same server principal should
1213 not be have their authenticators rejected if the time and microsecond
1214 fields happen to match some other client's authenticator.). The
1215 server must remember any authenticator presented within the allowable
1216 clock skew, so that a replay attempt is guaranteed to fail. If a
1217 server loses track of any authenticator presented within the
1218 allowable clock skew, it must reject all requests until the clock
1219 skew interval has passed. This assures that any lost or re-played
1220 authenticators will fall outside the allowable clock skew and can no
1221 longer be successfully replayed (If this is not done, an attacker
1222 could conceivably record the ticket and authenticator sent over the
1223 network to a server, then disable the client's host, pose as the
1224 disabled host, and replay the ticket and authenticator to subvert the
1225 authentication.). If a sequence number is provided in the
1226 authenticator, the server saves it for later use in processing
1227 KRB_SAFE and/or KRB_PRIV messages. If a subkey is present, the
1228 server either saves it for later use or uses it to help generate its
1229 own choice for a subkey to be returned in a KRB_AP_REP message.
1234 Kohl & Neuman [Page 22]
1236 RFC 1510 Kerberos September 1993
1239 The server computes the age of the ticket: local (server) time minus
1240 the start time inside the Ticket. If the start time is later than
1241 the current time by more than the allowable clock skew or if the
1242 INVALID flag is set in the ticket, the KRB_AP_ERR_TKT_NYV error is
1243 returned. Otherwise, if the current time is later than end time by
1244 more than the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error
1247 If all these checks succeed without an error, the server is assured
1248 that the client possesses the credentials of the principal named in
1249 the ticket and thus, the client has been authenticated to the server.
1250 See section A.10 for pseudocode.
1252 3.2.4. Generation of a KRB_AP_REP message
1254 Typically, a client's request will include both the authentication
1255 information and its initial request in the same message, and the
1256 server need not explicitly reply to the KRB_AP_REQ. However, if
1257 mutual authentication (not only authenticating the client to the
1258 server, but also the server to the client) is being performed, the
1259 KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options
1260 field, and a KRB_AP_REP message is required in response. As with the
1261 error message, this message may be encapsulated in the application
1262 protocol if its "raw" form is not acceptable to the application's
1263 protocol. The timestamp and microsecond field used in the reply must
1264 be the client's timestamp and microsecond field (as provided in the
1265 authenticator). [Note: In the Kerberos version 4 protocol, the
1266 timestamp in the reply was the client's timestamp plus one. This is
1267 not necessary in version 5 because version 5 messages are formatted
1268 in such a way that it is not possible to create the reply by
1269 judicious message surgery (even in encrypted form) without knowledge
1270 of the appropriate encryption keys.] If a sequence number is to be
1271 included, it should be randomly chosen as described above for the
1272 authenticator. A subkey may be included if the server desires to
1273 negotiate a different subkey. The KRB_AP_REP message is encrypted in
1274 the session key extracted from the ticket. See section A.11 for
1277 3.2.5. Receipt of KRB_AP_REP message
1279 If a KRB_AP_REP message is returned, the client uses the session key
1280 from the credentials obtained for the server (Note that for
1281 encrypting the KRB_AP_REP message, the sub-session key is not used,
1282 even if present in the Authenticator.) to decrypt the message, and
1283 verifies that the timestamp and microsecond fields match those in the
1284 Authenticator it sent to the server. If they match, then the client
1285 is assured that the server is genuine. The sequence number and subkey
1286 (if present) are retained for later use. See section A.12 for
1290 Kohl & Neuman [Page 23]
1292 RFC 1510 Kerberos September 1993
1297 3.2.6. Using the encryption key
1299 After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and
1300 server share an encryption key which can be used by the application.
1301 The "true session key" to be used for KRB_PRIV, KRB_SAFE, or other
1302 application-specific uses may be chosen by the application based on
1303 the subkeys in the KRB_AP_REP message and the authenticator
1304 (Implementations of the protocol may wish to provide routines to
1305 choose subkeys based on session keys and random numbers and to
1306 orchestrate a negotiated key to be returned in the KRB_AP_REP
1307 message.). In some cases, the use of this session key will be
1308 implicit in the protocol; in others the method of use must be chosen
1309 from a several alternatives. We leave the protocol negotiations of
1310 how to use the key (e.g., selecting an encryption or checksum type)
1311 to the application programmer; the Kerberos protocol does not
1312 constrain the implementation options.
1314 With both the one-way and mutual authentication exchanges, the peers
1315 should take care not to send sensitive information to each other
1316 without proper assurances. In particular, applications that require
1317 privacy or integrity should use the KRB_AP_REP or KRB_ERROR responses
1318 from the server to client to assure both client and server of their
1319 peer's identity. If an application protocol requires privacy of its
1320 messages, it can use the KRB_PRIV message (section 3.5). The KRB_SAFE
1321 message (section 3.4) can be used to assure integrity.
1323 3.3. The Ticket-Granting Service (TGS) Exchange
1327 Message direction Message type Section
1328 1. Client to Kerberos KRB_TGS_REQ 5.4.1
1329 2. Kerberos to client KRB_TGS_REP or 5.4.2
1332 The TGS exchange between a client and the Kerberos Ticket-Granting
1333 Server is initiated by a client when it wishes to obtain
1334 authentication credentials for a given server (which might be
1335 registered in a remote realm), when it wishes to renew or validate an
1336 existing ticket, or when it wishes to obtain a proxy ticket. In the
1337 first case, the client must already have acquired a ticket for the
1338 Ticket-Granting Service using the AS exchange (the ticket-granting
1339 ticket is usually obtained when a client initially authenticates to
1340 the system, such as when a user logs in). The message format for the
1341 TGS exchange is almost identical to that for the AS exchange. The
1342 primary difference is that encryption and decryption in the TGS
1346 Kohl & Neuman [Page 24]
1348 RFC 1510 Kerberos September 1993
1351 exchange does not take place under the client's key. Instead, the
1352 session key from the ticket-granting ticket or renewable ticket, or
1353 sub-session key from an Authenticator is used. As is the case for
1354 all application servers, expired tickets are not accepted by the TGS,
1355 so once a renewable or ticket-granting ticket expires, the client
1356 must use a separate exchange to obtain valid tickets.
1358 The TGS exchange consists of two messages: A request (KRB_TGS_REQ)
1359 from the client to the Kerberos Ticket-Granting Server, and a reply
1360 (KRB_TGS_REP or KRB_ERROR). The KRB_TGS_REQ message includes
1361 information authenticating the client plus a request for credentials.
1362 The authentication information consists of the authentication header
1363 (KRB_AP_REQ) which includes the client's previously obtained ticket-
1364 granting, renewable, or invalid ticket. In the ticket-granting
1365 ticket and proxy cases, the request may include one or more of: a
1366 list of network addresses, a collection of typed authorization data
1367 to be sealed in the ticket for authorization use by the application
1368 server, or additional tickets (the use of which are described later).
1369 The TGS reply (KRB_TGS_REP) contains the requested credentials,
1370 encrypted in the session key from the ticket-granting ticket or
1371 renewable ticket, or if present, in the subsession key from the
1372 Authenticator (part of the authentication header). The KRB_ERROR
1373 message contains an error code and text explaining what went wrong.
1374 The KRB_ERROR message is not encrypted. The KRB_TGS_REP message
1375 contains information which can be used to detect replays, and to
1376 associate it with the message to which it replies. The KRB_ERROR
1377 message also contains information which can be used to associate it
1378 with the message to which it replies, but the lack of encryption in
1379 the KRB_ERROR message precludes the ability to detect replays or
1380 fabrications of such messages.
1382 3.3.1. Generation of KRB_TGS_REQ message
1384 Before sending a request to the ticket-granting service, the client
1385 must determine in which realm the application server is registered
1386 [Note: This can be accomplished in several ways. It might be known
1387 beforehand (since the realm is part of the principal identifier), or
1388 it might be stored in a nameserver. Presently, however, this
1389 information is obtained from a configuration file. If the realm to
1390 be used is obtained from a nameserver, there is a danger of being
1391 spoofed if the nameservice providing the realm name is not
1392 authenticated. This might result in the use of a realm which has
1393 been compromised, and would result in an attacker's ability to
1394 compromise the authentication of the application server to the
1395 client.]. If the client does not already possess a ticket-granting
1396 ticket for the appropriate realm, then one must be obtained. This is
1397 first attempted by requesting a ticket-granting ticket for the
1398 destination realm from the local Kerberos server (using the
1402 Kohl & Neuman [Page 25]
1404 RFC 1510 Kerberos September 1993
1407 KRB_TGS_REQ message recursively). The Kerberos server may return a
1408 TGT for the desired realm in which case one can proceed.
1409 Alternatively, the Kerberos server may return a TGT for a realm which
1410 is "closer" to the desired realm (further along the standard
1411 hierarchical path), in which case this step must be repeated with a
1412 Kerberos server in the realm specified in the returned TGT. If
1413 neither are returned, then the request must be retried with a
1414 Kerberos server for a realm higher in the hierarchy. This request
1415 will itself require a ticket-granting ticket for the higher realm
1416 which must be obtained by recursively applying these directions.
1418 Once the client obtains a ticket-granting ticket for the appropriate
1419 realm, it determines which Kerberos servers serve that realm, and
1420 contacts one. The list might be obtained through a configuration file
1421 or network service; as long as the secret keys exchanged by realms
1422 are kept secret, only denial of service results from a false Kerberos
1425 As in the AS exchange, the client may specify a number of options in
1426 the KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ
1427 message, providing an authentication header as an element of the
1428 padata field, and including the same fields as used in the KRB_AS_REQ
1429 message along with several optional fields: the enc-authorization-
1430 data field for application server use and additional tickets required
1433 In preparing the authentication header, the client can select a sub-
1434 session key under which the response from the Kerberos server will be
1435 encrypted (If the client selects a sub-session key, care must be
1436 taken to ensure the randomness of the selected subsession key. One
1437 approach would be to generate a random number and XOR it with the
1438 session key from the ticket-granting ticket.). If the sub-session key
1439 is not specified, the session key from the ticket-granting ticket
1440 will be used. If the enc-authorization-data is present, it must be
1441 encrypted in the sub-session key, if present, from the authenticator
1442 portion of the authentication header, or if not present in the
1443 session key from the ticket-granting ticket.
1445 Once prepared, the message is sent to a Kerberos server for the
1446 destination realm. See section A.5 for pseudocode.
1448 3.3.2. Receipt of KRB_TGS_REQ message
1450 The KRB_TGS_REQ message is processed in a manner similar to the
1451 KRB_AS_REQ message, but there are many additional checks to be
1452 performed. First, the Kerberos server must determine which server
1453 the accompanying ticket is for and it must select the appropriate key
1454 to decrypt it. For a normal KRB_TGS_REQ message, it will be for the
1458 Kohl & Neuman [Page 26]
1460 RFC 1510 Kerberos September 1993
1463 ticket granting service, and the TGS's key will be used. If the TGT
1464 was issued by another realm, then the appropriate inter-realm key
1465 must be used. If the accompanying ticket is not a ticket granting
1466 ticket for the current realm, but is for an application server in the
1467 current realm, the RENEW, VALIDATE, or PROXY options are specified in
1468 the request, and the server for which a ticket is requested is the
1469 server named in the accompanying ticket, then the KDC will decrypt
1470 the ticket in the authentication header using the key of the server
1471 for which it was issued. If no ticket can be found in the padata
1472 field, the KDC_ERR_PADATA_TYPE_NOSUPP error is returned.
1474 Once the accompanying ticket has been decrypted, the user-supplied
1475 checksum in the Authenticator must be verified against the contents
1476 of the request, and the message rejected if the checksums do not
1477 match (with an error code of KRB_AP_ERR_MODIFIED) or if the checksum
1478 is not keyed or not collision-proof (with an error code of
1479 KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported, the
1480 KDC_ERR_SUMTYPE_NOSUPP error is returned. If the authorization-data
1481 are present, they are decrypted using the sub-session key from the
1484 If any of the decryptions indicate failed integrity checks, the
1485 KRB_AP_ERR_BAD_INTEGRITY error is returned.
1487 3.3.3. Generation of KRB_TGS_REP message
1489 The KRB_TGS_REP message shares its format with the KRB_AS_REP
1490 (KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The
1491 detailed specification is in section 5.4.2.
1493 The response will include a ticket for the requested server. The
1494 Kerberos database is queried to retrieve the record for the requested
1495 server (including the key with which the ticket will be encrypted).
1496 If the request is for a ticket granting ticket for a remote realm,
1497 and if no key is shared with the requested realm, then the Kerberos
1498 server will select the realm "closest" to the requested realm with
1499 which it does share a key, and use that realm instead. This is the
1500 only case where the response from the KDC will be for a different
1501 server than that requested by the client.
1503 By default, the address field, the client's name and realm, the list
1504 of transited realms, the time of initial authentication, the
1505 expiration time, and the authorization data of the newly-issued
1506 ticket will be copied from the ticket-granting ticket (TGT) or
1507 renewable ticket. If the transited field needs to be updated, but
1508 the transited type is not supported, the KDC_ERR_TRTYPE_NOSUPP error
1514 Kohl & Neuman [Page 27]
1516 RFC 1510 Kerberos September 1993
1519 If the request specifies an endtime, then the endtime of the new
1520 ticket is set to the minimum of (a) that request, (b) the endtime
1521 from the TGT, and (c) the starttime of the TGT plus the minimum of
1522 the maximum life for the application server and the maximum life for
1523 the local realm (the maximum life for the requesting principal was
1524 already applied when the TGT was issued). If the new ticket is to be
1525 a renewal, then the endtime above is replaced by the minimum of (a)
1526 the value of the renew_till field of the ticket and (b) the starttime
1527 for the new ticket plus the life (endtimestarttime) of the old
1530 If the FORWARDED option has been requested, then the resulting ticket
1531 will contain the addresses specified by the client. This option will
1532 only be honored if the FORWARDABLE flag is set in the TGT. The PROXY
1533 option is similar; the resulting ticket will contain the addresses
1534 specified by the client. It will be honored only if the PROXIABLE
1535 flag in the TGT is set. The PROXY option will not be honored on
1536 requests for additional ticket-granting tickets.
1538 If the requested start time is absent or indicates a time in the
1539 past, then the start time of the ticket is set to the authentication
1540 server's current time. If it indicates a time in the future, but the
1541 POSTDATED option has not been specified or the MAY-POSTDATE flag is
1542 not set in the TGT, then the error KDC_ERR_CANNOT_POSTDATE is
1543 returned. Otherwise, if the ticket-granting ticket has the
1544 MAYPOSTDATE flag set, then the resulting ticket will be postdated and
1545 the requested starttime is checked against the policy of the local
1546 realm. If acceptable, the ticket's start time is set as requested,
1547 and the INVALID flag is set. The postdated ticket must be validated
1548 before use by presenting it to the KDC after the starttime has been
1549 reached. However, in no case may the starttime, endtime, or renew-
1550 till time of a newly-issued postdated ticket extend beyond the
1551 renew-till time of the ticket-granting ticket.
1553 If the ENC-TKT-IN-SKEY option has been specified and an additional
1554 ticket has been included in the request, the KDC will decrypt the
1555 additional ticket using the key for the server to which the
1556 additional ticket was issued and verify that it is a ticket-granting
1557 ticket. If the name of the requested server is missing from the
1558 request, the name of the client in the additional ticket will be
1559 used. Otherwise the name of the requested server will be compared to
1560 the name of the client in the additional ticket and if different, the
1561 request will be rejected. If the request succeeds, the session key
1562 from the additional ticket will be used to encrypt the new ticket
1563 that is issued instead of using the key of the server for which the
1564 new ticket will be used (This allows easy implementation of user-to-
1565 user authentication [6], which uses ticket-granting ticket session
1566 keys in lieu of secret server keys in situations where such secret
1570 Kohl & Neuman [Page 28]
1572 RFC 1510 Kerberos September 1993
1575 keys could be easily compromised.).
1577 If the name of the server in the ticket that is presented to the KDC
1578 as part of the authentication header is not that of the ticket-
1579 granting server itself, and the server is registered in the realm of
1580 the KDC, If the RENEW option is requested, then the KDC will verify
1581 that the RENEWABLE flag is set in the ticket and that the renew_till
1582 time is still in the future. If the VALIDATE option is rqeuested,
1583 the KDC will check that the starttime has passed and the INVALID flag
1584 is set. If the PROXY option is requested, then the KDC will check
1585 that the PROXIABLE flag is set in the ticket. If the tests succeed,
1586 the KDC will issue the appropriate new ticket.
1588 Whenever a request is made to the ticket-granting server, the
1589 presented ticket(s) is(are) checked against a hot-list of tickets
1590 which have been canceled. This hot-list might be implemented by
1591 storing a range of issue dates for "suspect tickets"; if a presented
1592 ticket had an authtime in that range, it would be rejected. In this
1593 way, a stolen ticket-granting ticket or renewable ticket cannot be
1594 used to gain additional tickets (renewals or otherwise) once the
1595 theft has been reported. Any normal ticket obtained before it was
1596 reported stolen will still be valid (because they require no
1597 interaction with the KDC), but only until their normal expiration
1600 The ciphertext part of the response in the KRB_TGS_REP message is
1601 encrypted in the sub-session key from the Authenticator, if present,
1602 or the session key key from the ticket-granting ticket. It is not
1603 encrypted using the client's secret key. Furthermore, the client's
1604 key's expiration date and the key version number fields are left out
1605 since these values are stored along with the client's database
1606 record, and that record is not needed to satisfy a request based on a
1607 ticket-granting ticket. See section A.6 for pseudocode.
1609 3.3.3.1. Encoding the transited field
1611 If the identity of the server in the TGT that is presented to the KDC
1612 as part of the authentication header is that of the ticket-granting
1613 service, but the TGT was issued from another realm, the KDC will look
1614 up the inter-realm key shared with that realm and use that key to
1615 decrypt the ticket. If the ticket is valid, then the KDC will honor
1616 the request, subject to the constraints outlined above in the section
1617 describing the AS exchange. The realm part of the client's identity
1618 will be taken from the ticket-granting ticket. The name of the realm
1619 that issued the ticket-granting ticket will be added to the transited
1620 field of the ticket to be issued. This is accomplished by reading
1621 the transited field from the ticket-granting ticket (which is treated
1622 as an unordered set of realm names), adding the new realm to the set,
1626 Kohl & Neuman [Page 29]
1628 RFC 1510 Kerberos September 1993
1631 then constructing and writing out its encoded (shorthand) form (this
1632 may involve a rearrangement of the existing encoding).
1634 Note that the ticket-granting service does not add the name of its
1635 own realm. Instead, its responsibility is to add the name of the
1636 previous realm. This prevents a malicious Kerberos server from
1637 intentionally leaving out its own name (it could, however, omit other
1640 The names of neither the local realm nor the principal's realm are to
1641 be included in the transited field. They appear elsewhere in the
1642 ticket and both are known to have taken part in authenticating the
1643 principal. Since the endpoints are not included, both local and
1644 single-hop inter-realm authentication result in a transited field
1647 Because the name of each realm transited is added to this field,
1648 it might potentially be very long. To decrease the length of this
1649 field, its contents are encoded. The initially supported encoding is
1650 optimized for the normal case of inter-realm communication: a
1651 hierarchical arrangement of realms using either domain or X.500 style
1652 realm names. This encoding (called DOMAIN-X500-COMPRESS) is now
1655 Realm names in the transited field are separated by a ",". The ",",
1656 "\", trailing "."s, and leading spaces (" ") are special characters,
1657 and if they are part of a realm name, they must be quoted in the
1658 transited field by preceding them with a "\".
1660 A realm name ending with a "." is interpreted as being prepended to
1661 the previous realm. For example, we can encode traversal of EDU,
1662 MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as:
1664 "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
1666 Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were endpoints,
1667 that they would not be included in this field, and we would have:
1669 "EDU,MIT.,WASHINGTON.EDU"
1671 A realm name beginning with a "/" is interpreted as being appended to
1672 the previous realm (For the purpose of appending, the realm preceding
1673 the first listed realm is considered to be the null realm ("")). If
1674 it is to stand by itself, then it should be preceded by a space ("
1675 "). For example, we can encode traversal of /COM/HP/APOLLO, /COM/HP,
1676 /COM, and /COM/DEC as:
1678 "/COM,/HP,/APOLLO, /COM/DEC".
1682 Kohl & Neuman [Page 30]
1684 RFC 1510 Kerberos September 1993
1687 Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints,
1688 they they would not be included in this field, and we would have:
1692 A null subfield preceding or following a "," indicates that all
1693 realms between the previous realm and the next realm have been
1694 traversed (For the purpose of interpreting null subfields, the
1695 client's realm is considered to precede those in the transited field,
1696 and the server's realm is considered to follow them.). Thus, ","
1697 means that all realms along the path between the client and the
1698 server have been traversed. ",EDU, /COM," means that that all realms
1699 from the client's realm up to EDU (in a domain style hierarchy) have
1700 been traversed, and that everything from /COM down to the server's
1701 realm in an X.500 style has also been traversed. This could occur if
1702 the EDU realm in one hierarchy shares an inter-realm key directly
1703 with the /COM realm in another hierarchy.
1705 3.3.4. Receipt of KRB_TGS_REP message
1707 When the KRB_TGS_REP is received by the client, it is processed in
1708 the same manner as the KRB_AS_REP processing described above. The
1709 primary difference is that the ciphertext part of the response must
1710 be decrypted using the session key from the ticket-granting ticket
1711 rather than the client's secret key. See section A.7 for pseudocode.
1713 3.4. The KRB_SAFE Exchange
1715 The KRB_SAFE message may be used by clients requiring the ability to
1716 detect modifications of messages they exchange. It achieves this by
1717 including a keyed collisionproof checksum of the user data and some
1718 control information. The checksum is keyed with an encryption key
1719 (usually the last key negotiated via subkeys, or the session key if
1720 no negotiation has occured).
1722 3.4.1. Generation of a KRB_SAFE message
1724 When an application wishes to send a KRB_SAFE message, it collects
1725 its data and the appropriate control information and computes a
1726 checksum over them. The checksum algorithm should be some sort of
1727 keyed one-way hash function (such as the RSA-MD5-DES checksum
1728 algorithm specified in section 6.4.5, or the DES MAC), generated
1729 using the sub-session key if present, or the session key. Different
1730 algorithms may be selected by changing the checksum type in the
1731 message. Unkeyed or non-collision-proof checksums are not suitable
1734 The control information for the KRB_SAFE message includes both a
1738 Kohl & Neuman [Page 31]
1740 RFC 1510 Kerberos September 1993
1743 timestamp and a sequence number. The designer of an application
1744 using the KRB_SAFE message must choose at least one of the two
1745 mechanisms. This choice should be based on the needs of the
1746 application protocol.
1748 Sequence numbers are useful when all messages sent will be received
1749 by one's peer. Connection state is presently required to maintain
1750 the session key, so maintaining the next sequence number should not
1751 present an additional problem.
1753 If the application protocol is expected to tolerate lost messages
1754 without them being resent, the use of the timestamp is the
1755 appropriate replay detection mechanism. Using timestamps is also the
1756 appropriate mechanism for multi-cast protocols where all of one's
1757 peers share a common sub-session key, but some messages will be sent
1758 to a subset of one's peers.
1760 After computing the checksum, the client then transmits the
1761 information and checksum to the recipient in the message format
1762 specified in section 5.6.1.
1764 3.4.2. Receipt of KRB_SAFE message
1766 When an application receives a KRB_SAFE message, it verifies it as
1767 follows. If any error occurs, an error code is reported for use by
1770 The message is first checked by verifying that the protocol version
1771 and type fields match the current version and KRB_SAFE, respectively.
1772 A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE
1773 error. The application verifies that the checksum used is a
1774 collisionproof keyed checksum, and if it is not, a
1775 KRB_AP_ERR_INAPP_CKSUM error is generated. The recipient verifies
1776 that the operating system's report of the sender's address matches
1777 the sender's address in the message, and (if a recipient address is
1778 specified or the recipient requires an address) that one of the
1779 recipient's addresses appears as the recipient's address in the
1780 message. A failed match for either case generates a
1781 KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the
1782 sequence number fields are checked. If timestamp and usec are
1783 expected and not present, or they are present but not current, the
1784 KRB_AP_ERR_SKEW error is generated. If the server name, along with
1785 the client name, time and microsecond fields from the Authenticator
1786 match any recently-seen such tuples, the KRB_AP_ERR_REPEAT error is
1787 generated. If an incorrect sequence number is included, or a
1788 sequence number is expected but not present, the KRB_AP_ERR_BADORDER
1789 error is generated. If neither a timestamp and usec or a sequence
1790 number is present, a KRB_AP_ERR_MODIFIED error is generated.
1794 Kohl & Neuman [Page 32]
1796 RFC 1510 Kerberos September 1993
1799 Finally, the checksum is computed over the data and control
1800 information, and if it doesn't match the received checksum, a
1801 KRB_AP_ERR_MODIFIED error is generated.
1803 If all the checks succeed, the application is assured that the
1804 message was generated by its peer and was not modified in transit.
1806 3.5. The KRB_PRIV Exchange
1808 The KRB_PRIV message may be used by clients requiring confidentiality
1809 and the ability to detect modifications of exchanged messages. It
1810 achieves this by encrypting the messages and adding control
1813 3.5.1. Generation of a KRB_PRIV message
1815 When an application wishes to send a KRB_PRIV message, it collects
1816 its data and the appropriate control information (specified in
1817 section 5.7.1) and encrypts them under an encryption key (usually the
1818 last key negotiated via subkeys, or the session key if no negotiation
1819 has occured). As part of the control information, the client must
1820 choose to use either a timestamp or a sequence number (or both); see
1821 the discussion in section 3.4.1 for guidelines on which to use.
1822 After the user data and control information are encrypted, the client
1823 transmits the ciphertext and some "envelope" information to the
1826 3.5.2. Receipt of KRB_PRIV message
1828 When an application receives a KRB_PRIV message, it verifies it as
1829 follows. If any error occurs, an error code is reported for use by
1832 The message is first checked by verifying that the protocol version
1833 and type fields match the current version and KRB_PRIV, respectively.
1834 A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE
1835 error. The application then decrypts the ciphertext and processes
1836 the resultant plaintext. If decryption shows the data to have been
1837 modified, a KRB_AP_ERR_BAD_INTEGRITY error is generated. The
1838 recipient verifies that the operating system's report of the sender's
1839 address matches the sender's address in the message, and (if a
1840 recipient address is specified or the recipient requires an address)
1841 that one of the recipient's addresses appears as the recipient's
1842 address in the message. A failed match for either case generates a
1843 KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the
1844 sequence number fields are checked. If timestamp and usec are
1845 expected and not present, or they are present but not current, the
1846 KRB_AP_ERR_SKEW error is generated. If the server name, along with
1850 Kohl & Neuman [Page 33]
1852 RFC 1510 Kerberos September 1993
1855 the client name, time and microsecond fields from the Authenticator
1856 match any recently-seen such tuples, the KRB_AP_ERR_REPEAT error is
1857 generated. If an incorrect sequence number is included, or a
1858 sequence number is expected but not present, the KRB_AP_ERR_BADORDER
1859 error is generated. If neither a timestamp and usec or a sequence
1860 number is present, a KRB_AP_ERR_MODIFIED error is generated.
1862 If all the checks succeed, the application can assume the message was
1863 generated by its peer, and was securely transmitted (without
1864 intruders able to see the unencrypted contents).
1866 3.6. The KRB_CRED Exchange
1868 The KRB_CRED message may be used by clients requiring the ability to
1869 send Kerberos credentials from one host to another. It achieves this
1870 by sending the tickets together with encrypted data containing the
1871 session keys and other information associated with the tickets.
1873 3.6.1. Generation of a KRB_CRED message
1875 When an application wishes to send a KRB_CRED message it first (using
1876 the KRB_TGS exchange) obtains credentials to be sent to the remote
1877 host. It then constructs a KRB_CRED message using the ticket or
1878 tickets so obtained, placing the session key needed to use each
1879 ticket in the key field of the corresponding KrbCredInfo sequence of
1880 the encrypted part of the the KRB_CRED message.
1882 Other information associated with each ticket and obtained during the
1883 KRB_TGS exchange is also placed in the corresponding KrbCredInfo
1884 sequence in the encrypted part of the KRB_CRED message. The current
1885 time and, if specifically required by the application the nonce, s-
1886 address, and raddress fields, are placed in the encrypted part of the
1887 KRB_CRED message which is then encrypted under an encryption key
1888 previosuly exchanged in the KRB_AP exchange (usually the last key
1889 negotiated via subkeys, or the session key if no negotiation has
1892 3.6.2. Receipt of KRB_CRED message
1894 When an application receives a KRB_CRED message, it verifies it. If
1895 any error occurs, an error code is reported for use by the
1896 application. The message is verified by checking that the protocol
1897 version and type fields match the current version and KRB_CRED,
1898 respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or
1899 KRB_AP_ERR_MSG_TYPE error. The application then decrypts the
1900 ciphertext and processes the resultant plaintext. If decryption shows
1901 the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is
1906 Kohl & Neuman [Page 34]
1908 RFC 1510 Kerberos September 1993
1911 If present or required, the recipient verifies that the operating
1912 system's report of the sender's address matches the sender's address
1913 in the message, and that one of the recipient's addresses appears as
1914 the recipient's address in the message. A failed match for either
1915 case generates a KRB_AP_ERR_BADADDR error. The timestamp and usec
1916 fields (and the nonce field if required) are checked next. If the
1917 timestamp and usec are not present, or they are present but not
1918 current, the KRB_AP_ERR_SKEW error is generated.
1920 If all the checks succeed, the application stores each of the new
1921 tickets in its ticket cache together with the session key and other
1922 information in the corresponding KrbCredInfo sequence from the
1923 encrypted part of the KRB_CRED message.
1925 4. The Kerberos Database
1927 The Kerberos server must have access to a database containing the
1928 principal identifiers and secret keys of principals to be
1929 authenticated (The implementation of the Kerberos server need not
1930 combine the database and the server on the same machine; it is
1931 feasible to store the principal database in, say, a network name
1932 service, as long as the entries stored therein are protected from
1933 disclosure to and modification by unauthorized parties. However, we
1934 recommend against such strategies, as they can make system management
1935 and threat analysis quite complex.).
1937 4.1. Database contents
1939 A database entry should contain at least the following fields:
1943 name Principal's identifier
1944 key Principal's secret key
1945 p_kvno Principal's key version
1946 max_life Maximum lifetime for Tickets
1947 max_renewable_life Maximum total lifetime for renewable
1950 The name field is an encoding of the principal's identifier. The key
1951 field contains an encryption key. This key is the principal's secret
1952 key. (The key can be encrypted before storage under a Kerberos
1953 "master key" to protect it in case the database is compromised but
1954 the master key is not. In that case, an extra field must be added to
1955 indicate the master key version used, see below.) The p_kvno field is
1956 the key version number of the principal's secret key. The max_life
1957 field contains the maximum allowable lifetime (endtime - starttime)
1958 for any Ticket issued for this principal. The max_renewable_life
1962 Kohl & Neuman [Page 35]
1964 RFC 1510 Kerberos September 1993
1967 field contains the maximum allowable total lifetime for any renewable
1968 Ticket issued for this principal. (See section 3.1 for a description
1969 of how these lifetimes are used in determining the lifetime of a
1972 A server may provide KDC service to several realms, as long as the
1973 database representation provides a mechanism to distinguish between
1974 principal records with identifiers which differ only in the realm
1977 When an application server's key changes, if the change is routine
1978 (i.e., not the result of disclosure of the old key), the old key
1979 should be retained by the server until all tickets that had been
1980 issued using that key have expired. Because of this, it is possible
1981 for several keys to be active for a single principal. Ciphertext
1982 encrypted in a principal's key is always tagged with the version of
1983 the key that was used for encryption, to help the recipient find the
1984 proper key for decryption.
1986 When more than one key is active for a particular principal, the
1987 principal will have more than one record in the Kerberos database.
1988 The keys and key version numbers will differ between the records (the
1989 rest of the fields may or may not be the same). Whenever Kerberos
1990 issues a ticket, or responds to a request for initial authentication,
1991 the most recent key (known by the Kerberos server) will be used for
1992 encryption. This is the key with the highest key version number.
1994 4.2. Additional fields
1996 Project Athena's KDC implementation uses additional fields in its
2001 K_kvno Kerberos' key version
2002 expiration Expiration date for entry
2003 attributes Bit field of attributes
2004 mod_date Timestamp of last modification
2005 mod_name Modifying principal's identifier
2007 The K_kvno field indicates the key version of the Kerberos master key
2008 under which the principal's secret key is encrypted.
2010 After an entry's expiration date has passed, the KDC will return an
2011 error to any client attempting to gain tickets as or for the
2012 principal. (A database may want to maintain two expiration dates:
2013 one for the principal, and one for the principal's current key. This
2014 allows password aging to work independently of the principal's
2018 Kohl & Neuman [Page 36]
2020 RFC 1510 Kerberos September 1993
2023 expiration date. However, due to the limited space in the responses,
2024 the KDC must combine the key expiration and principal expiration date
2025 into a single value called "key_exp", which is used as a hint to the
2026 user to take administrative action.)
2028 The attributes field is a bitfield used to govern the operations
2029 involving the principal. This field might be useful in conjunction
2030 with user registration procedures, for site-specific policy
2031 implementations (Project Athena currently uses it for their user
2032 registration process controlled by the system-wide database service,
2033 Moira [7]), or to identify the "string to key" conversion algorithm
2034 used for a principal's key. (See the discussion of the padata field
2035 in section 5.4.2 for details on why this can be useful.) Other bits
2036 are used to indicate that certain ticket options should not be
2037 allowed in tickets encrypted under a principal's key (one bit each):
2038 Disallow issuing postdated tickets, disallow issuing forwardable
2039 tickets, disallow issuing tickets based on TGT authentication,
2040 disallow issuing renewable tickets, disallow issuing proxiable
2041 tickets, and disallow issuing tickets for which the principal is the
2044 The mod_date field contains the time of last modification of the
2045 entry, and the mod_name field contains the name of the principal
2046 which last modified the entry.
2048 4.3. Frequently Changing Fields
2050 Some KDC implementations may wish to maintain the last time that a
2051 request was made by a particular principal. Information that might
2052 be maintained includes the time of the last request, the time of the
2053 last request for a ticket-granting ticket, the time of the last use
2054 of a ticket-granting ticket, or other times. This information can
2055 then be returned to the user in the last-req field (see section 5.2).
2057 Other frequently changing information that can be maintained is the
2058 latest expiration time for any tickets that have been issued using
2059 each key. This field would be used to indicate how long old keys
2060 must remain valid to allow the continued use of outstanding tickets.
2064 The KDC implementation should have the following configurable
2065 constants or options, to allow an administrator to make and enforce
2068 + The minimum supported lifetime (used to determine whether the
2069 KDC_ERR_NEVER_VALID error should be returned). This constant
2070 should reflect reasonable expectations of round-trip time to the
2074 Kohl & Neuman [Page 37]
2076 RFC 1510 Kerberos September 1993
2079 KDC, encryption/decryption time, and processing time by the client
2080 and target server, and it should allow for a minimum "useful"
2083 + The maximum allowable total (renewable) lifetime of a ticket
2084 (renew_till - starttime).
2086 + The maximum allowable lifetime of a ticket (endtime - starttime).
2088 + Whether to allow the issue of tickets with empty address fields
2089 (including the ability to specify that such tickets may only be
2090 issued if the request specifies some authorization_data).
2092 + Whether proxiable, forwardable, renewable or post-datable tickets
2095 5. Message Specifications
2097 The following sections describe the exact contents and encoding of
2098 protocol messages and objects. The ASN.1 base definitions are
2099 presented in the first subsection. The remaining subsections specify
2100 the protocol objects (tickets and authenticators) and messages.
2101 Specification of encryption and checksum techniques, and the fields
2102 related to them, appear in section 6.
2104 5.1. ASN.1 Distinguished Encoding Representation
2106 All uses of ASN.1 in Kerberos shall use the Distinguished Encoding
2107 Representation of the data elements as described in the X.509
2108 specification, section 8.7 [8].
2110 5.2. ASN.1 Base Definitions
2112 The following ASN.1 base definitions are used in the rest of this
2113 section. Note that since the underscore character (_) is not
2114 permitted in ASN.1 names, the hyphen (-) is used in its place for the
2115 purposes of ASN.1 names.
2117 Realm ::= GeneralString
2118 PrincipalName ::= SEQUENCE {
2119 name-type[0] INTEGER,
2120 name-string[1] SEQUENCE OF GeneralString
2123 Kerberos realms are encoded as GeneralStrings. Realms shall not
2124 contain a character with the code 0 (the ASCII NUL). Most realms
2125 will usually consist of several components separated by periods (.),
2126 in the style of Internet Domain Names, or separated by slashes (/) in
2130 Kohl & Neuman [Page 38]
2132 RFC 1510 Kerberos September 1993
2135 the style of X.500 names. Acceptable forms for realm names are
2136 specified in section 7. A PrincipalName is a typed sequence of
2137 components consisting of the following sub-fields:
2139 name-type This field specifies the type of name that follows.
2140 Pre-defined values for this field are
2141 specified in section 7.2. The name-type should be
2142 treated as a hint. Ignoring the name type, no two
2143 names can be the same (i.e., at least one of the
2144 components, or the realm, must be different).
2145 This constraint may be eliminated in the future.
2147 name-string This field encodes a sequence of components that
2148 form a name, each component encoded as a General
2149 String. Taken together, a PrincipalName and a Realm
2150 form a principal identifier. Most PrincipalNames
2151 will have only a few components (typically one or two).
2153 KerberosTime ::= GeneralizedTime
2154 -- Specifying UTC time zone (Z)
2156 The timestamps used in Kerberos are encoded as GeneralizedTimes. An
2157 encoding shall specify the UTC time zone (Z) and shall not include
2158 any fractional portions of the seconds. It further shall not include
2159 any separators. Example: The only valid format for UTC time 6
2160 minutes, 27 seconds after 9 pm on 6 November 1985 is 19851106210627Z.
2162 HostAddress ::= SEQUENCE {
2163 addr-type[0] INTEGER,
2164 address[1] OCTET STRING
2167 HostAddresses ::= SEQUENCE OF SEQUENCE {
2168 addr-type[0] INTEGER,
2169 address[1] OCTET STRING
2173 The host adddress encodings consists of two fields:
2175 addr-type This field specifies the type of address that
2176 follows. Pre-defined values for this field are
2177 specified in section 8.1.
2180 address This field encodes a single address of type addr-type.
2182 The two forms differ slightly. HostAddress contains exactly one
2186 Kohl & Neuman [Page 39]
2188 RFC 1510 Kerberos September 1993
2191 address; HostAddresses contains a sequence of possibly many
2194 AuthorizationData ::= SEQUENCE OF SEQUENCE {
2196 ad-data[1] OCTET STRING
2200 ad-data This field contains authorization data to be
2201 interpreted according to the value of the
2202 corresponding ad-type field.
2204 ad-type This field specifies the format for the ad-data
2205 subfield. All negative values are reserved for
2206 local use. Non-negative values are reserved for
2209 APOptions ::= BIT STRING {
2216 TicketFlags ::= BIT STRING {
2231 KDCOptions ::= BIT STRING {
2242 Kohl & Neuman [Page 40]
2244 RFC 1510 Kerberos September 1993
2253 enc-tkt-in-skey(28),
2259 LastReq ::= SEQUENCE OF SEQUENCE {
2261 lr-value[1] KerberosTime
2264 lr-type This field indicates how the following lr-value
2265 field is to be interpreted. Negative values indicate
2266 that the information pertains only to the
2267 responding server. Non-negative values pertain to
2268 all servers for the realm.
2270 If the lr-type field is zero (0), then no information
2271 is conveyed by the lr-value subfield. If the
2272 absolute value of the lr-type field is one (1),
2273 then the lr-value subfield is the time of last
2274 initial request for a TGT. If it is two (2), then
2275 the lr-value subfield is the time of last initial
2276 request. If it is three (3), then the lr-value
2277 subfield is the time of issue for the newest
2278 ticket-granting ticket used. If it is four (4),
2279 then the lr-value subfield is the time of the last
2280 renewal. If it is five (5), then the lr-value
2281 subfield is the time of last request (of any
2284 lr-value This field contains the time of the last request.
2285 The time must be interpreted according to the contents
2286 of the accompanying lr-type subfield.
2288 See section 6 for the definitions of Checksum, ChecksumType,
2289 EncryptedData, EncryptionKey, EncryptionType, and KeyType.
2298 Kohl & Neuman [Page 41]
2300 RFC 1510 Kerberos September 1993
2303 5.3. Tickets and Authenticators
2305 This section describes the format and encryption parameters for
2306 tickets and authenticators. When a ticket or authenticator is
2307 included in a protocol message it is treated as an opaque object.
2311 A ticket is a record that helps a client authenticate to a service.
2312 A Ticket contains the following information:
2314 Ticket ::= [APPLICATION 1] SEQUENCE {
2317 sname[2] PrincipalName,
2318 enc-part[3] EncryptedData
2320 -- Encrypted part of ticket
2321 EncTicketPart ::= [APPLICATION 3] SEQUENCE {
2322 flags[0] TicketFlags,
2323 key[1] EncryptionKey,
2325 cname[3] PrincipalName,
2326 transited[4] TransitedEncoding,
2327 authtime[5] KerberosTime,
2328 starttime[6] KerberosTime OPTIONAL,
2329 endtime[7] KerberosTime,
2330 renew-till[8] KerberosTime OPTIONAL,
2331 caddr[9] HostAddresses OPTIONAL,
2332 authorization-data[10] AuthorizationData OPTIONAL
2334 -- encoded Transited field
2335 TransitedEncoding ::= SEQUENCE {
2336 tr-type[0] INTEGER, -- must be registered
2337 contents[1] OCTET STRING
2340 The encoding of EncTicketPart is encrypted in the key shared by
2341 Kerberos and the end server (the server's secret key). See section 6
2342 for the format of the ciphertext.
2344 tkt-vno This field specifies the version number for the ticket
2345 format. This document describes version number 5.
2347 realm This field specifies the realm that issued a ticket. It
2348 also serves to identify the realm part of the server's
2349 principal identifier. Since a Kerberos server can only
2350 issue tickets for servers within its realm, the two will
2354 Kohl & Neuman [Page 42]
2356 RFC 1510 Kerberos September 1993
2359 always be identical.
2361 sname This field specifies the name part of the server's
2364 enc-part This field holds the encrypted encoding of the
2365 EncTicketPart sequence.
2367 flags This field indicates which of various options were used or
2368 requested when the ticket was issued. It is a bit-field,
2369 where the selected options are indicated by the bit being
2370 set (1), and the unselected options and reserved fields
2371 being reset (0). Bit 0 is the most significant bit. The
2372 encoding of the bits is specified in section 5.2. The
2373 flags are described in more detail above in section 2. The
2374 meanings of the flags are:
2376 Bit(s) Name Description
2378 0 RESERVED Reserved for future expansion of this
2381 1 FORWARDABLE The FORWARDABLE flag is normally only
2382 interpreted by the TGS, and can be
2383 ignored by end servers. When set,
2384 this flag tells the ticket-granting
2385 server that it is OK to issue a new
2386 ticket- granting ticket with a
2387 different network address based on
2388 the presented ticket.
2390 2 FORWARDED When set, this flag indicates that
2391 the ticket has either been forwarded
2392 or was issued based on authentication
2393 involving a forwarded ticket-granting
2396 3 PROXIABLE The PROXIABLE flag is normally only
2397 interpreted by the TGS, and can be
2398 ignored by end servers. The PROXIABLE
2399 flag has an interpretation identical
2400 to that of the FORWARDABLE flag,
2401 except that the PROXIABLE flag tells
2402 the ticket-granting server that only
2403 non- ticket-granting tickets may be
2404 issued with different network
2410 Kohl & Neuman [Page 43]
2412 RFC 1510 Kerberos September 1993
2415 4 PROXY When set, this flag indicates that a
2418 5 MAY-POSTDATE The MAY-POSTDATE flag is normally
2419 only interpreted by the TGS, and can
2420 be ignored by end servers. This flag
2421 tells the ticket-granting server that
2422 a post- dated ticket may be issued
2423 based on this ticket-granting ticket.
2425 6 POSTDATED This flag indicates that this ticket
2426 has been postdated. The end-service
2427 can check the authtime field to see
2428 when the original authentication
2431 7 INVALID This flag indicates that a ticket is
2432 invalid, and it must be validated by
2433 the KDC before use. Application
2434 servers must reject tickets which
2437 8 RENEWABLE The RENEWABLE flag is normally only
2438 interpreted by the TGS, and can
2439 usually be ignored by end servers
2440 (some particularly careful servers
2441 may wish to disallow renewable
2442 tickets). A renewable ticket can be
2443 used to obtain a replacement ticket
2444 that expires at a later date.
2446 9 INITIAL This flag indicates that this ticket
2447 was issued using the AS protocol, and
2448 not issued based on a ticket-granting
2451 10 PRE-AUTHENT This flag indicates that during
2452 initial authentication, the client
2453 was authenticated by the KDC before a
2454 ticket was issued. The strength of
2455 the preauthentication method is not
2456 indicated, but is acceptable to the
2459 11 HW-AUTHENT This flag indicates that the protocol
2460 employed for initial authentication
2461 required the use of hardware expected
2462 to be possessed solely by the named
2466 Kohl & Neuman [Page 44]
2468 RFC 1510 Kerberos September 1993
2471 client. The hardware authentication
2472 method is selected by the KDC and the
2473 strength of the method is not
2476 12-31 RESERVED Reserved for future use.
2478 key This field exists in the ticket and the KDC response and is
2479 used to pass the session key from Kerberos to the
2480 application server and the client. The field's encoding is
2481 described in section 6.2.
2483 crealm This field contains the name of the realm in which the
2484 client is registered and in which initial authentication
2487 cname This field contains the name part of the client's principal
2490 transited This field lists the names of the Kerberos realms that took
2491 part in authenticating the user to whom this ticket was
2492 issued. It does not specify the order in which the realms
2493 were transited. See section 3.3.3.1 for details on how
2494 this field encodes the traversed realms.
2496 authtime This field indicates the time of initial authentication for
2497 the named principal. It is the time of issue for the
2498 original ticket on which this ticket is based. It is
2499 included in the ticket to provide additional information to
2500 the end service, and to provide the necessary information
2501 for implementation of a `hot list' service at the KDC. An
2502 end service that is particularly paranoid could refuse to
2503 accept tickets for which the initial authentication
2504 occurred "too far" in the past.
2506 This field is also returned as part of the response from
2507 the KDC. When returned as part of the response to initial
2508 authentication (KRB_AS_REP), this is the current time on
2509 the Kerberos server (It is NOT recommended that this time
2510 value be used to adjust the workstation's clock since the
2511 workstation cannot reliably determine that such a
2512 KRB_AS_REP actually came from the proper KDC in a timely
2515 starttime This field in the ticket specifies the time after which the
2516 ticket is valid. Together with endtime, this field
2517 specifies the life of the ticket. If it is absent from
2518 the ticket, its value should be treated as that of the
2522 Kohl & Neuman [Page 45]
2524 RFC 1510 Kerberos September 1993
2529 endtime This field contains the time after which the ticket will
2530 not be honored (its expiration time). Note that individual
2531 services may place their own limits on the life of a ticket
2532 and may reject tickets which have not yet expired. As
2533 such, this is really an upper bound on the expiration time
2536 renew-till This field is only present in tickets that have the
2537 RENEWABLE flag set in the flags field. It indicates the
2538 maximum endtime that may be included in a renewal. It can
2539 be thought of as the absolute expiration time for the
2540 ticket, including all renewals.
2542 caddr This field in a ticket contains zero (if omitted) or more
2543 (if present) host addresses. These are the addresses from
2544 which the ticket can be used. If there are no addresses,
2545 the ticket can be used from any location. The decision
2546 by the KDC to issue or by the end server to accept zero-
2547 address tickets is a policy decision and is left to the
2548 Kerberos and end-service administrators; they may refuse to
2549 issue or accept such tickets. The suggested and default
2550 policy, however, is that such tickets will only be issued
2551 or accepted when additional information that can be used to
2552 restrict the use of the ticket is included in the
2553 authorization_data field. Such a ticket is a capability.
2555 Network addresses are included in the ticket to make it
2556 harder for an attacker to use stolen credentials. Because
2557 the session key is not sent over the network in cleartext,
2558 credentials can't be stolen simply by listening to the
2559 network; an attacker has to gain access to the session key
2560 (perhaps through operating system security breaches or a
2561 careless user's unattended session) to make use of stolen
2564 It is important to note that the network address from which
2565 a connection is received cannot be reliably determined.
2566 Even if it could be, an attacker who has compromised the
2567 client's workstation could use the credentials from there.
2568 Including the network addresses only makes it more
2569 difficult, not impossible, for an attacker to walk off with
2570 stolen credentials and then use them from a "safe"
2578 Kohl & Neuman [Page 46]
2580 RFC 1510 Kerberos September 1993
2583 authorization-data The authorization-data field is used to pass
2584 authorization data from the principal on whose behalf a
2585 ticket was issued to the application service. If no
2586 authorization data is included, this field will be left
2587 out. The data in this field are specific to the end
2588 service. It is expected that the field will contain the
2589 names of service specific objects, and the rights to those
2590 objects. The format for this field is described in section
2591 5.2. Although Kerberos is not concerned with the format of
2592 the contents of the subfields, it does carry type
2593 information (ad-type).
2595 By using the authorization_data field, a principal is able
2596 to issue a proxy that is valid for a specific purpose. For
2597 example, a client wishing to print a file can obtain a file
2598 server proxy to be passed to the print server. By
2599 specifying the name of the file in the authorization_data
2600 field, the file server knows that the print server can only
2601 use the client's rights when accessing the particular file
2604 It is interesting to note that if one specifies the
2605 authorization-data field of a proxy and leaves the host
2606 addresses blank, the resulting ticket and session key can
2607 be treated as a capability. See [9] for some suggested
2610 The authorization-data field is optional and does not have
2611 to be included in a ticket.
2613 5.3.2. Authenticators
2615 An authenticator is a record sent with a ticket to a server to
2616 certify the client's knowledge of the encryption key in the ticket,
2617 to help the server detect replays, and to help choose a "true session
2618 key" to use with the particular session. The encoding is encrypted
2619 in the ticket's session key shared by the client and the server:
2621 -- Unencrypted authenticator
2622 Authenticator ::= [APPLICATION 2] SEQUENCE {
2623 authenticator-vno[0] INTEGER,
2625 cname[2] PrincipalName,
2626 cksum[3] Checksum OPTIONAL,
2628 ctime[5] KerberosTime,
2629 subkey[6] EncryptionKey OPTIONAL,
2630 seq-number[7] INTEGER OPTIONAL,
2634 Kohl & Neuman [Page 47]
2636 RFC 1510 Kerberos September 1993
2639 authorization-data[8] AuthorizationData OPTIONAL
2642 authenticator-vno This field specifies the version number for the
2643 format of the authenticator. This document specifies
2646 crealm and cname These fields are the same as those described for the
2647 ticket in section 5.3.1.
2649 cksum This field contains a checksum of the the application data
2650 that accompanies the KRB_AP_REQ.
2652 cusec This field contains the microsecond part of the client's
2653 timestamp. Its value (before encryption) ranges from 0 to
2654 999999. It often appears along with ctime. The two fields
2655 are used together to specify a reasonably accurate
2658 ctime This field contains the current time on the client's host.
2660 subkey This field contains the client's choice for an encryption
2661 key which is to be used to protect this specific
2662 application session. Unless an application specifies
2663 otherwise, if this field is left out the session key from
2664 the ticket will be used.
2666 seq-number This optional field includes the initial sequence number
2667 to be used by the KRB_PRIV or KRB_SAFE messages when
2668 sequence numbers are used to detect replays (It may also be
2669 used by application specific messages). When included in
2670 the authenticator this field specifies the initial sequence
2671 number for messages from the client to the server. When
2672 included in the AP-REP message, the initial sequence number
2673 is that for messages from the server to the client. When
2674 used in KRB_PRIV or KRB_SAFE messages, it is incremented by
2675 one after each message is sent.
2677 For sequence numbers to adequately support the detection of
2678 replays they should be non-repeating, even across
2679 connection boundaries. The initial sequence number should
2680 be random and uniformly distributed across the full space
2681 of possible sequence numbers, so that it cannot be guessed
2682 by an attacker and so that it and the successive sequence
2683 numbers do not repeat other sequences.
2690 Kohl & Neuman [Page 48]
2692 RFC 1510 Kerberos September 1993
2695 authorization-data This field is the same as described for the ticket
2696 in section 5.3.1. It is optional and will only appear when
2697 additional restrictions are to be placed on the use of a
2698 ticket, beyond those carried in the ticket itself.
2700 5.4. Specifications for the AS and TGS exchanges
2702 This section specifies the format of the messages used in exchange
2703 between the client and the Kerberos server. The format of possible
2704 error messages appears in section 5.9.1.
2706 5.4.1. KRB_KDC_REQ definition
2708 The KRB_KDC_REQ message has no type of its own. Instead, its type is
2709 one of KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is
2710 for an initial ticket or an additional ticket. In either case, the
2711 message is sent from the client to the Authentication Server to
2712 request credentials for a service.
2714 The message fields are:
2716 AS-REQ ::= [APPLICATION 10] KDC-REQ
2717 TGS-REQ ::= [APPLICATION 12] KDC-REQ
2719 KDC-REQ ::= SEQUENCE {
2721 msg-type[2] INTEGER,
2722 padata[3] SEQUENCE OF PA-DATA OPTIONAL,
2723 req-body[4] KDC-REQ-BODY
2726 PA-DATA ::= SEQUENCE {
2727 padata-type[1] INTEGER,
2728 padata-value[2] OCTET STRING,
2729 -- might be encoded AP-REQ
2732 KDC-REQ-BODY ::= SEQUENCE {
2733 kdc-options[0] KDCOptions,
2734 cname[1] PrincipalName OPTIONAL,
2735 -- Used only in AS-REQ
2736 realm[2] Realm, -- Server's realm
2737 -- Also client's in AS-REQ
2738 sname[3] PrincipalName OPTIONAL,
2739 from[4] KerberosTime OPTIONAL,
2740 till[5] KerberosTime,
2741 rtime[6] KerberosTime OPTIONAL,
2746 Kohl & Neuman [Page 49]
2748 RFC 1510 Kerberos September 1993
2751 etype[8] SEQUENCE OF INTEGER, -- EncryptionType,
2752 -- in preference order
2753 addresses[9] HostAddresses OPTIONAL,
2754 enc-authorization-data[10] EncryptedData OPTIONAL,
2755 -- Encrypted AuthorizationData encoding
2756 additional-tickets[11] SEQUENCE OF Ticket OPTIONAL
2759 The fields in this message are:
2761 pvno This field is included in each message, and specifies the
2762 protocol version number. This document specifies protocol
2765 msg-type This field indicates the type of a protocol message. It
2766 will almost always be the same as the application
2767 identifier associated with a message. It is included to
2768 make the identifier more readily accessible to the
2769 application. For the KDC-REQ message, this type will be
2770 KRB_AS_REQ or KRB_TGS_REQ.
2772 padata The padata (pre-authentication data) field contains a of
2773 authentication information which may be needed before
2774 credentials can be issued or decrypted. In the case of
2775 requests for additional tickets (KRB_TGS_REQ), this field
2776 will include an element with padata-type of PA-TGS-REQ and
2777 data of an authentication header (ticket-granting ticket
2778 and authenticator). The checksum in the authenticator
2779 (which must be collisionproof) is to be computed over the
2780 KDC-REQ-BODY encoding. In most requests for initial
2781 authentication (KRB_AS_REQ) and most replies (KDC-REP), the
2782 padata field will be left out.
2784 This field may also contain information needed by certain
2785 extensions to the Kerberos protocol. For example, it might
2786 be used to initially verify the identity of a client before
2787 any response is returned. This is accomplished with a
2788 padata field with padata-type equal to PA-ENC-TIMESTAMP and
2789 padata-value defined as follows:
2791 padata-type ::= PA-ENC-TIMESTAMP
2792 padata-value ::= EncryptedData -- PA-ENC-TS-ENC
2794 PA-ENC-TS-ENC ::= SEQUENCE {
2795 patimestamp[0] KerberosTime, -- client's time
2796 pausec[1] INTEGER OPTIONAL
2802 Kohl & Neuman [Page 50]
2804 RFC 1510 Kerberos September 1993
2807 with patimestamp containing the client's time and pausec
2808 containing the microseconds which may be omitted if a
2809 client will not generate more than one request per second.
2810 The ciphertext (padata-value) consists of the PA-ENC-TS-ENC
2811 sequence, encrypted using the client's secret key.
2813 The padata field can also contain information needed to
2814 help the KDC or the client select the key needed for
2815 generating or decrypting the response. This form of the
2816 padata is useful for supporting the use of certain
2817 "smartcards" with Kerberos. The details of such extensions
2818 are beyond the scope of this specification. See [10] for
2819 additional uses of this field.
2821 padata-type The padata-type element of the padata field indicates the
2822 way that the padata-value element is to be interpreted.
2823 Negative values of padata-type are reserved for
2824 unregistered use; non-negative values are used for a
2825 registered interpretation of the element type.
2827 req-body This field is a placeholder delimiting the extent of the
2828 remaining fields. If a checksum is to be calculated over
2829 the request, it is calculated over an encoding of the KDC-
2830 REQ-BODY sequence which is enclosed within the req-body
2833 kdc-options This field appears in the KRB_AS_REQ and KRB_TGS_REQ
2834 requests to the KDC and indicates the flags that the client
2835 wants set on the tickets as well as other information that
2836 is to modify the behavior of the KDC. Where appropriate,
2837 the name of an option may be the same as the flag that is
2838 set by that option. Although in most case, the bit in the
2839 options field will be the same as that in the flags field,
2840 this is not guaranteed, so it is not acceptable to simply
2841 copy the options field to the flags field. There are
2842 various checks that must be made before honoring an option
2845 The kdc_options field is a bit-field, where the selected
2846 options are indicated by the bit being set (1), and the
2847 unselected options and reserved fields being reset (0).
2848 The encoding of the bits is specified in section 5.2. The
2849 options are described in more detail above in section 2.
2850 The meanings of the options are:
2858 Kohl & Neuman [Page 51]
2860 RFC 1510 Kerberos September 1993
2863 Bit(s) Name Description
2865 0 RESERVED Reserved for future expansion of this
2868 1 FORWARDABLE The FORWARDABLE option indicates that
2869 the ticket to be issued is to have its
2870 forwardable flag set. It may only be
2871 set on the initial request, or in a
2872 subsequent request if the ticket-
2873 granting ticket on which it is based
2874 is also forwardable.
2876 2 FORWARDED The FORWARDED option is only specified
2877 in a request to the ticket-granting
2878 server and will only be honored if the
2879 ticket-granting ticket in the request
2880 has its FORWARDABLE bit set. This
2881 option indicates that this is a
2882 request for forwarding. The
2883 address(es) of the host from which the
2884 resulting ticket is to be valid are
2885 included in the addresses field of the
2889 3 PROXIABLE The PROXIABLE option indicates that
2890 the ticket to be issued is to have its
2891 proxiable flag set. It may only be set
2892 on the initial request, or in a
2893 subsequent request if the ticket-
2894 granting ticket on which it is based
2897 4 PROXY The PROXY option indicates that this
2898 is a request for a proxy. This option
2899 will only be honored if the ticket-
2900 granting ticket in the request has its
2901 PROXIABLE bit set. The address(es) of
2902 the host from which the resulting
2903 ticket is to be valid are included in
2904 the addresses field of the request.
2906 5 ALLOW-POSTDATE The ALLOW-POSTDATE option indicates
2907 that the ticket to be issued is to
2908 have its MAY-POSTDATE flag set. It
2909 may only be set on the initial
2910 request, or in a subsequent request if
2914 Kohl & Neuman [Page 52]
2916 RFC 1510 Kerberos September 1993
2919 the ticket-granting ticket on which it
2920 is based also has its MAY-POSTDATE
2923 6 POSTDATED The POSTDATED option indicates that
2924 this is a request for a postdated
2925 ticket. This option will only be
2926 honored if the ticket-granting ticket
2927 on which it is based has its MAY-
2928 POSTDATE flag set. The resulting
2929 ticket will also have its INVALID flag
2930 set, and that flag may be reset by a
2931 subsequent request to the KDC after
2932 the starttime in the ticket has been
2935 7 UNUSED This option is presently unused.
2937 8 RENEWABLE The RENEWABLE option indicates that
2938 the ticket to be issued is to have its
2939 RENEWABLE flag set. It may only be
2940 set on the initial request, or when
2941 the ticket-granting ticket on which
2942 the request is based is also
2943 renewable. If this option is
2944 requested, then the rtime field in the
2945 request contains the desired absolute
2946 expiration time for the ticket.
2948 9-26 RESERVED Reserved for future use.
2950 27 RENEWABLE-OK The RENEWABLE-OK option indicates that
2951 a renewable ticket will be acceptable
2952 if a ticket with the requested life
2953 cannot otherwise be provided. If a
2954 ticket with the requested life cannot
2955 be provided, then a renewable ticket
2956 may be issued with a renew-till equal
2957 to the the requested endtime. The
2958 value of the renew-till field may
2959 still be limited by local limits, or
2960 limits selected by the individual
2961 principal or server.
2963 28 ENC-TKT-IN-SKEY This option is used only by the
2964 ticket-granting service. The ENC-
2965 TKT-IN-SKEY option indicates that the
2966 ticket for the end server is to be
2970 Kohl & Neuman [Page 53]
2972 RFC 1510 Kerberos September 1993
2975 encrypted in the session key from the
2976 additional ticket-granting ticket
2979 29 RESERVED Reserved for future use.
2981 30 RENEW This option is used only by the
2982 ticket-granting service. The RENEW
2983 option indicates that the present
2984 request is for a renewal. The ticket
2985 provided is encrypted in the secret
2986 key for the server on which it is
2987 valid. This option will only be
2988 honored if the ticket to be renewed
2989 has its RENEWABLE flag set and if the
2990 time in its renew till field has not
2991 passed. The ticket to be renewed is
2992 passed in the padata field as part of
2993 the authentication header.
2995 31 VALIDATE This option is used only by the
2996 ticket-granting service. The VALIDATE
2997 option indicates that the request is
2998 to validate a postdated ticket. It
2999 will only be honored if the ticket
3000 presented is postdated, presently has
3001 its INVALID flag set, and would be
3002 otherwise usable at this time. A
3003 ticket cannot be validated before its
3004 starttime. The ticket presented for
3005 validation is encrypted in the key of
3006 the server for which it is valid and
3007 is passed in the padata field as part
3008 of the authentication header.
3010 cname and sname These fields are the same as those described for the
3011 ticket in section 5.3.1. sname may only be absent when the
3012 ENC-TKT-IN-SKEY option is specified. If absent, the name
3013 of the server is taken from the name of the client in the
3014 ticket passed as additional-tickets.
3016 enc-authorization-data The enc-authorization-data, if present (and it
3017 can only be present in the TGS_REQ form), is an encoding of
3018 the desired authorization-data encrypted under the sub-
3019 session key if present in the Authenticator, or
3020 alternatively from the session key in the ticket-granting
3021 ticket, both from the padata field in the KRB_AP_REQ.
3026 Kohl & Neuman [Page 54]
3028 RFC 1510 Kerberos September 1993
3031 realm This field specifies the realm part of the server's
3032 principal identifier. In the AS exchange, this is also the
3033 realm part of the client's principal identifier.
3035 from This field is included in the KRB_AS_REQ and KRB_TGS_REQ
3036 ticket requests when the requested ticket is to be
3037 postdated. It specifies the desired start time for the
3040 till This field contains the expiration date requested by the
3041 client in a ticket request.
3043 rtime This field is the requested renew-till time sent from a
3044 client to the KDC in a ticket request. It is optional.
3046 nonce This field is part of the KDC request and response. It it
3047 intended to hold a random number generated by the client.
3048 If the same number is included in the encrypted response
3049 from the KDC, it provides evidence that the response is
3050 fresh and has not been replayed by an attacker. Nonces
3051 must never be re-used. Ideally, it should be gen erated
3052 randomly, but if the correct time is known, it may suffice
3053 (Note, however, that if the time is used as the nonce, one
3054 must make sure that the workstation time is monotonically
3055 increasing. If the time is ever reset backwards, there is
3056 a small, but finite, probability that a nonce will be
3059 etype This field specifies the desired encryption algorithm to be
3060 used in the response.
3062 addresses This field is included in the initial request for tickets,
3063 and optionally included in requests for additional tickets
3064 from the ticket-granting server. It specifies the
3065 addresses from which the requested ticket is to be valid.
3066 Normally it includes the addresses for the client's host.
3067 If a proxy is requested, this field will contain other
3068 addresses. The contents of this field are usually copied
3069 by the KDC into the caddr field of the resulting ticket.
3071 additional-tickets Additional tickets may be optionally included in a
3072 request to the ticket-granting server. If the ENC-TKT-IN-
3073 SKEY option has been specified, then the session key from
3074 the additional ticket will be used in place of the server's
3075 key to encrypt the new ticket. If more than one option
3076 which requires additional tickets has been specified, then
3077 the additional tickets are used in the order specified by
3078 the ordering of the options bits (see kdc-options, above).
3082 Kohl & Neuman [Page 55]
3084 RFC 1510 Kerberos September 1993
3087 The application code will be either ten (10) or twelve (12) depending
3088 on whether the request is for an initial ticket (AS-REQ) or for an
3089 additional ticket (TGS-REQ).
3091 The optional fields (addresses, authorization-data and additional-
3092 tickets) are only included if necessary to perform the operation
3093 specified in the kdc-options field.
3095 It should be noted that in KRB_TGS_REQ, the protocol version number
3096 appears twice and two different message types appear: the KRB_TGS_REQ
3097 message contains these fields as does the authentication header
3098 (KRB_AP_REQ) that is passed in the padata field.
3100 5.4.2. KRB_KDC_REP definition
3102 The KRB_KDC_REP message format is used for the reply from the KDC for
3103 either an initial (AS) request or a subsequent (TGS) request. There
3104 is no message type for KRB_KDC_REP. Instead, the type will be either
3105 KRB_AS_REP or KRB_TGS_REP. The key used to encrypt the ciphertext
3106 part of the reply depends on the message type. For KRB_AS_REP, the
3107 ciphertext is encrypted in the client's secret key, and the client's
3108 key version number is included in the key version number for the
3109 encrypted data. For KRB_TGS_REP, the ciphertext is encrypted in the
3110 sub-session key from the Authenticator, or if absent, the session key
3111 from the ticket-granting ticket used in the request. In that case,
3112 no version number will be present in the EncryptedData sequence.
3114 The KRB_KDC_REP message contains the following fields:
3116 AS-REP ::= [APPLICATION 11] KDC-REP
3117 TGS-REP ::= [APPLICATION 13] KDC-REP
3119 KDC-REP ::= SEQUENCE {
3121 msg-type[1] INTEGER,
3122 padata[2] SEQUENCE OF PA-DATA OPTIONAL,
3124 cname[4] PrincipalName,
3126 enc-part[6] EncryptedData
3129 EncASRepPart ::= [APPLICATION 25[25]] EncKDCRepPart
3130 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart
3132 EncKDCRepPart ::= SEQUENCE {
3133 key[0] EncryptionKey,
3134 last-req[1] LastReq,
3138 Kohl & Neuman [Page 56]
3140 RFC 1510 Kerberos September 1993
3144 key-expiration[3] KerberosTime OPTIONAL,
3145 flags[4] TicketFlags,
3146 authtime[5] KerberosTime,
3147 starttime[6] KerberosTime OPTIONAL,
3148 endtime[7] KerberosTime,
3149 renew-till[8] KerberosTime OPTIONAL,
3151 sname[10] PrincipalName,
3152 caddr[11] HostAddresses OPTIONAL
3155 NOTE: In EncASRepPart, the application code in the encrypted
3156 part of a message provides an additional check that
3157 the message was decrypted properly.
3159 pvno and msg-type These fields are described above in section 5.4.1.
3160 msg-type is either KRB_AS_REP or KRB_TGS_REP.
3162 padata This field is described in detail in section 5.4.1. One
3163 possible use for this field is to encode an alternate
3164 "mix-in" string to be used with a string-to-key algorithm
3165 (such as is described in section 6.3.2). This ability is
3166 useful to ease transitions if a realm name needs to change
3167 (e.g., when a company is acquired); in such a case all
3168 existing password-derived entries in the KDC database would
3169 be flagged as needing a special mix-in string until the
3170 next password change.
3172 crealm, cname, srealm and sname These fields are the same as those
3173 described for the ticket in section 5.3.1.
3175 ticket The newly-issued ticket, from section 5.3.1.
3177 enc-part This field is a place holder for the ciphertext and related
3178 information that forms the encrypted part of a message.
3179 The description of the encrypted part of the message
3180 follows each appearance of this field. The encrypted part
3181 is encoded as described in section 6.1.
3183 key This field is the same as described for the ticket in
3186 last-req This field is returned by the KDC and specifies the time(s)
3187 of the last request by a principal. Depending on what
3188 information is available, this might be the last time that
3189 a request for a ticket-granting ticket was made, or the
3190 last time that a request based on a ticket-granting ticket
3194 Kohl & Neuman [Page 57]
3196 RFC 1510 Kerberos September 1993
3199 was successful. It also might cover all servers for a
3200 realm, or just the particular server. Some implementations
3201 may display this information to the user to aid in
3202 discovering unauthorized use of one's identity. It is
3203 similar in spirit to the last login time displayed when
3204 logging into timesharing systems.
3206 nonce This field is described above in section 5.4.1.
3208 key-expiration The key-expiration field is part of the response from
3209 the KDC and specifies the time that the client's secret key
3210 is due to expire. The expiration might be the result of
3211 password aging or an account expiration. This field will
3212 usually be left out of the TGS reply since the response to
3213 the TGS request is encrypted in a session key and no client
3214 information need be retrieved from the KDC database. It is
3215 up to the application client (usually the login program) to
3216 take appropriate action (such as notifying the user) if the
3217 expira tion time is imminent.
3219 flags, authtime, starttime, endtime, renew-till and caddr These
3220 fields are duplicates of those found in the encrypted
3221 portion of the attached ticket (see section 5.3.1),
3222 provided so the client may verify they match the intended
3223 request and to assist in proper ticket caching. If the
3224 message is of type KRB_TGS_REP, the caddr field will only
3225 be filled in if the request was for a proxy or forwarded
3226 ticket, or if the user is substituting a subset of the
3227 addresses from the ticket granting ticket. If the client-
3228 requested addresses are not present or not used, then the
3229 addresses contained in the ticket will be the same as those
3230 included in the ticket-granting ticket.
3232 5.5. Client/Server (CS) message specifications
3234 This section specifies the format of the messages used for the
3235 authentication of the client to the application server.
3237 5.5.1. KRB_AP_REQ definition
3239 The KRB_AP_REQ message contains the Kerberos protocol version number,
3240 the message type KRB_AP_REQ, an options field to indicate any options
3241 in use, and the ticket and authenticator themselves. The KRB_AP_REQ
3242 message is often referred to as the "authentication header".
3244 AP-REQ ::= [APPLICATION 14] SEQUENCE {
3246 msg-type[1] INTEGER,
3250 Kohl & Neuman [Page 58]
3252 RFC 1510 Kerberos September 1993
3255 ap-options[2] APOptions,
3257 authenticator[4] EncryptedData
3260 APOptions ::= BIT STRING {
3266 pvno and msg-type These fields are described above in section 5.4.1.
3267 msg-type is KRB_AP_REQ.
3269 ap-options This field appears in the application request (KRB_AP_REQ)
3270 and affects the way the request is processed. It is a
3271 bit-field, where the selected options are indicated by the
3272 bit being set (1), and the unselected options and reserved
3273 fields being reset (0). The encoding of the bits is
3274 specified in section 5.2. The meanings of the options are:
3276 Bit(s) Name Description
3278 0 RESERVED Reserved for future expansion of
3281 1 USE-SESSION-KEYThe USE-SESSION-KEY option indicates
3282 that the ticket the client is
3283 presenting to a server is encrypted in
3284 the session key from the server's
3285 ticket-granting ticket. When this
3286 option is not specified, the ticket is
3287 encrypted in the server's secret key.
3289 2 MUTUAL-REQUIREDThe MUTUAL-REQUIRED option tells the
3290 server that the client requires mutual
3291 authentication, and that it must
3292 respond with a KRB_AP_REP message.
3294 3-31 RESERVED Reserved for future use.
3296 ticket This field is a ticket authenticating the client to the
3299 authenticator This contains the authenticator, which includes the
3300 client's choice of a subkey. Its encoding is described in
3306 Kohl & Neuman [Page 59]
3308 RFC 1510 Kerberos September 1993
3311 5.5.2. KRB_AP_REP definition
3313 The KRB_AP_REP message contains the Kerberos protocol version number,
3314 the message type, and an encrypted timestamp. The message is sent in
3315 in response to an application request (KRB_AP_REQ) where the mutual
3316 authentication option has been selected in the ap-options field.
3318 AP-REP ::= [APPLICATION 15] SEQUENCE {
3320 msg-type[1] INTEGER,
3321 enc-part[2] EncryptedData
3324 EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
3325 ctime[0] KerberosTime,
3327 subkey[2] EncryptionKey OPTIONAL,
3328 seq-number[3] INTEGER OPTIONAL
3331 NOTE: in EncAPRepPart, the application code in the encrypted part of
3332 a message provides an additional check that the message was decrypted
3335 The encoded EncAPRepPart is encrypted in the shared session key of
3336 the ticket. The optional subkey field can be used in an
3337 application-arranged negotiation to choose a per association session
3340 pvno and msg-type These fields are described above in section 5.4.1.
3341 msg-type is KRB_AP_REP.
3343 enc-part This field is described above in section 5.4.2.
3345 ctime This field contains the current time on the client's host.
3347 cusec This field contains the microsecond part of the client's
3350 subkey This field contains an encryption key which is to be used
3351 to protect this specific application session. See section
3352 3.2.6 for specifics on how this field is used to negotiate
3353 a key. Unless an application specifies otherwise, if this
3354 field is left out, the sub-session key from the
3355 authenticator, or if also left out, the session key from
3356 the ticket will be used.
3362 Kohl & Neuman [Page 60]
3364 RFC 1510 Kerberos September 1993
3367 5.5.3. Error message reply
3369 If an error occurs while processing the application request, the
3370 KRB_ERROR message will be sent in response. See section 5.9.1 for
3371 the format of the error message. The cname and crealm fields may be
3372 left out if the server cannot determine their appropriate values from
3373 the corresponding KRB_AP_REQ message. If the authenticator was
3374 decipherable, the ctime and cusec fields will contain the values from
3377 5.6. KRB_SAFE message specification
3379 This section specifies the format of a message that can be used by
3380 either side (client or server) of an application to send a tamper-
3381 proof message to its peer. It presumes that a session key has
3382 previously been exchanged (for example, by using the
3383 KRB_AP_REQ/KRB_AP_REP messages).
3385 5.6.1. KRB_SAFE definition
3387 The KRB_SAFE message contains user data along with a collision-proof
3388 checksum keyed with the session key. The message fields are:
3390 KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
3392 msg-type[1] INTEGER,
3393 safe-body[2] KRB-SAFE-BODY,
3397 KRB-SAFE-BODY ::= SEQUENCE {
3398 user-data[0] OCTET STRING,
3399 timestamp[1] KerberosTime OPTIONAL,
3400 usec[2] INTEGER OPTIONAL,
3401 seq-number[3] INTEGER OPTIONAL,
3402 s-address[4] HostAddress,
3403 r-address[5] HostAddress OPTIONAL
3406 pvno and msg-type These fields are described above in section 5.4.1.
3407 msg-type is KRB_SAFE.
3409 safe-body This field is a placeholder for the body of the KRB-SAFE
3410 message. It is to be encoded separately and then have the
3411 checksum computed over it, for use in the cksum field.
3413 cksum This field contains the checksum of the application data.
3414 Checksum details are described in section 6.4. The
3418 Kohl & Neuman [Page 61]
3420 RFC 1510 Kerberos September 1993
3423 checksum is computed over the encoding of the KRB-SAFE-BODY
3426 user-data This field is part of the KRB_SAFE and KRB_PRIV messages
3427 and contain the application specific data that is being
3428 passed from the sender to the recipient.
3430 timestamp This field is part of the KRB_SAFE and KRB_PRIV messages.
3431 Its contents are the current time as known by the sender of
3432 the message. By checking the timestamp, the recipient of
3433 the message is able to make sure that it was recently
3434 generated, and is not a replay.
3436 usec This field is part of the KRB_SAFE and KRB_PRIV headers.
3437 It contains the microsecond part of the timestamp.
3439 seq-number This field is described above in section 5.3.2.
3441 s-address This field specifies the address in use by the sender of
3444 r-address This field specifies the address in use by the recipient of
3445 the message. It may be omitted for some uses (such as
3446 broadcast protocols), but the recipient may arbitrarily
3447 reject such messages. This field along with s-address can
3448 be used to help detect messages which have been incorrectly
3449 or maliciously delivered to the wrong recipient.
3451 5.7. KRB_PRIV message specification
3453 This section specifies the format of a message that can be used by
3454 either side (client or server) of an application to securely and
3455 privately send a message to its peer. It presumes that a session key
3456 has previously been exchanged (for example, by using the
3457 KRB_AP_REQ/KRB_AP_REP messages).
3459 5.7.1. KRB_PRIV definition
3461 The KRB_PRIV message contains user data encrypted in the Session Key.
3462 The message fields are:
3464 KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
3466 msg-type[1] INTEGER,
3467 enc-part[3] EncryptedData
3474 Kohl & Neuman [Page 62]
3476 RFC 1510 Kerberos September 1993
3479 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
3480 user-data[0] OCTET STRING,
3481 timestamp[1] KerberosTime OPTIONAL,
3482 usec[2] INTEGER OPTIONAL,
3483 seq-number[3] INTEGER OPTIONAL,
3484 s-address[4] HostAddress, -- sender's addr
3485 r-address[5] HostAddress OPTIONAL
3489 NOTE: In EncKrbPrivPart, the application code in the encrypted part
3490 of a message provides an additional check that the message was
3493 pvno and msg-type These fields are described above in section 5.4.1.
3494 msg-type is KRB_PRIV.
3496 enc-part This field holds an encoding of the EncKrbPrivPart sequence
3497 encrypted under the session key (If supported by the
3498 encryption method in use, an initialization vector may be
3499 passed to the encryption procedure, in order to achieve
3500 proper cipher chaining. The initialization vector might
3501 come from the last block of the ciphertext from the
3502 previous KRB_PRIV message, but it is the application's
3503 choice whether or not to use such an initialization vector.
3504 If left out, the default initialization vector for the
3505 encryption algorithm will be used.). This encrypted
3506 encoding is used for the enc-part field of the KRB-PRIV
3507 message. See section 6 for the format of the ciphertext.
3509 user-data, timestamp, usec, s-address and r-address These fields are
3510 described above in section 5.6.1.
3512 seq-number This field is described above in section 5.3.2.
3514 5.8. KRB_CRED message specification
3516 This section specifies the format of a message that can be used to
3517 send Kerberos credentials from one principal to another. It is
3518 presented here to encourage a common mechanism to be used by
3519 applications when forwarding tickets or providing proxies to
3520 subordinate servers. It presumes that a session key has already been
3521 exchanged perhaps by using the KRB_AP_REQ/KRB_AP_REP messages.
3523 5.8.1. KRB_CRED definition
3525 The KRB_CRED message contains a sequence of tickets to be sent and
3526 information needed to use the tickets, including the session key from
3530 Kohl & Neuman [Page 63]
3532 RFC 1510 Kerberos September 1993
3535 each. The information needed to use the tickets is encryped under an
3536 encryption key previously exchanged. The message fields are:
3538 KRB-CRED ::= [APPLICATION 22] SEQUENCE {
3540 msg-type[1] INTEGER, -- KRB_CRED
3541 tickets[2] SEQUENCE OF Ticket,
3542 enc-part[3] EncryptedData
3545 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
3546 ticket-info[0] SEQUENCE OF KrbCredInfo,
3547 nonce[1] INTEGER OPTIONAL,
3548 timestamp[2] KerberosTime OPTIONAL,
3549 usec[3] INTEGER OPTIONAL,
3550 s-address[4] HostAddress OPTIONAL,
3551 r-address[5] HostAddress OPTIONAL
3554 KrbCredInfo ::= SEQUENCE {
3555 key[0] EncryptionKey,
3556 prealm[1] Realm OPTIONAL,
3557 pname[2] PrincipalName OPTIONAL,
3558 flags[3] TicketFlags OPTIONAL,
3559 authtime[4] KerberosTime OPTIONAL,
3560 starttime[5] KerberosTime OPTIONAL,
3561 endtime[6] KerberosTime OPTIONAL
3562 renew-till[7] KerberosTime OPTIONAL,
3563 srealm[8] Realm OPTIONAL,
3564 sname[9] PrincipalName OPTIONAL,
3565 caddr[10] HostAddresses OPTIONAL
3569 pvno and msg-type These fields are described above in section 5.4.1.
3570 msg-type is KRB_CRED.
3573 These are the tickets obtained from the KDC specifically
3574 for use by the intended recipient. Successive tickets are
3575 paired with the corresponding KrbCredInfo sequence from the
3576 enc-part of the KRB-CRED message.
3578 enc-part This field holds an encoding of the EncKrbCredPart sequence
3579 encrypted under the session key shared between the sender
3580 and the intended recipient. This encrypted encoding is
3581 used for the enc-part field of the KRB-CRED message. See
3582 section 6 for the format of the ciphertext.
3586 Kohl & Neuman [Page 64]
3588 RFC 1510 Kerberos September 1993
3591 nonce If practical, an application may require the inclusion of a
3592 nonce generated by the recipient of the message. If the
3593 same value is included as the nonce in the message, it
3594 provides evidence that the message is fresh and has not
3595 been replayed by an attacker. A nonce must never be re-
3596 used; it should be generated randomly by the recipient of
3597 the message and provided to the sender of the mes sage in
3598 an application specific manner.
3600 timestamp and usec These fields specify the time that the KRB-CRED
3601 message was generated. The time is used to provide
3602 assurance that the message is fresh.
3604 s-address and r-address These fields are described above in section
3605 5.6.1. They are used optionally to provide additional
3606 assurance of the integrity of the KRB-CRED message.
3608 key This field exists in the corresponding ticket passed by the
3609 KRB-CRED message and is used to pass the session key from
3610 the sender to the intended recipient. The field's encoding
3611 is described in section 6.2.
3613 The following fields are optional. If present, they can be
3614 associated with the credentials in the remote ticket file. If left
3615 out, then it is assumed that the recipient of the credentials already
3618 prealm and pname The name and realm of the delegated principal
3621 flags, authtime, starttime, endtime, renew-till, srealm, sname,
3622 and caddr These fields contain the values of the
3623 corresponding fields from the ticket found in the ticket
3624 field. Descriptions of the fields are identical to the
3625 descriptions in the KDC-REP message.
3627 5.9. Error message specification
3629 This section specifies the format for the KRB_ERROR message. The
3630 fields included in the message are intended to return as much
3631 information as possible about an error. It is not expected that all
3632 the information required by the fields will be available for all
3633 types of errors. If the appropriate information is not available
3634 when the message is composed, the corresponding field will be left
3637 Note that since the KRB_ERROR message is not protected by any
3638 encryption, it is quite possible for an intruder to synthesize or
3642 Kohl & Neuman [Page 65]
3644 RFC 1510 Kerberos September 1993
3647 modify such a message. In particular, this means that the client
3648 should not use any fields in this message for security-critical
3649 purposes, such as setting a system clock or generating a fresh
3650 authenticator. The message can be useful, however, for advising a
3651 user on the reason for some failure.
3653 5.9.1. KRB_ERROR definition
3655 The KRB_ERROR message consists of the following fields:
3657 KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
3659 msg-type[1] INTEGER,
3660 ctime[2] KerberosTime OPTIONAL,
3661 cusec[3] INTEGER OPTIONAL,
3662 stime[4] KerberosTime,
3664 error-code[6] INTEGER,
3665 crealm[7] Realm OPTIONAL,
3666 cname[8] PrincipalName OPTIONAL,
3667 realm[9] Realm, -- Correct realm
3668 sname[10] PrincipalName, -- Correct name
3669 e-text[11] GeneralString OPTIONAL,
3670 e-data[12] OCTET STRING OPTIONAL
3673 pvno and msg-type These fields are described above in section 5.4.1.
3674 msg-type is KRB_ERROR.
3676 ctime This field is described above in section 5.4.1.
3678 cusec This field is described above in section 5.5.2.
3680 stime This field contains the current time on the server. It is
3681 of type KerberosTime.
3683 susec This field contains the microsecond part of the server's
3684 timestamp. Its value ranges from 0 to 999. It appears
3685 along with stime. The two fields are used in conjunction to
3686 specify a reasonably accurate timestamp.
3688 error-code This field contains the error code returned by Kerberos or
3689 the server when a request fails. To interpret the value of
3690 this field see the list of error codes in section 8.
3691 Implementations are encouraged to provide for national
3692 language support in the display of error messages.
3694 crealm, cname, srealm and sname These fields are described above in
3698 Kohl & Neuman [Page 66]
3700 RFC 1510 Kerberos September 1993
3705 e-text This field contains additional text to help explain the
3706 error code associated with the failed request (for example,
3707 it might include a principal name which was unknown).
3709 e-data This field contains additional data about the error for use
3710 by the application to help it recover from or handle the
3711 error. If the errorcode is KDC_ERR_PREAUTH_REQUIRED, then
3712 the e-data field will contain an encoding of a sequence of
3713 padata fields, each corresponding to an acceptable pre-
3714 authentication method and optionally containing data for
3717 METHOD-DATA ::= SEQUENCE of PA-DATA
3719 If the error-code is KRB_AP_ERR_METHOD, then the e-data field will
3720 contain an encoding of the following sequence:
3722 METHOD-DATA ::= SEQUENCE {
3723 method-type[0] INTEGER,
3724 method-data[1] OCTET STRING OPTIONAL
3727 method-type will indicate the required alternate method; method-data
3728 will contain any required additional information.
3730 6. Encryption and Checksum Specifications
3732 The Kerberos protocols described in this document are designed to use
3733 stream encryption ciphers, which can be simulated using commonly
3734 available block encryption ciphers, such as the Data Encryption
3735 Standard [11], in conjunction with block chaining and checksum
3736 methods [12]. Encryption is used to prove the identities of the
3737 network entities participating in message exchanges. The Key
3738 Distribution Center for each realm is trusted by all principals
3739 registered in that realm to store a secret key in confidence. Proof
3740 of knowledge of this secret key is used to verify the authenticity of
3743 The KDC uses the principal's secret key (in the AS exchange) or a
3744 shared session key (in the TGS exchange) to encrypt responses to
3745 ticket requests; the ability to obtain the secret key or session key
3746 implies the knowledge of the appropriate keys and the identity of the
3747 KDC. The ability of a principal to decrypt the KDC response and
3748 present a Ticket and a properly formed Authenticator (generated with
3749 the session key from the KDC response) to a service verifies the
3750 identity of the principal; likewise the ability of the service to
3754 Kohl & Neuman [Page 67]
3756 RFC 1510 Kerberos September 1993
3759 extract the session key from the Ticket and prove its knowledge
3760 thereof in a response verifies the identity of the service.
3762 The Kerberos protocols generally assume that the encryption used is
3763 secure from cryptanalysis; however, in some cases, the order of
3764 fields in the encrypted portions of messages are arranged to minimize
3765 the effects of poorly chosen keys. It is still important to choose
3766 good keys. If keys are derived from user-typed passwords, those
3767 passwords need to be well chosen to make brute force attacks more
3768 difficult. Poorly chosen keys still make easy targets for intruders.
3770 The following sections specify the encryption and checksum mechanisms
3771 currently defined for Kerberos. The encodings, chaining, and padding
3772 requirements for each are described. For encryption methods, it is
3773 often desirable to place random information (often referred to as a
3774 confounder) at the start of the message. The requirements for a
3775 confounder are specified with each encryption mechanism.
3777 Some encryption systems use a block-chaining method to improve the
3778 the security characteristics of the ciphertext. However, these
3779 chaining methods often don't provide an integrity check upon
3780 decryption. Such systems (such as DES in CBC mode) must be augmented
3781 with a checksum of the plaintext which can be verified at decryption
3782 and used to detect any tampering or damage. Such checksums should be
3783 good at detecting burst errors in the input. If any damage is
3784 detected, the decryption routine is expected to return an error
3785 indicating the failure of an integrity check. Each encryption type is
3786 expected to provide and verify an appropriate checksum. The
3787 specification of each encryption method sets out its checksum
3790 Finally, where a key is to be derived from a user's password, an
3791 algorithm for converting the password to a key of the appropriate
3792 type is included. It is desirable for the string to key function to
3793 be one-way, and for the mapping to be different in different realms.
3794 This is important because users who are registered in more than one
3795 realm will often use the same password in each, and it is desirable
3796 that an attacker compromising the Kerberos server in one realm not
3797 obtain or derive the user's key in another.
3799 For a discussion of the integrity characteristics of the candidate
3800 encryption and checksum methods considered for Kerberos, the the
3801 reader is referred to [13].
3803 6.1. Encryption Specifications
3805 The following ASN.1 definition describes all encrypted messages. The
3806 enc-part field which appears in the unencrypted part of messages in
3810 Kohl & Neuman [Page 68]
3812 RFC 1510 Kerberos September 1993
3815 section 5 is a sequence consisting of an encryption type, an optional
3816 key version number, and the ciphertext.
3818 EncryptedData ::= SEQUENCE {
3819 etype[0] INTEGER, -- EncryptionType
3820 kvno[1] INTEGER OPTIONAL,
3821 cipher[2] OCTET STRING -- ciphertext
3824 etype This field identifies which encryption algorithm was used
3825 to encipher the cipher. Detailed specifications for
3826 selected encryption types appear later in this section.
3828 kvno This field contains the version number of the key under
3829 which data is encrypted. It is only present in messages
3830 encrypted under long lasting keys, such as principals'
3833 cipher This field contains the enciphered text, encoded as an
3836 The cipher field is generated by applying the specified encryption
3837 algorithm to data composed of the message and algorithm-specific
3838 inputs. Encryption mechanisms defined for use with Kerberos must
3839 take sufficient measures to guarantee the integrity of the plaintext,
3840 and we recommend they also take measures to protect against
3841 precomputed dictionary attacks. If the encryption algorithm is not
3842 itself capable of doing so, the protections can often be enhanced by
3843 adding a checksum and a confounder.
3845 The suggested format for the data to be encrypted includes a
3846 confounder, a checksum, the encoded plaintext, and any necessary
3847 padding. The msg-seq field contains the part of the protocol message
3848 described in section 5 which is to be encrypted. The confounder,
3849 checksum, and padding are all untagged and untyped, and their length
3850 is exactly sufficient to hold the appropriate item. The type and
3851 length is implicit and specified by the particular encryption type
3852 being used (etype). The format for the data to be encrypted is
3853 described in the following diagram:
3855 +-----------+----------+-------------+-----+
3856 |confounder | check | msg-seq | pad |
3857 +-----------+----------+-------------+-----+
3859 The format cannot be described in ASN.1, but for those who prefer an
3860 ASN.1-like notation:
3866 Kohl & Neuman [Page 69]
3868 RFC 1510 Kerberos September 1993
3871 CipherText ::= ENCRYPTED SEQUENCE {
3872 confounder[0] UNTAGGED OCTET STRING(conf_length) OPTIONAL,
3873 check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL,
3874 msg-seq[2] MsgSequence,
3875 pad UNTAGGED OCTET STRING(pad_length) OPTIONAL
3878 In the above specification, UNTAGGED OCTET STRING(length) is the
3879 notation for an octet string with its tag and length removed. It is
3880 not a valid ASN.1 type. The tag bits and length must be removed from
3881 the confounder since the purpose of the confounder is so that the
3882 message starts with random data, but the tag and its length are
3883 fixed. For other fields, the length and tag would be redundant if
3884 they were included because they are specified by the encryption type.
3886 One generates a random confounder of the appropriate length, placing
3887 it in confounder; zeroes out check; calculates the appropriate
3888 checksum over confounder, check, and msg-seq, placing the result in
3889 check; adds the necessary padding; then encrypts using the specified
3890 encryption type and the appropriate key.
3892 Unless otherwise specified, a definition of an encryption algorithm
3893 that specifies a checksum, a length for the confounder field, or an
3894 octet boundary for padding uses this ciphertext format (The ordering
3895 of the fields in the CipherText is important. Additionally, messages
3896 encoded in this format must include a length as part of the msg-seq
3897 field. This allows the recipient to verify that the message has not
3898 been truncated. Without a length, an attacker could use a chosen
3899 plaintext attack to generate a message which could be truncated,
3900 while leaving the checksum intact. Note that if the msg-seq is an
3901 encoding of an ASN.1 SEQUENCE or OCTET STRING, then the length is
3902 part of that encoding.). Those fields which are not specified will be
3905 In the interest of allowing all implementations using a particular
3906 encryption type to communicate with all others using that type, the
3907 specification of an encryption type defines any checksum that is
3908 needed as part of the encryption process. If an alternative checksum
3909 is to be used, a new encryption type must be defined.
3911 Some cryptosystems require additional information beyond the key and
3912 the data to be encrypted. For example, DES, when used in cipher-
3913 block-chaining mode, requires an initialization vector. If required,
3914 the description for each encryption type must specify the source of
3915 such additional information.
3922 Kohl & Neuman [Page 70]
3924 RFC 1510 Kerberos September 1993
3927 6.2. Encryption Keys
3929 The sequence below shows the encoding of an encryption key:
3931 EncryptionKey ::= SEQUENCE {
3933 keyvalue[1] OCTET STRING
3936 keytype This field specifies the type of encryption key that
3937 follows in the keyvalue field. It will almost always
3938 correspond to the encryption algorithm used to generate the
3939 EncryptedData, though more than one algorithm may use the
3940 same type of key (the mapping is many to one). This might
3941 happen, for example, if the encryption algorithm uses an
3942 alternate checksum algorithm for an integrity check, or a
3943 different chaining mechanism.
3945 keyvalue This field contains the key itself, encoded as an octet
3948 All negative values for the encryption key type are reserved for
3949 local use. All non-negative values are reserved for officially
3950 assigned type fields and interpretations.
3952 6.3. Encryption Systems
3954 6.3.1. The NULL Encryption System (null)
3956 If no encryption is in use, the encryption system is said to be the
3957 NULL encryption system. In the NULL encryption system there is no
3958 checksum, confounder or padding. The ciphertext is simply the
3959 plaintext. The NULL Key is used by the null encryption system and is
3960 zero octets in length, with keytype zero (0).
3962 6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc)
3964 The des-cbc-crc encryption mode encrypts information under the Data
3965 Encryption Standard [11] using the cipher block chaining mode [12].
3966 A CRC-32 checksum (described in ISO 3309 [14]) is applied to the
3967 confounder and message sequence (msg-seq) and placed in the cksum
3968 field. DES blocks are 8 bytes. As a result, the data to be
3969 encrypted (the concatenation of confounder, checksum, and message)
3970 must be padded to an 8 byte boundary before encryption. The details
3971 of the encryption of this data are identical to those for the des-
3972 cbc-md5 encryption mode.
3974 Note that, since the CRC-32 checksum is not collisionproof, an
3978 Kohl & Neuman [Page 71]
3980 RFC 1510 Kerberos September 1993
3983 attacker could use a probabilistic chosenplaintext attack to generate
3984 a valid message even if a confounder is used [13]. The use of
3985 collision-proof checksums is recommended for environments where such
3986 attacks represent a significant threat. The use of the CRC-32 as the
3987 checksum for ticket or authenticator is no longer mandated as an
3988 interoperability requirement for Kerberos Version 5 Specification 1
3989 (See section 9.1 for specific details).
3991 6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4)
3993 The des-cbc-md4 encryption mode encrypts information under the Data
3994 Encryption Standard [11] using the cipher block chaining mode [12].
3995 An MD4 checksum (described in [15]) is applied to the confounder and
3996 message sequence (msg-seq) and placed in the cksum field. DES blocks
3997 are 8 bytes. As a result, the data to be encrypted (the
3998 concatenation of confounder, checksum, and message) must be padded to
3999 an 8 byte boundary before encryption. The details of the encryption
4000 of this data are identical to those for the descbc-md5 encryption
4003 6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5)
4005 The des-cbc-md5 encryption mode encrypts information under the Data
4006 Encryption Standard [11] using the cipher block chaining mode [12].
4007 An MD5 checksum (described in [16]) is applied to the confounder and
4008 message sequence (msg-seq) and placed in the cksum field. DES blocks
4009 are 8 bytes. As a result, the data to be encrypted (the
4010 concatenation of confounder, checksum, and message) must be padded to
4011 an 8 byte boundary before encryption.
4013 Plaintext and DES ciphtertext are encoded as 8-octet blocks which are
4014 concatenated to make the 64-bit inputs for the DES algorithms. The
4015 first octet supplies the 8 most significant bits (with the octet's
4016 MSbit used as the DES input block's MSbit, etc.), the second octet
4017 the next 8 bits, ..., and the eighth octet supplies the 8 least
4020 Encryption under DES using cipher block chaining requires an
4021 additional input in the form of an initialization vector. Unless
4022 otherwise specified, zero should be used as the initialization
4023 vector. Kerberos' use of DES requires an 8-octet confounder.
4025 The DES specifications identify some "weak" and "semiweak" keys;
4026 those keys shall not be used for encrypting messages for use in
4027 Kerberos. Additionally, because of the way that keys are derived for
4028 the encryption of checksums, keys shall not be used that yield "weak"
4029 or "semi-weak" keys when eXclusive-ORed with the constant
4034 Kohl & Neuman [Page 72]
4036 RFC 1510 Kerberos September 1993
4039 A DES key is 8 octets of data, with keytype one (1). This consists
4040 of 56 bits of key, and 8 parity bits (one per octet). The key is
4041 encoded as a series of 8 octets written in MSB-first order. The bits
4042 within the key are also encoded in MSB order. For example, if the
4044 (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where
4045 B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the
4046 parity bits, the first octet of the key would be B1,B2,...,B7,P1
4047 (with B1 as the MSbit). [See the FIPS 81 introduction for
4050 To generate a DES key from a text string (password), the text string
4051 normally must have the realm and each component of the principal's
4052 name appended(In some cases, it may be necessary to use a different
4053 "mix-in" string for compatibility reasons; see the discussion of
4054 padata in section 5.4.2.), then padded with ASCII nulls to an 8 byte
4055 boundary. This string is then fan-folded and eXclusive-ORed with
4056 itself to form an 8 byte DES key. The parity is corrected on the
4057 key, and it is used to generate a DES CBC checksum on the initial
4058 string (with the realm and name appended). Next, parity is corrected
4059 on the CBC checksum. If the result matches a "weak" or "semiweak"
4060 key as described in the DES specification, it is eXclusive-ORed with
4061 the constant 00000000000000F0. Finally, the result is returned as
4062 the key. Pseudocode follows:
4064 string_to_key(string,realm,name) {
4067 for(each component in name) {
4071 pad(s); /* with nulls to 8 byte boundary */
4072 for(8byteblock in s) {
4078 tempkey = tempkey XOR 8byteblock;
4081 key = DES-CBC-check(s,tempkey);
4083 if(is_weak_key_key(key))
4090 Kohl & Neuman [Page 73]
4092 RFC 1510 Kerberos September 1993
4097 The following is the ASN.1 definition used for a checksum:
4099 Checksum ::= SEQUENCE {
4100 cksumtype[0] INTEGER,
4101 checksum[1] OCTET STRING
4104 cksumtype This field indicates the algorithm used to generate the
4105 accompanying checksum.
4107 checksum This field contains the checksum itself, encoded
4110 Detailed specification of selected checksum types appear later in
4111 this section. Negative values for the checksum type are reserved for
4112 local use. All non-negative values are reserved for officially
4113 assigned type fields and interpretations.
4115 Checksums used by Kerberos can be classified by two properties:
4116 whether they are collision-proof, and whether they are keyed. It is
4117 infeasible to find two plaintexts which generate the same checksum
4118 value for a collision-proof checksum. A key is required to perturb
4119 or initialize the algorithm in a keyed checksum. To prevent
4120 message-stream modification by an active attacker, unkeyed checksums
4121 should only be used when the checksum and message will be
4122 subsequently encrypted (e.g., the checksums defined as part of the
4123 encryption algorithms covered earlier in this section). Collision-
4124 proof checksums can be made tamper-proof as well if the checksum
4125 value is encrypted before inclusion in a message. In such cases, the
4126 composition of the checksum and the encryption algorithm must be
4127 considered a separate checksum algorithm (e.g., RSA-MD5 encrypted
4128 using DES is a new checksum algorithm of type RSA-MD5-DES). For most
4129 keyed checksums, as well as for the encrypted forms of collisionproof
4130 checksums, Kerberos prepends a confounder before the checksum is
4133 6.4.1. The CRC-32 Checksum (crc32)
4135 The CRC-32 checksum calculates a checksum based on a cyclic
4136 redundancy check as described in ISO 3309 [14]. The resulting
4137 checksum is four (4) octets in length. The CRC-32 is neither keyed
4138 nor collision-proof. The use of this checksum is not recommended.
4139 An attacker using a probabilistic chosen-plaintext attack as
4140 described in [13] might be able to generate an alternative message
4141 that satisfies the checksum. The use of collision-proof checksums is
4142 recommended for environments where such attacks represent a
4146 Kohl & Neuman [Page 74]
4148 RFC 1510 Kerberos September 1993
4153 6.4.2. The RSA MD4 Checksum (rsa-md4)
4155 The RSA-MD4 checksum calculates a checksum using the RSA MD4
4156 algorithm [15]. The algorithm takes as input an input message of
4157 arbitrary length and produces as output a 128-bit (16 octet)
4158 checksum. RSA-MD4 is believed to be collision-proof.
4160 6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4des)
4162 The RSA-MD4-DES checksum calculates a keyed collisionproof checksum
4163 by prepending an 8 octet confounder before the text, applying the RSA
4164 MD4 checksum algorithm, and encrypting the confounder and the
4165 checksum using DES in cipher-block-chaining (CBC) mode using a
4166 variant of the key, where the variant is computed by eXclusive-ORing
4167 the key with the constant F0F0F0F0F0F0F0F0 (A variant of the key is
4168 used to limit the use of a key to a particular function, separating
4169 the functions of generating a checksum from other encryption
4170 performed using the session key. The constant F0F0F0F0F0F0F0F0 was
4171 chosen because it maintains key parity. The properties of DES
4172 precluded the use of the complement. The same constant is used for
4173 similar purpose in the Message Integrity Check in the Privacy
4174 Enhanced Mail standard.). The initialization vector should be zero.
4175 The resulting checksum is 24 octets long (8 octets of which are
4176 redundant). This checksum is tamper-proof and believed to be
4179 The DES specifications identify some "weak keys"; those keys shall
4180 not be used for generating RSA-MD4 checksums for use in Kerberos.
4182 The format for the checksum is described in the following diagram:
4184 +--+--+--+--+--+--+--+--
4185 | des-cbc(confounder
4186 +--+--+--+--+--+--+--+--
4188 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4189 rsa-md4(confounder+msg),key=var(key),iv=0) |
4190 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4192 The format cannot be described in ASN.1, but for those who prefer an
4193 ASN.1-like notation:
4195 rsa-md4-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE {
4196 confounder[0] UNTAGGED OCTET STRING(8),
4197 check[1] UNTAGGED OCTET STRING(16)
4202 Kohl & Neuman [Page 75]
4204 RFC 1510 Kerberos September 1993
4207 6.4.4. The RSA MD5 Checksum (rsa-md5)
4209 The RSA-MD5 checksum calculates a checksum using the RSA MD5
4210 algorithm [16]. The algorithm takes as input an input message of
4211 arbitrary length and produces as output a 128-bit (16 octet)
4212 checksum. RSA-MD5 is believed to be collision-proof.
4214 6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5des)
4216 The RSA-MD5-DES checksum calculates a keyed collisionproof checksum
4217 by prepending an 8 octet confounder before the text, applying the RSA
4218 MD5 checksum algorithm, and encrypting the confounder and the
4219 checksum using DES in cipher-block-chaining (CBC) mode using a
4220 variant of the key, where the variant is computed by eXclusive-ORing
4221 the key with the constant F0F0F0F0F0F0F0F0. The initialization
4222 vector should be zero. The resulting checksum is 24 octets long (8
4223 octets of which are redundant). This checksum is tamper-proof and
4224 believed to be collision-proof.
4226 The DES specifications identify some "weak keys"; those keys shall
4227 not be used for encrypting RSA-MD5 checksums for use in Kerberos.
4229 The format for the checksum is described in the following diagram:
4231 +--+--+--+--+--+--+--+--
4232 | des-cbc(confounder
4233 +--+--+--+--+--+--+--+--
4235 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4236 rsa-md5(confounder+msg),key=var(key),iv=0) |
4237 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4239 The format cannot be described in ASN.1, but for those who prefer an
4240 ASN.1-like notation:
4242 rsa-md5-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE {
4243 confounder[0] UNTAGGED OCTET STRING(8),
4244 check[1] UNTAGGED OCTET STRING(16)
4247 6.4.6. DES cipher-block chained checksum (des-mac)
4249 The DES-MAC checksum is computed by prepending an 8 octet confounder
4250 to the plaintext, performing a DES CBC-mode encryption on the result
4251 using the key and an initialization vector of zero, taking the last
4252 block of the ciphertext, prepending the same confounder and
4253 encrypting the pair using DES in cipher-block-chaining (CBC) mode
4254 using a a variant of the key, where the variant is computed by
4258 Kohl & Neuman [Page 76]
4260 RFC 1510 Kerberos September 1993
4263 eXclusive-ORing the key with the constant F0F0F0F0F0F0F0F0. The
4264 initialization vector should be zero. The resulting checksum is 128
4265 bits (16 octets) long, 64 bits of which are redundant. This checksum
4266 is tamper-proof and collision-proof.
4268 The format for the checksum is described in the following diagram:
4270 +--+--+--+--+--+--+--+--
4271 | des-cbc(confounder
4272 +--+--+--+--+--+--+--+--
4274 +-----+-----+-----+-----+-----+-----+-----+-----+
4275 des-mac(conf+msg,iv=0,key),key=var(key),iv=0) |
4276 +-----+-----+-----+-----+-----+-----+-----+-----+
4278 The format cannot be described in ASN.1, but for those who prefer an
4279 ASN.1-like notation:
4281 des-mac-checksum ::= ENCRYPTED UNTAGGED SEQUENCE {
4282 confounder[0] UNTAGGED OCTET STRING(8),
4283 check[1] UNTAGGED OCTET STRING(8)
4286 The DES specifications identify some "weak" and "semiweak" keys;
4287 those keys shall not be used for generating DES-MAC checksums for use
4288 in Kerberos, nor shall a key be used whose veriant is "weak" or
4291 6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative
4294 The RSA-MD4-DES-K checksum calculates a keyed collision-proof
4295 checksum by applying the RSA MD4 checksum algorithm and encrypting
4296 the results using DES in cipherblock-chaining (CBC) mode using a DES
4297 key as both key and initialization vector. The resulting checksum is
4298 16 octets long. This checksum is tamper-proof and believed to be
4299 collision-proof. Note that this checksum type is the old method for
4300 encoding the RSA-MD4-DES checksum and it is no longer recommended.
4302 6.4.8. DES cipher-block chained checksum alternative (desmac-k)
4304 The DES-MAC-K checksum is computed by performing a DES CBC-mode
4305 encryption of the plaintext, and using the last block of the
4306 ciphertext as the checksum value. It is keyed with an encryption key
4307 and an initialization vector; any uses which do not specify an
4308 additional initialization vector will use the key as both key and
4309 initialization vector. The resulting checksum is 64 bits (8 octets)
4310 long. This checksum is tamper-proof and collision-proof. Note that
4314 Kohl & Neuman [Page 77]
4316 RFC 1510 Kerberos September 1993
4319 this checksum type is the old method for encoding the DESMAC checksum
4320 and it is no longer recommended.
4322 The DES specifications identify some "weak keys"; those keys shall
4323 not be used for generating DES-MAC checksums for use in Kerberos.
4325 7. Naming Constraints
4329 Although realm names are encoded as GeneralStrings and although a
4330 realm can technically select any name it chooses, interoperability
4331 across realm boundaries requires agreement on how realm names are to
4332 be assigned, and what information they imply.
4334 To enforce these conventions, each realm must conform to the
4335 conventions itself, and it must require that any realms with which
4336 inter-realm keys are shared also conform to the conventions and
4337 require the same from its neighbors.
4339 There are presently four styles of realm names: domain, X500, other,
4340 and reserved. Examples of each style follow:
4342 domain: host.subdomain.domain (example)
4343 X500: C=US/O=OSF (example)
4344 other: NAMETYPE:rest/of.name=without-restrictions (example)
4345 reserved: reserved, but will not conflict with above
4347 Domain names must look like domain names: they consist of components
4348 separated by periods (.) and they contain neither colons (:) nor
4351 X.500 names contain an equal (=) and cannot contain a colon (:)
4352 before the equal. The realm names for X.500 names will be string
4353 representations of the names with components separated by slashes.
4354 Leading and trailing slashes will not be included.
4356 Names that fall into the other category must begin with a prefix that
4357 contains no equal (=) or period (.) and the prefix must be followed
4358 by a colon (:) and the rest of the name. All prefixes must be
4359 assigned before they may be used. Presently none are assigned.
4361 The reserved category includes strings which do not fall into the
4362 first three categories. All names in this category are reserved. It
4363 is unlikely that names will be assigned to this category unless there
4364 is a very strong argument for not using the "other" category.
4366 These rules guarantee that there will be no conflicts between the
4370 Kohl & Neuman [Page 78]
4372 RFC 1510 Kerberos September 1993
4375 various name styles. The following additional constraints apply to
4376 the assignment of realm names in the domain and X.500 categories: the
4377 name of a realm for the domain or X.500 formats must either be used
4378 by the organization owning (to whom it was assigned) an Internet
4379 domain name or X.500 name, or in the case that no such names are
4380 registered, authority to use a realm name may be derived from the
4381 authority of the parent realm. For example, if there is no domain
4382 name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can
4383 authorize the creation of a realm with that name.
4385 This is acceptable because the organization to which the parent is
4386 assigned is presumably the organization authorized to assign names to
4387 its children in the X.500 and domain name systems as well. If the
4388 parent assigns a realm name without also registering it in the domain
4389 name or X.500 hierarchy, it is the parent's responsibility to make
4390 sure that there will not in the future exists a name identical to the
4391 realm name of the child unless it is assigned to the same entity as
4394 7.2. Principal Names
4396 As was the case for realm names, conventions are needed to ensure
4397 that all agree on what information is implied by a principal name.
4398 The name-type field that is part of the principal name indicates the
4399 kind of information implied by the name. The name-type should be
4400 treated as a hint. Ignoring the name type, no two names can be the
4401 same (i.e., at least one of the components, or the realm, must be
4402 different). This constraint may be eliminated in the future. The
4403 following name types are defined:
4405 name-type value meaning
4406 NT-UNKNOWN 0 Name type not known
4407 NT-PRINCIPAL 1 Just the name of the principal as in
4409 NT-SRV-INST 2 Service and other unique instance (krbtgt)
4410 NT-SRV-HST 3 Service with host name as instance
4412 NT-SRV-XHST 4 Service with host as remaining components
4415 When a name implies no information other than its uniqueness at a
4416 particular time the name type PRINCIPAL should be used. The
4417 principal name type should be used for users, and it might also be
4418 used for a unique server. If the name is a unique machine generated
4419 ID that is guaranteed never to be reassigned then the name type of
4420 UID should be used (note that it is generally a bad idea to reassign
4421 names of any type since stale entries might remain in access control
4426 Kohl & Neuman [Page 79]
4428 RFC 1510 Kerberos September 1993
4431 If the first component of a name identifies a service and the
4432 remaining components identify an instance of the service in a server
4433 specified manner, then the name type of SRV-INST should be used. An
4434 example of this name type is the Kerberos ticket-granting ticket
4435 which has a first component of krbtgt and a second component
4436 identifying the realm for which the ticket is valid.
4438 If instance is a single component following the service name and the
4439 instance identifies the host on which the server is running, then the
4440 name type SRV-HST should be used. This type is typically used for
4441 Internet services such as telnet and the Berkeley R commands. If the
4442 separate components of the host name appear as successive components
4443 following the name of the service, then the name type SRVXHST should
4444 be used. This type might be used to identify servers on hosts with
4445 X.500 names where the slash (/) might otherwise be ambiguous.
4447 A name type of UNKNOWN should be used when the form of the name is
4448 not known. When comparing names, a name of type UNKNOWN will match
4449 principals authenticated with names of any type. A principal
4450 authenticated with a name of type UNKNOWN, however, will only match
4451 other names of type UNKNOWN.
4453 Names of any type with an initial component of "krbtgt" are reserved
4454 for the Kerberos ticket granting service. See section 8.2.3 for the
4457 7.2.1. Name of server principals
4459 The principal identifier for a server on a host will generally be
4460 composed of two parts: (1) the realm of the KDC with which the server
4461 is registered, and (2) a two-component name of type NT-SRV-HST if the
4462 host name is an Internet domain name or a multi-component name of
4463 type NT-SRV-XHST if the name of the host is of a form such as X.500
4464 that allows slash (/) separators. The first component of the two- or
4465 multi-component name will identify the service and the latter
4466 components will identify the host. Where the name of the host is not
4467 case sensitive (for example, with Internet domain names) the name of
4468 the host must be lower case. For services such as telnet and the
4469 Berkeley R commands which run with system privileges, the first
4470 component will be the string "host" instead of a service specific
4473 8. Constants and other defined values
4475 8.1. Host address types
4477 All negative values for the host address type are reserved for local
4478 use. All non-negative values are reserved for officially assigned
4482 Kohl & Neuman [Page 80]
4484 RFC 1510 Kerberos September 1993
4487 type fields and interpretations.
4489 The values of the types for the following addresses are chosen to
4490 match the defined address family constants in the Berkeley Standard
4491 Distributions of Unix. They can be found in <sys/socket.h> with
4492 symbolic names AF_xxx (where xxx is an abbreviation of the address
4498 Internet addresses are 32-bit (4-octet) quantities, encoded in MSB
4499 order. The type of internet addresses is two (2).
4503 CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB
4504 order. The type of CHAOSnet addresses is five (5).
4508 ISO addresses are variable-length. The type of ISO addresses is
4511 Xerox Network Services (XNS) addresses
4513 XNS addresses are 48-bit (6-octet) quantities, encoded in MSB
4514 order. The type of XNS addresses is six (6).
4516 AppleTalk Datagram Delivery Protocol (DDP) addresses
4518 AppleTalk DDP addresses consist of an 8-bit node number and a 16-
4519 bit network number. The first octet of the address is the node
4520 number; the remaining two octets encode the network number in MSB
4521 order. The type of AppleTalk DDP addresses is sixteen (16).
4523 DECnet Phase IV addresses
4525 DECnet Phase IV addresses are 16-bit addresses, encoded in LSB
4526 order. The type of DECnet Phase IV addresses is twelve (12).
4532 When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request
4533 using IP transport, the client shall send a UDP datagram containing
4534 only an encoding of the request to port 88 (decimal) at the KDC's IP
4538 Kohl & Neuman [Page 81]
4540 RFC 1510 Kerberos September 1993
4543 address; the KDC will respond with a reply datagram containing only
4544 an encoding of the reply message (either a KRB_ERROR or a
4545 KRB_KDC_REP) to the sending port at the sender's IP address.
4547 8.2.2. OSI transport
4549 During authentication of an OSI client to and OSI server, the mutual
4550 authentication of an OSI server to an OSI client, the transfer of
4551 credentials from an OSI client to an OSI server, or during exchange
4552 of private or integrity checked messages, Kerberos protocol messages
4553 may be treated as opaque objects and the type of the authentication
4556 OBJECT IDENTIFIER ::= {iso (1), org(3), dod(5),internet(1),
4557 security(5), kerberosv5(2)}
4559 Depending on the situation, the opaque object will be an
4560 authentication header (KRB_AP_REQ), an authentication reply
4561 (KRB_AP_REP), a safe message (KRB_SAFE), a private message
4562 (KRB_PRIV), or a credentials message (KRB_CRED). The opaque data
4563 contains an application code as specified in the ASN.1 description
4564 for each message. The application code may be used by Kerberos to
4565 determine the message type.
4567 8.2.3. Name of the TGS
4569 The principal identifier of the ticket-granting service shall be
4570 composed of three parts: (1) the realm of the KDC issuing the TGS
4571 ticket (2) a two-part name of type NT-SRVINST, with the first part
4572 "krbtgt" and the second part the name of the realm which will accept
4573 the ticket-granting ticket. For example, a ticket-granting ticket
4574 issued by the ATHENA.MIT.EDU realm to be used to get tickets from the
4575 ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU"
4576 (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting
4577 ticket issued by the ATHENA.MIT.EDU realm to be used to get tickets
4578 from the MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU"
4579 (realm), ("krbtgt", "MIT.EDU") (name).
4581 8.3. Protocol constants and associated values
4583 The following tables list constants used in the protocol and defines
4594 Kohl & Neuman [Page 82]
4596 RFC 1510 Kerberos September 1993
4599 ---------------+-----------+----------+----------------+---------------
4600 Encryption type|etype value|block size|minimum pad size|confounder size
4601 ---------------+-----------+----------+----------------+---------------
4607 -------------------------------+-------------------+-------------
4608 Checksum type |sumtype value |checksum size
4609 -------------------------------+-------------------+-------------
4619 -------------------------------+-----------------
4620 padata type |padata-type value
4621 -------------------------------+-----------------
4626 -------------------------------+-------------
4627 authorization data type |ad-type value
4628 -------------------------------+-------------
4629 reserved values 0-63
4633 -------------------------------+-----------------
4634 alternate authentication type |method-type value
4635 -------------------------------+-----------------
4636 reserved values 0-63
4637 ATT-CHALLENGE-RESPONSE 64
4639 -------------------------------+-------------
4640 transited encoding type |tr-type value
4641 -------------------------------+-------------
4642 DOMAIN-X500-COMPRESS 1
4643 reserved values all others
4650 Kohl & Neuman [Page 83]
4652 RFC 1510 Kerberos September 1993
4655 --------------+-------+-----------------------------------------
4656 Label |Value |Meaning or MIT code
4657 --------------+-------+-----------------------------------------
4659 pvno 5 current Kerberos protocol version number
4663 KRB_AS_REQ 10 Request for initial authentication
4664 KRB_AS_REP 11 Response to KRB_AS_REQ request
4665 KRB_TGS_REQ 12 Request for authentication based on TGT
4666 KRB_TGS_REP 13 Response to KRB_TGS_REQ request
4667 KRB_AP_REQ 14 application request to server
4668 KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL
4669 KRB_SAFE 20 Safe (checksummed) application message
4670 KRB_PRIV 21 Private (encrypted) application message
4671 KRB_CRED 22 Private (encrypted) message to forward
4673 KRB_ERROR 30 Error response
4677 KRB_NT_UNKNOWN 0 Name type not known
4678 KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or
4680 KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt)
4681 KRB_NT_SRV_HST 3 Service with host name as instance (telnet,
4683 KRB_NT_SRV_XHST 4 Service with host as remaining components
4684 KRB_NT_UID 5 Unique ID
4688 KDC_ERR_NONE 0 No error
4689 KDC_ERR_NAME_EXP 1 Client's entry in database has
4691 KDC_ERR_SERVICE_EXP 2 Server's entry in database has
4693 KDC_ERR_BAD_PVNO 3 Requested protocol version number
4695 KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old
4697 KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old
4699 KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database
4700 KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database
4701 KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in
4706 Kohl & Neuman [Page 84]
4708 RFC 1510 Kerberos September 1993
4711 KDC_ERR_NULL_KEY 9 The client or server has a null key
4712 KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating
4713 KDC_ERR_NEVER_VALID 11 Requested start time is later than
4715 KDC_ERR_POLICY 12 KDC policy rejects request
4716 KDC_ERR_BADOPTION 13 KDC cannot accommodate requested
4718 KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption
4720 KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type
4721 KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type
4722 KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type
4723 KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked
4724 KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been
4726 KDC_ERR_TGT_REVOKED 20 TGT has been revoked
4727 KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again
4729 KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again
4731 KDC_ERR_KEY_EXPIRED 23 Password has expired - change
4733 KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information
4735 KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authentication
4737 KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field
4739 KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired
4740 KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid
4741 KRB_AP_ERR_REPEAT 34 Request is a replay
4742 KRB_AP_ERR_NOT_US 35 The ticket isn't for us
4743 KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match
4744 KRB_AP_ERR_SKEW 37 Clock skew too great
4745 KRB_AP_ERR_BADADDR 38 Incorrect net address
4746 KRB_AP_ERR_BADVERSION 39 Protocol version mismatch
4747 KRB_AP_ERR_MSG_TYPE 40 Invalid msg type
4748 KRB_AP_ERR_MODIFIED 41 Message stream modified
4749 KRB_AP_ERR_BADORDER 42 Message out of order
4750 KRB_AP_ERR_BADKEYVER 44 Specified version of key is not
4752 KRB_AP_ERR_NOKEY 45 Service key not available
4753 KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed
4754 KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction
4755 KRB_AP_ERR_METHOD 48 Alternative authentication method
4757 KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message
4758 KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in
4762 Kohl & Neuman [Page 85]
4764 RFC 1510 Kerberos September 1993
4768 KRB_ERR_GENERIC 60 Generic error (description in e-text)
4769 KRB_ERR_FIELD_TOOLONG 61 Field is too long for this
4772 *This error carries additional information in the e-data field. The
4773 contents of the e-data field for this message is described in section
4776 9. Interoperability requirements
4778 Version 5 of the Kerberos protocol supports a myriad of options.
4779 Among these are multiple encryption and checksum types, alternative
4780 encoding schemes for the transited field, optional mechanisms for
4781 pre-authentication, the handling of tickets with no addresses,
4782 options for mutual authentication, user to user authentication,
4783 support for proxies, forwarding, postdating, and renewing tickets,
4784 the format of realm names, and the handling of authorization data.
4786 In order to ensure the interoperability of realms, it is necessary to
4787 define a minimal configuration which must be supported by all
4788 implementations. This minimal configuration is subject to change as
4789 technology does. For example, if at some later date it is discovered
4790 that one of the required encryption or checksum algorithms is not
4791 secure, it will be replaced.
4793 9.1. Specification 1
4795 This section defines the first specification of these options.
4796 Implementations which are configured in this way can be said to
4797 support Kerberos Version 5 Specification 1 (5.1).
4799 Encryption and checksum methods
4801 The following encryption and checksum mechanisms must be supported.
4802 Implementations may support other mechanisms as well, but the
4803 additional mechanisms may only be used when communicating with
4804 principals known to also support them: Encryption: DES-CBC-MD5
4805 Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5
4809 All implementations must understand hierarchical realms in both the
4810 Internet Domain and the X.500 style. When a ticket granting ticket
4811 for an unknown realm is requested, the KDC must be able to determine
4812 the names of the intermediate realms between the KDCs realm and the
4818 Kohl & Neuman [Page 86]
4820 RFC 1510 Kerberos September 1993
4823 Transited field encoding
4825 DOMAIN-X500-COMPRESS (described in section 3.3.3.1) must be
4826 supported. Alternative encodings may be supported, but they may be
4827 used only when that encoding is supported by ALL intermediate realms.
4829 Pre-authentication methods
4831 The TGS-REQ method must be supported. The TGS-REQ method is not used
4832 on the initial request. The PA-ENC-TIMESTAMP method must be supported
4833 by clients but whether it is enabled by default may be determined on
4834 a realm by realm basis. If not used in the initial request and the
4835 error KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENCTIMESTAMP
4836 as an acceptable method, the client should retry the initial request
4837 using the PA-ENC-TIMESTAMP preauthentication method. Servers need not
4838 support the PAENC-TIMESTAMP method, but if not supported the server
4839 should ignore the presence of PA-ENC-TIMESTAMP pre-authentication in
4842 Mutual authentication
4844 Mutual authentication (via the KRB_AP_REP message) must be supported.
4846 Ticket addresses and flags
4848 All KDC's must pass on tickets that carry no addresses (i.e., if a
4849 TGT contains no addresses, the KDC will return derivative tickets),
4850 but each realm may set its own policy for issuing such tickets, and
4851 each application server will set its own policy with respect to
4852 accepting them. By default, servers should not accept them.
4854 Proxies and forwarded tickets must be supported. Individual realms
4855 and application servers can set their own policy on when such tickets
4858 All implementations must recognize renewable and postdated tickets,
4859 but need not actually implement them. If these options are not
4860 supported, the starttime and endtime in the ticket shall specify a
4861 ticket's entire useful life. When a postdated ticket is decoded by a
4862 server, all implementations shall make the presence of the postdated
4863 flag visible to the calling server.
4865 User-to-user authentication
4867 Support for user to user authentication (via the ENC-TKTIN-SKEY KDC
4868 option) must be provided by implementations, but individual realms
4869 may decide as a matter of policy to reject such requests on a per-
4870 principal or realm-wide basis.
4874 Kohl & Neuman [Page 87]
4876 RFC 1510 Kerberos September 1993
4881 Implementations must pass all authorization data subfields from
4882 ticket-granting tickets to any derivative tickets unless directed to
4883 suppress a subfield as part of the definition of that registered
4884 subfield type (it is never incorrect to pass on a subfield, and no
4885 registered subfield types presently specify suppression at the KDC).
4887 Implementations must make the contents of any authorization data
4888 subfields available to the server when a ticket is used.
4889 Implementations are not required to allow clients to specify the
4890 contents of the authorization data fields.
4892 9.2. Recommended KDC values
4894 Following is a list of recommended values for a KDC implementation,
4895 based on the list of suggested configuration constants (see section
4898 minimum lifetime 5 minutes
4900 maximum renewable lifetime 1 week
4902 maximum ticket lifetime 1 day
4904 empty addresses only when suitable restrictions appear
4905 in authorization data
4907 proxiable, etc. Allowed.
4911 Early versions of this document, describing version 4 of the
4912 protocol, were written by Jennifer Steiner (formerly at Project
4913 Athena); these drafts provided an excellent starting point for this
4914 current version 5 specification. Many people in the Internet
4915 community have contributed ideas and suggested protocol changes for
4916 version 5. Notable contributions came from Ted Anderson, Steve
4917 Bellovin and Michael Merritt [17], Daniel Bernstein, Mike Burrows,
4918 Donald Davis, Ravi Ganesan, Morrie Gasser, Virgil Gligor, Bill
4919 Griffeth, Mark Lillibridge, Mark Lomas, Steve Lunt, Piers McMahon,
4920 Joe Pato, William Sommerfeld, Stuart Stubblebine, Ralph Swick, Ted
4921 T'so, and Stanley Zanarotti. Many others commented and helped shape
4922 this specification into its current form.
4930 Kohl & Neuman [Page 88]
4932 RFC 1510 Kerberos September 1993
4937 [1] Miller, S., Neuman, C., Schiller, J., and J. Saltzer, "Section
4938 E.2.1: Kerberos Authentication and Authorization System",
4939 M.I.T. Project Athena, Cambridge, Massachusetts, December 21,
4942 [2] Steiner, J., Neuman, C., and J. Schiller, "Kerberos: An
4943 Authentication Service for Open Network Systems", pp. 191-202 in
4944 Usenix Conference Proceedings, Dallas, Texas, February, 1988.
4946 [3] Needham, R., and M. Schroeder, "Using Encryption for
4947 Authentication in Large Networks of Computers", Communications
4948 of the ACM, Vol. 21 (12), pp. 993-999, December 1978.
4950 [4] Denning, D., and G. Sacco, "Time stamps in Key Distribution
4951 Protocols", Communications of the ACM, Vol. 24 (8), pp. 533-536,
4954 [5] Kohl, J., Neuman, C., and T. Ts'o, "The Evolution of the
4955 Kerberos Authentication Service", in an IEEE Computer Society
4956 Text soon to be published, June 1992.
4958 [6] Davis, D., and R. Swick, "Workstation Services and Kerberos
4959 Authentication at Project Athena", Technical Memorandum TM-424,
4960 MIT Laboratory for Computer Science, February 1990.
4962 [7] Levine, P., Gretzinger, M, Diaz, J., Sommerfeld, W., and K.
4963 Raeburn, "Section E.1: Service Management System, M.I.T.
4964 Project Athena, Cambridge, Mas sachusetts (1987).
4966 [8] CCITT, Recommendation X.509: The Directory Authentication
4967 Framework, December 1988.
4969 [9] Neuman, C., "Proxy-Based Authorization and Accounting for
4970 Distributed Systems," in Proceedings of the 13th International
4971 Conference on Distributed Computing Systems", Pittsburgh, PA,
4974 [10] Pato, J., "Using Pre-Authentication to Avoid Password Guessing
4975 Attacks", Open Software Foundation DCE Request for Comments 26,
4978 [11] National Bureau of Standards, U.S. Department of Commerce, "Data
4979 Encryption Standard", Federal Information Processing Standards
4980 Publication 46, Washington, DC (1977).
4986 Kohl & Neuman [Page 89]
4988 RFC 1510 Kerberos September 1993
4991 [12] National Bureau of Standards, U.S. Department of Commerce, "DES
4992 Modes of Operation", Federal Information Processing Standards
4993 Publication 81, Springfield, VA, December 1980.
4995 [13] Stubblebine S., and V. Gligor, "On Message Integrity in
4996 Cryptographic Protocols", in Proceedings of the IEEE Symposium
4997 on Research in Security and Privacy, Oakland, California, May
5000 [14] International Organization for Standardization, "ISO Information
5001 Processing Systems - Data Communication High-Level Data Link
5002 Control Procedure - Frame Structure", IS 3309, October 1984, 3rd
5005 [15] Rivest, R., "The MD4 Message Digest Algorithm", RFC 1320, MIT
5006 Laboratory for Computer Science, April 1992.
5008 [16] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, MIT
5009 Laboratory for Computer Science, April 1992.
5011 [17] Bellovin S., and M. Merritt, "Limitations of the Kerberos
5012 Authentication System", Computer Communications Review, Vol.
5013 20(5), pp. 119-132, October 1990.
5015 12. Security Considerations
5017 Security issues are discussed throughout this memo.
5019 13. Authors' Addresses
5022 Digital Equipment Corporation
5023 110 Spit Brook Road, M/S ZKO3-3/U14
5027 EMail: jtkohl@zk3.dec.com
5031 USC/Information Sciences Institute
5032 4676 Admiralty Way #1001
5033 Marina del Rey, CA 90292-6695
5042 Kohl & Neuman [Page 90]
5044 RFC 1510 Kerberos September 1993
5047 A. Pseudo-code for protocol processing
5049 This appendix provides pseudo-code describing how the messages are to
5050 be constructed and interpreted by clients and servers.
5052 A.1. KRB_AS_REQ generation
5053 request.pvno := protocol version; /* pvno = 5 */
5054 request.msg-type := message type; /* type = KRB_AS_REQ */
5056 if(pa_enc_timestamp_required) then
5057 request.padata.padata-type = PA-ENC-TIMESTAMP;
5059 padata-body.patimestamp,pausec = system_time;
5060 encrypt padata-body into request.padata.padata-value
5061 using client.key; /* derived from password */
5064 body.kdc-options := users's preferences;
5065 body.cname := user's name;
5066 body.realm := user's realm;
5067 body.sname := service's name; /* usually "krbtgt",
5069 if (body.kdc-options.POSTDATED is set) then
5070 body.from := requested starting time;
5074 body.till := requested end time;
5075 if (body.kdc-options.RENEWABLE is set) then
5076 body.rtime := requested final renewal time;
5078 body.nonce := random_nonce();
5079 body.etype := requested etypes;
5080 if (user supplied addresses) then
5081 body.addresses := user's addresses;
5083 omit body.addresses;
5085 omit body.enc-authorization-data;
5086 request.req-body := body;
5088 kerberos := lookup(name of local kerberos server (or servers));
5089 send(packet,kerberos);
5093 retry or use alternate server;
5098 Kohl & Neuman [Page 91]
5100 RFC 1510 Kerberos September 1993
5103 A.2. KRB_AS_REQ verification and KRB_AS_REP generation
5104 decode message into req;
5106 client := lookup(req.cname,req.realm);
5107 server := lookup(req.sname,req.realm);
5109 kdc_time := system_time.seconds;
5112 /* no client in Database */
5113 error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN);
5116 /* no server in Database */
5117 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
5120 if(client.pa_enc_timestamp_required and
5121 pa_enc_timestamp not present) then
5122 error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP));
5125 if(pa_enc_timestamp present) then
5126 decrypt req.padata-value into decrypted_enc_timestamp
5128 using auth_hdr.authenticator.subkey;
5129 if (decrypt_error()) then
5130 error_out(KRB_AP_ERR_BAD_INTEGRITY);
5131 if(decrypted_enc_timestamp is not within allowable
5132 skew) then error_out(KDC_ERR_PREAUTH_FAILED);
5134 if(decrypted_enc_timestamp and usec is replay)
5135 error_out(KDC_ERR_PREAUTH_FAILED);
5137 add decrypted_enc_timestamp and usec to replay cache;
5140 use_etype := first supported etype in req.etypes;
5142 if (no support for req.etypes) then
5143 error_out(KDC_ERR_ETYPE_NOSUPP);
5146 new_tkt.vno := ticket version; /* = 5 */
5147 new_tkt.sname := req.sname;
5148 new_tkt.srealm := req.srealm;
5149 reset all flags in new_tkt.flags;
5154 Kohl & Neuman [Page 92]
5156 RFC 1510 Kerberos September 1993
5159 /* It should be noted that local policy may affect the */
5160 /* processing of any of these flags. For example, some */
5161 /* realms may refuse to issue renewable tickets */
5163 if (req.kdc-options.FORWARDABLE is set) then
5164 set new_tkt.flags.FORWARDABLE;
5166 if (req.kdc-options.PROXIABLE is set) then
5167 set new_tkt.flags.PROXIABLE;
5169 if (req.kdc-options.ALLOW-POSTDATE is set) then
5170 set new_tkt.flags.ALLOW-POSTDATE;
5172 if ((req.kdc-options.RENEW is set) or
5173 (req.kdc-options.VALIDATE is set) or
5174 (req.kdc-options.PROXY is set) or
5175 (req.kdc-options.FORWARDED is set) or
5176 (req.kdc-options.ENC-TKT-IN-SKEY is set)) then
5177 error_out(KDC_ERR_BADOPTION);
5180 new_tkt.session := random_session_key();
5181 new_tkt.cname := req.cname;
5182 new_tkt.crealm := req.crealm;
5183 new_tkt.transited := empty_transited_field();
5185 new_tkt.authtime := kdc_time;
5187 if (req.kdc-options.POSTDATED is set) then
5188 if (against_postdate_policy(req.from)) then
5189 error_out(KDC_ERR_POLICY);
5191 set new_tkt.flags.INVALID;
5192 new_tkt.starttime := req.from;
5194 omit new_tkt.starttime; /* treated as authtime when
5197 if (req.till = 0) then
5203 new_tkt.endtime := min(till,
5204 new_tkt.starttime+client.max_life,
5205 new_tkt.starttime+server.max_life,
5206 new_tkt.starttime+max_life_for_realm);
5210 Kohl & Neuman [Page 93]
5212 RFC 1510 Kerberos September 1993
5215 if ((req.kdc-options.RENEWABLE-OK is set) and
5216 (new_tkt.endtime < req.till)) then
5217 /* we set the RENEWABLE option for later processing */
5218 set req.kdc-options.RENEWABLE;
5219 req.rtime := req.till;
5222 if (req.rtime = 0) then
5228 if (req.kdc-options.RENEWABLE is set) then
5229 set new_tkt.flags.RENEWABLE;
5230 new_tkt.renew-till := min(rtime,
5231 new_tkt.starttime+client.max_rlife,
5232 new_tkt.starttime+server.max_rlife,
5233 new_tkt.starttime+max_rlife_for_realm);
5235 omit new_tkt.renew-till; /* only present if RENEWABLE */
5238 if (req.addresses) then
5239 new_tkt.caddr := req.addresses;
5244 new_tkt.authorization_data := empty_authorization_data();
5246 encode to-be-encrypted part of ticket into OCTET STRING;
5247 new_tkt.enc-part := encrypt OCTET STRING
5248 using etype_for_key(server.key), server.key, server.p_kvno;
5251 /* Start processing the response */
5254 resp.msg-type := KRB_AS_REP;
5255 resp.cname := req.cname;
5256 resp.crealm := req.realm;
5257 resp.ticket := new_tkt;
5259 resp.key := new_tkt.session;
5260 resp.last-req := fetch_last_request_info(client);
5261 resp.nonce := req.nonce;
5262 resp.key-expiration := client.expiration;
5266 Kohl & Neuman [Page 94]
5268 RFC 1510 Kerberos September 1993
5271 resp.flags := new_tkt.flags;
5273 resp.authtime := new_tkt.authtime;
5274 resp.starttime := new_tkt.starttime;
5275 resp.endtime := new_tkt.endtime;
5277 if (new_tkt.flags.RENEWABLE) then
5278 resp.renew-till := new_tkt.renew-till;
5281 resp.realm := new_tkt.realm;
5282 resp.sname := new_tkt.sname;
5284 resp.caddr := new_tkt.caddr;
5286 encode body of reply into OCTET STRING;
5288 resp.enc-part := encrypt OCTET STRING
5289 using use_etype, client.key, client.p_kvno;
5292 A.3. KRB_AS_REP verification
5293 decode response into resp;
5295 if (resp.msg-type = KRB_ERROR) then
5296 if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP))
5297 then set pa_enc_timestamp_required;
5300 process_error(resp);
5304 /* On error, discard the response, and zero the session key */
5305 /* from the response immediately */
5307 key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype,
5309 unencrypted part of resp := decode of decrypt of resp.enc-part
5310 using resp.enc-part.etype and key;
5313 if (common_as_rep_tgs_rep_checks fail) then
5318 if near(resp.princ_exp) then
5322 Kohl & Neuman [Page 95]
5324 RFC 1510 Kerberos September 1993
5327 print(warning message);
5329 save_for_later(ticket,session,client,server,times,flags);
5331 A.4. KRB_AS_REP and KRB_TGS_REP common checks
5332 if (decryption_error() or
5333 (req.cname != resp.cname) or
5334 (req.realm != resp.crealm) or
5335 (req.sname != resp.sname) or
5336 (req.realm != resp.realm) or
5337 (req.nonce != resp.nonce) or
5338 (req.addresses != resp.caddr)) then
5340 return KRB_AP_ERR_MODIFIED;
5343 /* make sure no flags are set that shouldn't be, and that */
5344 /* all that should be are set */
5345 if (!check_flags_for_compatability(req.kdc-options,resp.flags))
5346 then destroy resp.key;
5347 return KRB_AP_ERR_MODIFIED;
5350 if ((req.from = 0) and
5351 (resp.starttime is not within allowable skew)) then
5353 return KRB_AP_ERR_SKEW;
5355 if ((req.from != 0) and (req.from != resp.starttime)) then
5357 return KRB_AP_ERR_MODIFIED;
5359 if ((req.till != 0) and (resp.endtime > req.till)) then
5361 return KRB_AP_ERR_MODIFIED;
5364 if ((req.kdc-options.RENEWABLE is set) and
5365 (req.rtime != 0) and (resp.renew-till > req.rtime)) then
5367 return KRB_AP_ERR_MODIFIED;
5369 if ((req.kdc-options.RENEWABLE-OK is set) and
5370 (resp.flags.RENEWABLE) and
5372 (resp.renew-till > req.till)) then
5374 return KRB_AP_ERR_MODIFIED;
5378 Kohl & Neuman [Page 96]
5380 RFC 1510 Kerberos September 1993
5385 A.5. KRB_TGS_REQ generation
5386 /* Note that make_application_request might have to */
5387 /* recursivly call this routine to get the appropriate */
5388 /* ticket-granting ticket */
5390 request.pvno := protocol version; /* pvno = 5 */
5391 request.msg-type := message type; /* type = KRB_TGS_REQ */
5393 body.kdc-options := users's preferences;
5394 /* If the TGT is not for the realm of the end-server */
5395 /* then the sname will be for a TGT for the end-realm */
5396 /* and the realm of the requested ticket (body.realm) */
5397 /* will be that of the TGS to which the TGT we are */
5398 /* sending applies */
5399 body.sname := service's name;
5400 body.realm := service's realm;
5402 if (body.kdc-options.POSTDATED is set) then
5403 body.from := requested starting time;
5407 body.till := requested end time;
5408 if (body.kdc-options.RENEWABLE is set) then
5409 body.rtime := requested final renewal time;
5411 body.nonce := random_nonce();
5412 body.etype := requested etypes;
5413 if (user supplied addresses) then
5414 body.addresses := user's addresses;
5416 omit body.addresses;
5419 body.enc-authorization-data := user-supplied data;
5420 if (body.kdc-options.ENC-TKT-IN-SKEY) then
5421 body.additional-tickets_ticket := second TGT;
5424 request.req-body := body;
5425 check := generate_checksum (req.body,checksumtype);
5427 request.padata[0].padata-type := PA-TGS-REQ;
5428 request.padata[0].padata-value := create a KRB_AP_REQ using
5429 the TGT and checksum
5434 Kohl & Neuman [Page 97]
5436 RFC 1510 Kerberos September 1993
5439 /* add in any other padata as required/supplied */
5441 kerberos := lookup(name of local kerberose server (or servers));
5442 send(packet,kerberos);
5446 retry or use alternate server;
5449 A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation
5450 /* note that reading the application request requires first
5451 determining the server for which a ticket was issued, and
5452 choosing the correct key for decryption. The name of the
5453 server appears in the plaintext part of the ticket. */
5455 if (no KRB_AP_REQ in req.padata) then
5456 error_out(KDC_ERR_PADATA_TYPE_NOSUPP);
5458 verify KRB_AP_REQ in req.padata;
5460 /* Note that the realm in which the Kerberos server is
5461 operating is determined by the instance from the
5462 ticket-granting ticket. The realm in the ticket-granting
5463 ticket is the realm under which the ticket granting ticket was
5464 issued. It is possible for a single Kerberos server to
5465 support more than one realm. */
5467 auth_hdr := KRB_AP_REQ;
5468 tgt := auth_hdr.ticket;
5470 if (tgt.sname is not a TGT for local realm and is not
5471 req.sname) then error_out(KRB_AP_ERR_NOT_US);
5473 realm := realm_tgt_is_for(tgt);
5475 decode remainder of request;
5477 if (auth_hdr.authenticator.cksum is missing) then
5478 error_out(KRB_AP_ERR_INAPP_CKSUM);
5480 if (auth_hdr.authenticator.cksum type is not supported) then
5481 error_out(KDC_ERR_SUMTYPE_NOSUPP);
5483 if (auth_hdr.authenticator.cksum is not both collision-proof
5485 error_out(KRB_AP_ERR_INAPP_CKSUM);
5490 Kohl & Neuman [Page 98]
5492 RFC 1510 Kerberos September 1993
5495 set computed_checksum := checksum(req);
5496 if (computed_checksum != auth_hdr.authenticatory.cksum) then
5497 error_out(KRB_AP_ERR_MODIFIED);
5500 server := lookup(req.sname,realm);
5503 if (is_foreign_tgt_name(server)) then
5504 server := best_intermediate_tgs(server);
5506 /* no server in Database */
5507 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
5511 session := generate_random_session_key();
5514 use_etype := first supported etype in req.etypes;
5516 if (no support for req.etypes) then
5517 error_out(KDC_ERR_ETYPE_NOSUPP);
5520 new_tkt.vno := ticket version; /* = 5 */
5521 new_tkt.sname := req.sname;
5522 new_tkt.srealm := realm;
5523 reset all flags in new_tkt.flags;
5525 /* It should be noted that local policy may affect the */
5526 /* processing of any of these flags. For example, some */
5527 /* realms may refuse to issue renewable tickets */
5529 new_tkt.caddr := tgt.caddr;
5530 resp.caddr := NULL; /* We only include this if they change */
5531 if (req.kdc-options.FORWARDABLE is set) then
5532 if (tgt.flags.FORWARDABLE is reset) then
5533 error_out(KDC_ERR_BADOPTION);
5535 set new_tkt.flags.FORWARDABLE;
5537 if (req.kdc-options.FORWARDED is set) then
5538 if (tgt.flags.FORWARDABLE is reset) then
5539 error_out(KDC_ERR_BADOPTION);
5541 set new_tkt.flags.FORWARDED;
5542 new_tkt.caddr := req.addresses;
5546 Kohl & Neuman [Page 99]
5548 RFC 1510 Kerberos September 1993
5551 resp.caddr := req.addresses;
5553 if (tgt.flags.FORWARDED is set) then
5554 set new_tkt.flags.FORWARDED;
5557 if (req.kdc-options.PROXIABLE is set) then
5558 if (tgt.flags.PROXIABLE is reset)
5559 error_out(KDC_ERR_BADOPTION);
5561 set new_tkt.flags.PROXIABLE;
5563 if (req.kdc-options.PROXY is set) then
5564 if (tgt.flags.PROXIABLE is reset) then
5565 error_out(KDC_ERR_BADOPTION);
5567 set new_tkt.flags.PROXY;
5568 new_tkt.caddr := req.addresses;
5569 resp.caddr := req.addresses;
5572 if (req.kdc-options.POSTDATE is set) then
5573 if (tgt.flags.POSTDATE is reset)
5574 error_out(KDC_ERR_BADOPTION);
5576 set new_tkt.flags.POSTDATE;
5578 if (req.kdc-options.POSTDATED is set) then
5579 if (tgt.flags.POSTDATE is reset) then
5580 error_out(KDC_ERR_BADOPTION);
5582 set new_tkt.flags.POSTDATED;
5583 set new_tkt.flags.INVALID;
5584 if (against_postdate_policy(req.from)) then
5585 error_out(KDC_ERR_POLICY);
5587 new_tkt.starttime := req.from;
5591 if (req.kdc-options.VALIDATE is set) then
5592 if (tgt.flags.INVALID is reset) then
5593 error_out(KDC_ERR_POLICY);
5595 if (tgt.starttime > kdc_time) then
5596 error_out(KRB_AP_ERR_NYV);
5598 if (check_hot_list(tgt)) then
5602 Kohl & Neuman [Page 100]
5604 RFC 1510 Kerberos September 1993
5607 error_out(KRB_AP_ERR_REPEAT);
5610 reset new_tkt.flags.INVALID;
5613 if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW,
5614 and those already processed) is set) then
5615 error_out(KDC_ERR_BADOPTION);
5618 new_tkt.authtime := tgt.authtime;
5620 if (req.kdc-options.RENEW is set) then
5621 /* Note that if the endtime has already passed, the ticket */
5622 /* would have been rejected in the initial authentication */
5623 /* stage, so there is no need to check again here */
5624 if (tgt.flags.RENEWABLE is reset) then
5625 error_out(KDC_ERR_BADOPTION);
5627 if (tgt.renew-till >= kdc_time) then
5628 error_out(KRB_AP_ERR_TKT_EXPIRED);
5631 new_tkt.starttime := kdc_time;
5632 old_life := tgt.endttime - tgt.starttime;
5633 new_tkt.endtime := min(tgt.renew-till,
5634 new_tkt.starttime + old_life);
5636 new_tkt.starttime := kdc_time;
5637 if (req.till = 0) then
5642 new_tkt.endtime := min(till,
5643 new_tkt.starttime+client.max_life,
5644 new_tkt.starttime+server.max_life,
5645 new_tkt.starttime+max_life_for_realm,
5648 if ((req.kdc-options.RENEWABLE-OK is set) and
5649 (new_tkt.endtime < req.till) and
5650 (tgt.flags.RENEWABLE is set) then
5651 /* we set the RENEWABLE option for later */
5653 set req.kdc-options.RENEWABLE;
5654 req.rtime := min(req.till, tgt.renew-till);
5658 Kohl & Neuman [Page 101]
5660 RFC 1510 Kerberos September 1993
5666 if (req.rtime = 0) then
5672 if ((req.kdc-options.RENEWABLE is set) and
5673 (tgt.flags.RENEWABLE is set)) then
5674 set new_tkt.flags.RENEWABLE;
5675 new_tkt.renew-till := min(rtime,
5676 new_tkt.starttime+client.max_rlife,
5677 new_tkt.starttime+server.max_rlife,
5678 new_tkt.starttime+max_rlife_for_realm,
5681 new_tkt.renew-till := OMIT;
5682 /* leave the renew-till field out */
5684 if (req.enc-authorization-data is present) then
5685 decrypt req.enc-authorization-data
5686 into decrypted_authorization_data
5687 using auth_hdr.authenticator.subkey;
5688 if (decrypt_error()) then
5689 error_out(KRB_AP_ERR_BAD_INTEGRITY);
5692 new_tkt.authorization_data :=
5693 req.auth_hdr.ticket.authorization_data +
5694 decrypted_authorization_data;
5696 new_tkt.key := session;
5697 new_tkt.crealm := tgt.crealm;
5698 new_tkt.cname := req.auth_hdr.ticket.cname;
5700 if (realm_tgt_is_for(tgt) := tgt.realm) then
5701 /* tgt issued by local realm */
5702 new_tkt.transited := tgt.transited;
5704 /* was issued for this realm by some other realm */
5705 if (tgt.transited.tr-type not supported) then
5706 error_out(KDC_ERR_TRTYPE_NOSUPP);
5709 := compress_transited(tgt.transited + tgt.realm)
5714 Kohl & Neuman [Page 102]
5716 RFC 1510 Kerberos September 1993
5719 encode encrypted part of new_tkt into OCTET STRING;
5720 if (req.kdc-options.ENC-TKT-IN-SKEY is set) then
5721 if (server not specified) then
5722 server = req.second_ticket.client;
5724 if ((req.second_ticket is not a TGT) or
5725 (req.second_ticket.client != server)) then
5726 error_out(KDC_ERR_POLICY);
5729 new_tkt.enc-part := encrypt OCTET STRING using
5730 using etype_for_key(second-ticket.key),
5733 new_tkt.enc-part := encrypt OCTET STRING
5734 using etype_for_key(server.key), server.key,
5739 resp.msg-type := KRB_TGS_REP;
5740 resp.crealm := tgt.crealm;
5741 resp.cname := tgt.cname;
5742 resp.ticket := new_tkt;
5744 resp.key := session;
5745 resp.nonce := req.nonce;
5746 resp.last-req := fetch_last_request_info(client);
5747 resp.flags := new_tkt.flags;
5749 resp.authtime := new_tkt.authtime;
5750 resp.starttime := new_tkt.starttime;
5751 resp.endtime := new_tkt.endtime;
5753 omit resp.key-expiration;
5755 resp.sname := new_tkt.sname;
5756 resp.realm := new_tkt.realm;
5758 if (new_tkt.flags.RENEWABLE) then
5759 resp.renew-till := new_tkt.renew-till;
5763 encode body of reply into OCTET STRING;
5765 if (req.padata.authenticator.subkey)
5766 resp.enc-part := encrypt OCTET STRING using use_etype,
5770 Kohl & Neuman [Page 103]
5772 RFC 1510 Kerberos September 1993
5775 req.padata.authenticator.subkey;
5776 else resp.enc-part := encrypt OCTET STRING
5777 using use_etype, tgt.key;
5781 A.7. KRB_TGS_REP verification
5782 decode response into resp;
5784 if (resp.msg-type = KRB_ERROR) then
5785 process_error(resp);
5789 /* On error, discard the response, and zero the session key from
5790 the response immediately */
5792 if (req.padata.authenticator.subkey)
5793 unencrypted part of resp :=
5794 decode of decrypt of resp.enc-part
5795 using resp.enc-part.etype and subkey;
5796 else unencrypted part of resp :=
5797 decode of decrypt of resp.enc-part
5798 using resp.enc-part.etype and tgt's session key;
5799 if (common_as_rep_tgs_rep_checks fail) then
5804 check authorization_data as necessary;
5805 save_for_later(ticket,session,client,server,times,flags);
5807 A.8. Authenticator generation
5808 body.authenticator-vno := authenticator vno; /* = 5 */
5809 body.cname, body.crealm := client name;
5810 if (supplying checksum) then
5811 body.cksum := checksum;
5814 body.ctime, body.cusec := system_time;
5815 if (selecting sub-session key) then
5816 select sub-session key;
5817 body.subkey := sub-session key;
5819 if (using sequence numbers) then
5820 select initial sequence number;
5821 body.seq-number := initial sequence;
5826 Kohl & Neuman [Page 104]
5828 RFC 1510 Kerberos September 1993
5831 A.9. KRB_AP_REQ generation
5832 obtain ticket and session_key from cache;
5834 packet.pvno := protocol version; /* 5 */
5835 packet.msg-type := message type; /* KRB_AP_REQ */
5837 if (desired(MUTUAL_AUTHENTICATION)) then
5838 set packet.ap-options.MUTUAL-REQUIRED;
5840 reset packet.ap-options.MUTUAL-REQUIRED;
5842 if (using session key for ticket) then
5843 set packet.ap-options.USE-SESSION-KEY;
5845 reset packet.ap-options.USE-SESSION-KEY;
5847 packet.ticket := ticket; /* ticket */
5848 generate authenticator;
5849 encode authenticator into OCTET STRING;
5850 encrypt OCTET STRING into packet.authenticator
5853 A.10. KRB_AP_REQ verification
5855 if (packet.pvno != 5) then
5856 either process using other protocol spec
5857 or error_out(KRB_AP_ERR_BADVERSION);
5859 if (packet.msg-type != KRB_AP_REQ) then
5860 error_out(KRB_AP_ERR_MSG_TYPE);
5862 if (packet.ticket.tkt_vno != 5) then
5863 either process using other protocol spec
5864 or error_out(KRB_AP_ERR_BADVERSION);
5866 if (packet.ap_options.USE-SESSION-KEY is set) then
5867 retrieve session key from ticket-granting ticket for
5868 packet.ticket.{sname,srealm,enc-part.etype};
5870 retrieve service key for
5871 packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno};
5873 if (no_key_available) then
5874 if (cannot_find_specified_skvno) then
5875 error_out(KRB_AP_ERR_BADKEYVER);
5877 error_out(KRB_AP_ERR_NOKEY);
5882 Kohl & Neuman [Page 105]
5884 RFC 1510 Kerberos September 1993
5888 decrypt packet.ticket.enc-part into decr_ticket
5889 using retrieved key;
5890 if (decryption_error()) then
5891 error_out(KRB_AP_ERR_BAD_INTEGRITY);
5893 decrypt packet.authenticator into decr_authenticator
5894 using decr_ticket.key;
5895 if (decryption_error()) then
5896 error_out(KRB_AP_ERR_BAD_INTEGRITY);
5898 if (decr_authenticator.{cname,crealm} !=
5899 decr_ticket.{cname,crealm}) then
5900 error_out(KRB_AP_ERR_BADMATCH);
5902 if (decr_ticket.caddr is present) then
5903 if (sender_address(packet) is not in decr_ticket.caddr)
5904 then error_out(KRB_AP_ERR_BADADDR);
5906 elseif (application requires addresses) then
5907 error_out(KRB_AP_ERR_BADADDR);
5909 if (not in_clock_skew(decr_authenticator.ctime,
5910 decr_authenticator.cusec)) then
5911 error_out(KRB_AP_ERR_SKEW);
5913 if (repeated(decr_authenticator.{ctime,cusec,cname,crealm}))
5914 then error_out(KRB_AP_ERR_REPEAT);
5916 save_identifier(decr_authenticator.{ctime,cusec,cname,crealm});
5918 if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or
5919 (decr_ticket.flags.INVALID is set)) then
5920 /* it hasn't yet become valid */
5921 error_out(KRB_AP_ERR_TKT_NYV);
5923 if (system_time-decr_ticket.endtime > CLOCK_SKEW) then
5924 error_out(KRB_AP_ERR_TKT_EXPIRED);
5926 /* caller must check decr_ticket.flags for any pertinent */
5928 return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED);
5930 A.11. KRB_AP_REP generation
5931 packet.pvno := protocol version; /* 5 */
5932 packet.msg-type := message type; /* KRB_AP_REP */
5933 body.ctime := packet.ctime;
5934 body.cusec := packet.cusec;
5938 Kohl & Neuman [Page 106]
5940 RFC 1510 Kerberos September 1993
5943 if (selecting sub-session key) then
5944 select sub-session key;
5945 body.subkey := sub-session key;
5947 if (using sequence numbers) then
5948 select initial sequence number;
5949 body.seq-number := initial sequence;
5952 encode body into OCTET STRING;
5954 select encryption type;
5955 encrypt OCTET STRING into packet.enc-part;
5957 A.12. KRB_AP_REP verification
5959 if (packet.pvno != 5) then
5960 either process using other protocol spec
5961 or error_out(KRB_AP_ERR_BADVERSION);
5963 if (packet.msg-type != KRB_AP_REP) then
5964 error_out(KRB_AP_ERR_MSG_TYPE);
5966 cleartext := decrypt(packet.enc-part)
5967 using ticket's session key;
5968 if (decryption_error()) then
5969 error_out(KRB_AP_ERR_BAD_INTEGRITY);
5971 if (cleartext.ctime != authenticator.ctime) then
5972 error_out(KRB_AP_ERR_MUT_FAIL);
5974 if (cleartext.cusec != authenticator.cusec) then
5975 error_out(KRB_AP_ERR_MUT_FAIL);
5977 if (cleartext.subkey is present) then
5978 save cleartext.subkey for future use;
5980 if (cleartext.seq-number is present) then
5981 save cleartext.seq-number for future verifications;
5983 return(AUTHENTICATION_SUCCEEDED);
5985 A.13. KRB_SAFE generation
5986 collect user data in buffer;
5988 /* assemble packet: */
5989 packet.pvno := protocol version; /* 5 */
5990 packet.msg-type := message type; /* KRB_SAFE */
5994 Kohl & Neuman [Page 107]
5996 RFC 1510 Kerberos September 1993
5999 body.user-data := buffer; /* DATA */
6000 if (using timestamp) then
6002 body.timestamp, body.usec := system_time;
6004 if (using sequence numbers) then
6005 body.seq-number := sequence number;
6007 body.s-address := sender host addresses;
6008 if (only one recipient) then
6009 body.r-address := recipient host address;
6011 checksum.cksumtype := checksum type;
6012 compute checksum over body;
6013 checksum.checksum := checksum value; /* checksum.checksum */
6014 packet.cksum := checksum;
6015 packet.safe-body := body;
6017 A.14. KRB_SAFE verification
6019 if (packet.pvno != 5) then
6020 either process using other protocol spec
6021 or error_out(KRB_AP_ERR_BADVERSION);
6023 if (packet.msg-type != KRB_SAFE) then
6024 error_out(KRB_AP_ERR_MSG_TYPE);
6026 if (packet.checksum.cksumtype is not both collision-proof
6028 error_out(KRB_AP_ERR_INAPP_CKSUM);
6030 if (safe_priv_common_checks_ok(packet)) then
6031 set computed_checksum := checksum(packet.body);
6032 if (computed_checksum != packet.checksum) then
6033 error_out(KRB_AP_ERR_MODIFIED);
6035 return (packet, PACKET_IS_GENUINE);
6037 return common_checks_error;
6040 A.15. KRB_SAFE and KRB_PRIV common checks
6041 if (packet.s-address != O/S_sender(packet)) then
6042 /* O/S report of sender not who claims to have sent it */
6043 error_out(KRB_AP_ERR_BADADDR);
6045 if ((packet.r-address is present) and
6046 (packet.r-address != local_host_address)) then
6050 Kohl & Neuman [Page 108]
6052 RFC 1510 Kerberos September 1993
6055 /* was not sent to proper place */
6056 error_out(KRB_AP_ERR_BADADDR);
6058 if (((packet.timestamp is present) and
6059 (not in_clock_skew(packet.timestamp,packet.usec))) or
6060 (packet.timestamp is not present and timestamp expected))
6061 then error_out(KRB_AP_ERR_SKEW);
6063 if (repeated(packet.timestamp,packet.usec,packet.s-address))
6064 then error_out(KRB_AP_ERR_REPEAT);
6066 if (((packet.seq-number is present) and
6067 ((not in_sequence(packet.seq-number)))) or
6068 (packet.seq-number is not present and sequence expected))
6069 then error_out(KRB_AP_ERR_BADORDER);
6071 if (packet.timestamp not present and
6072 packet.seq-number not present) then
6073 error_out(KRB_AP_ERR_MODIFIED);
6076 save_identifier(packet.{timestamp,usec,s-address},
6077 sender_principal(packet));
6079 return PACKET_IS_OK;
6081 A.16. KRB_PRIV generation
6082 collect user data in buffer;
6084 /* assemble packet: */
6085 packet.pvno := protocol version; /* 5 */
6086 packet.msg-type := message type; /* KRB_PRIV */
6088 packet.enc-part.etype := encryption type;
6090 body.user-data := buffer;
6091 if (using timestamp) then
6093 body.timestamp, body.usec := system_time;
6095 if (using sequence numbers) then
6096 body.seq-number := sequence number;
6098 body.s-address := sender host addresses;
6099 if (only one recipient) then
6100 body.r-address := recipient host address;
6106 Kohl & Neuman [Page 109]
6108 RFC 1510 Kerberos September 1993
6111 encode body into OCTET STRING;
6113 select encryption type;
6114 encrypt OCTET STRING into packet.enc-part.cipher;
6116 A.17. KRB_PRIV verification
6118 if (packet.pvno != 5) then
6119 either process using other protocol spec
6120 or error_out(KRB_AP_ERR_BADVERSION);
6122 if (packet.msg-type != KRB_PRIV) then
6123 error_out(KRB_AP_ERR_MSG_TYPE);
6126 cleartext := decrypt(packet.enc-part) using negotiated key;
6127 if (decryption_error()) then
6128 error_out(KRB_AP_ERR_BAD_INTEGRITY);
6131 if (safe_priv_common_checks_ok(cleartext)) then
6132 return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED);
6134 return common_checks_error;
6137 A.18. KRB_CRED generation
6138 invoke KRB_TGS; /* obtain tickets to be provided to peer */
6140 /* assemble packet: */
6141 packet.pvno := protocol version; /* 5 */
6142 packet.msg-type := message type; /* KRB_CRED */
6144 for (tickets[n] in tickets to be forwarded) do
6145 packet.tickets[n] = tickets[n].ticket;
6148 packet.enc-part.etype := encryption type;
6150 for (ticket[n] in tickets to be forwarded) do
6151 body.ticket-info[n].key = tickets[n].session;
6152 body.ticket-info[n].prealm = tickets[n].crealm;
6153 body.ticket-info[n].pname = tickets[n].cname;
6154 body.ticket-info[n].flags = tickets[n].flags;
6155 body.ticket-info[n].authtime = tickets[n].authtime;
6156 body.ticket-info[n].starttime = tickets[n].starttime;
6157 body.ticket-info[n].endtime = tickets[n].endtime;
6158 body.ticket-info[n].renew-till = tickets[n].renew-till;
6162 Kohl & Neuman [Page 110]
6164 RFC 1510 Kerberos September 1993
6167 body.ticket-info[n].srealm = tickets[n].srealm;
6168 body.ticket-info[n].sname = tickets[n].sname;
6169 body.ticket-info[n].caddr = tickets[n].caddr;
6173 body.timestamp, body.usec := system_time;
6175 if (using nonce) then
6176 body.nonce := nonce;
6179 if (using s-address) then
6180 body.s-address := sender host addresses;
6182 if (limited recipients) then
6183 body.r-address := recipient host address;
6186 encode body into OCTET STRING;
6188 select encryption type;
6189 encrypt OCTET STRING into packet.enc-part.cipher
6190 using negotiated encryption key;
6192 A.19. KRB_CRED verification
6194 if (packet.pvno != 5) then
6195 either process using other protocol spec
6196 or error_out(KRB_AP_ERR_BADVERSION);
6198 if (packet.msg-type != KRB_CRED) then
6199 error_out(KRB_AP_ERR_MSG_TYPE);
6202 cleartext := decrypt(packet.enc-part) using negotiated key;
6203 if (decryption_error()) then
6204 error_out(KRB_AP_ERR_BAD_INTEGRITY);
6206 if ((packet.r-address is present or required) and
6207 (packet.s-address != O/S_sender(packet)) then
6208 /* O/S report of sender not who claims to have sent it */
6209 error_out(KRB_AP_ERR_BADADDR);
6211 if ((packet.r-address is present) and
6212 (packet.r-address != local_host_address)) then
6213 /* was not sent to proper place */
6214 error_out(KRB_AP_ERR_BADADDR);
6218 Kohl & Neuman [Page 111]
6220 RFC 1510 Kerberos September 1993
6224 if (not in_clock_skew(packet.timestamp,packet.usec)) then
6225 error_out(KRB_AP_ERR_SKEW);
6227 if (repeated(packet.timestamp,packet.usec,packet.s-address))
6228 then error_out(KRB_AP_ERR_REPEAT);
6230 if (packet.nonce is required or present) and
6231 (packet.nonce != expected-nonce) then
6232 error_out(KRB_AP_ERR_MODIFIED);
6235 for (ticket[n] in tickets that were forwarded) do
6236 save_for_later(ticket[n],key[n],principal[n],
6237 server[n],times[n],flags[n]);
6240 A.20. KRB_ERROR generation
6242 /* assemble packet: */
6243 packet.pvno := protocol version; /* 5 */
6244 packet.msg-type := message type; /* KRB_ERROR */
6247 packet.stime, packet.susec := system_time;
6248 packet.realm, packet.sname := server name;
6250 if (client time available) then
6251 packet.ctime, packet.cusec := client_time;
6253 packet.error-code := error code;
6254 if (client name available) then
6255 packet.cname, packet.crealm := client name;
6257 if (error text available) then
6258 packet.e-text := error text;
6260 if (error data available) then
6261 packet.e-data := error data;
6274 Kohl & Neuman [Page 112]
projects / dragonfly.git / blob