2 INTERNET-DRAFT Clifford Neuman
9 The Kerberos Network Authentication Service (V5)
14 This document is an Internet-Draft. Internet-Drafts
15 are working documents of the Internet Engineering Task Force
16 (IETF), its areas, and its working groups. Note that other
17 groups may also distribute working documents as Internet-
20 Internet-Drafts are draft documents valid for a maximum
21 of six months and may be updated, replaced, or obsoleted by
22 other documents at any time. It is inappropriate to use
23 Internet-Drafts as reference material or to cite them other
24 than as "work in progress."
26 To learn the current status of any Internet-Draft,
27 please check the "1id-abstracts.txt" listing contained in
28 the Internet-Drafts Shadow Directories on ds.internic.net
29 (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US
30 West Coast), or munnari.oz.au (Pacific Rim).
32 The distribution of this memo is unlimited. It is
33 filed as draft-ietf-cat-kerberos-revisions-00.txt, and expires
34 11 January 1998. Please send comments to:
41 This document provides an overview and specification of
42 Version 5 of the Kerberos protocol, and updates RFC1510 to
43 clarify aspects of the protocol and its intended use that
44 require more detailed or clearer explanation than was pro-
45 vided in RFC1510. This document is intended to provide a
46 detailed description of the protocol, suitable for implemen-
47 tation, together with descriptions of the appropriate use of
48 protocol messages and fields within those messages.
50 This document is not intended to describe Kerberos to
51 __________________________
52 Project Athena, Athena, and Kerberos are trademarks of
53 the Massachusetts Institute of Technology (MIT). No
54 commercial use of these trademarks may be made without
55 prior written permission of MIT.
59 Overview - 1 - Expires 11 January 1998
67 Version 5 - Specification Revision 6
70 the end user, system administrator, or application
71 developer. Higher level papers describing Version 5 of the
72 Kerberos system [1] and documenting version 4 [23], are
77 This INTERNET-DRAFT describes the concepts and model
78 upon which the Kerberos network authentication system is
79 based. It also specifies Version 5 of the Kerberos proto-
82 The motivations, goals, assumptions, and rationale
83 behind most design decisions are treated cursorily; they are
84 more fully described in a paper available in IEEE communica-
85 tions [1] and earlier in the Kerberos portion of the Athena
86 Technical Plan [2]. The protocols have been a proposed
87 standard and are being considered for advancement for draft
88 standard through the IETF standard process. Comments are
89 encouraged on the presentation, but only minor refinements
90 to the protocol as implemented or extensions that fit within
91 current protocol framework will be considered at this time.
93 Requests for addition to an electronic mailing list for
94 discussion of Kerberos, kerberos@MIT.EDU, may be addressed
95 to kerberos-request@MIT.EDU. This mailing list is gatewayed
96 onto the Usenet as the group comp.protocols.kerberos.
97 Requests for further information, including documents and
98 code availability, may be sent to info-kerberos@MIT.EDU.
102 The Kerberos model is based in part on Needham and
103 Schroeder's trusted third-party authentication protocol [4]
104 and on modifications suggested by Denning and Sacco [5].
105 The original design and implementation of Kerberos Versions
106 1 through 4 was the work of two former Project Athena staff
107 members, Steve Miller of Digital Equipment Corporation and
108 Clifford Neuman (now at the Information Sciences Institute
109 of the University of Southern California), along with Jerome
110 Saltzer, Technical Director of Project Athena, and Jeffrey
111 Schiller, MIT Campus Network Manager. Many other members of
112 Project Athena have also contributed to the work on Ker-
115 Version 5 of the Kerberos protocol (described in this
116 document) has evolved from Version 4 based on new require-
117 ments and desires for features not available in Version 4.
118 The design of Version 5 of the Kerberos protocol was led by
119 Clifford Neuman and John Kohl with much input from the com-
120 munity. The development of the MIT reference implementation
121 was led at MIT by John Kohl and Theodore T'so, with help and
122 contributed code from many others. Reference implementa-
123 tions of both version 4 and version 5 of Kerberos are pub-
124 licly available and commercial implementations have been
126 Overview - 2 - Expires 11 January 1998
134 Version 5 - Specification Revision 6
137 developed and are widely used.
139 Details on the differences between Kerberos Versions 4
140 and 5 can be found in [6].
144 Kerberos provides a means of verifying the identities
145 of principals, (e.g. a workstation user or a network server)
146 on an open (unprotected) network. This is accomplished
147 without relying on assertions by the host operating system,
148 without basing trust on host addresses, without requiring
149 physical security of all the hosts on the network, and under
150 the assumption that packets traveling along the network can
151 be read, modified, and inserted at will[1]. Kerberos per-
152 forms authentication under these conditions as a trusted
153 third-party authentication service by using conventional
154 (shared secret key[2]) cryptography. Kerberos extensions
155 have been proposed and implemented that provide for the use
156 of public key cryptography during certain phases of the
157 authentication protocol. These extensions provide for
158 authentication of users registered with public key certifi-
159 cation authorities, and allow the system to provide certain
160 benefits of public key cryptography in situations where they
163 The basic Kerberos authentication process proceeds as
164 follows: A client sends a request to the authentication
165 server (AS) requesting "credentials" for a given server.
166 The AS responds with these credentials, encrypted in the
167 client's key. The credentials consist of 1) a "ticket" for
168 the server and 2) a temporary encryption key (often called a
169 "session key"). The client transmits the ticket (which con-
170 tains the client's identity and a copy of the session key,
171 all encrypted in the server's key) to the server. The ses-
172 sion key (now shared by the client and server) is used to
173 authenticate the client, and may optionally be used to
174 __________________________
175 [1] Note, however, that many applications use Kerberos'
176 functions only upon the initiation of a stream-based
177 network connection. Unless an application subsequently
178 provides integrity protection for the data stream, the
179 identity verification applies only to the initiation of
180 the connection, and does not guarantee that subsequent
181 messages on the connection originate from the same
183 [2] Secret and private are often used interchangeably
184 in the literature. In our usage, it takes two (or
185 more) to share a secret, thus a shared DES key is a
186 secret key. Something is only private when no one but
187 its owner knows it. Thus, in public key cryptosystems,
188 one has a public and a private key.
192 Section 1. - 3 - Expires 11 January 1998
200 Version 5 - Specification Revision 6
203 authenticate the server. It may also be used to encrypt
204 further communication between the two parties or to exchange
205 a separate sub-session key to be used to encrypt further
208 Implementation of the basic protocol consists of one or
209 more authentication servers running on physically secure
210 hosts. The authentication servers maintain a database of
211 principals (i.e., users and servers) and their secret keys.
212 Code libraries provide encryption and implement the Kerberos
213 protocol. In order to add authentication to its transac-
214 tions, a typical network application adds one or two calls
215 to the Kerberos library directly or through the Generic
216 Security Services Application Programming Interface, GSSAPI,
217 described in separate document. These calls result in the
218 transmission of the necessary messages to achieve authenti-
221 The Kerberos protocol consists of several sub-protocols
222 (or exchanges). There are two basic methods by which a
223 client can ask a Kerberos server for credentials. In the
224 first approach, the client sends a cleartext request for a
225 ticket for the desired server to the AS. The reply is sent
226 encrypted in the client's secret key. Usually this request
227 is for a ticket-granting ticket (TGT) which can later be
228 used with the ticket-granting server (TGS). In the second
229 method, the client sends a request to the TGS. The client
230 uses the TGT to authenticate itself to the TGS in the same
231 manner as if it were contacting any other application server
232 that requires Kerberos authentication. The reply is
233 encrypted in the session key from the TGT. Though the pro-
234 tocol specification describes the AS and the TGS as separate
235 servers, they are implemented in practice as different pro-
236 tocol entry points within a single Kerberos server.
238 Once obtained, credentials may be used to verify the
239 identity of the principals in a transaction, to ensure the
240 integrity of messages exchanged between them, or to preserve
241 privacy of the messages. The application is free to choose
242 whatever protection may be necessary.
244 To verify the identities of the principals in a tran-
245 saction, the client transmits the ticket to the application
246 server. Since the ticket is sent "in the clear" (parts of
247 it are encrypted, but this encryption doesn't thwart replay)
248 and might be intercepted and reused by an attacker, addi-
249 tional information is sent to prove that the message ori-
250 ginated with the principal to whom the ticket was issued.
251 This information (called the authenticator) is encrypted in
252 the session key, and includes a timestamp. The timestamp
253 proves that the message was recently generated and is not a
254 replay. Encrypting the authenticator in the session key
255 proves that it was generated by a party possessing the ses-
256 sion key. Since no one except the requesting principal and
259 Section 1. - 4 - Expires 11 January 1998
267 Version 5 - Specification Revision 6
270 the server know the session key (it is never sent over the
271 network in the clear) this guarantees the identity of the
274 The integrity of the messages exchanged between princi-
275 pals can also be guaranteed using the session key (passed in
276 the ticket and contained in the credentials). This approach
277 provides detection of both replay attacks and message stream
278 modification attacks. It is accomplished by generating and
279 transmitting a collision-proof checksum (elsewhere called a
280 hash or digest function) of the client's message, keyed with
281 the session key. Privacy and integrity of the messages
282 exchanged between principals can be secured by encrypting
283 the data to be passed using the session key contained in the
284 ticket or the subsession key found in the authenticator.
286 The authentication exchanges mentioned above require
287 read-only access to the Kerberos database. Sometimes, how-
288 ever, the entries in the database must be modified, such as
289 when adding new principals or changing a principal's key.
290 This is done using a protocol between a client and a third
291 Kerberos server, the Kerberos Administration Server (KADM).
292 There is also a protocol for maintaining multiple copies of
293 the Kerberos database. Neither of these protocols are
294 described in this document.
296 1.1. Cross-Realm Operation
298 The Kerberos protocol is designed to operate across
299 organizational boundaries. A client in one organization can
300 be authenticated to a server in another. Each organization
301 wishing to run a Kerberos server establishes its own
302 "realm". The name of the realm in which a client is
303 registered is part of the client's name, and can be used by
304 the end-service to decide whether to honor a request.
306 By establishing "inter-realm" keys, the administrators
307 of two realms can allow a client authenticated in the local
308 realm to prove its identity to servers in other realms[3].
309 The exchange of inter-realm keys (a separate key may be used
310 for each direction) registers the ticket-granting service of
311 each realm as a principal in the other realm. A client is
312 then able to obtain a ticket-granting ticket for the remote
313 realm's ticket-granting service from its local realm. When
314 that ticket-granting ticket is used, the remote ticket-
315 granting service uses the inter-realm key (which usually
316 __________________________
317 [3] Of course, with appropriate permission the client
318 could arrange registration of a separately-named prin-
319 cipal in a remote realm, and engage in normal exchanges
320 with that realm's services. However, for even small
321 numbers of clients this becomes cumbersome, and more
322 automatic methods as described here are necessary.
325 Section 1.1. - 5 - Expires 11 January 1998
333 Version 5 - Specification Revision 6
336 differs from its own normal TGS key) to decrypt the ticket-
337 granting ticket, and is thus certain that it was issued by
338 the client's own TGS. Tickets issued by the remote ticket-
339 granting service will indicate to the end-service that the
340 client was authenticated from another realm.
342 A realm is said to communicate with another realm if
343 the two realms share an inter-realm key, or if the local
344 realm shares an inter-realm key with an intermediate realm
345 that communicates with the remote realm. An authentication
346 path is the sequence of intermediate realms that are tran-
347 sited in communicating from one realm to another.
349 Realms are typically organized hierarchically. Each
350 realm shares a key with its parent and a different key with
351 each child. If an inter-realm key is not directly shared by
352 two realms, the hierarchical organization allows an authen-
353 tication path to be easily constructed. If a hierarchical
354 organization is not used, it may be necessary to consult a
355 database in order to construct an authentication path
358 Although realms are typically hierarchical, intermedi-
359 ate realms may be bypassed to achieve cross-realm authenti-
360 cation through alternate authentication paths (these might
361 be established to make communication between two realms more
362 efficient). It is important for the end-service to know
363 which realms were transited when deciding how much faith to
364 place in the authentication process. To facilitate this
365 decision, a field in each ticket contains the names of the
366 realms that were involved in authenticating the client.
370 As an authentication service, Kerberos provides a means of
371 verifying the identity of principals on a network. Authen-
372 tication is usually useful primarily as a first step in the
373 process of authorization, determining whether a client may
374 use a service, which objects the client is allowed to
375 access, and the type of access allowed for each. Kerberos
376 does not, by itself, provide authorization. Possession of a
377 client ticket for a service provides only for authentication
378 of the client to that service, and in the absence of a
379 separate authorization procedure, it should not be con-
380 sidered by an application as authorizing the use of that
383 Such separate authorization methods may be implemented
384 as application specific access control functions and may be
385 based on files such as the application server, or on
386 separately issued authorization credentials such as those
387 based on proxies [7] , or on other authorization services.
389 Applications should not be modified to accept the
390 issuance of a service ticket by the Kerberos server (even by
392 Section 1.2. - 6 - Expires 11 January 1998
400 Version 5 - Specification Revision 6
403 an modified Kerberos server) as granting authority to use
404 the service, since such applications may become vulnerable
405 to the bypass of this authorization check in an environment
406 where they interoperate with other KDCs or where other
407 options for application authentication (e.g. the PKTAPP pro-
410 1.3. Environmental assumptions
412 Kerberos imposes a few assumptions on the environment in
413 which it can properly function:
415 + "Denial of service" attacks are not solved with Ker-
416 beros. There are places in these protocols where an
417 intruder can prevent an application from participating
418 in the proper authentication steps. Detection and
419 solution of such attacks (some of which can appear to
420 be not-uncommon "normal" failure modes for the system)
421 is usually best left to the human administrators and
424 + Principals must keep their secret keys secret. If an
425 intruder somehow steals a principal's key, it will be
426 able to masquerade as that principal or impersonate any
427 server to the legitimate principal.
429 + "Password guessing" attacks are not solved by Kerberos.
430 If a user chooses a poor password, it is possible for
431 an attacker to successfully mount an offline dictionary
432 attack by repeatedly attempting to decrypt, with suc-
433 cessive entries from a dictionary, messages obtained
434 which are encrypted under a key derived from the user's
437 + Each host on the network must have a clock which is
438 "loosely synchronized" to the time of the other hosts;
439 this synchronization is used to reduce the bookkeeping
440 needs of application servers when they do replay detec-
441 tion. The degree of "looseness" can be configured on a
442 per-server basis, but is typically on the order of 5
443 minutes. If the clocks are synchronized over the net-
444 work, the clock synchronization protocol must itself be
445 secured from network attackers.
447 + Principal identifiers are not recycled on a short-term
448 basis. A typical mode of access control will use
449 access control lists (ACLs) to grant permissions to
450 particular principals. If a stale ACL entry remains
451 for a deleted principal and the principal identifier is
452 reused, the new principal will inherit rights specified
453 in the stale ACL entry. By not re-using principal
454 identifiers, the danger of inadvertent access is
459 Section 1.3. - 7 - Expires 11 January 1998
467 Version 5 - Specification Revision 6
470 1.4. Glossary of terms
472 Below is a list of terms used throughout this document.
475 Authentication Verifying the claimed identity of a
479 Authentication headerA record containing a Ticket and an
480 Authenticator to be presented to a
481 server as part of the authentication
485 Authentication path A sequence of intermediate realms tran-
486 sited in the authentication process when
487 communicating from one realm to another.
490 Authenticator A record containing information that can
491 be shown to have been recently generated
492 using the session key known only by the
496 Authorization The process of determining whether a
497 client may use a service, which objects
498 the client is allowed to access, and the
499 type of access allowed for each.
502 Capability A token that grants the bearer permis-
503 sion to access an object or service. In
504 Kerberos, this might be a ticket whose
505 use is restricted by the contents of the
506 authorization data field, but which
507 lists no network addresses, together
508 with the session key necessary to use
512 Ciphertext The output of an encryption function.
513 Encryption transforms plaintext into
517 Client A process that makes use of a network
518 service on behalf of a user. Note that
519 in some cases a Server may itself be a
520 client of some other server (e.g. a
521 print server may be a client of a file
526 Section 1.4. - 8 - Expires 11 January 1998
534 Version 5 - Specification Revision 6
537 Credentials A ticket plus the secret session key
538 necessary to successfully use that
539 ticket in an authentication exchange.
542 KDC Key Distribution Center, a network ser-
543 vice that supplies tickets and temporary
544 session keys; or an instance of that
545 service or the host on which it runs.
546 The KDC services both initial ticket and
547 ticket-granting ticket requests. The
548 initial ticket portion is sometimes
549 referred to as the Authentication Server
550 (or service). The ticket-granting
551 ticket portion is sometimes referred to
552 as the ticket-granting server (or ser-
556 Kerberos Aside from the 3-headed dog guarding
557 Hades, the name given to Project
558 Athena's authentication service, the
559 protocol used by that service, or the
560 code used to implement the authentica-
564 Plaintext The input to an encryption function or
565 the output of a decryption function.
566 Decryption transforms ciphertext into
570 Principal A uniquely named client or server
571 instance that participates in a network
575 Principal identifierThe name used to uniquely identify each
579 Seal To encipher a record containing several
580 fields in such a way that the fields
581 cannot be individually replaced without
582 either knowledge of the encryption key
583 or leaving evidence of tampering.
586 Secret key An encryption key shared by a principal
587 and the KDC, distributed outside the
588 bounds of the system, with a long life-
589 time. In the case of a human user's
590 principal, the secret key is derived
593 Section 1.4. - 9 - Expires 11 January 1998
601 Version 5 - Specification Revision 6
607 Server A particular Principal which provides a
608 resource to network clients. The server
609 is sometimes refered to as the Applica-
613 Service A resource provided to network clients;
614 often provided by more than one server
615 (for example, remote file service).
618 Session key A temporary encryption key used between
619 two principals, with a lifetime limited
620 to the duration of a single login "ses-
624 Sub-session key A temporary encryption key used between
625 two principals, selected and exchanged
626 by the principals using the session key,
627 and with a lifetime limited to the dura-
628 tion of a single association.
631 Ticket A record that helps a client authenti-
632 cate itself to a server; it contains the
633 client's identity, a session key, a
634 timestamp, and other information, all
635 sealed using the server's secret key.
636 It only serves to authenticate a client
637 when presented along with a fresh
640 2. Ticket flag uses and requests
642 Each Kerberos ticket contains a set of flags which are used
643 to indicate various attributes of that ticket. Most flags
644 may be requested by a client when the ticket is obtained;
645 some are automatically turned on and off by a Kerberos
646 server as required. The following sections explain what the
647 various flags mean, and gives examples of reasons to use
650 2.1. Initial and pre-authenticated tickets
652 The INITIAL flag indicates that a ticket was issued
653 using the AS protocol and not issued based on a ticket-
654 granting ticket. Application servers that want to require
655 the demonstrated knowledge of a client's secret key (e.g. a
656 password-changing program) can insist that this flag be set
657 in any tickets they accept, and thus be assured that the
660 Section 2.1. - 10 - Expires 11 January 1998
668 Version 5 - Specification Revision 6
671 client's key was recently presented to the application
674 The PRE-AUTHENT and HW-AUTHENT flags provide addition
675 information about the initial authentication, regardless of
676 whether the current ticket was issued directly (in which
677 case INITIAL will also be set) or issued on the basis of a
678 ticket-granting ticket (in which case the INITIAL flag is
679 clear, but the PRE-AUTHENT and HW-AUTHENT flags are carried
680 forward from the ticket-granting ticket).
684 The INVALID flag indicates that a ticket is invalid.
685 Application servers must reject tickets which have this flag
686 set. A postdated ticket will usually be issued in this
687 form. Invalid tickets must be validated by the KDC before
688 use, by presenting them to the KDC in a TGS request with the
689 VALIDATE option specified. The KDC will only validate tick-
690 ets after their starttime has passed. The validation is
691 required so that postdated tickets which have been stolen
692 before their starttime can be rendered permanently invalid
693 (through a hot-list mechanism) (see section 3.3.3.1).
695 2.3. Renewable tickets
697 Applications may desire to hold tickets which can be
698 valid for long periods of time. However, this can expose
699 their credentials to potential theft for equally long
700 periods, and those stolen credentials would be valid until
701 the expiration time of the ticket(s). Simply using short-
702 lived tickets and obtaining new ones periodically would
703 require the client to have long-term access to its secret
704 key, an even greater risk. Renewable tickets can be used to
705 mitigate the consequences of theft. Renewable tickets have
706 two "expiration times": the first is when the current
707 instance of the ticket expires, and the second is the latest
708 permissible value for an individual expiration time. An
709 application client must periodically (i.e. before it
710 expires) present a renewable ticket to the KDC, with the
711 RENEW option set in the KDC request. The KDC will issue a
712 new ticket with a new session key and a later expiration
713 time. All other fields of the ticket are left unmodified by
714 the renewal process. When the latest permissible expiration
715 time arrives, the ticket expires permanently. At each
716 renewal, the KDC may consult a hot-list to determine if the
717 ticket had been reported stolen since its last renewal; it
718 will refuse to renew such stolen tickets, and thus the
719 usable lifetime of stolen tickets is reduced.
721 The RENEWABLE flag in a ticket is normally only inter-
722 preted by the ticket-granting service (discussed below in
723 section 3.3). It can usually be ignored by application
724 servers. However, some particularly careful application
727 Section 2.3. - 11 - Expires 11 January 1998
735 Version 5 - Specification Revision 6
738 servers may wish to disallow renewable tickets.
740 If a renewable ticket is not renewed by its expiration
741 time, the KDC will not renew the ticket. The RENEWABLE flag
742 is reset by default, but a client may request it be set by
743 setting the RENEWABLE option in the KRB_AS_REQ message. If
744 it is set, then the renew-till field in the ticket contains
745 the time after which the ticket may not be renewed.
747 2.4. Postdated tickets
749 Applications may occasionally need to obtain tickets
750 for use much later, e.g. a batch submission system would
751 need tickets to be valid at the time the batch job is ser-
752 viced. However, it is dangerous to hold valid tickets in a
753 batch queue, since they will be on-line longer and more
754 prone to theft. Postdated tickets provide a way to obtain
755 these tickets from the KDC at job submission time, but to
756 leave them "dormant" until they are activated and validated
757 by a further request of the KDC. If a ticket theft were
758 reported in the interim, the KDC would refuse to validate
759 the ticket, and the thief would be foiled.
761 The MAY-POSTDATE flag in a ticket is normally only
762 interpreted by the ticket-granting service. It can be
763 ignored by application servers. This flag must be set in a
764 ticket-granting ticket in order to issue a postdated ticket
765 based on the presented ticket. It is reset by default; it
766 may be requested by a client by setting the ALLOW-POSTDATE
767 option in the KRB_AS_REQ message. This flag does not allow
768 a client to obtain a postdated ticket-granting ticket; post-
769 dated ticket-granting tickets can only by obtained by
770 requesting the postdating in the KRB_AS_REQ message. The
771 life (endtime-starttime) of a postdated ticket will be the
772 remaining life of the ticket-granting ticket at the time of
773 the request, unless the RENEWABLE option is also set, in
774 which case it can be the full life (endtime-starttime) of
775 the ticket-granting ticket. The KDC may limit how far in
776 the future a ticket may be postdated.
778 The POSTDATED flag indicates that a ticket has been
779 postdated. The application server can check the authtime
780 field in the ticket to see when the original authentication
781 occurred. Some services may choose to reject postdated
782 tickets, or they may only accept them within a certain
783 period after the original authentication. When the KDC
784 issues a POSTDATED ticket, it will also be marked as
785 INVALID, so that the application client must present the
786 ticket to the KDC to be validated before use.
788 2.5. Proxiable and proxy tickets
790 At times it may be necessary for a principal to allow a
791 service to perform an operation on its behalf. The service
794 Section 2.5. - 12 - Expires 11 January 1998
802 Version 5 - Specification Revision 6
805 must be able to take on the identity of the client, but only
806 for a particular purpose. A principal can allow a service
807 to take on the principal's identity for a particular purpose
808 by granting it a proxy.
810 The process of granting a proxy using the proxy and
811 proxiable flags is used to provide credentials for use with
812 specific services. Though conceptually also a proxy, user's
813 wishing to delegate their identity for ANY purpose must use
814 the ticket forwarding mechanism described in the next sec-
815 tion to forward a ticket granting ticket.
817 The PROXIABLE flag in a ticket is normally only inter-
818 preted by the ticket-granting service. It can be ignored by
819 application servers. When set, this flag tells the ticket-
820 granting server that it is OK to issue a new ticket (but not
821 a ticket-granting ticket) with a different network address
822 based on this ticket. This flag is set if requested by the
823 client on initial authentication. By default, the client
824 will request that it be set when requesting a ticket grant-
825 ing ticket, and reset when requesting any other ticket.
827 This flag allows a client to pass a proxy to a server
828 to perform a remote request on its behalf, e.g. a print ser-
829 vice client can give the print server a proxy to access the
830 client's files on a particular file server in order to
831 satisfy a print request.
833 In order to complicate the use of stolen credentials,
834 Kerberos tickets are usually valid from only those network
835 addresses specifically included in the ticket[4]. When
836 granting a proxy, the client must specify the new network
837 address from which the proxy is to be used, or indicate that
838 the proxy is to be issued for use from any address.
840 The PROXY flag is set in a ticket by the TGS when it
841 issues a proxy ticket. Application servers may check this
842 flag and at their option they may require additional authen-
843 tication from the agent presenting the proxy in order to
844 provide an audit trail.
846 2.6. Forwardable tickets
848 Authentication forwarding is an instance of a proxy
849 where the service is granted complete use of the client's
850 identity. An example where it might be used is when a user
851 logs in to a remote system and wants authentication to work
852 from that system as if the login were local.
854 The FORWARDABLE flag in a ticket is normally only
855 __________________________
856 [4] Though it is permissible to request or issue tick-
857 ets with no network addresses specified.
860 Section 2.6. - 13 - Expires 11 January 1998
868 Version 5 - Specification Revision 6
871 interpreted by the ticket-granting service. It can be
872 ignored by application servers. The FORWARDABLE flag has an
873 interpretation similar to that of the PROXIABLE flag, except
874 ticket-granting tickets may also be issued with different
875 network addresses. This flag is reset by default, but users
876 may request that it be set by setting the FORWARDABLE option
877 in the AS request when they request their initial ticket-
880 This flag allows for authentication forwarding without
881 requiring the user to enter a password again. If the flag
882 is not set, then authentication forwarding is not permitted,
883 but the same result can still be achieved if the user
884 engages in the AS exchange specifying the requested network
885 addresses and supplies a password.
887 The FORWARDED flag is set by the TGS when a client
888 presents a ticket with the FORWARDABLE flag set and requests
889 a forwarded ticket by specifying the FORWARDED KDC option
890 and supplying a set of addresses for the new ticket. It is
891 also set in all tickets issued based on tickets with the
892 FORWARDED flag set. Application servers may choose to pro-
893 cess FORWARDED tickets differently than non-FORWARDED tick-
896 2.7. Other KDC options
898 There are two additional options which may be set in a
899 client's request of the KDC. The RENEWABLE-OK option indi-
900 cates that the client will accept a renewable ticket if a
901 ticket with the requested life cannot otherwise be provided.
902 If a ticket with the requested life cannot be provided, then
903 the KDC may issue a renewable ticket with a renew-till equal
904 to the the requested endtime. The value of the renew-till
905 field may still be adjusted by site-determined limits or
906 limits imposed by the individual principal or server.
908 The ENC-TKT-IN-SKEY option is honored only by the
909 ticket-granting service. It indicates that the ticket to be
910 issued for the end server is to be encrypted in the session
911 key from the a additional second ticket-granting ticket pro-
912 vided with the request. See section 3.3.3 for specific
915 __________________________
916 [5] The password-changing request must not be honored
917 unless the requester can provide the old password (the
918 user's current secret key). Otherwise, it would be
919 possible for someone to walk up to an unattended ses-
920 sion and change another user's password.
921 [6] To authenticate a user logging on to a local sys-
922 tem, the credentials obtained in the AS exchange may
923 first be used in a TGS exchange to obtain credentials
926 Section 3.1. - 14 - Expires 11 January 1998
933 Version 5 - Specification Revision 6
939 The following sections describe the interactions between
940 network clients and servers and the messages involved in
943 3.1. The Authentication Service Exchange
946 Message direction Message type Section
947 1. Client to Kerberos KRB_AS_REQ 5.4.1
948 2. Kerberos to client KRB_AS_REP or 5.4.2
952 The Authentication Service (AS) Exchange between the
953 client and the Kerberos Authentication Server is initiated
954 by a client when it wishes to obtain authentication creden-
955 tials for a given server but currently holds no credentials.
956 In its basic form, the client's secret key is used for en-
957 cryption and decryption. This exchange is typically used at
958 the initiation of a login session to obtain credentials for
959 a Ticket-Granting Server which will subsequently be used to
960 obtain credentials for other servers (see section 3.3)
961 without requiring further use of the client's secret key.
962 This exchange is also used to request credentials for ser-
963 vices which must not be mediated through the Ticket-Granting
964 Service, but rather require a principal's secret key, such
965 as the password-changing service[5]. This exchange does not
966 by itself provide any assurance of the the identity of the
969 The exchange consists of two messages: KRB_AS_REQ from
970 the client to Kerberos, and KRB_AS_REP or KRB_ERROR in
971 reply. The formats for these messages are described in sec-
972 tions 5.4.1, 5.4.2, and 5.9.1.
974 In the request, the client sends (in cleartext) its own
975 identity and the identity of the server for which it is
976 requesting credentials. The response, KRB_AS_REP, contains
977 a ticket for the client to present to the server, and a ses-
978 sion key that will be shared by the client and the server.
979 The session key and additional information are encrypted in
980 the client's secret key. The KRB_AS_REP message contains
981 information which can be used to detect replays, and to
982 associate it with the message to which it replies. Various
983 errors can occur; these are indicated by an error response
984 (KRB_ERROR) instead of the KRB_AS_REP response. The error
985 __________________________
986 for a local server. Those credentials must then be
987 verified by a local server through successful comple-
988 tion of the Client/Server exchange.
992 Section 3.1. - 15 - Expires 11 January 1998
1000 Version 5 - Specification Revision 6
1003 message is not encrypted. The KRB_ERROR message contains
1004 information which can be used to associate it with the mes-
1005 sage to which it replies. The lack of encryption in the
1006 KRB_ERROR message precludes the ability to detect replays,
1007 fabrications, or modifications of such messages.
1009 Without preautentication, the authentication server
1010 does not know whether the client is actually the principal
1011 named in the request. It simply sends a reply without know-
1012 ing or caring whether they are the same. This is acceptable
1013 because nobody but the principal whose identity was given in
1014 the request will be able to use the reply. Its critical
1015 information is encrypted in that principal's key. The ini-
1016 tial request supports an optional field that can be used to
1017 pass additional information that might be needed for the
1018 initial exchange. This field may be used for pre-
1019 authentication as described in section <<sec preauth>>.
1021 3.1.1. Generation of KRB_AS_REQ message
1023 The client may specify a number of options in the ini-
1024 tial request. Among these options are whether pre-
1025 authentication is to be performed; whether the requested
1026 ticket is to be renewable, proxiable, or forwardable;
1027 whether it should be postdated or allow postdating of
1028 derivative tickets; and whether a renewable ticket will be
1029 accepted in lieu of a non-renewable ticket if the requested
1030 ticket expiration date cannot be satisfied by a non-
1031 renewable ticket (due to configuration constraints; see sec-
1032 tion 4). See section A.1 for pseudocode.
1034 The client prepares the KRB_AS_REQ message and sends it
1037 3.1.2. Receipt of KRB_AS_REQ message
1039 If all goes well, processing the KRB_AS_REQ message
1040 will result in the creation of a ticket for the client to
1041 present to the server. The format for the ticket is
1042 described in section 5.3.1. The contents of the ticket are
1043 determined as follows.
1045 3.1.3. Generation of KRB_AS_REP message
1047 The authentication server looks up the client and
1048 server principals named in the KRB_AS_REQ in its database,
1049 extracting their respective keys. If required, the server
1050 pre-authenticates the request, and if the pre-authentication
1051 check fails, an error message with the code
1052 KDC_ERR_PREAUTH_FAILED is returned. If the server cannot
1053 accommodate the requested encryption type, an error message
1054 with code KDC_ERR_ETYPE_NOSUPP is returned. Otherwise it
1055 generates a "random" session key[7].
1056 __________________________
1059 Section 3.1.3. - 16 - Expires 11 January 1998
1067 Version 5 - Specification Revision 6
1070 If there are multiple encryption keys registered for a
1071 client in the Kerberos database (or if the key registered
1072 supports multiple encryption types; e.g. DES-CBC-CRC and
1073 DES-CBC-MD5), then the etype field from the AS request is
1074 used by the KDC to select the encryption method to be used
1075 for encrypting the response to the client. If there is more
1076 than one supported, strong encryption type in the etype
1077 list, the first valid etype for which an encryption key is
1078 available is used. The encryption method used to respond to
1079 a TGS request is taken from the keytype of the session key
1080 found in the ticket granting ticket.
1082 When the etype field is present in a KDC request,
1083 whether an AS or TGS request, the KDC will attempt to assign
1084 the type of the random session key from the list of methods
1085 in the etype field. The KDC will select the appropriate
1086 type using the list of methods provided together with infor-
1087 mation from the Kerberos database indicating acceptable
1088 encryption methods for the application server. The KDC will
1089 not issue tickets with a weak session key encryption type.
1091 If the requested start time is absent, indicates a time
1092 in the past, or is within the window of acceptable clock
1093 skew for the KDC and the POSTDATE option has not been speci-
1094 fied, then the start time of the ticket is set to the
1095 authentication server's current time. If it indicates a
1096 time in the future beyond the acceptable clock skew, but the
1097 POSTDATED option has not been specified then the error
1098 KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the
1099 requested start time is checked against the policy of the
1100 local realm (the administrator might decide to prohibit cer-
1101 tain types or ranges of postdated tickets), and if accept-
1102 able, the ticket's start time is set as requested and the
1103 INVALID flag is set in the new ticket. The postdated ticket
1104 must be validated before use by presenting it to the KDC
1105 after the start time has been reached.
1115 __________________________
1116 [7] "Random" means that, among other things, it should
1117 be impossible to guess the next session key based on
1118 knowledge of past session keys. This can only be
1119 achieved in a pseudo-random number generator if it is
1120 based on cryptographic principles. It is more desir-
1121 able to use a truly random number generator, such as
1122 one based on measurements of random physical phenomena.
1126 Section 3.1.3. - 17 - Expires 11 January 1998
1134 Version 5 - Specification Revision 6
1137 The expiration time of the ticket will be set to the minimum
1140 +The expiration time (endtime) requested in the KRB_AS_REQ
1143 +The ticket's start time plus the maximum allowable lifetime
1144 associated with the client principal (the authentication
1145 server's database includes a maximum ticket lifetime field
1146 in each principal's record; see section 4).
1148 +The ticket's start time plus the maximum allowable lifetime
1149 associated with the server principal.
1151 +The ticket's start time plus the maximum lifetime set by
1152 the policy of the local realm.
1154 If the requested expiration time minus the start time
1155 (as determined above) is less than a site-determined minimum
1156 lifetime, an error message with code KDC_ERR_NEVER_VALID is
1157 returned. If the requested expiration time for the ticket
1158 exceeds what was determined as above, and if the
1159 "RENEWABLE-OK" option was requested, then the "RENEWABLE"
1160 flag is set in the new ticket, and the renew-till value is
1161 set as if the "RENEWABLE" option were requested (the field
1162 and option names are described fully in section 5.4.1).
1164 If the RENEWABLE option has been requested or if the
1165 RENEWABLE-OK option has been set and a renewable ticket is
1166 to be issued, then the renew-till field is set to the
1169 +Its requested value.
1171 +The start time of the ticket plus the minimum of the two
1172 maximum renewable lifetimes associated with the principals'
1175 +The start time of the ticket plus the maximum renewable
1176 lifetime set by the policy of the local realm.
1178 The flags field of the new ticket will have the follow-
1179 ing options set if they have been requested and if the pol-
1180 icy of the local realm allows: FORWARDABLE, MAY-POSTDATE,
1181 POSTDATED, PROXIABLE, RENEWABLE. If the new ticket is post-
1182 dated (the start time is in the future), its INVALID flag
1185 If all of the above succeed, the server formats a
1186 KRB_AS_REP message (see section 5.4.2), copying the
1187 addresses in the request into the caddr of the response,
1188 placing any required pre-authentication data into the padata
1189 of the response, and encrypts the ciphertext part in the
1190 client's key using the requested encryption method, and
1193 Section 3.1.3. - 18 - Expires 11 January 1998
1201 Version 5 - Specification Revision 6
1204 sends it to the client. See section A.2 for pseudocode.
1206 3.1.4. Generation of KRB_ERROR message
1208 Several errors can occur, and the Authentication Server
1209 responds by returning an error message, KRB_ERROR, to the
1210 client, with the error-code and e-text fields set to
1211 appropriate values. The error message contents and details
1212 are described in Section 5.9.1.
1214 3.1.5. Receipt of KRB_AS_REP message
1216 If the reply message type is KRB_AS_REP, then the
1217 client verifies that the cname and crealm fields in the
1218 cleartext portion of the reply match what it requested. If
1219 any padata fields are present, they may be used to derive
1220 the proper secret key to decrypt the message. The client
1221 decrypts the encrypted part of the response using its secret
1222 key, verifies that the nonce in the encrypted part matches
1223 the nonce it supplied in its request (to detect replays).
1224 It also verifies that the sname and srealm in the response
1225 match those in the request (or are otherwise expected
1226 values), and that the host address field is also correct.
1227 It then stores the ticket, session key, start and expiration
1228 times, and other information for later use. The key-
1229 expiration field from the encrypted part of the response may
1230 be checked to notify the user of impending key expiration
1231 (the client program could then suggest remedial action, such
1232 as a password change). See section A.3 for pseudocode.
1234 Proper decryption of the KRB_AS_REP message is not suf-
1235 ficient to verify the identity of the user; the user and an
1236 attacker could cooperate to generate a KRB_AS_REP format
1237 message which decrypts properly but is not from the proper
1238 KDC. If the host wishes to verify the identity of the user,
1239 it must require the user to present application credentials
1240 which can be verified using a securely-stored secret key for
1241 the host. If those credentials can be verified, then the
1242 identity of the user can be assured.
1244 3.1.6. Receipt of KRB_ERROR message
1246 If the reply message type is KRB_ERROR, then the client
1247 interprets it as an error and performs whatever
1248 application-specific tasks are necessary to recover.
1250 3.2. The Client/Server Authentication Exchange
1253 Message direction Message type Section
1254 Client to Application server KRB_AP_REQ 5.5.1
1255 [optional] Application server to client KRB_AP_REP or 5.5.2
1260 Section 3.2. - 19 - Expires 11 January 1998
1268 Version 5 - Specification Revision 6
1271 The client/server authentication (CS) exchange is used
1272 by network applications to authenticate the client to the
1273 server and vice versa. The client must have already
1274 acquired credentials for the server using the AS or TGS
1277 3.2.1. The KRB_AP_REQ message
1279 The KRB_AP_REQ contains authentication information
1280 which should be part of the first message in an authenti-
1281 cated transaction. It contains a ticket, an authenticator,
1282 and some additional bookkeeping information (see section
1283 5.5.1 for the exact format). The ticket by itself is insuf-
1284 ficient to authenticate a client, since tickets are passed
1285 across the network in cleartext[8], so the authenticator is
1286 used to prevent invalid replay of tickets by proving to the
1287 server that the client knows the session key of the ticket
1288 and thus is entitled to use the ticket. The KRB_AP_REQ mes-
1289 sage is referred to elsewhere as the "authentication
1292 3.2.2. Generation of a KRB_AP_REQ message
1294 When a client wishes to initiate authentication to a
1295 server, it obtains (either through a credentials cache, the
1296 AS exchange, or the TGS exchange) a ticket and session key
1297 for the desired service. The client may re-use any tickets
1298 it holds until they expire. To use a ticket the client con-
1299 structs a new Authenticator from the the system time, its
1300 name, and optionally an application specific checksum, an
1301 initial sequence number to be used in KRB_SAFE or KRB_PRIV
1302 messages, and/or a session subkey to be used in negotiations
1303 for a session key unique to this particular session.
1304 Authenticators may not be re-used and will be rejected if
1305 replayed to a server[9]. If a sequence number is to be
1306 included, it should be randomly chosen so that even after
1307 many messages have been exchanged it is not likely to col-
1308 lide with other sequence numbers in use.
1310 The client may indicate a requirement of mutual
1311 __________________________
1312 [8] Tickets contain both an encrypted and unencrypted
1313 portion, so cleartext here refers to the entire unit,
1314 which can be copied from one message and replayed in
1315 another without any cryptographic skill.
1316 [9] Note that this can make applications based on un-
1317 reliable transports difficult to code correctly. If the
1318 transport might deliver duplicated messages, either a
1319 new authenticator must be generated for each retry, or
1320 the application server must match requests and replies
1321 and replay the first reply in response to a detected
1326 Section 3.2.2. - 20 - Expires 11 January 1998
1334 Version 5 - Specification Revision 6
1337 authentication or the use of a session-key based ticket by
1338 setting the appropriate flag(s) in the ap-options field of
1341 The Authenticator is encrypted in the session key and
1342 combined with the ticket to form the KRB_AP_REQ message
1343 which is then sent to the end server along with any addi-
1344 tional application-specific information. See section A.9
1347 3.2.3. Receipt of KRB_AP_REQ message
1349 Authentication is based on the server's current time of
1350 day (clocks must be loosely synchronized), the authentica-
1351 tor, and the ticket. Several errors are possible. If an
1352 error occurs, the server is expected to reply to the client
1353 with a KRB_ERROR message. This message may be encapsulated
1354 in the application protocol if its "raw" form is not accept-
1355 able to the protocol. The format of error messages is
1356 described in section 5.9.1.
1358 The algorithm for verifying authentication information
1359 is as follows. If the message type is not KRB_AP_REQ, the
1360 server returns the KRB_AP_ERR_MSG_TYPE error. If the key
1361 version indicated by the Ticket in the KRB_AP_REQ is not one
1362 the server can use (e.g., it indicates an old key, and the
1363 server no longer possesses a copy of the old key), the
1364 KRB_AP_ERR_BADKEYVER error is returned. If the USE-
1365 SESSION-KEY flag is set in the ap-options field, it indi-
1366 cates to the server that the ticket is encrypted in the ses-
1367 sion key from the server's ticket-granting ticket rather
1368 than its secret key[10]. Since it is possible for the
1369 server to be registered in multiple realms, with different
1370 keys in each, the srealm field in the unencrypted portion of
1371 the ticket in the KRB_AP_REQ is used to specify which secret
1372 key the server should use to decrypt that ticket. The
1373 KRB_AP_ERR_NOKEY error code is returned if the server
1374 doesn't have the proper key to decipher the ticket.
1376 The ticket is decrypted using the version of the
1377 server's key specified by the ticket. If the decryption
1378 routines detect a modification of the ticket (each encryp-
1379 tion system must provide safeguards to detect modified
1380 ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY
1381 error is returned (chances are good that different keys were
1382 used to encrypt and decrypt).
1384 The authenticator is decrypted using the session key
1385 extracted from the decrypted ticket. If decryption shows it
1386 to have been modified, the KRB_AP_ERR_BAD_INTEGRITY error is
1387 __________________________
1388 [10] This is used for user-to-user authentication as
1392 Section 3.2.3. - 21 - Expires 11 January 1998
1400 Version 5 - Specification Revision 6
1403 returned. The name and realm of the client from the ticket
1404 are compared against the same fields in the authenticator.
1405 If they don't match, the KRB_AP_ERR_BADMATCH error is
1406 returned (they might not match, for example, if the wrong
1407 session key was used to encrypt the authenticator). The
1408 addresses in the ticket (if any) are then searched for an
1409 address matching the operating-system reported address of
1410 the client. If no match is found or the server insists on
1411 ticket addresses but none are present in the ticket, the
1412 KRB_AP_ERR_BADADDR error is returned.
1414 If the local (server) time and the client time in the
1415 authenticator differ by more than the allowable clock skew
1416 (e.g., 5 minutes), the KRB_AP_ERR_SKEW error is returned.
1417 If the server name, along with the client name, time and
1418 microsecond fields from the Authenticator match any
1419 recently-seen such tuples, the KRB_AP_ERR_REPEAT error is
1420 returned[11]. The server must remember any authenticator
1421 presented within the allowable clock skew, so that a replay
1422 attempt is guaranteed to fail. If a server loses track of
1423 any authenticator presented within the allowable clock skew,
1424 it must reject all requests until the clock skew interval
1425 has passed. This assures that any lost or re-played authen-
1426 ticators will fall outside the allowable clock skew and can
1427 no longer be successfully replayed (If this is not done, an
1428 attacker could conceivably record the ticket and authentica-
1429 tor sent over the network to a server, then disable the
1430 client's host, pose as the disabled host, and replay the
1431 ticket and authenticator to subvert the authentication.).
1432 If a sequence number is provided in the authenticator, the
1433 server saves it for later use in processing KRB_SAFE and/or
1434 KRB_PRIV messages. If a subkey is present, the server
1435 either saves it for later use or uses it to help generate
1436 its own choice for a subkey to be returned in a KRB_AP_REP
1439 The server computes the age of the ticket: local
1440 (server) time minus the start time inside the Ticket. If
1441 the start time is later than the current time by more than
1442 the allowable clock skew or if the INVALID flag is set in
1443 the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Oth-
1444 erwise, if the current time is later than end time by more
1445 than the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED
1448 If all these checks succeed without an error, the
1449 __________________________
1450 [11] Note that the rejection here is restricted to au-
1451 thenticators from the same principal to the same
1452 server. Other client principals communicating with the
1453 same server principal should not be have their authen-
1454 ticators rejected if the time and microsecond fields
1455 happen to match some other client's authenticator.
1458 Section 3.2.3. - 22 - Expires 11 January 1998
1466 Version 5 - Specification Revision 6
1469 server is assured that the client possesses the credentials
1470 of the principal named in the ticket and thus, the client
1471 has been authenticated to the server. See section A.10 for
1474 Passing these checks provides only authentication of
1475 the named principal; it does not imply authorization to use
1476 the named service. Applications must make a separate
1477 authorization decisions based upon the authenticated name of
1478 the user, the requested operation, local acces control
1479 information such as that contained in a .k5login or .k5users
1480 file, and possibly a separate distributed authorization ser-
1483 3.2.4. Generation of a KRB_AP_REP message
1485 Typically, a client's request will include both the
1486 authentication information and its initial request in the
1487 same message, and the server need not explicitly reply to
1488 the KRB_AP_REQ. However, if mutual authentication (not only
1489 authenticating the client to the server, but also the server
1490 to the client) is being performed, the KRB_AP_REQ message
1491 will have MUTUAL-REQUIRED set in its ap-options field, and a
1492 KRB_AP_REP message is required in response. As with the
1493 error message, this message may be encapsulated in the
1494 application protocol if its "raw" form is not acceptable to
1495 the application's protocol. The timestamp and microsecond
1496 field used in the reply must be the client's timestamp and
1497 microsecond field (as provided in the authenticator)[12].
1498 If a sequence number is to be included, it should be ran-
1499 domly chosen as described above for the authenticator. A
1500 subkey may be included if the server desires to negotiate a
1501 different subkey. The KRB_AP_REP message is encrypted in
1502 the session key extracted from the ticket. See section A.11
1505 3.2.5. Receipt of KRB_AP_REP message
1508 If a KRB_AP_REP message is returned, the client uses
1509 the session key from the credentials obtained for the
1510 server[13] to decrypt the message, and verifies that the
1511 __________________________
1512 [12] In the Kerberos version 4 protocol, the timestamp
1513 in the reply was the client's timestamp plus one. This
1514 is not necessary in version 5 because version 5 mes-
1515 sages are formatted in such a way that it is not possi-
1516 ble to create the reply by judicious message surgery
1517 (even in encrypted form) without knowledge of the ap-
1518 propriate encryption keys.
1519 [13] Note that for encrypting the KRB_AP_REP message,
1520 the sub-session key is not used, even if present in the
1524 Section 3.2.5. - 23 - Expires 11 January 1998
1532 Version 5 - Specification Revision 6
1535 timestamp and microsecond fields match those in the Authen-
1536 ticator it sent to the server. If they match, then the
1537 client is assured that the server is genuine. The sequence
1538 number and subkey (if present) are retained for later use.
1539 See section A.12 for pseudocode.
1542 3.2.6. Using the encryption key
1544 After the KRB_AP_REQ/KRB_AP_REP exchange has occurred,
1545 the client and server share an encryption key which can be
1546 used by the application. The "true session key" to be used
1547 for KRB_PRIV, KRB_SAFE, or other application-specific uses
1548 may be chosen by the application based on the subkeys in the
1549 KRB_AP_REP message and the authenticator[14]. In some
1550 cases, the use of this session key will be implicit in the
1551 protocol; in others the method of use must be chosen from
1552 several alternatives. We leave the protocol negotiations of
1553 how to use the key (e.g. selecting an encryption or check-
1554 sum type) to the application programmer; the Kerberos proto-
1555 col does not constrain the implementation options, but an
1556 example of how this might be done follows.
1558 One way that an application may choose to negotiate a
1559 key to be used for subequent integrity and privacy protec-
1560 tion is for the client to propose a key in the subkey field
1561 of the authenticator. The server can then choose a key
1562 using the proposed key from the client as input, returning
1563 the new subkey in the subkey field of the application reply.
1564 This key could then be used for subsequent communication.
1565 To make this example more concrete, if the encryption method
1566 in use required a 56 bit key, and for whatever reason, one
1567 of the parties was prevented from using a key with more than
1568 40 unknown bits, this method would allow the the party which
1569 is prevented from using more than 40 bits to either propose
1570 (if the client) an initial key with a known quantity for 16
1571 of those bits, or to mask 16 of the bits (if the server)
1572 with the known quantity. The application implementor is
1573 warned, however, that this is only an example, and that an
1574 analysis of the particular crytosystem to be used, and the
1575 reasons for limiting the key length, must be made before
1576 deciding whether it is acceptable to mask bits of the key.
1578 With both the one-way and mutual authentication
1579 exchanges, the peers should take care not to send sensitive
1580 information to each other without proper assurances. In
1581 particular, applications that require privacy or integrity
1582 should use the KRB_AP_REP response from the server to client
1583 __________________________
1584 [14] Implementations of the protocol may wish to pro-
1585 vide routines to choose subkeys based on session keys
1586 and random numbers and to generate a negotiated key to
1587 be returned in the KRB_AP_REP message.
1590 Section 3.2.6. - 24 - Expires 11 January 1998
1598 Version 5 - Specification Revision 6
1601 to assure both client and server of their peer's identity.
1602 If an application protocol requires privacy of its messages,
1603 it can use the KRB_PRIV message (section 3.5). The KRB_SAFE
1604 message (section 3.4) can be used to assure integrity.
1607 3.3. The Ticket-Granting Service (TGS) Exchange
1610 Message direction Message type Section
1611 1. Client to Kerberos KRB_TGS_REQ 5.4.1
1612 2. Kerberos to client KRB_TGS_REP or 5.4.2
1616 The TGS exchange between a client and the Kerberos
1617 Ticket-Granting Server is initiated by a client when it
1618 wishes to obtain authentication credentials for a given
1619 server (which might be registered in a remote realm), when
1620 it wishes to renew or validate an existing ticket, or when
1621 it wishes to obtain a proxy ticket. In the first case, the
1622 client must already have acquired a ticket for the Ticket-
1623 Granting Service using the AS exchange (the ticket-granting
1624 ticket is usually obtained when a client initially authenti-
1625 cates to the system, such as when a user logs in). The mes-
1626 sage format for the TGS exchange is almost identical to that
1627 for the AS exchange. The primary difference is that encryp-
1628 tion and decryption in the TGS exchange does not take place
1629 under the client's key. Instead, the session key from the
1630 ticket-granting ticket or renewable ticket, or sub-session
1631 key from an Authenticator is used. As is the case for all
1632 application servers, expired tickets are not accepted by the
1633 TGS, so once a renewable or ticket-granting ticket expires,
1634 the client must use a separate exchange to obtain valid
1637 The TGS exchange consists of two messages: A request
1638 (KRB_TGS_REQ) from the client to the Kerberos Ticket-
1639 Granting Server, and a reply (KRB_TGS_REP or KRB_ERROR).
1640 The KRB_TGS_REQ message includes information authenticating
1641 the client plus a request for credentials. The authentica-
1642 tion information consists of the authentication header
1643 (KRB_AP_REQ) which includes the client's previously obtained
1644 ticket-granting, renewable, or invalid ticket. In the
1645 ticket-granting ticket and proxy cases, the request may
1646 include one or more of: a list of network addresses, a col-
1647 lection of typed authorization data to be sealed in the
1648 ticket for authorization use by the application server, or
1649 additional tickets (the use of which are described later).
1650 The TGS reply (KRB_TGS_REP) contains the requested creden-
1651 tials, encrypted in the session key from the ticket-granting
1652 ticket or renewable ticket, or if present, in the sub-
1653 session key from the Authenticator (part of the authentica-
1654 tion header). The KRB_ERROR message contains an error code
1657 Section 3.3. - 25 - Expires 11 January 1998
1665 Version 5 - Specification Revision 6
1668 and text explaining what went wrong. The KRB_ERROR message
1669 is not encrypted. The KRB_TGS_REP message contains informa-
1670 tion which can be used to detect replays, and to associate
1671 it with the message to which it replies. The KRB_ERROR mes-
1672 sage also contains information which can be used to associ-
1673 ate it with the message to which it replies, but the lack of
1674 encryption in the KRB_ERROR message precludes the ability to
1675 detect replays or fabrications of such messages.
1677 3.3.1. Generation of KRB_TGS_REQ message
1679 Before sending a request to the ticket-granting ser-
1680 vice, the client must determine in which realm the applica-
1681 tion server is registered[15]. If the client does not
1682 already possess a ticket-granting ticket for the appropriate
1683 realm, then one must be obtained. This is first attempted
1684 by requesting a ticket-granting ticket for the destination
1685 realm from a Kerberos server for which the client does
1686 posess a ticket-granting ticket (using the KRB_TGS_REQ mes-
1687 sage recursively). The Kerberos server may return a TGT for
1688 the desired realm in which case one can proceed. Alterna-
1689 tively, the Kerberos server may return a TGT for a realm
1690 which is "closer" to the desired realm (further along the
1691 standard hierarchical path), in which case this step must be
1692 repeated with a Kerberos server in the realm specified in
1693 the returned TGT. If neither are returned, then the request
1694 must be retried with a Kerberos server for a realm higher in
1695 the hierarchy. This request will itself require a ticket-
1696 granting ticket for the higher realm which must be obtained
1697 by recursively applying these directions.
1700 Once the client obtains a ticket-granting ticket for
1701 the appropriate realm, it determines which Kerberos servers
1702 serve that realm, and contacts one. The list might be
1703 obtained through a configuration file or network service or
1704 it may be generated from the name of the realm; as long as
1705 the secret keys exchanged by realms are kept secret, only
1706 denial of service results from using a false Kerberos
1708 __________________________
1709 [15] This can be accomplished in several ways. It
1710 might be known beforehand (since the realm is part of
1711 the principal identifier), it might be stored in a
1712 nameserver, or it might be obtained from a configura-
1713 tion file. If the realm to be used is obtained from a
1714 nameserver, there is a danger of being spoofed if the
1715 nameservice providing the realm name is not authenti-
1716 cated. This might result in the use of a realm which
1717 has been compromised, and would result in an attacker's
1718 ability to compromise the authentication of the appli-
1719 cation server to the client.
1723 Section 3.3.1. - 26 - Expires 11 January 1998
1731 Version 5 - Specification Revision 6
1734 As in the AS exchange, the client may specify a number
1735 of options in the KRB_TGS_REQ message. The client prepares
1736 the KRB_TGS_REQ message, providing an authentication header
1737 as an element of the padata field, and including the same
1738 fields as used in the KRB_AS_REQ message along with several
1739 optional fields: the enc-authorization-data field for appli-
1740 cation server use and additional tickets required by some
1743 In preparing the authentication header, the client can
1744 select a sub-session key under which the response from the
1745 Kerberos server will be encrypted[16]. If the sub-session
1746 key is not specified, the session key from the ticket-
1747 granting ticket will be used. If the enc-authorization-data
1748 is present, it must be encrypted in the sub-session key, if
1749 present, from the authenticator portion of the authentica-
1750 tion header, or if not present, using the session key from
1751 the ticket-granting ticket.
1753 Once prepared, the message is sent to a Kerberos server
1754 for the destination realm. See section A.5 for pseudocode.
1756 3.3.2. Receipt of KRB_TGS_REQ message
1758 The KRB_TGS_REQ message is processed in a manner simi-
1759 lar to the KRB_AS_REQ message, but there are many additional
1760 checks to be performed. First, the Kerberos server must
1761 determine which server the accompanying ticket is for and it
1762 must select the appropriate key to decrypt it. For a normal
1763 KRB_TGS_REQ message, it will be for the ticket granting ser-
1764 vice, and the TGS's key will be used. If the TGT was issued
1765 by another realm, then the appropriate inter-realm key must
1766 be used. If the accompanying ticket is not a ticket grant-
1767 ing ticket for the current realm, but is for an application
1768 server in the current realm, the RENEW, VALIDATE, or PROXY
1769 options are specified in the request, and the server for
1770 which a ticket is requested is the server named in the
1771 accompanying ticket, then the KDC will decrypt the ticket in
1772 the authentication header using the key of the server for
1773 which it was issued. If no ticket can be found in the
1774 padata field, the KDC_ERR_PADATA_TYPE_NOSUPP error is
1777 Once the accompanying ticket has been decrypted, the
1778 user-supplied checksum in the Authenticator must be verified
1779 against the contents of the request, and the message
1780 rejected if the checksums do not match (with an error code
1781 __________________________
1782 [16] If the client selects a sub-session key, care must
1783 be taken to ensure the randomness of the selected sub-
1784 session key. One approach would be to generate a ran-
1785 dom number and XOR it with the session key from the
1786 ticket-granting ticket.
1789 Section 3.3.2. - 27 - Expires 11 January 1998
1797 Version 5 - Specification Revision 6
1800 of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or
1801 not collision-proof (with an error code of
1802 KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not sup-
1803 ported, the KDC_ERR_SUMTYPE_NOSUPP error is returned. If
1804 the authorization-data are present, they are decrypted using
1805 the sub-session key from the Authenticator.
1807 If any of the decryptions indicate failed integrity
1808 checks, the KRB_AP_ERR_BAD_INTEGRITY error is returned.
1810 3.3.3. Generation of KRB_TGS_REP message
1812 The KRB_TGS_REP message shares its format with the
1813 KRB_AS_REP (KRB_KDC_REP), but with its type field set to
1814 KRB_TGS_REP. The detailed specification is in section
1817 The response will include a ticket for the requested
1818 server. The Kerberos database is queried to retrieve the
1819 record for the requested server (including the key with
1820 which the ticket will be encrypted). If the request is for
1821 a ticket granting ticket for a remote realm, and if no key
1822 is shared with the requested realm, then the Kerberos server
1823 will select the realm "closest" to the requested realm with
1824 which it does share a key, and use that realm instead. This
1825 is the only case where the response from the KDC will be for
1826 a different server than that requested by the client.
1828 By default, the address field, the client's name and
1829 realm, the list of transited realms, the time of initial
1830 authentication, the expiration time, and the authorization
1831 data of the newly-issued ticket will be copied from the
1832 ticket-granting ticket (TGT) or renewable ticket. If the
1833 transited field needs to be updated, but the transited type
1834 is not supported, the KDC_ERR_TRTYPE_NOSUPP error is
1837 If the request specifies an endtime, then the endtime
1838 of the new ticket is set to the minimum of (a) that request,
1839 (b) the endtime from the TGT, and (c) the starttime of the
1840 TGT plus the minimum of the maximum life for the application
1841 server and the maximum life for the local realm (the maximum
1842 life for the requesting principal was already applied when
1843 the TGT was issued). If the new ticket is to be a renewal,
1844 then the endtime above is replaced by the minimum of (a) the
1845 value of the renew_till field of the ticket and (b) the
1846 starttime for the new ticket plus the life (endtime-
1847 starttime) of the old ticket.
1849 If the FORWARDED option has been requested, then the
1850 resulting ticket will contain the addresses specified by the
1851 client. This option will only be honored if the FORWARDABLE
1852 flag is set in the TGT. The PROXY option is similar; the
1853 resulting ticket will contain the addresses specified by the
1856 Section 3.3.3. - 28 - Expires 11 January 1998
1864 Version 5 - Specification Revision 6
1867 client. It will be honored only if the PROXIABLE flag in
1868 the TGT is set. The PROXY option will not be honored on
1869 requests for additional ticket-granting tickets.
1871 If the requested start time is absent, indicates a time
1872 in the past, or is within the window of acceptable clock
1873 skew for the KDC and the POSTDATE option has not been speci-
1874 fied, then the start time of the ticket is set to the
1875 authentication server's current time. If it indicates a
1876 time in the future beyond the acceptable clock skew, but the
1877 POSTDATED option has not been specified or the MAY-POSTDATE
1878 flag is not set in the TGT, then the error
1879 KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the
1880 ticket-granting ticket has the MAY-POSTDATE flag set, then
1881 the resulting ticket will be postdated and the requested
1882 starttime is checked against the policy of the local realm.
1883 If acceptable, the ticket's start time is set as requested,
1884 and the INVALID flag is set. The postdated ticket must be
1885 validated before use by presenting it to the KDC after the
1886 starttime has been reached. However, in no case may the
1887 starttime, endtime, or renew-till time of a newly-issued
1888 postdated ticket extend beyond the renew-till time of the
1889 ticket-granting ticket.
1891 If the ENC-TKT-IN-SKEY option has been specified and an
1892 additional ticket has been included in the request, the KDC
1893 will decrypt the additional ticket using the key for the
1894 server to which the additional ticket was issued and verify
1895 that it is a ticket-granting ticket. If the name of the
1896 requested server is missing from the request, the name of
1897 the client in the additional ticket will be used. Otherwise
1898 the name of the requested server will be compared to the
1899 name of the client in the additional ticket and if dif-
1900 ferent, the request will be rejected. If the request
1901 succeeds, the session key from the additional ticket will be
1902 used to encrypt the new ticket that is issued instead of
1903 using the key of the server for which the new ticket will be
1906 If the name of the server in the ticket that is
1907 presented to the KDC as part of the authentication header is
1908 not that of the ticket-granting server itself, the server is
1909 registered in the realm of the KDC, and the RENEW option is
1910 requested, then the KDC will verify that the RENEWABLE flag
1911 is set in the ticket, that the INVALID flag is not set in
1912 the ticket, and that the renew_till time is still in the
1913 future. If the VALIDATE option is rqeuested, the KDC will
1914 __________________________
1915 [17] This allows easy implementation of user-to-user
1916 authentication [8], which uses ticket-granting ticket
1917 session keys in lieu of secret server keys in situa-
1918 tions where such secret keys could be easily comprom-
1922 Section 3.3.3. - 29 - Expires 11 January 1998
1930 Version 5 - Specification Revision 6
1933 check that the starttime has passed and the INVALID flag is
1934 set. If the PROXY option is requested, then the KDC will
1935 check that the PROXIABLE flag is set in the ticket. If the
1936 tests succeed, and the ticket passes the hotlist check
1937 described in the next paragraph, the KDC will issue the
1938 appropriate new ticket.
1941 3.3.3.1. Checking for revoked tickets
1943 Whenever a request is made to the ticket-granting
1944 server, the presented ticket(s) is(are) checked against a
1945 hot-list of tickets which have been canceled. This hot-list
1946 might be implemented by storing a range of issue timestamps
1947 for "suspect tickets"; if a presented ticket had an authtime
1948 in that range, it would be rejected. In this way, a stolen
1949 ticket-granting ticket or renewable ticket cannot be used to
1950 gain additional tickets (renewals or otherwise) once the
1951 theft has been reported. Any normal ticket obtained before
1952 it was reported stolen will still be valid (because they
1953 require no interaction with the KDC), but only until their
1954 normal expiration time.
1956 The ciphertext part of the response in the KRB_TGS_REP
1957 message is encrypted in the sub-session key from the Authen-
1958 ticator, if present, or the session key key from the
1959 ticket-granting ticket. It is not encrypted using the
1960 client's secret key. Furthermore, the client's key's
1961 expiration date and the key version number fields are left
1962 out since these values are stored along with the client's
1963 database record, and that record is not needed to satisfy a
1964 request based on a ticket-granting ticket. See section A.6
1967 3.3.3.2. Encoding the transited field
1969 If the identity of the server in the TGT that is
1970 presented to the KDC as part of the authentication header is
1971 that of the ticket-granting service, but the TGT was issued
1972 from another realm, the KDC will look up the inter-realm key
1973 shared with that realm and use that key to decrypt the
1974 ticket. If the ticket is valid, then the KDC will honor the
1975 request, subject to the constraints outlined above in the
1976 section describing the AS exchange. The realm part of the
1977 client's identity will be taken from the ticket-granting
1978 ticket. The name of the realm that issued the ticket-
1979 granting ticket will be added to the transited field of the
1980 ticket to be issued. This is accomplished by reading the
1981 transited field from the ticket-granting ticket (which is
1982 treated as an unordered set of realm names), adding the new
1983 realm to the set, then constructing and writing out its
1984 encoded (shorthand) form (this may involve a rearrangement
1985 of the existing encoding).
1989 Section 3.3.3.2. - 30 - Expires 11 January 1998
1997 Version 5 - Specification Revision 6
2000 Note that the ticket-granting service does not add the
2001 name of its own realm. Instead, its responsibility is to
2002 add the name of the previous realm. This prevents a mali-
2003 cious Kerberos server from intentionally leaving out its own
2004 name (it could, however, omit other realms' names).
2006 The names of neither the local realm nor the
2007 principal's realm are to be included in the transited field.
2008 They appear elsewhere in the ticket and both are known to
2009 have taken part in authenticating the principal. Since the
2010 endpoints are not included, both local and single-hop
2011 inter-realm authentication result in a transited field that
2014 Because the name of each realm transited is added to
2015 this field, it might potentially be very long. To decrease
2016 the length of this field, its contents are encoded. The
2017 initially supported encoding is optimized for the normal
2018 case of inter-realm communication: a hierarchical arrange-
2019 ment of realms using either domain or X.500 style realm
2020 names. This encoding (called DOMAIN-X500-COMPRESS) is now
2023 Realm names in the transited field are separated by a
2024 ",". The ",", "\", trailing "."s, and leading spaces (" ")
2025 are special characters, and if they are part of a realm
2026 name, they must be quoted in the transited field by preced-
2027 ing them with a "\".
2029 A realm name ending with a "." is interpreted as being
2030 prepended to the previous realm. For example, we can encode
2031 traversal of EDU, MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU,
2032 and CS.WASHINGTON.EDU as:
2034 "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
2036 Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-
2037 points, that they would not be included in this field, and
2040 "EDU,MIT.,WASHINGTON.EDU"
2042 A realm name beginning with a "/" is interpreted as being
2043 appended to the previous realm[18]. If it is to stand by
2044 itself, then it should be preceded by a space (" "). For
2045 example, we can encode traversal of /COM/HP/APOLLO, /COM/HP,
2046 /COM, and /COM/DEC as:
2048 "/COM,/HP,/APOLLO, /COM/DEC".
2049 __________________________
2050 [18] For the purpose of appending, the realm preceding
2051 the first listed realm is considered to be the null
2055 Section 3.3.3.2. - 31 - Expires 11 January 1998
2063 Version 5 - Specification Revision 6
2066 Like the example above, if /COM/HP/APOLLO and /COM/DEC are
2067 endpoints, they they would not be included in this field,
2073 A null subfield preceding or following a "," indicates
2074 that all realms between the previous realm and the next
2075 realm have been traversed[19]. Thus, "," means that all
2076 realms along the path between the client and the server have
2077 been traversed. ",EDU, /COM," means that that all realms
2078 from the client's realm up to EDU (in a domain style hierar-
2079 chy) have been traversed, and that everything from /COM down
2080 to the server's realm in an X.500 style has also been
2081 traversed. This could occur if the EDU realm in one hierar-
2082 chy shares an inter-realm key directly with the /COM realm
2083 in another hierarchy.
2085 3.3.4. Receipt of KRB_TGS_REP message
2087 When the KRB_TGS_REP is received by the client, it is pro-
2088 cessed in the same manner as the KRB_AS_REP processing
2089 described above. The primary difference is that the cipher-
2090 text part of the response must be decrypted using the ses-
2091 sion key from the ticket-granting ticket rather than the
2092 client's secret key. See section A.7 for pseudocode.
2095 3.4. The KRB_SAFE Exchange
2097 The KRB_SAFE message may be used by clients requiring
2098 the ability to detect modifications of messages they
2099 exchange. It achieves this by including a keyed collision-
2100 proof checksum of the user data and some control informa-
2101 tion. The checksum is keyed with an encryption key (usually
2102 the last key negotiated via subkeys, or the session key if
2103 no negotiation has occured).
2105 3.4.1. Generation of a KRB_SAFE message
2107 When an application wishes to send a KRB_SAFE message, it
2108 collects its data and the appropriate control information
2109 and computes a checksum over them. The checksum algorithm
2110 should be a keyed one-way hash function (such as the RSA-
2111 MD5-DES checksum algorithm specified in section 6.4.5, or
2112 the DES MAC), generated using the sub-session key if
2113 present, or the session key. Different algorithms may be
2114 __________________________
2115 [19] For the purpose of interpreting null subfields,
2116 the client's realm is considered to precede those in
2117 the transited field, and the server's realm is con-
2118 sidered to follow them.
2121 Section 3.4.1. - 32 - Expires 11 January 1998
2129 Version 5 - Specification Revision 6
2132 selected by changing the checksum type in the message.
2133 Unkeyed or non-collision-proof checksums are not suitable
2136 The control information for the KRB_SAFE message
2137 includes both a timestamp and a sequence number. The
2138 designer of an application using the KRB_SAFE message must
2139 choose at least one of the two mechanisms. This choice
2140 should be based on the needs of the application protocol.
2142 Sequence numbers are useful when all messages sent will
2143 be received by one's peer. Connection state is presently
2144 required to maintain the session key, so maintaining the
2145 next sequence number should not present an additional prob-
2148 If the application protocol is expected to tolerate
2149 lost messages without them being resent, the use of the
2150 timestamp is the appropriate replay detection mechanism.
2151 Using timestamps is also the appropriate mechanism for
2152 multi-cast protocols where all of one's peers share a common
2153 sub-session key, but some messages will be sent to a subset
2156 After computing the checksum, the client then transmits
2157 the information and checksum to the recipient in the message
2158 format specified in section 5.6.1.
2160 3.4.2. Receipt of KRB_SAFE message
2162 When an application receives a KRB_SAFE message, it verifies
2163 it as follows. If any error occurs, an error code is
2164 reported for use by the application.
2166 The message is first checked by verifying that the pro-
2167 tocol version and type fields match the current version and
2168 KRB_SAFE, respectively. A mismatch generates a
2169 KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The
2170 application verifies that the checksum used is a collision-
2171 proof keyed checksum, and if it is not, a
2172 KRB_AP_ERR_INAPP_CKSUM error is generated. The recipient
2173 verifies that the operating system's report of the sender's
2174 address matches the sender's address in the message, and (if
2175 a recipient address is specified or the recipient requires
2176 an address) that one of the recipient's addresses appears as
2177 the recipient's address in the message. A failed match for
2178 either case generates a KRB_AP_ERR_BADADDR error. Then the
2179 timestamp and usec and/or the sequence number fields are
2180 checked. If timestamp and usec are expected and not
2181 present, or they are present but not current, the
2182 KRB_AP_ERR_SKEW error is generated. If the server name,
2183 along with the client name, time and microsecond fields from
2184 the Authenticator match any recently-seen (sent or
2185 received[20] ) such tuples, the KRB_AP_ERR_REPEAT error is
2186 __________________________
2187 [20] This means that a client and server running on the
2194 Version 5 - Specification Revision 6
2197 generated. If an incorrect sequence number is included, or
2198 a sequence number is expected but not present, the
2199 KRB_AP_ERR_BADORDER error is generated. If neither a time-
2200 stamp and usec or a sequence number is present, a
2201 KRB_AP_ERR_MODIFIED error is generated. Finally, the check-
2202 sum is computed over the data and control information, and
2203 if it doesn't match the received checksum, a
2204 KRB_AP_ERR_MODIFIED error is generated.
2206 If all the checks succeed, the application is assured
2207 that the message was generated by its peer and was not modi-
2210 3.5. The KRB_PRIV Exchange
2212 The KRB_PRIV message may be used by clients requiring
2213 confidentiality and the ability to detect modifications of
2214 exchanged messages. It achieves this by encrypting the mes-
2215 sages and adding control information.
2217 3.5.1. Generation of a KRB_PRIV message
2219 When an application wishes to send a KRB_PRIV message, it
2220 collects its data and the appropriate control information
2221 (specified in section 5.7.1) and encrypts them under an
2222 encryption key (usually the last key negotiated via subkeys,
2223 or the session key if no negotiation has occured). As part
2224 of the control information, the client must choose to use
2225 either a timestamp or a sequence number (or both); see the
2226 discussion in section 3.4.1 for guidelines on which to use.
2227 After the user data and control information are encrypted,
2228 the client transmits the ciphertext and some "envelope"
2229 information to the recipient.
2231 3.5.2. Receipt of KRB_PRIV message
2233 When an application receives a KRB_PRIV message, it verifies
2234 it as follows. If any error occurs, an error code is
2235 reported for use by the application.
2237 The message is first checked by verifying that the pro-
2238 tocol version and type fields match the current version and
2239 KRB_PRIV, respectively. A mismatch generates a
2240 KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The
2241 application then decrypts the ciphertext and processes the
2242 resultant plaintext. If decryption shows the data to have
2243 been modified, a KRB_AP_ERR_BAD_INTEGRITY error is gen-
2244 erated. The recipient verifies that the operating system's
2245 report of the sender's address matches the sender's address
2246 __________________________
2247 same host and communicating with one another using the
2248 KRB_SAFE messages should not share a common replay
2249 cache to detect KRB_SAFE replays.
2253 Section 3.5.2. - 34 - Expires 11 January 1998
2261 Version 5 - Specification Revision 6
2264 in the message, and (if a recipient address is specified or
2265 the recipient requires an address) that one of the
2266 recipient's addresses appears as the recipient's address in
2267 the message. A failed match for either case generates a
2268 KRB_AP_ERR_BADADDR error. Then the timestamp and usec
2269 and/or the sequence number fields are checked. If timestamp
2270 and usec are expected and not present, or they are present
2271 but not current, the KRB_AP_ERR_SKEW error is generated. If
2272 the server name, along with the client name, time and
2273 microsecond fields from the Authenticator match any
2274 recently-seen such tuples, the KRB_AP_ERR_REPEAT error is
2275 generated. If an incorrect sequence number is included, or
2276 a sequence number is expected but not present, the
2277 KRB_AP_ERR_BADORDER error is generated. If neither a time-
2278 stamp and usec or a sequence number is present, a
2279 KRB_AP_ERR_MODIFIED error is generated.
2281 If all the checks succeed, the application can assume
2282 the message was generated by its peer, and was securely
2283 transmitted (without intruders able to see the unencrypted
2286 3.6. The KRB_CRED Exchange
2288 The KRB_CRED message may be used by clients requiring
2289 the ability to send Kerberos credentials from one host to
2290 another. It achieves this by sending the tickets together
2291 with encrypted data containing the session keys and other
2292 information associated with the tickets.
2294 3.6.1. Generation of a KRB_CRED message
2296 When an application wishes to send a KRB_CRED message it
2297 first (using the KRB_TGS exchange) obtains credentials to be
2298 sent to the remote host. It then constructs a KRB_CRED mes-
2299 sage using the ticket or tickets so obtained, placing the
2300 session key needed to use each ticket in the key field of
2301 the corresponding KrbCredInfo sequence of the encrypted part
2302 of the the KRB_CRED message.
2304 Other information associated with each ticket and
2305 obtained during the KRB_TGS exchange is also placed in the
2306 corresponding KrbCredInfo sequence in the encrypted part of
2307 the KRB_CRED message. The current time and, if specifically
2308 required by the application the nonce, s-address, and r-
2309 address fields, are placed in the encrypted part of the
2310 KRB_CRED message which is then encrypted under an encryption
2311 key previosuly exchanged in the KRB_AP exchange (usually the
2312 last key negotiated via subkeys, or the session key if no
2313 negotiation has occured).
2315 3.6.2. Receipt of KRB_CRED message
2317 When an application receives a KRB_CRED message, it verifies
2320 Section 3.6.2. - 35 - Expires 11 January 1998
2328 Version 5 - Specification Revision 6
2331 it. If any error occurs, an error code is reported for use
2332 by the application. The message is verified by checking
2333 that the protocol version and type fields match the current
2334 version and KRB_CRED, respectively. A mismatch generates a
2335 KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The
2336 application then decrypts the ciphertext and processes the
2337 resultant plaintext. If decryption shows the data to have
2338 been modified, a KRB_AP_ERR_BAD_INTEGRITY error is gen-
2341 If present or required, the recipient verifies that the
2342 operating system's report of the sender's address matches
2343 the sender's address in the message, and that one of the
2344 recipient's addresses appears as the recipient's address in
2345 the message. A failed match for either case generates a
2346 KRB_AP_ERR_BADADDR error. The timestamp and usec fields
2347 (and the nonce field if required) are checked next. If the
2348 timestamp and usec are not present, or they are present but
2349 not current, the KRB_AP_ERR_SKEW error is generated.
2351 If all the checks succeed, the application stores each
2352 of the new tickets in its ticket cache together with the
2353 session key and other information in the corresponding
2354 KrbCredInfo sequence from the encrypted part of the KRB_CRED
2357 4. The Kerberos Database
2359 The Kerberos server must have access to a database contain-
2360 ing the principal identifiers and secret keys of principals
2361 to be authenticated[21].
2363 4.1. Database contents
2365 A database entry should contain at least the following
2370 name Principal's identif-
2372 key Principal's secret key
2373 p_kvno Principal's key version
2374 max_life Maximum lifetime for Tickets
2375 __________________________
2376 [21] The implementation of the Kerberos server need not
2377 combine the database and the server on the same
2378 machine; it is feasible to store the principal database
2379 in, say, a network name service, as long as the entries
2380 stored therein are protected from disclosure to and
2381 modification by unauthorized parties. However, we
2382 recommend against such strategies, as they can make
2383 system management and threat analysis quite complex.
2386 Section 4.1. - 36 - Expires 11 January 1998
2394 Version 5 - Specification Revision 6
2397 max_renewable_life Maximum total lifetime for renewable Tickets
2399 The name field is an encoding of the principal's identifier.
2400 The key field contains an encryption key. This key is the
2401 principal's secret key. (The key can be encrypted before
2402 storage under a Kerberos "master key" to protect it in case
2403 the database is compromised but the master key is not. In
2404 that case, an extra field must be added to indicate the mas-
2405 ter key version used, see below.) The p_kvno field is the
2406 key version number of the principal's secret key. The
2407 max_life field contains the maximum allowable lifetime (end-
2408 time - starttime) for any Ticket issued for this principal.
2409 The max_renewable_life field contains the maximum allowable
2410 total lifetime for any renewable Ticket issued for this
2411 principal. (See section 3.1 for a description of how these
2412 lifetimes are used in determining the lifetime of a given
2415 A server may provide KDC service to several realms, as
2416 long as the database representation provides a mechanism to
2417 distinguish between principal records with identifiers which
2418 differ only in the realm name.
2420 When an application server's key changes, if the change
2421 is routine (i.e. not the result of disclosure of the old
2422 key), the old key should be retained by the server until all
2423 tickets that had been issued using that key have expired.
2424 Because of this, it is possible for several keys to be
2425 active for a single principal. Ciphertext encrypted in a
2426 principal's key is always tagged with the version of the key
2427 that was used for encryption, to help the recipient find the
2428 proper key for decryption.
2430 When more than one key is active for a particular prin-
2431 cipal, the principal will have more than one record in the
2432 Kerberos database. The keys and key version numbers will
2433 differ between the records (the rest of the fields may or
2434 may not be the same). Whenever Kerberos issues a ticket, or
2435 responds to a request for initial authentication, the most
2436 recent key (known by the Kerberos server) will be used for
2437 encryption. This is the key with the highest key version
2440 4.2. Additional fields
2442 Project Athena's KDC implementation uses additional fields
2447 K_kvno Kerberos' key version
2448 expiration Expiration date for entry
2449 attributes Bit field of attributes
2450 mod_date Timestamp of last modification
2453 Section 4.2. - 37 - Expires 11 January 1998
2461 Version 5 - Specification Revision 6
2464 mod_name Modifying principal's identifier
2467 The K_kvno field indicates the key version of the Kerberos
2468 master key under which the principal's secret key is
2471 After an entry's expiration date has passed, the KDC
2472 will return an error to any client attempting to gain tick-
2473 ets as or for the principal. (A database may want to main-
2474 tain two expiration dates: one for the principal, and one
2475 for the principal's current key. This allows password aging
2476 to work independently of the principal's expiration date.
2477 However, due to the limited space in the responses, the KDC
2478 must combine the key expiration and principal expiration
2479 date into a single value called "key_exp", which is used as
2480 a hint to the user to take administrative action.)
2482 The attributes field is a bitfield used to govern the
2483 operations involving the principal. This field might be
2484 useful in conjunction with user registration procedures, for
2485 site-specific policy implementations (Project Athena
2486 currently uses it for their user registration process con-
2487 trolled by the system-wide database service, Moira [9]), to
2488 identify whether a principal can play the role of a client
2489 or server or both, to note whether a server is appropriate
2490 trusted to recieve credentials delegated by a client, or to
2491 identify the "string to key" conversion algorithm used for a
2492 principal's key[22]. Other bits are used to indicate that
2493 certain ticket options should not be allowed in tickets
2494 encrypted under a principal's key (one bit each): Disallow
2495 issuing postdated tickets, disallow issuing forwardable
2496 tickets, disallow issuing tickets based on TGT authentica-
2497 tion, disallow issuing renewable tickets, disallow issuing
2498 proxiable tickets, and disallow issuing tickets for which
2499 the principal is the server.
2501 The mod_date field contains the time of last modifica-
2502 tion of the entry, and the mod_name field contains the name
2503 of the principal which last modified the entry.
2505 4.3. Frequently Changing Fields
2507 Some KDC implementations may wish to maintain the last
2508 time that a request was made by a particular principal.
2509 Information that might be maintained includes the time of
2510 the last request, the time of the last request for a
2511 ticket-granting ticket, the time of the last use of a
2512 ticket-granting ticket, or other times. This information
2513 can then be returned to the user in the last-req field (see
2514 __________________________
2515 [22] See the discussion of the padata field in section
2516 5.4.2 for details on why this can be useful.
2519 Section 4.3. - 38 - Expires 11 January 1998
2527 Version 5 - Specification Revision 6
2532 Other frequently changing information that can be main-
2533 tained is the latest expiration time for any tickets that
2534 have been issued using each key. This field would be used
2535 to indicate how long old keys must remain valid to allow the
2536 continued use of outstanding tickets.
2540 The KDC implementation should have the following confi-
2541 gurable constants or options, to allow an administrator to
2542 make and enforce policy decisions:
2544 + The minimum supported lifetime (used to determine whether
2545 the KDC_ERR_NEVER_VALID error should be returned). This
2546 constant should reflect reasonable expectations of
2547 round-trip time to the KDC, encryption/decryption time,
2548 and processing time by the client and target server, and
2549 it should allow for a minimum "useful" lifetime.
2551 + The maximum allowable total (renewable) lifetime of a
2552 ticket (renew_till - starttime).
2554 + The maximum allowable lifetime of a ticket (endtime -
2557 + Whether to allow the issue of tickets with empty address
2558 fields (including the ability to specify that such tick-
2559 ets may only be issued if the request specifies some
2560 authorization_data).
2562 + Whether proxiable, forwardable, renewable or post-datable
2563 tickets are to be issued.
2566 5. Message Specifications
2568 The following sections describe the exact contents and
2569 encoding of protocol messages and objects. The ASN.1 base
2570 definitions are presented in the first subsection. The
2571 remaining subsections specify the protocol objects (tickets
2572 and authenticators) and messages. Specification of encryp-
2573 tion and checksum techniques, and the fields related to
2574 them, appear in section 6.
2576 5.1. ASN.1 Distinguished Encoding Representation
2578 All uses of ASN.1 in Kerberos shall use the Dis-
2579 tinguished Encoding Representation of the data elements as
2580 described in the X.509 specification, section 8.7 [10].
2586 Section 5.1. - 39 - Expires 11 January 1998
2594 Version 5 - Specification Revision 6
2597 5.2. ASN.1 Base Definitions
2599 The following ASN.1 base definitions are used in the
2600 rest of this section. Note that since the underscore char-
2601 acter (_) is not permitted in ASN.1 names, the hyphen (-) is
2602 used in its place for the purposes of ASN.1 names.
2604 Realm ::= GeneralString
2605 PrincipalName ::= SEQUENCE {
2606 name-type[0] INTEGER,
2607 name-string[1] SEQUENCE OF GeneralString
2611 Kerberos realms are encoded as GeneralStrings. Realms shall
2612 not contain a character with the code 0 (the ASCII NUL).
2613 Most realms will usually consist of several components
2614 separated by periods (.), in the style of Internet Domain
2615 Names, or separated by slashes (/) in the style of X.500
2616 names. Acceptable forms for realm names are specified in
2617 section 7. A PrincipalName is a typed sequence of com-
2618 ponents consisting of the following sub-fields:
2620 name-type This field specifies the type of name that fol-
2621 lows. Pre-defined values for this field are
2622 specified in section 7.2. The name-type should be
2623 treated as a hint. Ignoring the name type, no two
2624 names can be the same (i.e. at least one of the
2625 components, or the realm, must be different).
2626 This constraint may be eliminated in the future.
2628 name-stringThis field encodes a sequence of components that
2629 form a name, each component encoded as a General-
2630 String. Taken together, a PrincipalName and a
2631 Realm form a principal identifier. Most Princi-
2632 palNames will have only a few components (typi-
2637 KerberosTime ::= GeneralizedTime
2638 -- Specifying UTC time zone (Z)
2641 The timestamps used in Kerberos are encoded as General-
2642 izedTimes. An encoding shall specify the UTC time zone (Z)
2643 and shall not include any fractional portions of the
2644 seconds. It further shall not include any separators.
2645 Example: The only valid format for UTC time 6 minutes, 27
2646 seconds after 9 pm on 6 November 1985 is 19851106210627Z.
2648 HostAddress ::= SEQUENCE {
2649 addr-type[0] INTEGER,
2650 address[1] OCTET STRING
2653 Section 5.2. - 40 - Expires 11 January 1998
2661 Version 5 - Specification Revision 6
2666 HostAddresses ::= SEQUENCE OF SEQUENCE {
2667 addr-type[0] INTEGER,
2668 address[1] OCTET STRING
2672 The host adddress encodings consists of two fields:
2674 addr-type This field specifies the type of address that
2675 follows. Pre-defined values for this field are
2676 specified in section 8.1.
2679 address This field encodes a single address of type addr-
2682 The two forms differ slightly. HostAddress contains exactly
2683 one address; HostAddresses contains a sequence of possibly
2686 AuthorizationData ::= SEQUENCE OF SEQUENCE {
2688 ad-data[1] OCTET STRING
2692 ad-data This field contains authorization data to be
2693 interpreted according to the value of the
2694 corresponding ad-type field.
2696 ad-type This field specifies the format for the ad-data
2697 subfield. All negative values are reserved for
2698 local use. Non-negative values are reserved for
2701 APOptions ::= BIT STRING {
2708 TicketFlags ::= BIT STRING {
2721 Section 5.2. - 41 - Expires 11 January 1998
2729 Version 5 - Specification Revision 6
2734 transited-policy-checked(12),
2739 KDCOptions ::= BIT STRING {
2754 disable-transited-check(26),
2756 enc-tkt-in-skey(28),
2761 ASN.1 Bit strings have a length and a value. When
2762 used in Kerberos for the APOptions, TicketFlags,
2763 and KDCOptions, the length of the bit string on
2764 generated values should be the smallest multiple
2765 of 32 bits needed to include the highest order bit
2766 that is set (1), but in no case less than 32 bits.
2767 Implementations should accept values of bit
2768 strings of any length and treat the value of flags
2769 cooresponding to bits beyond the end of the bit
2770 string as if the bit were reset (0). Comparisonof
2771 bit strings of different length should treat the
2772 smaller string as if it were padded with zeros
2773 beyond the high order bits to the length of the
2776 __________________________
2777 [23] Warning for implementations that unpack and repack
2778 data structures during the generation and verification
2779 of embedded checksums: Because any checksums applied to
2780 data structures must be checked against the original
2781 data the length of bit strings must be preserved within
2782 a data structure between the time that a checksum is
2783 generated through transmission to the time that the
2784 checksum is verified.
2788 Section 5.2. - 42 - Expires 11 January 1998
2796 Version 5 - Specification Revision 6
2799 LastReq ::= SEQUENCE OF SEQUENCE {
2801 lr-value[1] KerberosTime
2805 lr-type This field indicates how the following lr-value
2806 field is to be interpreted. Negative values indi-
2807 cate that the information pertains only to the
2808 responding server. Non-negative values pertain to
2809 all servers for the realm.
2811 If the lr-type field is zero (0), then no informa-
2812 tion is conveyed by the lr-value subfield. If the
2813 absolute value of the lr-type field is one (1),
2814 then the lr-value subfield is the time of last
2815 initial request for a TGT. If it is two (2), then
2816 the lr-value subfield is the time of last initial
2817 request. If it is three (3), then the lr-value
2818 subfield is the time of issue for the newest
2819 ticket-granting ticket used. If it is four (4),
2820 then the lr-value subfield is the time of the last
2821 renewal. If it is five (5), then the lr-value
2822 subfield is the time of last request (of any
2826 lr-value This field contains the time of the last request.
2827 The time must be interpreted according to the con-
2828 tents of the accompanying lr-type subfield.
2830 See section 6 for the definitions of Checksum, Check-
2831 sumType, EncryptedData, EncryptionKey, EncryptionType, and
2835 5.3. Tickets and Authenticators
2837 This section describes the format and encryption param-
2838 eters for tickets and authenticators. When a ticket or
2839 authenticator is included in a protocol message it is
2840 treated as an opaque object.
2844 A ticket is a record that helps a client authenticate
2845 to a service. A Ticket contains the following information:
2847 Ticket ::= [APPLICATION 1] SEQUENCE {
2850 sname[2] PrincipalName,
2851 enc-part[3] EncryptedData
2855 Section 5.3.1. - 43 - Expires 11 January 1998
2863 Version 5 - Specification Revision 6
2866 -- Encrypted part of ticket
2867 EncTicketPart ::= [APPLICATION 3] SEQUENCE {
2868 flags[0] TicketFlags,
2869 key[1] EncryptionKey,
2871 cname[3] PrincipalName,
2872 transited[4] TransitedEncoding,
2873 authtime[5] KerberosTime,
2874 starttime[6] KerberosTime OPTIONAL,
2875 endtime[7] KerberosTime,
2876 renew-till[8] KerberosTime OPTIONAL,
2877 caddr[9] HostAddresses OPTIONAL,
2878 authorization-data[10] AuthorizationData OPTIONAL
2880 -- encoded Transited field
2881 TransitedEncoding ::= SEQUENCE {
2882 tr-type[0] INTEGER, -- must be registered
2883 contents[1] OCTET STRING
2886 The encoding of EncTicketPart is encrypted in the key shared
2887 by Kerberos and the end server (the server's secret key).
2888 See section 6 for the format of the ciphertext.
2890 tkt-vno This field specifies the version number for the
2891 ticket format. This document describes version
2895 realm This field specifies the realm that issued a
2896 ticket. It also serves to identify the realm part
2897 of the server's principal identifier. Since a
2898 Kerberos server can only issue tickets for servers
2899 within its realm, the two will always be identi-
2903 sname This field specifies the name part of the server's
2907 enc-part This field holds the encrypted encoding of the
2908 EncTicketPart sequence.
2911 flags This field indicates which of various options were
2912 used or requested when the ticket was issued. It
2913 is a bit-field, where the selected options are
2914 indicated by the bit being set (1), and the
2915 unselected options and reserved fields being reset
2916 (0). Bit 0 is the most significant bit. The
2917 encoding of the bits is specified in section 5.2.
2918 The flags are described in more detail above in
2919 section 2. The meanings of the flags are:
2922 Section 5.3.1. - 44 - Expires 11 January 1998
2928 Version 5 - Specification Revision 6
2931 Bit(s) Name Description
2934 Reserved for future expansion of this
2938 The FORWARDABLE flag is normally only
2939 interpreted by the TGS, and can be
2940 ignored by end servers. When set, this
2941 flag tells the ticket-granting server
2942 that it is OK to issue a new ticket-
2943 granting ticket with a different network
2944 address based on the presented ticket.
2947 When set, this flag indicates that the
2948 ticket has either been forwarded or was
2949 issued based on authentication involving
2950 a forwarded ticket-granting ticket.
2953 The PROXIABLE flag is normally only
2954 interpreted by the TGS, and can be
2955 ignored by end servers. The PROXIABLE
2956 flag has an interpretation identical to
2957 that of the FORWARDABLE flag, except
2958 that the PROXIABLE flag tells the
2959 ticket-granting server that only non-
2960 ticket-granting tickets may be issued
2961 with different network addresses.
2964 When set, this flag indicates that a
2968 The MAY-POSTDATE flag is normally only
2969 interpreted by the TGS, and can be
2970 ignored by end servers. This flag tells
2971 the ticket-granting server that a post-
2972 dated ticket may be issued based on this
2973 ticket-granting ticket.
2976 This flag indicates that this ticket has
2977 been postdated. The end-service can
2978 check the authtime field to see when the
2979 original authentication occurred.
2982 This flag indicates that a ticket is
2983 invalid, and it must be validated by the
2984 KDC before use. Application servers
2985 must reject tickets which have this flag
2995 Section 5.3.1. - 45 - Expires 11 January 1998
3003 Version 5 - Specification Revision 6
3007 The RENEWABLE flag is normally only
3008 interpreted by the TGS, and can usually
3009 be ignored by end servers (some particu-
3010 larly careful servers may wish to disal-
3011 low renewable tickets). A renewable
3012 ticket can be used to obtain a replace-
3013 ment ticket that expires at a later
3017 This flag indicates that this ticket was
3018 issued using the AS protocol, and not
3019 issued based on a ticket-granting
3023 This flag indicates that during initial
3024 authentication, the client was authenti-
3025 cated by the KDC before a ticket was
3026 issued. The strength of the pre-
3027 authentication method is not indicated,
3028 but is acceptable to the KDC.
3031 This flag indicates that the protocol
3032 employed for initial authentication
3033 required the use of hardware expected to
3034 be possessed solely by the named client.
3035 The hardware authentication method is
3036 selected by the KDC and the strength of
3037 the method is not indicated.
3042 Section 5.3.1. - 46 - Expires 11 January 1998
3050 Version 5 - Specification Revision 6
3053 12 TRANSITED This flag indicates that the KDC for the
3054 POLICY-CHECKED realm has checked the transited field
3055 against a realm defined policy for
3056 trusted certifiers. If this flag is
3057 reset (0), then the application server
3058 must check the transited field itself,
3059 and if unable to do so it must reject
3060 the authentication. If the flag is set
3061 (1) then the application server may skip
3062 its own validation of the transited
3063 field, relying on the validation
3064 performed by the KDC. At its option the
3065 application server may still apply its
3066 own validation based on a separate
3067 policy for acceptance.
3069 Section 5.3.1. - 47 - Expires 11 January 1998
3077 Version 5 - Specification Revision 6
3080 13 OK-AS-DELEGATE This flag indicates that the server (not
3081 the client) specified in the ticket has
3082 been determined by policy of the realm
3083 to be a suitable recipient of
3084 delegation. A client can use the
3085 presence of this flag to help it make a
3086 decision whether to delegate credentials
3087 (either grant a proxy or a forwarded
3088 ticket granting ticket) to this server.
3089 The client is free to ignore the value
3090 of this flag. When setting this flag,
3091 an administrator should consider the
3092 security and placement of the server on
3093 which the service will run, as well as
3094 whether the service requires the use of
3095 delegated credentials.
3100 Section 5.3.1. - 48 - Expires 11 January 1998
3108 Version 5 - Specification Revision 6
3112 This flag indicates that the principal
3113 named in the ticket is a generic princi-
3114 pal for the realm and does not identify
3115 the individual using the ticket. The
3116 purpose of the ticket is only to
3117 securely distribute a session key, and
3118 not to identify the user. Subsequent
3119 requests using the same ticket and ses-
3120 sion may be considered as originating
3121 from the same user, but requests with
3122 the same username but a different ticket
3123 are likely to originate from different
3127 Reserved for future use.
3131 key This field exists in the ticket and the KDC
3132 response and is used to pass the session key from
3133 Kerberos to the application server and the client.
3134 The field's encoding is described in section 6.2.
3136 crealm This field contains the name of the realm in which
3137 the client is registered and in which initial
3138 authentication took place.
3141 cname This field contains the name part of the client's
3142 principal identifier.
3145 transited This field lists the names of the Kerberos realms
3146 that took part in authenticating the user to whom
3147 this ticket was issued. It does not specify the
3148 order in which the realms were transited. See
3149 section 3.3.3.2 for details on how this field
3150 encodes the traversed realms.
3153 authtime This field indicates the time of initial authenti-
3154 cation for the named principal. It is the time of
3155 issue for the original ticket on which this ticket
3156 is based. It is included in the ticket to provide
3157 additional information to the end service, and to
3158 provide the necessary information for implementa-
3159 tion of a `hot list' service at the KDC. An end
3160 service that is particularly paranoid could refuse
3161 to accept tickets for which the initial authenti-
3162 cation occurred "too far" in the past.
3164 This field is also returned as part of the
3165 response from the KDC. When returned as part of
3166 the response to initial authentication
3169 Section 5.3.1. - 49 - Expires 11 January 1998
3177 Version 5 - Specification Revision 6
3180 (KRB_AS_REP), this is the current time on the Ker-
3184 starttime This field in the ticket specifies the time after
3185 which the ticket is valid. Together with endtime,
3186 this field specifies the life of the ticket. If
3187 it is absent from the ticket, its value should be
3188 treated as that of the authtime field.
3191 endtime This field contains the time after which the
3192 ticket will not be honored (its expiration time).
3193 Note that individual services may place their own
3194 limits on the life of a ticket and may reject
3195 tickets which have not yet expired. As such, this
3196 is really an upper bound on the expiration time
3200 renew-tillThis field is only present in tickets that have
3201 the RENEWABLE flag set in the flags field. It
3202 indicates the maximum endtime that may be included
3203 in a renewal. It can be thought of as the abso-
3204 lute expiration time for the ticket, including all
3208 caddr This field in a ticket contains zero (if omitted)
3209 or more (if present) host addresses. These are
3210 the addresses from which the ticket can be used.
3211 If there are no addresses, the ticket can be used
3212 from any location. The decision by the KDC to
3213 issue or by the end server to accept zero-address
3214 tickets is a policy decision and is left to the
3215 Kerberos and end-service administrators; they may
3216 refuse to issue or accept such tickets. The sug-
3217 gested and default policy, however, is that such
3218 tickets will only be issued or accepted when addi-
3219 tional information that can be used to restrict
3220 the use of the ticket is included in the
3221 authorization_data field. Such a ticket is a
3224 Network addresses are included in the ticket to
3225 make it harder for an attacker to use stolen
3226 credentials. Because the session key is not sent
3227 over the network in cleartext, credentials can't
3228 __________________________
3229 [24] It is NOT recommended that this time value be used
3230 to adjust the workstation's clock since the workstation
3231 cannot reliably determine that such a KRB_AS_REP actu-
3232 ally came from the proper KDC in a timely manner.
3235 Section 5.3.1. - 50 - Expires 11 January 1998
3243 Version 5 - Specification Revision 6
3246 be stolen simply by listening to the network; an
3247 attacker has to gain access to the session key
3248 (perhaps through operating system security
3249 breaches or a careless user's unattended session)
3250 to make use of stolen tickets.
3252 It is important to note that the network address
3253 from which a connection is received cannot be
3254 reliably determined. Even if it could be, an
3255 attacker who has compromised the client's worksta-
3256 tion could use the credentials from there.
3257 Including the network addresses only makes it more
3258 difficult, not impossible, for an attacker to walk
3259 off with stolen credentials and then use them from
3264 The authorization-data field is used to pass
3265 authorization data from the principal on whose
3266 behalf a ticket was issued to the application ser-
3267 vice. If no authorization data is included, this
3268 field will be left out. Experience has shown that
3269 the name of this field is confusing, and that a
3270 better name for this field would be restrictions.
3271 Unfortunately, it is not possible to change the
3272 name of this field at this time.
3274 This field contains restrictions on any authority
3275 obtained on the bases of authentication using the
3276 ticket. It is possible for any principal in
3277 posession of credentials to add entries to the
3278 authorization data field since these entries
3279 further restrict what can be done with the ticket.
3280 Such additions can be made by specifying the addi-
3281 tional entries when a new ticket is obtained dur-
3282 ing the TGS exchange, or they may be added during
3283 chained delegation using the authorization data
3284 field of the authenticator.
3286 Because entries may be added to this field by the
3287 holder of credentials, it is not allowable for the
3288 presence of an entry in the authorization data
3289 field of a ticket to amplify the priveleges one
3290 would obtain from using a ticket.
3292 The data in this field may be specific to the end
3293 service; the field will contain the names of ser-
3294 vice specific objects, and the rights to those
3295 objects. The format for this field is described
3296 in section 5.2. Although Kerberos is not con-
3297 cerned with the format of the contents of the sub-
3298 fields, it does carry type information (ad-type).
3302 Section 5.3.1. - 51 - Expires 11 January 1998
3310 Version 5 - Specification Revision 6
3313 By using the authorization_data field, a principal
3314 is able to issue a proxy that is valid for a
3315 specific purpose. For example, a client wishing
3316 to print a file can obtain a file server proxy to
3317 be passed to the print server. By specifying the
3318 name of the file in the authorization_data field,
3319 the file server knows that the print server can
3320 only use the client's rights when accessing the
3321 particular file to be printed.
3323 A separate service providing providing authoriza-
3324 tion or certifying group membership may be built
3325 using the authorization-data field. In this case,
3326 the entity granting authorization (not the author-
3327 ized entity), obtains a ticket in its own name
3328 (e.g. the ticket is issued in the name of a
3329 privelege server), and this entity adds restric-
3330 tions on its own authority and delegates the res-
3331 tricted authority through a proxy to the client.
3332 The client would then present this authorization
3333 credential to the application server separately
3334 from the authentication exchange.
3336 Similarly, if one specifies the authorization-data
3337 field of a proxy and leaves the host addresses
3338 blank, the resulting ticket and session key can be
3339 treated as a capability. See [7] for some sug-
3340 gested uses of this field.
3342 The authorization-data field is optional and does
3343 not have to be included in a ticket.
3346 5.3.2. Authenticators
3348 An authenticator is a record sent with a ticket to a
3349 server to certify the client's knowledge of the encryption
3350 key in the ticket, to help the server detect replays, and to
3351 help choose a "true session key" to use with the particular
3352 session. The encoding is encrypted in the ticket's session
3353 key shared by the client and the server:
3355 -- Unencrypted authenticator
3356 Authenticator ::= [APPLICATION 2] SEQUENCE {
3357 authenticator-vno[0] INTEGER,
3359 cname[2] PrincipalName,
3360 cksum[3] Checksum OPTIONAL,
3362 ctime[5] KerberosTime,
3363 subkey[6] EncryptionKey OPTIONAL,
3364 seq-number[7] INTEGER OPTIONAL,
3365 authorization-data[8] AuthorizationData OPTIONAL
3370 Section 5.3.2. - 52 - Expires 11 January 1998
3378 Version 5 - Specification Revision 6
3382 This field specifies the version number for the
3383 format of the authenticator. This document speci-
3388 These fields are the same as those described for
3389 the ticket in section 5.3.1.
3392 cksum This field contains a checksum of the the applica-
3393 tion data that accompanies the KRB_AP_REQ.
3396 cusec This field contains the microsecond part of the
3397 client's timestamp. Its value (before encryption)
3398 ranges from 0 to 999999. It often appears along
3399 with ctime. The two fields are used together to
3400 specify a reasonably accurate timestamp.
3403 ctime This field contains the current time on the
3407 subkey This field contains the client's choice for an
3408 encryption key which is to be used to protect this
3409 specific application session. Unless an applica-
3410 tion specifies otherwise, if this field is left
3411 out the session key from the ticket will be used.
3413 seq-numberThis optional field includes the initial sequence
3414 number to be used by the KRB_PRIV or KRB_SAFE mes-
3415 sages when sequence numbers are used to detect
3416 replays (It may also be used by application
3417 specific messages). When included in the authen-
3418 ticator this field specifies the initial sequence
3419 number for messages from the client to the server.
3420 When included in the AP-REP message, the initial
3421 sequence number is that for messages from the
3422 server to the client. When used in KRB_PRIV or
3423 KRB_SAFE messages, it is incremented by one after
3424 each message is sent.
3426 For sequence numbers to adequately support the
3427 detection of replays they should be non-repeating,
3428 even across connection boundaries. The initial
3429 sequence number should be random and uniformly
3430 distributed across the full space of possible
3431 sequence numbers, so that it cannot be guessed by
3432 an attacker and so that it and the successive
3433 sequence numbers do not repeat other sequences.
3437 Section 5.3.2. - 53 - Expires 11 January 1998
3445 Version 5 - Specification Revision 6
3449 This field is the same as described for the ticket
3450 in section 5.3.1. It is optional and will only
3451 appear when additional restrictions are to be
3452 placed on the use of a ticket, beyond those car-
3453 ried in the ticket itself.
3455 5.4. Specifications for the AS and TGS exchanges
3457 This section specifies the format of the messages used
3458 in the exchange between the client and the Kerberos server.
3459 The format of possible error messages appears in section
3462 5.4.1. KRB_KDC_REQ definition
3464 The KRB_KDC_REQ message has no type of its own.
3465 Instead, its type is one of KRB_AS_REQ or KRB_TGS_REQ
3466 depending on whether the request is for an initial ticket or
3467 an additional ticket. In either case, the message is sent
3468 from the client to the Authentication Server to request
3469 credentials for a service.
3471 The message fields are:
3473 AS-REQ ::= [APPLICATION 10] KDC-REQ
3474 TGS-REQ ::= [APPLICATION 12] KDC-REQ
3476 KDC-REQ ::= SEQUENCE {
3478 msg-type[2] INTEGER,
3479 padata[3] SEQUENCE OF PA-DATA OPTIONAL,
3480 req-body[4] KDC-REQ-BODY
3483 PA-DATA ::= SEQUENCE {
3484 padata-type[1] INTEGER,
3485 padata-value[2] OCTET STRING,
3486 -- might be encoded AP-REQ
3489 KDC-REQ-BODY ::= SEQUENCE {
3490 kdc-options[0] KDCOptions,
3491 cname[1] PrincipalName OPTIONAL,
3492 -- Used only in AS-REQ
3493 realm[2] Realm, -- Server's realm
3494 -- Also client's in AS-REQ
3495 sname[3] PrincipalName OPTIONAL,
3496 from[4] KerberosTime OPTIONAL,
3497 till[5] KerberosTime OPTIONAL,
3498 rtime[6] KerberosTime OPTIONAL,
3500 etype[8] SEQUENCE OF INTEGER,
3502 -- in preference order
3505 Section 5.4.1. - 54 - Expires 11 January 1998
3513 Version 5 - Specification Revision 6
3516 addresses[9] HostAddresses OPTIONAL,
3517 enc-authorization-data[10] EncryptedData OPTIONAL,
3518 -- Encrypted AuthorizationData
3520 additional-tickets[11] SEQUENCE OF Ticket OPTIONAL
3523 The fields in this message are:
3526 pvno This field is included in each message, and speci-
3527 fies the protocol version number. This document
3528 specifies protocol version 5.
3531 msg-type This field indicates the type of a protocol mes-
3532 sage. It will almost always be the same as the
3533 application identifier associated with a message.
3534 It is included to make the identifier more readily
3535 accessible to the application. For the KDC-REQ
3536 message, this type will be KRB_AS_REQ or
3540 padata The padata (pre-authentication data) field con-
3541 tains a sequence of authentication information
3542 which may be needed before credentials can be
3543 issued or decrypted. In the case of requests for
3544 additional tickets (KRB_TGS_REQ), this field will
3545 include an element with padata-type of PA-TGS-REQ
3546 and data of an authentication header (ticket-
3547 granting ticket and authenticator). The checksum
3548 in the authenticator (which must be collision-
3549 proof) is to be computed over the KDC-REQ-BODY
3550 encoding. In most requests for initial authenti-
3551 cation (KRB_AS_REQ) and most replies (KDC-REP),
3552 the padata field will be left out.
3554 This field may also contain information needed by
3555 certain extensions to the Kerberos protocol. For
3556 example, it might be used to initially verify the
3557 identity of a client before any response is
3558 returned. This is accomplished with a padata
3559 field with padata-type equal to PA-ENC-TIMESTAMP
3560 and padata-value defined as follows:
3562 padata-type ::= PA-ENC-TIMESTAMP
3563 padata-value ::= EncryptedData -- PA-ENC-TS-ENC
3565 PA-ENC-TS-ENC ::= SEQUENCE {
3566 patimestamp[0] KerberosTime, -- client's time
3567 pausec[1] INTEGER OPTIONAL
3570 with patimestamp containing the client's time and
3573 Section 5.4.1. - 55 - Expires 11 January 1998
3581 Version 5 - Specification Revision 6
3584 pausec containing the microseconds which may be
3585 omitted if a client will not generate more than
3586 one request per second. The ciphertext (padata-
3587 value) consists of the PA-ENC-TS-ENC sequence,
3588 encrypted using the client's secret key.
3590 The padata field can also contain information
3591 needed to help the KDC or the client select the
3592 key needed for generating or decrypting the
3593 response. This form of the padata is useful for
3594 supporting the use of certain token cards with
3595 Kerberos. The details of such extensions are
3596 specified in separate documents. See [11] for
3597 additional uses of this field.
3600 The padata-type element of the padata field indi-
3601 cates the way that the padata-value element is to
3602 be interpreted. Negative values of padata-type
3603 are reserved for unregistered use; non-negative
3604 values are used for a registered interpretation of
3608 req-body This field is a placeholder delimiting the extent
3609 of the remaining fields. If a checksum is to be
3610 calculated over the request, it is calculated over
3611 an encoding of the KDC-REQ-BODY sequence which is
3612 enclosed within the req-body field.
3616 This field appears in the KRB_AS_REQ and
3617 KRB_TGS_REQ requests to the KDC and indicates the
3618 flags that the client wants set on the tickets as
3619 well as other information that is to modify the
3620 behavior of the KDC. Where appropriate, the name
3621 of an option may be the same as the flag that is
3622 set by that option. Although in most case, the
3623 bit in the options field will be the same as that
3624 in the flags field, this is not guaranteed, so it
3625 is not acceptable to simply copy the options field
3626 to the flags field. There are various checks that
3627 must be made before honoring an option anyway.
3629 The kdc_options field is a bit-field, where the
3630 selected options are indicated by the bit being
3631 set (1), and the unselected options and reserved
3632 fields being reset (0). The encoding of the bits
3633 is specified in section 5.2. The options are
3634 described in more detail above in section 2. The
3635 meanings of the options are:
3640 Section 5.4.1. - 56 - Expires 11 January 1998
3645 Version 5 - Specification Revision 6
3648 Bit(s) Name Description
3650 Reserved for future expansion of this
3654 The FORWARDABLE option indicates that
3655 the ticket to be issued is to have its
3656 forwardable flag set. It may only be
3657 set on the initial request, or in a sub-
3658 sequent request if the ticket-granting
3659 ticket on which it is based is also for-
3663 The FORWARDED option is only specified
3664 in a request to the ticket-granting
3665 server and will only be honored if the
3666 ticket-granting ticket in the request
3667 has its FORWARDABLE bit set. This
3668 option indicates that this is a request
3669 for forwarding. The address(es) of the
3670 host from which the resulting ticket is
3671 to be valid are included in the
3672 addresses field of the request.
3675 The PROXIABLE option indicates that the
3676 ticket to be issued is to have its prox-
3677 iable flag set. It may only be set on
3678 the initial request, or in a subsequent
3679 request if the ticket-granting ticket on
3680 which it is based is also proxiable.
3683 The PROXY option indicates that this is
3684 a request for a proxy. This option will
3685 only be honored if the ticket-granting
3686 ticket in the request has its PROXIABLE
3687 bit set. The address(es) of the host
3688 from which the resulting ticket is to be
3689 valid are included in the addresses
3690 field of the request.
3693 The ALLOW-POSTDATE option indicates that
3694 the ticket to be issued is to have its
3695 MAY-POSTDATE flag set. It may only be
3696 set on the initial request, or in a sub-
3697 sequent request if the ticket-granting
3698 ticket on which it is based also has its
3699 MAY-POSTDATE flag set.
3707 Section 5.4.1. - 57 - Expires 11 January 1998
3715 Version 5 - Specification Revision 6
3719 The POSTDATED option indicates that this
3720 is a request for a postdated ticket.
3721 This option will only be honored if the
3722 ticket-granting ticket on which it is
3723 based has its MAY-POSTDATE flag set.
3724 The resulting ticket will also have its
3725 INVALID flag set, and that flag may be
3726 reset by a subsequent request to the KDC
3727 after the starttime in the ticket has
3731 This option is presently unused.
3734 The RENEWABLE option indicates that the
3735 ticket to be issued is to have its
3736 RENEWABLE flag set. It may only be set
3737 on the initial request, or when the
3738 ticket-granting ticket on which the
3739 request is based is also renewable. If
3740 this option is requested, then the rtime
3741 field in the request contains the
3742 desired absolute expiration time for the
3746 These options are presently unused.
3748 14 REQUEST-ANONYMOUS
3749 The REQUEST-ANONYMOUS option indicates
3750 that the ticket to be issued is not to
3751 identify the user to which it was
3752 issued. Instead, the principal identif-
3753 ier is to be generic, as specified by
3754 the policy of the realm (e.g. usually
3755 anonymous@realm). The purpose of the
3756 ticket is only to securely distribute a
3757 session key, and not to identify the
3758 user. The ANONYMOUS flag on the ticket
3759 to be returned should be set. If the
3760 local realms policy does not permit
3761 anonymous credentials, the request is to
3765 Reserved for future use.
3767 26 DISABLE-TRANSITED-CHECK
3768 By default the KDC will check the
3769 transited field of a ticket-granting-
3770 ticket against the policy of the local
3771 realm before it will issue derivative
3772 tickets based on the ticket granting
3773 ticket. If this flag is set in the
3774 request, checking of the transited field
3775 is disabled. Tickets issued without the
3776 performance of this check will be noted
3777 by the reset (0) value of the
3778 TRANSITED-POLICY-CHECKED flag,
3779 indicating to the application server
3780 that the tranisted field must be checked
3781 locally. KDC's are encouraged but not
3782 required to honor the
3783 DISABLE-TRANSITED-CHECK option.
3787 Section 5.4.1. - 58 - Expires 11 January 1998
3795 Version 5 - Specification Revision 6
3799 The RENEWABLE-OK option indicates that a
3800 renewable ticket will be acceptable if a
3801 ticket with the requested life cannot
3802 otherwise be provided. If a ticket with
3803 the requested life cannot be provided,
3804 then a renewable ticket may be issued
3805 with a renew-till equal to the the
3806 requested endtime. The value of the
3807 renew-till field may still be limited by
3808 local limits, or limits selected by the
3809 individual principal or server.
3812 This option is used only by the ticket-
3813 granting service. The ENC-TKT-IN-SKEY
3814 option indicates that the ticket for the
3815 end server is to be encrypted in the
3816 session key from the additional ticket-
3817 granting ticket provided.
3820 Reserved for future use.
3823 This option is used only by the ticket-
3824 granting service. The RENEW option
3825 indicates that the present request is
3826 for a renewal. The ticket provided is
3827 encrypted in the secret key for the
3828 server on which it is valid. This
3829 option will only be honored if the
3830 ticket to be renewed has its RENEWABLE
3831 flag set and if the time in its renew-
3832 till field has not passed. The ticket
3833 to be renewed is passed in the padata
3834 field as part of the authentication
3838 This option is used only by the ticket-
3839 granting service. The VALIDATE option
3840 indicates that the request is to vali-
3841 date a postdated ticket. It will only
3842 be honored if the ticket presented is
3843 postdated, presently has its INVALID
3844 flag set, and would be otherwise usable
3845 at this time. A ticket cannot be vali-
3846 dated before its starttime. The ticket
3847 presented for validation is encrypted in
3848 the key of the server for which it is
3849 valid and is passed in the padata field
3850 as part of the authentication header.
3853 These fields are the same as those described for
3854 the ticket in section 5.3.1. sname may only be
3857 Section 5.4.1. - 59 - Expires 11 January 1998
3865 Version 5 - Specification Revision 6
3868 absent when the ENC-TKT-IN-SKEY option is speci-
3869 fied. If absent, the name of the server is taken
3870 from the name of the client in the ticket passed
3871 as additional-tickets.
3874 enc-authorization-data
3875 The enc-authorization-data, if present (and it can
3876 only be present in the TGS_REQ form), is an encod-
3877 ing of the desired authorization-data encrypted
3878 under the sub-session key if present in the
3879 Authenticator, or alternatively from the session
3880 key in the ticket-granting ticket, both from the
3881 padata field in the KRB_AP_REQ.
3884 realm This field specifies the realm part of the
3885 server's principal identifier. In the AS
3886 exchange, this is also the realm part of the
3887 client's principal identifier.
3890 from This field is included in the KRB_AS_REQ and
3891 KRB_TGS_REQ ticket requests when the requested
3892 ticket is to be postdated. It specifies the
3893 desired start time for the requested ticket.
3897 till This field contains the expiration date requested
3898 by the client in a ticket request. It is option
3899 and if omitted the requested ticket is to have the
3900 maximum endtime permitted according to KDC policy
3901 for the parties to the authentication exchange as
3902 limited by expiration date of the ticket granting
3903 ticket or other preauthentication credentials.
3906 rtime This field is the requested renew-till time sent
3907 from a client to the KDC in a ticket request. It
3911 nonce This field is part of the KDC request and
3912 response. It it intended to hold a random number
3913 generated by the client. If the same number is
3914 included in the encrypted response from the KDC,
3915 it provides evidence that the response is fresh
3916 and has not been replayed by an attacker. Nonces
3917 must never be re-used. Ideally, it should be gen-
3918 erated randomly, but if the correct time is known,
3920 __________________________
3921 [25] Note, however, that if the time is used as the
3923 Section 5.4.1. - 60 - Expires 11 January 1998
3931 Version 5 - Specification Revision 6
3934 etype This field specifies the desired encryption algo-
3935 rithm to be used in the response.
3938 addresses This field is included in the initial request for
3939 tickets, and optionally included in requests for
3940 additional tickets from the ticket-granting
3941 server. It specifies the addresses from which the
3942 requested ticket is to be valid. Normally it
3943 includes the addresses for the client's host. If
3944 a proxy is requested, this field will contain
3945 other addresses. The contents of this field are
3946 usually copied by the KDC into the caddr field of
3947 the resulting ticket.
3951 Additional tickets may be optionally included in a
3952 request to the ticket-granting server. If the
3953 ENC-TKT-IN-SKEY option has been specified, then
3954 the session key from the additional ticket will be
3955 used in place of the server's key to encrypt the
3956 new ticket. If more than one option which
3957 requires additional tickets has been specified,
3958 then the additional tickets are used in the order
3959 specified by the ordering of the options bits (see
3960 kdc-options, above).
3963 The application code will be either ten (10) or twelve
3964 (12) depending on whether the request is for an initial
3965 ticket (AS-REQ) or for an additional ticket (TGS-REQ).
3967 The optional fields (addresses, authorization-data and
3968 additional-tickets) are only included if necessary to per-
3969 form the operation specified in the kdc-options field.
3971 It should be noted that in KRB_TGS_REQ, the protocol
3972 version number appears twice and two different message types
3973 appear: the KRB_TGS_REQ message contains these fields as
3974 does the authentication header (KRB_AP_REQ) that is passed
3975 in the padata field.
3977 5.4.2. KRB_KDC_REP definition
3979 The KRB_KDC_REP message format is used for the reply
3980 from the KDC for either an initial (AS) request or a subse-
3981 quent (TGS) request. There is no message type for
3982 __________________________
3983 nonce, one must make sure that the workstation time is
3984 monotonically increasing. If the time is ever reset
3985 backwards, there is a small, but finite, probability
3986 that a nonce will be reused.
3990 Section 5.4.2. - 61 - Expires 11 January 1998
3998 Version 5 - Specification Revision 6
4001 KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or
4002 KRB_TGS_REP. The key used to encrypt the ciphertext part of
4003 the reply depends on the message type. For KRB_AS_REP, the
4004 ciphertext is encrypted in the client's secret key, and the
4005 client's key version number is included in the key version
4006 number for the encrypted data. For KRB_TGS_REP, the cipher-
4007 text is encrypted in the sub-session key from the Authenti-
4008 cator, or if absent, the session key from the ticket-
4009 granting ticket used in the request. In that case, no ver-
4010 sion number will be present in the EncryptedData sequence.
4012 The KRB_KDC_REP message contains the following fields:
4014 AS-REP ::= [APPLICATION 11] KDC-REP
4015 TGS-REP ::= [APPLICATION 13] KDC-REP
4017 KDC-REP ::= SEQUENCE {
4019 msg-type[1] INTEGER,
4020 padata[2] SEQUENCE OF PA-DATA OPTIONAL,
4022 cname[4] PrincipalName,
4024 enc-part[6] EncryptedData
4028 EncASRepPart ::= [APPLICATION 25[27]] EncKDCRepPart
4029 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart
4033 EncKDCRepPart ::= SEQUENCE {
4034 key[0] EncryptionKey,
4035 last-req[1] LastReq,
4037 key-expiration[3] KerberosTime OPTIONAL,
4038 flags[4] TicketFlags,
4039 authtime[5] KerberosTime,
4040 starttime[6] KerberosTime OPTIONAL,
4041 endtime[7] KerberosTime,
4042 renew-till[8] KerberosTime OPTIONAL,
4044 sname[10] PrincipalName,
4045 caddr[11] HostAddresses OPTIONAL
4050 These fields are described above in section 5.4.1.
4051 msg-type is either KRB_AS_REP or KRB_TGS_REP.
4052 __________________________
4053 [27] An application code in the encrypted part of a
4054 message provides an additional check that the message
4055 was decrypted properly.
4058 Section 5.4.2. - 62 - Expires 11 January 1998
4066 Version 5 - Specification Revision 6
4069 padata This field is described in detail in section
4070 5.4.1. One possible use for this field is to
4071 encode an alternate "mix-in" string to be used
4072 with a string-to-key algorithm (such as is
4073 described in section 6.3.2). This ability is use-
4074 ful to ease transitions if a realm name needs to
4075 change (e.g. when a company is acquired); in such
4076 a case all existing password-derived entries in
4077 the KDC database would be flagged as needing a
4078 special mix-in string until the next password
4082 crealm, cname, srealm and sname
4083 These fields are the same as those described for
4084 the ticket in section 5.3.1.
4087 ticket The newly-issued ticket, from section 5.3.1.
4090 enc-part This field is a place holder for the ciphertext
4091 and related information that forms the encrypted
4092 part of a message. The description of the
4093 encrypted part of the message follows each appear-
4094 ance of this field. The encrypted part is encoded
4095 as described in section 6.1.
4098 key This field is the same as described for the ticket
4102 last-req This field is returned by the KDC and specifies
4103 the time(s) of the last request by a principal.
4104 Depending on what information is available, this
4105 might be the last time that a request for a
4106 ticket-granting ticket was made, or the last time
4107 that a request based on a ticket-granting ticket
4108 was successful. It also might cover all servers
4109 for a realm, or just the particular server. Some
4110 implementations may display this information to
4111 the user to aid in discovering unauthorized use of
4112 one's identity. It is similar in spirit to the
4113 last login time displayed when logging into
4114 timesharing systems.
4117 nonce This field is described above in section 5.4.1.
4121 The key-expiration field is part of the response
4122 from the KDC and specifies the time that the
4125 Section 5.4.2. - 63 - Expires 11 January 1998
4133 Version 5 - Specification Revision 6
4136 client's secret key is due to expire. The expira-
4137 tion might be the result of password aging or an
4138 account expiration. This field will usually be
4139 left out of the TGS reply since the response to
4140 the TGS request is encrypted in a session key and
4141 no client information need be retrieved from the
4142 KDC database. It is up to the application client
4143 (usually the login program) to take appropriate
4144 action (such as notifying the user) if the expira-
4145 tion time is imminent.
4148 flags, authtime, starttime, endtime, renew-till and caddr
4149 These fields are duplicates of those found in the
4150 encrypted portion of the attached ticket (see sec-
4151 tion 5.3.1), provided so the client may verify
4152 they match the intended request and to assist in
4153 proper ticket caching. If the message is of type
4154 KRB_TGS_REP, the caddr field will only be filled
4155 in if the request was for a proxy or forwarded
4156 ticket, or if the user is substituting a subset of
4157 the addresses from the ticket granting ticket. If
4158 the client-requested addresses are not present or
4159 not used, then the addresses contained in the
4160 ticket will be the same as those included in the
4161 ticket-granting ticket.
4164 5.5. Client/Server (CS) message specifications
4166 This section specifies the format of the messages used
4167 for the authentication of the client to the application
4170 5.5.1. KRB_AP_REQ definition
4172 The KRB_AP_REQ message contains the Kerberos protocol
4173 version number, the message type KRB_AP_REQ, an options
4174 field to indicate any options in use, and the ticket and
4175 authenticator themselves. The KRB_AP_REQ message is often
4176 referred to as the "authentication header".
4178 AP-REQ ::= [APPLICATION 14] SEQUENCE {
4180 msg-type[1] INTEGER,
4181 ap-options[2] APOptions,
4183 authenticator[4] EncryptedData
4186 APOptions ::= BIT STRING {
4192 Section 5.5.1. - 64 - Expires 11 January 1998
4200 Version 5 - Specification Revision 6
4207 These fields are described above in section 5.4.1.
4208 msg-type is KRB_AP_REQ.
4211 ap-optionsThis field appears in the application request
4212 (KRB_AP_REQ) and affects the way the request is
4213 processed. It is a bit-field, where the selected
4214 options are indicated by the bit being set (1),
4215 and the unselected options and reserved fields
4216 being reset (0). The encoding of the bits is
4217 specified in section 5.2. The meanings of the
4220 Bit(s) Name Description
4223 Reserved for future expansion of this
4227 The USE-SESSION-KEY option indicates
4228 that the ticket the client is presenting
4229 to a server is encrypted in the session
4230 key from the server's ticket-granting
4231 ticket. When this option is not speci-
4232 fied, the ticket is encrypted in the
4233 server's secret key.
4236 The MUTUAL-REQUIRED option tells the
4237 server that the client requires mutual
4238 authentication, and that it must respond
4239 with a KRB_AP_REP message.
4242 Reserved for future use.
4246 ticket This field is a ticket authenticating the client
4251 This contains the authenticator, which includes
4252 the client's choice of a subkey. Its encoding is
4253 described in section 5.3.2.
4255 5.5.2. KRB_AP_REP definition
4257 The KRB_AP_REP message contains the Kerberos protocol
4258 version number, the message type, and an encrypted time-
4259 stamp. The message is sent in in response to an application
4260 request (KRB_AP_REQ) where the mutual authentication option
4263 Section 5.5.2. - 65 - Expires 11 January 1998
4271 Version 5 - Specification Revision 6
4274 has been selected in the ap-options field.
4276 AP-REP ::= [APPLICATION 15] SEQUENCE {
4278 msg-type[1] INTEGER,
4279 enc-part[2] EncryptedData
4282 EncAPRepPart ::= [APPLICATION 27[29]] SEQUENCE {
4283 ctime[0] KerberosTime,
4285 subkey[2] EncryptionKey OPTIONAL,
4286 seq-number[3] INTEGER OPTIONAL
4289 The encoded EncAPRepPart is encrypted in the shared session
4290 key of the ticket. The optional subkey field can be used in
4291 an application-arranged negotiation to choose a per associa-
4296 These fields are described above in section 5.4.1.
4297 msg-type is KRB_AP_REP.
4300 enc-part This field is described above in section 5.4.2.
4303 ctime This field contains the current time on the
4307 cusec This field contains the microsecond part of the
4311 subkey This field contains an encryption key which is to
4312 be used to protect this specific application ses-
4313 sion. See section 3.2.6 for specifics on how this
4314 field is used to negotiate a key. Unless an
4315 application specifies otherwise, if this field is
4316 left out, the sub-session key from the authentica-
4317 tor, or if also left out, the session key from the
4318 ticket will be used.
4322 __________________________
4323 [29] An application code in the encrypted part of a
4324 message provides an additional check that the message
4325 was decrypted properly.
4329 Section 5.5.2. - 66 - Expires 11 January 1998
4337 Version 5 - Specification Revision 6
4340 5.5.3. Error message reply
4342 If an error occurs while processing the application
4343 request, the KRB_ERROR message will be sent in response.
4344 See section 5.9.1 for the format of the error message. The
4345 cname and crealm fields may be left out if the server cannot
4346 determine their appropriate values from the corresponding
4347 KRB_AP_REQ message. If the authenticator was decipherable,
4348 the ctime and cusec fields will contain the values from it.
4350 5.6. KRB_SAFE message specification
4352 This section specifies the format of a message that can
4353 be used by either side (client or server) of an application
4354 to send a tamper-proof message to its peer. It presumes
4355 that a session key has previously been exchanged (for exam-
4356 ple, by using the KRB_AP_REQ/KRB_AP_REP messages).
4358 5.6.1. KRB_SAFE definition
4360 The KRB_SAFE message contains user data along with a
4361 collision-proof checksum keyed with the last encryption key
4362 negotiated via subkeys, or the session key if no negotiation
4363 has occured. The message fields are:
4365 KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
4367 msg-type[1] INTEGER,
4368 safe-body[2] KRB-SAFE-BODY,
4372 KRB-SAFE-BODY ::= SEQUENCE {
4373 user-data[0] OCTET STRING,
4374 timestamp[1] KerberosTime OPTIONAL,
4375 usec[2] INTEGER OPTIONAL,
4376 seq-number[3] INTEGER OPTIONAL,
4377 s-address[4] HostAddress OPTIONAL,
4378 r-address[5] HostAddress OPTIONAL
4385 These fields are described above in section 5.4.1.
4386 msg-type is KRB_SAFE.
4389 safe-body This field is a placeholder for the body of the
4390 KRB-SAFE message. It is to be encoded separately
4391 and then have the checksum computed over it, for
4392 use in the cksum field.
4396 Section 5.6.1. - 67 - Expires 11 January 1998
4404 Version 5 - Specification Revision 6
4407 cksum This field contains the checksum of the applica-
4408 tion data. Checksum details are described in sec-
4409 tion 6.4. The checksum is computed over the
4410 encoding of the KRB-SAFE-BODY sequence.
4413 user-data This field is part of the KRB_SAFE and KRB_PRIV
4414 messages and contain the application specific data
4415 that is being passed from the sender to the reci-
4419 timestamp This field is part of the KRB_SAFE and KRB_PRIV
4420 messages. Its contents are the current time as
4421 known by the sender of the message. By checking
4422 the timestamp, the recipient of the message is
4423 able to make sure that it was recently generated,
4424 and is not a replay.
4427 usec This field is part of the KRB_SAFE and KRB_PRIV
4428 headers. It contains the microsecond part of the
4433 This field is described above in section 5.3.2.
4436 s-address This field specifies the address in use by the
4437 sender of the message.
4440 r-address This field specifies the address in use by the
4441 recipient of the message. It may be omitted for
4442 some uses (such as broadcast protocols), but the
4443 recipient may arbitrarily reject such messages.
4444 This field along with s-address can be used to
4445 help detect messages which have been incorrectly
4446 or maliciously delivered to the wrong recipient.
4448 5.7. KRB_PRIV message specification
4450 This section specifies the format of a message that can
4451 be used by either side (client or server) of an application
4452 to securely and privately send a message to its peer. It
4453 presumes that a session key has previously been exchanged
4454 (for example, by using the KRB_AP_REQ/KRB_AP_REP messages).
4456 5.7.1. KRB_PRIV definition
4458 The KRB_PRIV message contains user data encrypted in
4459 the Session Key. The message fields are:
4461 __________________________
4462 [31] An application code in the encrypted part of a
4469 Version 5 - Specification Revision 6
4473 KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
4475 msg-type[1] INTEGER,
4476 enc-part[3] EncryptedData
4479 EncKrbPrivPart ::= [APPLICATION 28[31]] SEQUENCE {
4480 user-data[0] OCTET STRING,
4481 timestamp[1] KerberosTime OPTIONAL,
4482 usec[2] INTEGER OPTIONAL,
4483 seq-number[3] INTEGER OPTIONAL,
4484 s-address[4] HostAddress OPTIONAL, -- sender's addr
4485 r-address[5] HostAddress OPTIONAL -- recip's addr
4491 These fields are described above in section 5.4.1.
4492 msg-type is KRB_PRIV.
4495 enc-part This field holds an encoding of the EncKrbPrivPart
4496 sequence encrypted under the session key[32].
4497 This encrypted encoding is used for the enc-part
4498 field of the KRB-PRIV message. See section 6 for
4499 the format of the ciphertext.
4502 user-data, timestamp, usec, s-address and r-address
4503 These fields are described above in section 5.6.1.
4507 This field is described above in section 5.3.2.
4509 5.8. KRB_CRED message specification
4511 This section specifies the format of a message that can
4512 be used to send Kerberos credentials from one principal to
4513 __________________________
4514 message provides an additional check that the message
4515 was decrypted properly.
4516 [32] If supported by the encryption method in use, an
4517 initialization vector may be passed to the encryption
4518 procedure, in order to achieve proper cipher chaining.
4519 The initialization vector might come from the last
4520 block of the ciphertext from the previous KRB_PRIV mes-
4521 sage, but it is the application's choice whether or not
4522 to use such an initialization vector. If left out, the
4523 default initialization vector for the encryption algo-
4527 Section 5.8. - 69 - Expires 11 January 1998
4535 Version 5 - Specification Revision 6
4538 another. It is presented here to encourage a common mechan-
4539 ism to be used by applications when forwarding tickets or
4540 providing proxies to subordinate servers. It presumes that
4541 a session key has already been exchanged perhaps by using
4542 the KRB_AP_REQ/KRB_AP_REP messages.
4544 5.8.1. KRB_CRED definition
4546 The KRB_CRED message contains a sequence of tickets to
4547 be sent and information needed to use the tickets, including
4548 the session key from each. The information needed to use
4549 the tickets is encrypted under an encryption key previously
4550 exchanged or transferred alongside the KRB_CRED message.
4551 The message fields are:
4553 KRB-CRED ::= [APPLICATION 22] SEQUENCE {
4555 msg-type[1] INTEGER, -- KRB_CRED
4556 tickets[2] SEQUENCE OF Ticket,
4557 enc-part[3] EncryptedData
4560 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
4561 ticket-info[0] SEQUENCE OF KrbCredInfo,
4562 nonce[1] INTEGER OPTIONAL,
4563 timestamp[2] KerberosTime OPTIONAL,
4564 usec[3] INTEGER OPTIONAL,
4565 s-address[4] HostAddress OPTIONAL,
4566 r-address[5] HostAddress OPTIONAL
4569 KrbCredInfo ::= SEQUENCE {
4570 key[0] EncryptionKey,
4571 prealm[1] Realm OPTIONAL,
4572 pname[2] PrincipalName OPTIONAL,
4573 flags[3] TicketFlags OPTIONAL,
4574 authtime[4] KerberosTime OPTIONAL,
4575 starttime[5] KerberosTime OPTIONAL,
4576 endtime[6] KerberosTime OPTIONAL
4577 renew-till[7] KerberosTime OPTIONAL,
4578 srealm[8] Realm OPTIONAL,
4579 sname[9] PrincipalName OPTIONAL,
4580 caddr[10] HostAddresses OPTIONAL
4588 These fields are described above in section 5.4.1.
4589 msg-type is KRB_CRED.
4594 Section 5.8.1. - 70 - Expires 11 January 1998
4602 Version 5 - Specification Revision 6
4606 These are the tickets obtained from the KDC
4607 specifically for use by the intended recipient.
4608 Successive tickets are paired with the correspond-
4609 ing KrbCredInfo sequence from the enc-part of the
4613 enc-part This field holds an encoding of the EncKrbCredPart
4614 sequence encrypted under the session key shared
4615 between the sender and the intended recipient.
4616 This encrypted encoding is used for the enc-part
4617 field of the KRB-CRED message. See section 6 for
4618 the format of the ciphertext.
4621 nonce If practical, an application may require the
4622 inclusion of a nonce generated by the recipient of
4623 the message. If the same value is included as the
4624 nonce in the message, it provides evidence that
4625 the message is fresh and has not been replayed by
4626 an attacker. A nonce must never be re-used; it
4627 should be generated randomly by the recipient of
4628 the message and provided to the sender of the mes-
4629 sage in an application specific manner.
4634 These fields specify the time that the KRB-CRED
4635 message was generated. The time is used to pro-
4636 vide assurance that the message is fresh.
4639 s-address and r-address
4640 These fields are described above in section 5.6.1.
4641 They are used optionally to provide additional
4642 assurance of the integrity of the KRB-CRED mes-
4646 key This field exists in the corresponding ticket
4647 passed by the KRB-CRED message and is used to pass
4648 the session key from the sender to the intended
4649 recipient. The field's encoding is described in
4652 The following fields are optional. If present, they
4653 can be associated with the credentials in the remote ticket
4654 file. If left out, then it is assumed that the recipient of
4655 the credentials already knows their value.
4661 Section 5.8.1. - 71 - Expires 11 January 1998
4669 Version 5 - Specification Revision 6
4672 The name and realm of the delegated principal
4676 flags, authtime, starttime, endtime, renew-till, srealm,
4678 These fields contain the values of the correspond-
4679 ing fields from the ticket found in the ticket
4680 field. Descriptions of the fields are identical
4681 to the descriptions in the KDC-REP message.
4683 5.9. Error message specification
4685 This section specifies the format for the KRB_ERROR
4686 message. The fields included in the message are intended to
4687 return as much information as possible about an error. It
4688 is not expected that all the information required by the
4689 fields will be available for all types of errors. If the
4690 appropriate information is not available when the message is
4691 composed, the corresponding field will be left out of the
4694 Note that since the KRB_ERROR message is not protected
4695 by any encryption, it is quite possible for an intruder to
4696 synthesize or modify such a message. In particular, this
4697 means that the client should not use any fields in this mes-
4698 sage for security-critical purposes, such as setting a sys-
4699 tem clock or generating a fresh authenticator. The message
4700 can be useful, however, for advising a user on the reason
4703 5.9.1. KRB_ERROR definition
4705 The KRB_ERROR message consists of the following fields:
4707 KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
4709 msg-type[1] INTEGER,
4710 ctime[2] KerberosTime OPTIONAL,
4711 cusec[3] INTEGER OPTIONAL,
4712 stime[4] KerberosTime,
4714 error-code[6] INTEGER,
4715 crealm[7] Realm OPTIONAL,
4716 cname[8] PrincipalName OPTIONAL,
4717 realm[9] Realm, -- Correct realm
4718 sname[10] PrincipalName, -- Correct name
4719 e-text[11] GeneralString OPTIONAL,
4720 e-data[12] OCTET STRING OPTIONAL,
4721 e-cksum[13] Checksum OPTIONAL
4728 Section 5.9.1. - 72 - Expires 11 January 1998
4736 Version 5 - Specification Revision 6
4740 These fields are described above in section 5.4.1.
4741 msg-type is KRB_ERROR.
4744 ctime This field is described above in section 5.4.1.
4748 cusec This field is described above in section 5.5.2.
4751 stime This field contains the current time on the
4752 server. It is of type KerberosTime.
4755 susec This field contains the microsecond part of the
4756 server's timestamp. Its value ranges from 0 to
4757 999999. It appears along with stime. The two
4758 fields are used in conjunction to specify a rea-
4759 sonably accurate timestamp.
4762 error-codeThis field contains the error code returned by
4763 Kerberos or the server when a request fails. To
4764 interpret the value of this field see the list of
4765 error codes in section 8. Implementations are
4766 encouraged to provide for national language sup-
4767 port in the display of error messages.
4770 crealm, cname, srealm and sname
4771 These fields are described above in section 5.3.1.
4774 e-text This field contains additional text to help
4775 explain the error code associated with the failed
4776 request (for example, it might include a principal
4777 name which was unknown).
4780 e-data This field contains additional data about the
4781 error for use by the application to help it
4782 recover from or handle the error. If the error-
4783 code is KDC_ERR_PREAUTH_REQUIRED, then the e-data
4784 field will contain an encoding of a sequence of
4785 padata fields, each corresponding to an acceptable
4786 pre-authentication method and optionally contain-
4787 ing data for the method:
4790 e-cksum This field contains an optional checksum for the
4791 KRB-ERROR message. The checksum is calculated
4792 over the Kerberos ASN.1 encoding of the KRB-ERROR
4795 Section 5.9.1. - 73 - Expires 11 January 1998
4803 Version 5 - Specification Revision 6
4806 message with the checksum absent. The checksum is
4807 then added to the KRB-ERROR structure and the mes-
4808 sage is re-encoded. The Checksum should be calcu-
4809 lated using the session key from the ticket grant-
4810 ing ticket or service ticket, where available. If
4811 the error is in response to a TGS or AP request,
4812 the checksum should be calculated uing the the
4813 session key from the client's ticket. If the
4814 error is in response to an AS request, then the
4815 checksum should be calulated using the client's
4816 secret key ONLY if there has been suitable preau-
4817 thentication to prove knowledge of the secret key
4818 by the client[33]. If a checksum can not be com-
4819 puted because the key to be used is not available,
4820 no checksum will be included.
4822 METHOD-DATA ::= SEQUENCE of PA-DATA
4825 If the error-code is KRB_AP_ERR_METHOD, then the
4826 e-data field will contain an encoding of the fol-
4829 METHOD-DATA ::= SEQUENCE {
4830 method-type[0] INTEGER,
4831 method-data[1] OCTET STRING OPTIONAL
4834 method-type will indicate the required alternate
4835 method; method-data will contain any required
4836 additional information.
4840 6. Encryption and Checksum Specifications
4842 The Kerberos protocols described in this document are
4843 designed to use stream encryption ciphers, which can be
4844 simulated using commonly available block encryption ciphers,
4845 such as the Data Encryption Standard, [12] in conjunction
4846 with block chaining and checksum methods [13]. Encryption
4847 is used to prove the identities of the network entities par-
4848 ticipating in message exchanges. The Key Distribution
4849 Center for each realm is trusted by all principals
4850 registered in that realm to store a secret key in confi-
4851 dence. Proof of knowledge of this secret key is used to
4852 verify the authenticity of a principal.
4854 The KDC uses the principal's secret key (in the AS
4855 __________________________
4856 [33] This prevents an attacker who generates an in-
4857 correct AS request from obtaining verifiable plaintext
4858 for use in an off-line password guessing attack.
4861 Section 6. - 74 - Expires 11 January 1998
4869 Version 5 - Specification Revision 6
4872 exchange) or a shared session key (in the TGS exchange) to
4873 encrypt responses to ticket requests; the ability to obtain
4874 the secret key or session key implies the knowledge of the
4875 appropriate keys and the identity of the KDC. The ability
4876 of a principal to decrypt the KDC response and present a
4877 Ticket and a properly formed Authenticator (generated with
4878 the session key from the KDC response) to a service verifies
4879 the identity of the principal; likewise the ability of the
4880 service to extract the session key from the Ticket and prove
4881 its knowledge thereof in a response verifies the identity of
4884 The Kerberos protocols generally assume that the
4885 encryption used is secure from cryptanalysis; however, in
4886 some cases, the order of fields in the encrypted portions of
4887 messages are arranged to minimize the effects of poorly
4888 chosen keys. It is still important to choose good keys. If
4889 keys are derived from user-typed passwords, those passwords
4890 need to be well chosen to make brute force attacks more dif-
4891 ficult. Poorly chosen keys still make easy targets for
4894 The following sections specify the encryption and
4895 checksum mechanisms currently defined for Kerberos. The
4896 encodings, chaining, and padding requirements for each are
4897 described. For encryption methods, it is often desirable to
4898 place random information (often referred to as a confounder)
4899 at the start of the message. The requirements for a con-
4900 founder are specified with each encryption mechanism.
4902 Some encryption systems use a block-chaining method to
4903 improve the the security characteristics of the ciphertext.
4904 However, these chaining methods often don't provide an
4905 integrity check upon decryption. Such systems (such as DES
4906 in CBC mode) must be augmented with a checksum of the plain-
4907 text which can be verified at decryption and used to detect
4908 any tampering or damage. Such checksums should be good at
4909 detecting burst errors in the input. If any damage is
4910 detected, the decryption routine is expected to return an
4911 error indicating the failure of an integrity check. Each
4912 encryption type is expected to provide and verify an
4913 appropriate checksum. The specification of each encryption
4914 method sets out its checksum requirements.
4916 Finally, where a key is to be derived from a user's
4917 password, an algorithm for converting the password to a key
4918 of the appropriate type is included. It is desirable for
4919 the string to key function to be one-way, and for the map-
4920 ping to be different in different realms. This is important
4921 because users who are registered in more than one realm will
4922 often use the same password in each, and it is desirable
4923 that an attacker compromising the Kerberos server in one
4924 realm not obtain or derive the user's key in another.
4928 Section 6. - 75 - Expires 11 January 1998
4936 Version 5 - Specification Revision 6
4939 For an discussion of the integrity characteristics of
4940 the candidate encryption and checksum methods considered for
4941 Kerberos, the the reader is referred to [14].
4943 6.1. Encryption Specifications
4945 The following ASN.1 definition describes all encrypted
4946 messages. The enc-part field which appears in the unen-
4947 crypted part of messages in section 5 is a sequence consist-
4948 ing of an encryption type, an optional key version number,
4952 EncryptedData ::= SEQUENCE {
4953 etype[0] INTEGER, -- EncryptionType
4954 kvno[1] INTEGER OPTIONAL,
4955 cipher[2] OCTET STRING -- ciphertext
4959 etype This field identifies which encryption algorithm
4960 was used to encipher the cipher. Detailed specif-
4961 ications for selected encryption types appear
4962 later in this section.
4965 kvno This field contains the version number of the key
4966 under which data is encrypted. It is only present
4967 in messages encrypted under long lasting keys,
4968 such as principals' secret keys.
4971 cipher This field contains the enciphered text, encoded
4975 The cipher field is generated by applying the specified
4976 encryption algorithm to data composed of the message and
4977 algorithm-specific inputs. Encryption mechanisms defined
4978 for use with Kerberos must take sufficient measures to
4979 guarantee the integrity of the plaintext, and we recommend
4980 they also take measures to protect against precomputed dic-
4981 tionary attacks. If the encryption algorithm is not itself
4982 capable of doing so, the protections can often be enhanced
4983 by adding a checksum and a confounder.
4985 The suggested format for the data to be encrypted
4986 includes a confounder, a checksum, the encoded plaintext,
4987 and any necessary padding. The msg-seq field contains the
4988 part of the protocol message described in section 5 which is
4989 to be encrypted. The confounder, checksum, and padding are
4990 all untagged and untyped, and their length is exactly suffi-
4991 cient to hold the appropriate item. The type and length is
4992 implicit and specified by the particular encryption type
4995 Section 6.1. - 76 - Expires 11 January 1998
5003 Version 5 - Specification Revision 6
5006 being used (etype). The format for the data to be encrypted
5007 is described in the following diagram:
5009 +-----------+----------+-------------+-----+
5010 |confounder | check | msg-seq | pad |
5011 +-----------+----------+-------------+-----+
5013 The format cannot be described in ASN.1, but for those who
5014 prefer an ASN.1-like notation:
5016 CipherText ::= ENCRYPTED SEQUENCE {
5017 confounder[0] UNTAGGED[35] OCTET STRING(conf_length) OPTIONAL,
5018 check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL,
5019 msg-seq[2] MsgSequence,
5020 pad UNTAGGED OCTET STRING(pad_length) OPTIONAL
5024 One generates a random confounder of the appropriate
5025 length, placing it in confounder; zeroes out check; calcu-
5026 lates the appropriate checksum over confounder, check, and
5027 msg-seq, placing the result in check; adds the necessary
5028 padding; then encrypts using the specified encryption type
5029 and the appropriate key.
5031 Unless otherwise specified, a definition of an encryp-
5032 tion algorithm that specifies a checksum, a length for the
5033 confounder field, or an octet boundary for padding uses this
5034 ciphertext format[36]. Those fields which are not specified
5037 In the interest of allowing all implementations using a
5038 __________________________
5039 [35] In the above specification, UNTAGGED OCTET
5040 STRING(length) is the notation for an octet string with
5041 its tag and length removed. It is not a valid ASN.1
5042 type. The tag bits and length must be removed from the
5043 confounder since the purpose of the confounder is so
5044 that the message starts with random data, but the tag
5045 and its length are fixed. For other fields, the length
5046 and tag would be redundant if they were included be-
5047 cause they are specified by the encryption type.
5048 [36] The ordering of the fields in the CipherText is
5049 important. Additionally, messages encoded in this for-
5050 mat must include a length as part of the msg-seq field.
5051 This allows the recipient to verify that the message
5052 has not been truncated. Without a length, an attacker
5053 could use a chosen plaintext attack to generate a mes-
5054 sage which could be truncated, while leaving the check-
5055 sum intact. Note that if the msg-seq is an encoding of
5056 an ASN.1 SEQUENCE or OCTET STRING, then the length is
5057 part of that encoding.
5061 Section 6.1. - 77 - Expires 11 January 1998
5069 Version 5 - Specification Revision 6
5072 particular encryption type to communicate with all others
5073 using that type, the specification of an encryption type
5074 defines any checksum that is needed as part of the encryp-
5075 tion process. If an alternative checksum is to be used, a
5076 new encryption type must be defined.
5078 Some cryptosystems require additional information
5079 beyond the key and the data to be encrypted. For example,
5080 DES, when used in cipher-block-chaining mode, requires an
5081 initialization vector. If required, the description for
5082 each encryption type must specify the source of such addi-
5085 6.2. Encryption Keys
5087 The sequence below shows the encoding of an encryption
5090 EncryptionKey ::= SEQUENCE {
5092 keyvalue[1] OCTET STRING
5096 keytype This field specifies the type of encryption key
5097 that follows in the keyvalue field. It will
5098 almost always correspond to the encryption algo-
5099 rithm used to generate the EncryptedData, though
5100 more than one algorithm may use the same type of
5101 key (the mapping is many to one). This might hap-
5102 pen, for example, if the encryption algorithm uses
5103 an alternate checksum algorithm for an integrity
5104 check, or a different chaining mechanism.
5107 keyvalue This field contains the key itself, encoded as an
5110 All negative values for the encryption key type are
5111 reserved for local use. All non-negative values are
5112 reserved for officially assigned type fields and interpreta-
5115 6.3. Encryption Systems
5117 6.3.1. The NULL Encryption System (null)
5119 If no encryption is in use, the encryption system is
5120 said to be the NULL encryption system. In the NULL encryp-
5121 tion system there is no checksum, confounder or padding.
5122 The ciphertext is simply the plaintext. The NULL Key is
5123 used by the null encryption system and is zero octets in
5124 length, with keytype zero (0).
5128 Section 6.3.1. - 78 - Expires 11 January 1998
5136 Version 5 - Specification Revision 6
5139 6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc)
5141 The des-cbc-crc encryption mode encrypts information
5142 under the Data Encryption Standard [12] using the cipher
5143 block chaining mode [13]. A CRC-32 checksum (described in
5144 ISO 3309 [15]) is applied to the confounder and message
5145 sequence (msg-seq) and placed in the cksum field. DES
5146 blocks are 8 bytes. As a result, the data to be encrypted
5147 (the concatenation of confounder, checksum, and message)
5148 must be padded to an 8 byte boundary before encryption. The
5149 details of the encryption of this data are identical to
5150 those for the des-cbc-md5 encryption mode.
5152 Note that, since the CRC-32 checksum is not collision-
5153 proof, an attacker could use a probabilistic chosen-
5154 plaintext attack to generate a valid message even if a con-
5155 founder is used [14]. The use of collision-proof checksums
5156 is recommended for environments where such attacks represent
5157 a significant threat. The use of the CRC-32 as the checksum
5158 for ticket or authenticator is no longer mandated as an
5159 interoperability requirement for Kerberos Version 5 Specifi-
5160 cation 1 (See section 9.1 for specific details).
5163 6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4)
5165 The des-cbc-md4 encryption mode encrypts information
5166 under the Data Encryption Standard [12] using the cipher
5167 block chaining mode [13]. An MD4 checksum (described in
5168 [16]) is applied to the confounder and message sequence
5169 (msg-seq) and placed in the cksum field. DES blocks are 8
5170 bytes. As a result, the data to be encrypted (the concate-
5171 nation of confounder, checksum, and message) must be padded
5172 to an 8 byte boundary before encryption. The details of the
5173 encryption of this data are identical to those for the des-
5174 cbc-md5 encryption mode.
5177 6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5)
5179 The des-cbc-md5 encryption mode encrypts information
5180 under the Data Encryption Standard [12] using the cipher
5181 block chaining mode [13]. An MD5 checksum (described in
5182 [17].) is applied to the confounder and message sequence
5183 (msg-seq) and placed in the cksum field. DES blocks are 8
5184 bytes. As a result, the data to be encrypted (the concate-
5185 nation of confounder, checksum, and message) must be padded
5186 to an 8 byte boundary before encryption.
5188 Plaintext and DES ciphtertext are encoded as 8-octet
5189 blocks which are concatenated to make the 64-bit inputs for
5190 the DES algorithms. The first octet supplies the 8 most
5191 significant bits (with the octet's MSbit used as the DES
5192 input block's MSbit, etc.), the second octet the next 8
5195 Section 6.3.4. - 79 - Expires 11 January 1998
5203 Version 5 - Specification Revision 6
5206 bits, ..., and the eighth octet supplies the 8 least signi-
5209 Encryption under DES using cipher block chaining
5210 requires an additional input in the form of an initializa-
5211 tion vector. Unless otherwise specified, zero should be
5212 used as the initialization vector. Kerberos' use of DES
5213 requires an 8-octet confounder.
5215 The DES specifications identify some "weak" and "semi-
5216 weak" keys; those keys shall not be used for encrypting mes-
5217 sages for use in Kerberos. Additionally, because of the way
5218 that keys are derived for the encryption of checksums, keys
5219 shall not be used that yield "weak" or "semi-weak" keys when
5220 eXclusive-ORed with the constant F0F0F0F0F0F0F0F0.
5222 A DES key is 8 octets of data, with keytype one (1).
5223 This consists of 56 bits of key, and 8 parity bits (one per
5224 octet). The key is encoded as a series of 8 octets written
5225 in MSB-first order. The bits within the key are also
5226 encoded in MSB order. For example, if the encryption key is
5227 (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8)
5228 where B1,B2,...,B56 are the key bits in MSB order, and
5229 P1,P2,...,P8 are the parity bits, the first octet of the key
5230 would be B1,B2,...,B7,P1 (with B1 as the MSbit). [See the
5231 FIPS 81 introduction for reference.]
5233 To generate a DES key from a text string (password),
5234 the text string normally must have the realm and each com-
5235 ponent of the principal's name appended[37], then padded
5236 with ASCII nulls to an 8 byte boundary. This string is then
5237 fan-folded and eXclusive-ORed with itself to form an 8 byte
5238 DES key. The parity is corrected on the key, and it is used
5239 to generate a DES CBC checksum on the initial string (with
5240 the realm and name appended). Next, parity is corrected on
5241 the CBC checksum. If the result matches a "weak" or "semi-
5242 weak" key as described in the DES specification, it is
5243 eXclusive-ORed with the constant 00000000000000F0. Finally,
5244 the result is returned as the key. Pseudocode follows:
5246 string_to_key(string,realm,name) {
5249 for(each component in name) {
5253 pad(s); /* with nulls to 8 byte boundary */
5254 for(8byteblock in s) {
5255 __________________________
5256 [37] In some cases, it may be necessary to use a dif-
5257 ferent "mix-in" string for compatibility reasons; see
5258 the discussion of padata in section 5.4.2.
5261 Section 6.3.4. - 80 - Expires 11 January 1998
5269 Version 5 - Specification Revision 6
5277 tempkey = tempkey XOR 8byteblock;
5280 key = DES-CBC-check(s,tempkey);
5282 if(is_weak_key_key(key))
5287 6.3.5. Triple DES EDE in outer CBC mode with an SHA1 check-
5290 The des3-cbc-sha1 encryption encodes information using
5291 three Data Encryption Standard transformations with three
5292 DES keys. The first key is used to perform a DES ECB
5293 encryption on an eight-octet data block using the first DES
5294 key, followed by a DES ECB decryption of the result using
5295 the second DES key, and a DES ECB encryption of the result
5296 using the third DES key. Because DES blocks are 8 bytes,
5297 the data to be encrypted (the concatenation of confounder,
5298 checksum, and message) must first be padded to an 8 byte
5299 boundary before encryption. To support the outer CBC mode,
5300 the input is padded an eight-octet boundary. The first 8
5301 octets of the data to be encrypted (the confounder) is
5302 exclusive-ored with an initialization vector of zero and
5303 then ECB encrypted using triple DES as described above.
5304 Subsequent blocks of 8 octets are exclusive-ored with the
5305 ciphertext produced by the encryption on the previous block
5306 before ECB encryption.
5308 An HMAC-SHA1 checksum (described in [18].) is applied
5309 to the confounder and message sequence (msg-seq) and placed
5312 Plaintext are encoded as 8-octet blocks which are con-
5313 catenated to make the 64-bit inputs for the DES algorithms.
5314 The first octet supplies the 8 most significant bits (with
5315 the octet's MSbit used as the DES input block's MSbit,
5316 etc.), the second octet the next 8 bits, ..., and the eighth
5317 octet supplies the 8 least significant bits.
5319 Encryption under Triple DES using cipher block chaining
5320 requires an additional input in the form of an initializa-
5321 tion vector. Unless otherwise specified, zero should be
5322 used as the initialization vector. Kerberos' use of DES
5323 requires an 8-octet confounder.
5325 The DES specifications identify some "weak" and "semi-
5328 Section 6.3.5. - 81 - Expires 11 January 1998
5336 Version 5 - Specification Revision 6
5339 weak" keys; those keys shall not be used for encrypting mes-
5340 sages for use in Kerberos. Additionally, because of the way
5341 that keys are derived for the encryption of checksums, keys
5342 shall not be used that yield "weak" or "semi-weak" keys when
5343 eXclusive-ORed with the constant F0F0F0F0F0F0F0F0.
5345 A Triple DES key is 24 octets of data, with keytype
5346 seven (7). This consists of 168 bits of key, and 24 parity
5347 bits (one per octet). The key is encoded as a series of 24
5348 octets written in MSB-first order, with the first 8 octets
5349 treated as the first DES key, the second 8 octets as the
5350 second key, and the third 8 octets the third DES key. The
5351 bits within each key are also encoded in MSB order. For
5352 example, if the encryption key is
5353 (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8)
5354 where B1,B2,...,B56 are the key bits in MSB order, and
5355 P1,P2,...,P8 are the parity bits, the first octet of the key
5356 would be B1,B2,...,B7,P1 (with B1 as the MSbit). [See the
5357 FIPS 81 introduction for reference.]
5359 To generate a DES key from a text string (password),
5360 the text string normally must have the realm and each com-
5361 ponent of the principal's name appended[38],
5363 The input string (with any salt data appended to it) is
5364 n-folded into a 24 octet (192 bit) string. To n-fold a
5365 number X, replicate the input value to a length that is the
5366 least common multiple of n and the length of X. Before each
5367 repetition, the input X is rotated to the right by 13 bit
5368 positions. The successive n-bit chunks are added together
5369 using 1's-complement addition (addition with end-around
5370 carry) to yield a n-bit result. (This transformation was
5371 proposed by Richard Basch)
5373 Each successive set of 8 octets is taken as a DES key,
5374 and its parity is adjusted in the same manner as previously
5375 described. If any of the three sets of 8 octets match a
5376 "weak" or "semi-weak" key as described in the DES specifica-
5377 tion, that chunk is eXclusive-ORed with the constant
5378 00000000000000F0. The resulting DES keys are then used in
5379 sequence to perform a Triple-DES CBC encryption of the n-
5380 folded input string (appended with any salt data), using a
5381 zero initial vector. Parity, weak, and semi-weak keys are
5382 once again corrected and the result is returned as the 24
5387 string_to_key(string,realm,name) {
5388 __________________________
5389 [38] In some cases, it may be necessary to use a dif-
5390 ferent "mix-in" string for compatibility reasons; see
5391 the discussion of padata in section 5.4.2.
5394 Section 6.3.5. - 82 - Expires 11 January 1998
5402 Version 5 - Specification Revision 6
5406 for(each component in name) {
5411 if(isweak(tkey[0-7])) tkey[0-7] = tkey[0-7] XOR 0xF0;
5412 if(isweak(tkey[8-15])) tkey[8-15] = tkey[8-15] XOR 0xF0;
5413 if(is_weak(tkey[16-23])) tkey[16-23] = tkey[16-23] XOR 0xF0;
5414 key[24] = 3DES-CBC(data=fold(s),key=tkey,iv=0);
5416 if(is_weak(key[0-7])) key[0-7] = key[0-7] XOR 0xF0;
5417 if(is_weak(key[8-15])) key[8-15] = key[8-15] XOR 0xF0;
5418 if(is_weak(key[16-23])) key[16-23] = key[16-23] XOR 0xF0;
5424 The following is the ASN.1 definition used for a check-
5427 Checksum ::= SEQUENCE {
5428 cksumtype[0] INTEGER,
5429 checksum[1] OCTET STRING
5433 cksumtype This field indicates the algorithm used to gen-
5434 erate the accompanying checksum.
5436 checksum This field contains the checksum itself, encoded
5439 Detailed specification of selected checksum types
5440 appear later in this section. Negative values for the
5441 checksum type are reserved for local use. All non-negative
5442 values are reserved for officially assigned type fields and
5445 Checksums used by Kerberos can be classified by two
5446 properties: whether they are collision-proof, and whether
5447 they are keyed. It is infeasible to find two plaintexts
5448 which generate the same checksum value for a collision-proof
5449 checksum. A key is required to perturb or initialize the
5450 algorithm in a keyed checksum. To prevent message-stream
5451 modification by an active attacker, unkeyed checksums should
5452 only be used when the checksum and message will be subse-
5453 quently encrypted (e.g. the checksums defined as part of the
5454 encryption algorithms covered earlier in this section).
5456 Collision-proof checksums can be made tamper-proof if
5457 the checksum value is encrypted before inclusion in a mes-
5458 sage. In such cases, the composition of the checksum and
5461 Section 6.4. - 83 - Expires 11 January 1998
5469 Version 5 - Specification Revision 6
5472 the encryption algorithm must be considered a separate
5473 checksum algorithm (e.g. RSA-MD5 encrypted using DES is a
5474 new checksum algorithm of type RSA-MD5-DES). For most keyed
5475 checksums, as well as for the encrypted forms of unkeyed
5476 collision-proof checksums, Kerberos prepends a confounder
5477 before the checksum is calculated.
5479 6.4.1. The CRC-32 Checksum (crc32)
5481 The CRC-32 checksum calculates a checksum based on a
5482 cyclic redundancy check as described in ISO 3309 [15]. The
5483 resulting checksum is four (4) octets in length. The CRC-32
5484 is neither keyed nor collision-proof. The use of this
5485 checksum is not recommended. An attacker using a proba-
5486 bilistic chosen-plaintext attack as described in [14] might
5487 be able to generate an alternative message that satisfies
5488 the checksum. The use of collision-proof checksums is
5489 recommended for environments where such attacks represent a
5492 6.4.2. The RSA MD4 Checksum (rsa-md4)
5494 The RSA-MD4 checksum calculates a checksum using the
5495 RSA MD4 algorithm [16]. The algorithm takes as input an
5496 input message of arbitrary length and produces as output a
5497 128-bit (16 octet) checksum. RSA-MD4 is believed to be
5500 6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4-
5503 The RSA-MD4-DES checksum calculates a keyed collision-
5504 proof checksum by prepending an 8 octet confounder before
5505 the text, applying the RSA MD4 checksum algorithm, and
5506 encrypting the confounder and the checksum using DES in
5507 cipher-block-chaining (CBC) mode using a variant of the key,
5508 where the variant is computed by eXclusive-ORing the key
5509 with the constant F0F0F0F0F0F0F0F0[39]. The initialization
5510 vector should be zero. The resulting checksum is 24 octets
5511 long (8 octets of which are redundant). This checksum is
5512 tamper-proof and believed to be collision-proof.
5514 The DES specifications identify some "weak keys" and
5515 __________________________
5516 [39] A variant of the key is used to limit the use of a
5517 key to a particular function, separating the functions
5518 of generating a checksum from other encryption per-
5519 formed using the session key. The constant
5520 F0F0F0F0F0F0F0F0 was chosen because it maintains key
5521 parity. The properties of DES precluded the use of the
5522 complement. The same constant is used for similar pur-
5523 pose in the Message Integrity Check in the Privacy
5524 Enhanced Mail standard.
5527 Section 6.4.3. - 84 - Expires 11 January 1998
5535 Version 5 - Specification Revision 6
5538 "semi-weak keys"; those keys shall not be used for generat-
5539 ing RSA-MD4 checksums for use in Kerberos.
5541 The format for the checksum is described in the follow-
5544 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
5545 | des-cbc(confounder + rsa-md4(confounder+msg),key=var(key),iv=0) |
5546 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
5548 The format cannot be described in ASN.1, but for those who
5549 prefer an ASN.1-like notation:
5551 rsa-md4-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE {
5552 confounder[0] UNTAGGED OCTET STRING(8),
5553 check[1] UNTAGGED OCTET STRING(16)
5558 6.4.4. The RSA MD5 Checksum (rsa-md5)
5560 The RSA-MD5 checksum calculates a checksum using the
5561 RSA MD5 algorithm. [17]. The algorithm takes as input an
5562 input message of arbitrary length and produces as output a
5563 128-bit (16 octet) checksum. RSA-MD5 is believed to be
5566 6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5-
5569 The RSA-MD5-DES checksum calculates a keyed collision-
5570 proof checksum by prepending an 8 octet confounder before
5571 the text, applying the RSA MD5 checksum algorithm, and
5572 encrypting the confounder and the checksum using DES in
5573 cipher-block-chaining (CBC) mode using a variant of the key,
5574 where the variant is computed by eXclusive-ORing the key
5575 with the constant F0F0F0F0F0F0F0F0. The initialization vec-
5576 tor should be zero. The resulting checksum is 24 octets
5577 long (8 octets of which are redundant). This checksum is
5578 tamper-proof and believed to be collision-proof.
5580 The DES specifications identify some "weak keys" and
5581 "semi-weak keys"; those keys shall not be used for encrypt-
5582 ing RSA-MD5 checksums for use in Kerberos.
5584 The format for the checksum is described in the follow-
5587 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
5588 | des-cbc(confounder + rsa-md5(confounder+msg),key=var(key),iv=0) |
5589 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
5591 The format cannot be described in ASN.1, but for those who
5594 Section 6.4.5. - 85 - Expires 11 January 1998
5602 Version 5 - Specification Revision 6
5605 prefer an ASN.1-like notation:
5607 rsa-md5-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE {
5608 confounder[0] UNTAGGED OCTET STRING(8),
5609 check[1] UNTAGGED OCTET STRING(16)
5613 6.4.6. DES cipher-block chained checksum (des-mac)
5615 The DES-MAC checksum is computed by prepending an 8
5616 octet confounder to the plaintext, performing a DES CBC-mode
5617 encryption on the result using the key and an initialization
5618 vector of zero, taking the last block of the ciphertext,
5619 prepending the same confounder and encrypting the pair using
5620 DES in cipher-block-chaining (CBC) mode using a a variant of
5621 the key, where the variant is computed by eXclusive-ORing
5622 the key with the constant F0F0F0F0F0F0F0F0. The initializa-
5623 tion vector should be zero. The resulting checksum is 128
5624 bits (16 octets) long, 64 bits of which are redundant. This
5625 checksum is tamper-proof and collision-proof.
5627 The format for the checksum is described in the follow-
5630 +--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
5631 | des-cbc(confounder + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) |
5632 +--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
5634 The format cannot be described in ASN.1, but for those who
5635 prefer an ASN.1-like notation:
5637 des-mac-checksum ::= ENCRYPTED UNTAGGED SEQUENCE {
5638 confounder[0] UNTAGGED OCTET STRING(8),
5639 check[1] UNTAGGED OCTET STRING(8)
5643 The DES specifications identify some "weak" and "semi-
5644 weak" keys; those keys shall not be used for generating
5645 DES-MAC checksums for use in Kerberos, nor shall a key be
5646 used whose variant is "weak" or "semi-weak".
5648 6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative
5651 The RSA-MD4-DES-K checksum calculates a keyed
5652 collision-proof checksum by applying the RSA MD4 checksum
5653 algorithm and encrypting the results using DES in cipher-
5654 block-chaining (CBC) mode using a DES key as both key and
5655 initialization vector. The resulting checksum is 16 octets
5656 long. This checksum is tamper-proof and believed to be
5657 collision-proof. Note that this checksum type is the old
5658 method for encoding the RSA-MD4-DES checksum and it is no
5661 Section 6.4.7. - 86 - Expires 11 January 1998
5669 Version 5 - Specification Revision 6
5674 6.4.8. DES cipher-block chained checksum alternative (des-
5677 The DES-MAC-K checksum is computed by performing a DES
5678 CBC-mode encryption of the plaintext, and using the last
5679 block of the ciphertext as the checksum value. It is keyed
5680 with an encryption key and an initialization vector; any
5681 uses which do not specify an additional initialization vec-
5682 tor will use the key as both key and initialization vector.
5683 The resulting checksum is 64 bits (8 octets) long. This
5684 checksum is tamper-proof and collision-proof. Note that
5685 this checksum type is the old method for encoding the DES-
5686 MAC checksum and it is no longer recommended.
5688 The DES specifications identify some "weak keys" and
5689 "semi-weak keys"; those keys shall not be used for generat-
5690 ing DES-MAC checksums for use in Kerberos.
5692 7. Naming Constraints
5697 Although realm names are encoded as GeneralStrings and
5698 although a realm can technically select any name it chooses,
5699 interoperability across realm boundaries requires agreement
5700 on how realm names are to be assigned, and what information
5703 To enforce these conventions, each realm must conform
5704 to the conventions itself, and it must require that any
5705 realms with which inter-realm keys are shared also conform
5706 to the conventions and require the same from its neighbors.
5708 Kerberos realm names are case sensitive. Realm names
5709 that differ only in the case of the characters are not
5710 equivalent. There are presently four styles of realm names:
5711 domain, X500, other, and reserved. Examples of each style
5714 domain: ATHENA.MIT.EDU (example)
5715 X500: C=US/O=OSF (example)
5716 other: NAMETYPE:rest/of.name=without-restrictions (example)
5717 reserved: reserved, but will not conflict with above
5720 Domain names must look like domain names: they consist of
5721 components separated by periods (.) and they contain neither
5722 colons (:) nor slashes (/). Domain names must be converted
5723 to upper case when used as realm names.
5725 X.500 names contain an equal (=) and cannot contain a
5728 Section 7.1. - 87 - Expires 11 January 1998
5736 Version 5 - Specification Revision 6
5739 colon (:) before the equal. The realm names for X.500 names
5740 will be string representations of the names with components
5741 separated by slashes. Leading and trailing slashes will not
5744 Names that fall into the other category must begin with
5745 a prefix that contains no equal (=) or period (.) and the
5746 prefix must be followed by a colon (:) and the rest of the
5747 name. All prefixes must be assigned before they may be
5748 used. Presently none are assigned.
5750 The reserved category includes strings which do not
5751 fall into the first three categories. All names in this
5752 category are reserved. It is unlikely that names will be
5753 assigned to this category unless there is a very strong
5754 argument for not using the "other" category.
5756 These rules guarantee that there will be no conflicts
5757 between the various name styles. The following additional
5758 constraints apply to the assignment of realm names in the
5759 domain and X.500 categories: the name of a realm for the
5760 domain or X.500 formats must either be used by the organiza-
5761 tion owning (to whom it was assigned) an Internet domain
5762 name or X.500 name, or in the case that no such names are
5763 registered, authority to use a realm name may be derived
5764 from the authority of the parent realm. For example, if
5765 there is no domain name for E40.MIT.EDU, then the adminis-
5766 trator of the MIT.EDU realm can authorize the creation of a
5767 realm with that name.
5769 This is acceptable because the organization to which
5770 the parent is assigned is presumably the organization
5771 authorized to assign names to its children in the X.500 and
5772 domain name systems as well. If the parent assigns a realm
5773 name without also registering it in the domain name or X.500
5774 hierarchy, it is the parent's responsibility to make sure
5775 that there will not in the future exists a name identical to
5776 the realm name of the child unless it is assigned to the
5777 same entity as the realm name.
5780 7.2. Principal Names
5782 As was the case for realm names, conventions are needed
5783 to ensure that all agree on what information is implied by a
5784 principal name. The name-type field that is part of the
5785 principal name indicates the kind of information implied by
5786 the name. The name-type should be treated as a hint.
5787 Ignoring the name type, no two names can be the same (i.e.
5788 at least one of the components, or the realm, must be dif-
5789 ferent). This constraint may be eliminated in the future.
5790 The following name types are defined:
5792 name-type value meaning
5795 Section 7.2. - 88 - Expires 11 January 1998
5803 Version 5 - Specification Revision 6
5806 NT-UNKNOWN 0 Name type not known
5807 NT-PRINCIPAL 1 General principal name (e.g. username, or DCE principal)
5808 NT-SRV-INST 2 Service and other unique instance (krbtgt)
5809 NT-SRV-HST 3 Service with host name as instance (telnet, rcommands)
5810 NT-SRV-XHST 4 Service with slash-separated host name components
5814 When a name implies no information other than its uniqueness
5815 at a particular time the name type PRINCIPAL should be used.
5816 The principal name type should be used for users, and it
5817 might also be used for a unique server. If the name is a
5818 unique machine generated ID that is guaranteed never to be
5819 reassigned then the name type of UID should be used (note
5820 that it is generally a bad idea to reassign names of any
5821 type since stale entries might remain in access control
5824 If the first component of a name identifies a service
5825 and the remaining components identify an instance of the
5826 service in a server specified manner, then the name type of
5827 SRV-INST should be used. An example of this name type is
5828 the Kerberos ticket-granting service whose name has a first
5829 component of krbtgt and a second component identifying the
5830 realm for which the ticket is valid.
5832 If instance is a single component following the service
5833 name and the instance identifies the host on which the
5834 server is running, then the name type SRV-HST should be
5835 used. This type is typically used for Internet services
5836 such as telnet and the Berkeley R commands. If the separate
5837 components of the host name appear as successive components
5838 following the name of the service, then the name type SRV-
5839 XHST should be used. This type might be used to identify
5840 servers on hosts with X.500 names where the slash (/) might
5841 otherwise be ambiguous.
5843 A name type of UNKNOWN should be used when the form of
5844 the name is not known. When comparing names, a name of type
5845 UNKNOWN will match principals authenticated with names of
5846 any type. A principal authenticated with a name of type
5847 UNKNOWN, however, will only match other names of type UNK-
5850 Names of any type with an initial component of "krbtgt"
5851 are reserved for the Kerberos ticket granting service. See
5852 section 8.2.3 for the form of such names.
5854 7.2.1. Name of server principals
5856 The principal identifier for a server on a host will
5857 generally be composed of two parts: (1) the realm of the KDC
5858 with which the server is registered, and (2) a two-component
5861 Section 7.2.1. - 89 - Expires 11 January 1998
5869 Version 5 - Specification Revision 6
5872 name of type NT-SRV-HST if the host name is an Internet
5873 domain name or a multi-component name of type NT-SRV-XHST if
5874 the name of the host is of a form such as X.500 that allows
5875 slash (/) separators. The first component of the two- or
5876 multi-component name will identify the service and the
5877 latter components will identify the host. Where the name of
5878 the host is not case sensitive (for example, with Internet
5879 domain names) the name of the host must be lower case. If
5880 specified by the application protocol for services such as
5881 telnet and the Berkeley R commands which run with system
5882 privileges, the first component may be the string "host"
5883 instead of a service specific identifier. When a host has
5884 an official name and one or more aliases, the official name
5885 of the host must be used when constructing the name of the
5888 8. Constants and other defined values
5891 8.1. Host address types
5893 All negative values for the host address type are
5894 reserved for local use. All non-negative values are
5895 reserved for officially assigned type fields and interpreta-
5898 The values of the types for the following addresses are
5899 chosen to match the defined address family constants in the
5900 Berkeley Standard Distributions of Unix. They can be found
5901 in <sys/socket.h> with symbolic names AF_xxx (where xxx is
5902 an abbreviation of the address family name).
5907 Internet addresses are 32-bit (4-octet) quantities,
5908 encoded in MSB order. The type of internet addresses is two
5913 CHAOSnet addresses are 16-bit (2-octet) quantities,
5914 encoded in MSB order. The type of CHAOSnet addresses is
5919 ISO addresses are variable-length. The type of ISO
5920 addresses is seven (7).
5922 Xerox Network Services (XNS) addresses
5924 XNS addresses are 48-bit (6-octet) quantities, encoded
5925 in MSB order. The type of XNS addresses is six (6).
5928 Section 8.1. - 90 - Expires 11 January 1998
5936 Version 5 - Specification Revision 6
5939 AppleTalk Datagram Delivery Protocol (DDP) addresses
5941 AppleTalk DDP addresses consist of an 8-bit node number
5942 and a 16-bit network number. The first octet of the address
5943 is the node number; the remaining two octets encode the net-
5944 work number in MSB order. The type of AppleTalk DDP
5945 addresses is sixteen (16).
5947 DECnet Phase IV addresses
5949 DECnet Phase IV addresses are 16-bit addresses, encoded
5950 in LSB order. The type of DECnet Phase IV addresses is
5957 When contacting a Kerberos server (KDC) for a
5958 KRB_KDC_REQ request using UDP IP transport, the client shall
5959 send a UDP datagram containing only an encoding of the
5960 request to port 88 (decimal) at the KDC's IP address; the
5961 KDC will respond with a reply datagram containing only an
5962 encoding of the reply message (either a KRB_ERROR or a
5963 KRB_KDC_REP) to the sending port at the sender's IP address.
5965 Kerberos servers supporting IP transport must accept
5966 UDP requests on port 88 (decimal). Servers may also accept
5967 TCP requests on port 88 (decimal). When the KRB_KDC_REQ
5968 message is sent to the KDC by TCP, a new connection will be
5969 established for each authentication exchange and the
5970 KRB_KDC_REP or KRB_ERROR message will be returned to the
5971 client on the TCP stream that was established for the
5972 request. The connection will be broken after the reply has
5973 been received (or upon time-out). Care must be taken in
5974 managing TCP/IP connections with the KDC to prevent denial
5975 of service attacks based on the number of TCP/IP connections
5976 with the KDC that remain open.
5978 8.2.2. OSI transport
5980 During authentication of an OSI client to an OSI
5981 server, the mutual authentication of an OSI server to an OSI
5982 client, the transfer of credentials from an OSI client to an
5983 OSI server, or during exchange of private or integrity
5984 checked messages, Kerberos protocol messages may be treated
5985 as opaque objects and the type of the authentication mechan-
5988 OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), security(5),
5991 Depending on the situation, the opaque object will be an
5992 authentication header (KRB_AP_REQ), an authentication reply
5993 (KRB_AP_REP), a safe message (KRB_SAFE), a private message
5996 Section 8.2.2. - 91 - Expires 11 January 1998
6004 Version 5 - Specification Revision 6
6007 (KRB_PRIV), or a credentials message (KRB_CRED). The opaque
6008 data contains an application code as specified in the ASN.1
6009 description for each message. The application code may be
6010 used by Kerberos to determine the message type.
6012 8.2.3. Name of the TGS
6014 The principal identifier of the ticket-granting service
6015 shall be composed of three parts: (1) the realm of the KDC
6016 issuing the TGS ticket (2) a two-part name of type NT-SRV-
6017 INST, with the first part "krbtgt" and the second part the
6018 name of the realm which will accept the ticket-granting
6019 ticket. For example, a ticket-granting ticket issued by the
6020 ATHENA.MIT.EDU realm to be used to get tickets from the
6021 ATHENA.MIT.EDU KDC has a principal identifier of
6022 "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU")
6023 (name). A ticket-granting ticket issued by the
6024 ATHENA.MIT.EDU realm to be used to get tickets from the
6025 MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU"
6026 (realm), ("krbtgt", "MIT.EDU") (name).
6029 8.3. Protocol constants and associated values
6031 The following tables list constants used in the protocol and defines their
6034 Encryption type etype value block size minimum pad size confounder size
6040 des3-cbc-md5 5 8 0 8
6042 des3-cbc-sha1 7 8 0 8
6043 sign-dsa-generate 8 (pkinit)
6044 encrypt-rsa-priv 9 (pkinit)
6045 encrypt-rsa-pub 10 (pkinit)
6046 ENCTYPE_PK_CROSS 48 (reserved for pkcross)
6049 Checksum type sumtype value checksum size
6059 hmac-sha1-des3 10 20 (I had this as 10, is it 12)
6062 Section 8.3. - 92 - Expires 11 January 1998
6070 Version 5 - Specification Revision 6
6073 padata type padata-type value
6080 PA-SANDIA-SECUREID 6
6083 PA-CYBERSAFE-SECUREID 9
6086 SAM-CHALLENGE 12 (sam/otp)
6087 SAM-RESPONSE 13 (sam/otp)
6088 PA-PK-AS-REQ 14 (pkinit)
6089 PA-PK-AS-REP 15 (pkinit)
6090 PA-PK-AS-SIGN 16 (pkinit)
6091 PA-PK-KEY-REQ 17 (pkinit)
6092 PA-PK-KEY-REP 18 (pkinit)
6094 authorization data type ad-type value
6095 reserved values 0-63
6099 alternate authentication type method-type value
6100 reserved values 0-63
6101 ATT-CHALLENGE-RESPONSE 64
6103 transited encoding type tr-type value
6104 DOMAIN-X500-COMPRESS 1
6105 reserved values all others
6109 Label Value Meaning or MIT code
6111 pvno 5 current Kerberos protocol version number
6115 KRB_AS_REQ 10 Request for initial authentication
6116 KRB_AS_REP 11 Response to KRB_AS_REQ request
6117 KRB_TGS_REQ 12 Request for authentication based on TGT
6118 KRB_TGS_REP 13 Response to KRB_TGS_REQ request
6119 KRB_AP_REQ 14 application request to server
6120 KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL
6121 KRB_SAFE 20 Safe (checksummed) application message
6122 KRB_PRIV 21 Private (encrypted) application message
6123 KRB_CRED 22 Private (encrypted) message to forward credentials
6124 KRB_ERROR 30 Error response
6127 Section 8.3. - 93 - Expires 11 January 1998
6135 Version 5 - Specification Revision 6
6140 KRB_NT_UNKNOWN 0 Name type not known
6141 KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users
6142 KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt)
6143 KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands)
6144 KRB_NT_SRV_XHST 4 Service with host as remaining components
6145 KRB_NT_UID 5 Unique ID
6149 KDC_ERR_NONE 0 No error
6150 KDC_ERR_NAME_EXP 1 Client's entry in database has expired
6151 KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired
6152 KDC_ERR_BAD_PVNO 3 Requested protocol version number not supported
6153 KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key
6154 KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key
6155 KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database
6156 KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database
6157 KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database
6158 KDC_ERR_NULL_KEY 9 The client or server has a null key
6159 KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating
6160 KDC_ERR_NEVER_VALID 11 Requested start time is later than end time
6161 KDC_ERR_POLICY 12 KDC policy rejects request
6162 KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option
6163 KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type
6164 KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type
6165 KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type
6166 KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type
6167 KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked
6168 KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked
6169 KDC_ERR_TGT_REVOKED 20 TGT has been revoked
6170 KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later
6171 KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later
6172 KDC_ERR_KEY_EXPIRED 23 Password has expired - change password to reset
6173 KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid
6174 KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired-
6175 KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match
6176 KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user only
6177 KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path
6178 KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed
6179 KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired
6180 KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid
6181 KRB_AP_ERR_REPEAT 34 Request is a replay
6182 KRB_AP_ERR_NOT_US 35 The ticket isn't for us
6183 KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match
6184 KRB_AP_ERR_SKEW 37 Clock skew too great
6185 KRB_AP_ERR_BADADDR 38 Incorrect net address
6186 KRB_AP_ERR_BADVERSION 39 Protocol version mismatch
6187 KRB_AP_ERR_MSG_TYPE 40 Invalid msg type
6188 KRB_AP_ERR_MODIFIED 41 Message stream modified
6189 KRB_AP_ERR_BADORDER 42 Message out of order
6190 KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available
6191 KRB_AP_ERR_NOKEY 45 Service key not available
6192 KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed
6193 KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction
6194 KRB_AP_ERR_METHOD 48 Alternative authentication method required
6195 KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message
6199 Section 8.3. - 94 - Expires 11 January 1998
6207 Version 5 - Specification Revision 6
6210 KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message
6211 KRB_ERR_GENERIC 60 Generic error (description in e-text)
6212 KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation
6213 KDC_ERROR_CLIENT_NOT_TRUSTED 62 (pkinit)
6214 KDC_ERROR_KDC_NOT_TRUSTED 63 (pkinit)
6215 KDC_ERROR_INVALID_SIG 64 (pkinit)
6216 KDC_ERR_KEY_TOO_WEAK 65 (pkinit)
6219 9. Interoperability requirements
6221 Version 5 of the Kerberos protocol supports a myriad of
6222 options. Among these are multiple encryption and checksum
6223 types, alternative encoding schemes for the transited field,
6224 optional mechanisms for pre-authentication, the handling of
6225 tickets with no addresses, options for mutual authentica-
6226 tion, user to user authentication, support for proxies, for-
6227 warding, postdating, and renewing tickets, the format of
6228 realm names, and the handling of authorization data.
6230 In order to ensure the interoperability of realms, it
6231 is necessary to define a minimal configuration which must be
6232 supported by all implementations. This minimal configura-
6233 tion is subject to change as technology does. For example,
6234 if at some later date it is discovered that one of the
6235 required encryption or checksum algorithms is not secure, it
6238 9.1. Specification 1
6240 This section defines the first specification of these
6241 options. Implementations which are configured in this way
6242 can be said to support Kerberos Version 5 Specification 1
6245 Encryption and checksum methods
6247 The following encryption and checksum mechanisms must be
6248 supported. Implementations may support other mechanisms as
6249 well, but the additional mechanisms may only be used when
6250 communicating with principals known to also support them:
6251 This list is to be determined.
6252 Encryption: DES-CBC-MD5
6253 Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5
6256 __________________________
6257 - This error carries additional information in the e-
6258 data field. The contents of the e-data field for this
6259 message is described in section 5.9.1.
6263 Section 9.1. - 95 - Expires 11 January 1998
6271 Version 5 - Specification Revision 6
6276 All implementations must understand hierarchical realms in
6277 both the Internet Domain and the X.500 style. When a ticket
6278 granting ticket for an unknown realm is requested, the KDC
6279 must be able to determine the names of the intermediate
6280 realms between the KDCs realm and the requested realm.
6282 Transited field encoding
6284 DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be
6285 supported. Alternative encodings may be supported, but they
6286 may be used only when that encoding is supported by ALL
6287 intermediate realms.
6289 Pre-authentication methods
6291 The TGS-REQ method must be supported. The TGS-REQ method is
6292 not used on the initial request. The PA-ENC-TIMESTAMP
6293 method must be supported by clients but whether it is
6294 enabled by default may be determined on a realm by realm
6295 basis. If not used in the initial request and the error
6296 KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-
6297 TIMESTAMP as an acceptable method, the client should retry
6298 the initial request using the PA-ENC-TIMESTAMP pre-
6299 authentication method. Servers need not support the PA-
6300 ENC-TIMESTAMP method, but if not supported the server should
6301 ignore the presence of PA-ENC-TIMESTAMP pre-authentication
6304 Mutual authentication
6306 Mutual authentication (via the KRB_AP_REP message) must be
6310 Ticket addresses and flags
6312 All KDC's must pass on tickets that carry no addresses (i.e.
6313 if a TGT contains no addresses, the KDC will return deriva-
6314 tive tickets), but each realm may set its own policy for
6315 issuing such tickets, and each application server will set
6316 its own policy with respect to accepting them.
6318 Proxies and forwarded tickets must be supported. Indi-
6319 vidual realms and application servers can set their own pol-
6320 icy on when such tickets will be accepted.
6322 All implementations must recognize renewable and post-
6323 dated tickets, but need not actually implement them. If
6324 these options are not supported, the starttime and endtime
6325 in the ticket shall specify a ticket's entire useful life.
6326 When a postdated ticket is decoded by a server, all imple-
6327 mentations shall make the presence of the postdated flag
6330 Section 9.1. - 96 - Expires 11 January 1998
6338 Version 5 - Specification Revision 6
6341 visible to the calling server.
6343 User-to-user authentication
6345 Support for user to user authentication (via the ENC-TKT-
6346 IN-SKEY KDC option) must be provided by implementations, but
6347 individual realms may decide as a matter of policy to reject
6348 such requests on a per-principal or realm-wide basis.
6352 Implementations must pass all authorization data subfields
6353 from ticket-granting tickets to any derivative tickets
6354 unless directed to suppress a subfield as part of the defin-
6355 ition of that registered subfield type (it is never
6356 incorrect to pass on a subfield, and no registered subfield
6357 types presently specify suppression at the KDC).
6359 Implementations must make the contents of any authori-
6360 zation data subfields available to the server when a ticket
6361 is used. Implementations are not required to allow clients
6362 to specify the contents of the authorization data fields.
6364 9.2. Recommended KDC values
6366 Following is a list of recommended values for a KDC imple-
6367 mentation, based on the list of suggested configuration con-
6368 stants (see section 4.4).
6370 minimum lifetime 5 minutes
6372 maximum renewable lifetime1 week
6374 maximum ticket lifetime1 day
6376 empty addresses only when suitable restrictions appear
6377 in authorization data
6379 proxiable, etc. Allowed.
6397 Section 9.2. - 97 - Expires 11 January 1998
6405 Version 5 - Specification Revision 6
6412 1. B. Clifford Neuman and Theodore Y. Ts'o, "An Authenti-
6413 cation Service for Computer Networks," IEEE Communica-
6414 tions Magazine, Vol. 32(9), pp. 33-38 (September 1994).
6416 2. S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H.
6417 Saltzer, Section E.2.1: Kerberos Authentication and
6418 Authorization System, M.I.T. Project Athena, Cambridge,
6419 Massachusetts (December 21, 1987).
6421 3. J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Ker-
6422 beros: An Authentication Service for Open Network Sys-
6423 tems," pp. 191-202 in Usenix Conference Proceedings,
6424 Dallas, Texas (February, 1988).
6426 4. Roger M. Needham and Michael D. Schroeder, "Using
6427 Encryption for Authentication in Large Networks of Com-
6428 puters," Communications of the ACM, Vol. 21(12),
6429 pp. 993-999 (December, 1978).
6431 5. Dorothy E. Denning and Giovanni Maria Sacco, "Time-
6432 stamps in Key Distribution Protocols," Communications
6433 of the ACM, Vol. 24(8), pp. 533-536 (August 1981).
6435 6. John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o,
6436 "The Evolution of the Kerberos Authentication Service,"
6437 in an IEEE Computer Society Text soon to be published
6440 7. B. Clifford Neuman, "Proxy-Based Authorization and
6441 Accounting for Distributed Systems," in Proceedings of
6442 the 13th International Conference on Distributed Com-
6443 puting Systems, Pittsburgh, PA (May, 1993).
6445 8. Don Davis and Ralph Swick, "Workstation Services and
6446 Kerberos Authentication at Project Athena," Technical
6447 Memorandum TM-424, MIT Laboratory for Computer Science
6450 9. P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E. Som-
6451 merfeld, and K. Raeburn, Section E.1: Service Manage-
6452 ment System, M.I.T. Project Athena, Cambridge, Mas-
6455 10. CCITT, Recommendation X.509: The Directory Authentica-
6456 tion Framework, December 1988.
6458 11. J. Pato, Using Pre-Authentication to Avoid Password
6459 Guessing Attacks, Open Software Foundation DCE Request
6460 for Comments 26 (December 1992).
6464 Section 10. - 98 - Expires 11 January 1998
6472 Version 5 - Specification Revision 6
6475 12. National Bureau of Standards, U.S. Department of Com-
6476 merce, "Data Encryption Standard," Federal Information
6477 Processing Standards Publication 46, Washington, DC
6480 13. National Bureau of Standards, U.S. Department of Com-
6481 merce, "DES Modes of Operation," Federal Information
6482 Processing Standards Publication 81, Springfield, VA
6485 14. Stuart G. Stubblebine and Virgil D. Gligor, "On Message
6486 Integrity in Cryptographic Protocols," in Proceedings
6487 of the IEEE Symposium on Research in Security and
6488 Privacy, Oakland, California (May 1992).
6490 15. International Organization for Standardization, "ISO
6491 Information Processing Systems - Data Communication -
6492 High-Level Data Link Control Procedure - Frame Struc-
6493 ture," IS 3309 (October 1984). 3rd Edition.
6495 16. R. Rivest, "The MD4 Message Digest Algorithm," RFC
6496 1320, MIT Laboratory for Computer Science (April
6499 17. R. Rivest, "The MD5 Message Digest Algorithm," RFC
6500 1321, MIT Laboratory for Computer Science (April
6503 18. H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed-
6504 Hashing for Message Authentication," Working Draft
6505 draft-ietf-ipsec-hmac-md5-01.txt, (August 1996).
6531 Section 10. - 99 - Expires 11 January 1998
6539 Version 5 - Specification Revision 6
6542 A. Pseudo-code for protocol processing
6544 This appendix provides pseudo-code describing how the
6545 messages are to be constructed and interpreted by clients
6548 A.1. KRB_AS_REQ generation
6549 request.pvno := protocol version; /* pvno = 5 */
6550 request.msg-type := message type; /* type = KRB_AS_REQ */
6552 if(pa_enc_timestamp_required) then
6553 request.padata.padata-type = PA-ENC-TIMESTAMP;
6555 padata-body.patimestamp,pausec = system_time;
6556 encrypt padata-body into request.padata.padata-value
6557 using client.key; /* derived from password */
6560 body.kdc-options := users's preferences;
6561 body.cname := user's name;
6562 body.realm := user's realm;
6563 body.sname := service's name; /* usually "krbtgt", "localrealm" */
6564 if (body.kdc-options.POSTDATED is set) then
6565 body.from := requested starting time;
6569 body.till := requested end time;
6570 if (body.kdc-options.RENEWABLE is set) then
6571 body.rtime := requested final renewal time;
6573 body.nonce := random_nonce();
6574 body.etype := requested etypes;
6575 if (user supplied addresses) then
6576 body.addresses := user's addresses;
6578 omit body.addresses;
6580 omit body.enc-authorization-data;
6581 request.req-body := body;
6583 kerberos := lookup(name of local kerberos server (or servers));
6584 send(packet,kerberos);
6588 retry or use alternate server;
6591 A.2. KRB_AS_REQ verification and KRB_AS_REP generation
6592 decode message into req;
6594 client := lookup(req.cname,req.realm);
6595 server := lookup(req.sname,req.realm);
6598 Section A.2. - 100 - Expires 11 January 1998
6606 Version 5 - Specification Revision 6
6611 kdc_time := system_time.seconds;
6614 /* no client in Database */
6615 error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN);
6618 /* no server in Database */
6619 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
6622 if(client.pa_enc_timestamp_required and
6623 pa_enc_timestamp not present) then
6624 error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP));
6627 if(pa_enc_timestamp present) then
6628 decrypt req.padata-value into decrypted_enc_timestamp
6630 using auth_hdr.authenticator.subkey;
6631 if (decrypt_error()) then
6632 error_out(KRB_AP_ERR_BAD_INTEGRITY);
6633 if(decrypted_enc_timestamp is not within allowable skew) then
6634 error_out(KDC_ERR_PREAUTH_FAILED);
6636 if(decrypted_enc_timestamp and usec is replay)
6637 error_out(KDC_ERR_PREAUTH_FAILED);
6639 add decrypted_enc_timestamp and usec to replay cache;
6642 use_etype := first supported etype in req.etypes;
6644 if (no support for req.etypes) then
6645 error_out(KDC_ERR_ETYPE_NOSUPP);
6648 new_tkt.vno := ticket version; /* = 5 */
6649 new_tkt.sname := req.sname;
6650 new_tkt.srealm := req.srealm;
6651 reset all flags in new_tkt.flags;
6653 /* It should be noted that local policy may affect the */
6654 /* processing of any of these flags. For example, some */
6655 /* realms may refuse to issue renewable tickets */
6657 if (req.kdc-options.FORWARDABLE is set) then
6658 set new_tkt.flags.FORWARDABLE;
6660 if (req.kdc-options.PROXIABLE is set) then
6661 set new_tkt.flags.PROXIABLE;
6665 Section A.2. - 101 - Expires 11 January 1998
6673 Version 5 - Specification Revision 6
6676 if (req.kdc-options.ALLOW-POSTDATE is set) then
6677 set new_tkt.flags.MAY-POSTDATE;
6679 if ((req.kdc-options.RENEW is set) or
6680 (req.kdc-options.VALIDATE is set) or
6681 (req.kdc-options.PROXY is set) or
6682 (req.kdc-options.FORWARDED is set) or
6683 (req.kdc-options.ENC-TKT-IN-SKEY is set)) then
6684 error_out(KDC_ERR_BADOPTION);
6687 new_tkt.session := random_session_key();
6688 new_tkt.cname := req.cname;
6689 new_tkt.crealm := req.crealm;
6690 new_tkt.transited := empty_transited_field();
6692 new_tkt.authtime := kdc_time;
6694 if (req.kdc-options.POSTDATED is set) then
6695 if (against_postdate_policy(req.from)) then
6696 error_out(KDC_ERR_POLICY);
6698 set new_tkt.flags.POSTDATED;
6699 set new_tkt.flags.INVALID;
6700 new_tkt.starttime := req.from;
6702 omit new_tkt.starttime; /* treated as authtime when omitted */
6704 if (req.till = 0) then
6710 new_tkt.endtime := min(till,
6711 new_tkt.starttime+client.max_life,
6712 new_tkt.starttime+server.max_life,
6713 new_tkt.starttime+max_life_for_realm);
6715 if ((req.kdc-options.RENEWABLE-OK is set) and
6716 (new_tkt.endtime < req.till)) then
6717 /* we set the RENEWABLE option for later processing */
6718 set req.kdc-options.RENEWABLE;
6719 req.rtime := req.till;
6722 if (req.rtime = 0) then
6728 if (req.kdc-options.RENEWABLE is set) then
6729 set new_tkt.flags.RENEWABLE;
6732 Section A.2. - 102 - Expires 11 January 1998
6740 Version 5 - Specification Revision 6
6743 new_tkt.renew-till := min(rtime,
6744 new_tkt.starttime+client.max_rlife,
6745 new_tkt.starttime+server.max_rlife,
6746 new_tkt.starttime+max_rlife_for_realm);
6748 omit new_tkt.renew-till; /* only present if RENEWABLE */
6751 if (req.addresses) then
6752 new_tkt.caddr := req.addresses;
6757 new_tkt.authorization_data := empty_authorization_data();
6759 encode to-be-encrypted part of ticket into OCTET STRING;
6760 new_tkt.enc-part := encrypt OCTET STRING
6761 using etype_for_key(server.key), server.key, server.p_kvno;
6764 /* Start processing the response */
6767 resp.msg-type := KRB_AS_REP;
6768 resp.cname := req.cname;
6769 resp.crealm := req.realm;
6770 resp.ticket := new_tkt;
6772 resp.key := new_tkt.session;
6773 resp.last-req := fetch_last_request_info(client);
6774 resp.nonce := req.nonce;
6775 resp.key-expiration := client.expiration;
6776 resp.flags := new_tkt.flags;
6778 resp.authtime := new_tkt.authtime;
6779 resp.starttime := new_tkt.starttime;
6780 resp.endtime := new_tkt.endtime;
6782 if (new_tkt.flags.RENEWABLE) then
6783 resp.renew-till := new_tkt.renew-till;
6786 resp.realm := new_tkt.realm;
6787 resp.sname := new_tkt.sname;
6789 resp.caddr := new_tkt.caddr;
6791 encode body of reply into OCTET STRING;
6793 resp.enc-part := encrypt OCTET STRING
6794 using use_etype, client.key, client.p_kvno;
6799 Section A.2. - 103 - Expires 11 January 1998
6807 Version 5 - Specification Revision 6
6810 A.3. KRB_AS_REP verification
6811 decode response into resp;
6813 if (resp.msg-type = KRB_ERROR) then
6814 if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) then
6815 set pa_enc_timestamp_required;
6818 process_error(resp);
6822 /* On error, discard the response, and zero the session key */
6823 /* from the response immediately */
6825 key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype,
6827 unencrypted part of resp := decode of decrypt of resp.enc-part
6828 using resp.enc-part.etype and key;
6831 if (common_as_rep_tgs_rep_checks fail) then
6836 if near(resp.princ_exp) then
6837 print(warning message);
6839 save_for_later(ticket,session,client,server,times,flags);
6841 A.4. KRB_AS_REP and KRB_TGS_REP common checks
6842 if (decryption_error() or
6843 (req.cname != resp.cname) or
6844 (req.realm != resp.crealm) or
6845 (req.sname != resp.sname) or
6846 (req.realm != resp.realm) or
6847 (req.nonce != resp.nonce) or
6848 (req.addresses != resp.caddr)) then
6850 return KRB_AP_ERR_MODIFIED;
6853 /* make sure no flags are set that shouldn't be, and that all that */
6854 /* should be are set */
6855 if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then
6857 return KRB_AP_ERR_MODIFIED;
6860 if ((req.from = 0) and
6861 (resp.starttime is not within allowable skew)) then
6863 return KRB_AP_ERR_SKEW;
6866 Section A.4. - 104 - Expires 11 January 1998
6874 Version 5 - Specification Revision 6
6878 if ((req.from != 0) and (req.from != resp.starttime)) then
6880 return KRB_AP_ERR_MODIFIED;
6882 if ((req.till != 0) and (resp.endtime > req.till)) then
6884 return KRB_AP_ERR_MODIFIED;
6887 if ((req.kdc-options.RENEWABLE is set) and
6888 (req.rtime != 0) and (resp.renew-till > req.rtime)) then
6890 return KRB_AP_ERR_MODIFIED;
6892 if ((req.kdc-options.RENEWABLE-OK is set) and
6893 (resp.flags.RENEWABLE) and
6895 (resp.renew-till > req.till)) then
6897 return KRB_AP_ERR_MODIFIED;
6900 A.5. KRB_TGS_REQ generation
6901 /* Note that make_application_request might have to recursivly */
6902 /* call this routine to get the appropriate ticket-granting ticket */
6904 request.pvno := protocol version; /* pvno = 5 */
6905 request.msg-type := message type; /* type = KRB_TGS_REQ */
6907 body.kdc-options := users's preferences;
6908 /* If the TGT is not for the realm of the end-server */
6909 /* then the sname will be for a TGT for the end-realm */
6910 /* and the realm of the requested ticket (body.realm) */
6911 /* will be that of the TGS to which the TGT we are */
6912 /* sending applies */
6913 body.sname := service's name;
6914 body.realm := service's realm;
6916 if (body.kdc-options.POSTDATED is set) then
6917 body.from := requested starting time;
6921 body.till := requested end time;
6922 if (body.kdc-options.RENEWABLE is set) then
6923 body.rtime := requested final renewal time;
6925 body.nonce := random_nonce();
6926 body.etype := requested etypes;
6927 if (user supplied addresses) then
6928 body.addresses := user's addresses;
6930 omit body.addresses;
6933 Section A.5. - 105 - Expires 11 January 1998
6941 Version 5 - Specification Revision 6
6946 body.enc-authorization-data := user-supplied data;
6947 if (body.kdc-options.ENC-TKT-IN-SKEY) then
6948 body.additional-tickets_ticket := second TGT;
6951 request.req-body := body;
6952 check := generate_checksum (req.body,checksumtype);
6954 request.padata[0].padata-type := PA-TGS-REQ;
6955 request.padata[0].padata-value := create a KRB_AP_REQ using
6956 the TGT and checksum
6958 /* add in any other padata as required/supplied */
6960 kerberos := lookup(name of local kerberose server (or servers));
6961 send(packet,kerberos);
6965 retry or use alternate server;
6968 A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation
6969 /* note that reading the application request requires first
6970 determining the server for which a ticket was issued, and choosing the
6971 correct key for decryption. The name of the server appears in the
6972 plaintext part of the ticket. */
6974 if (no KRB_AP_REQ in req.padata) then
6975 error_out(KDC_ERR_PADATA_TYPE_NOSUPP);
6977 verify KRB_AP_REQ in req.padata;
6979 /* Note that the realm in which the Kerberos server is operating is
6980 determined by the instance from the ticket-granting ticket. The realm
6981 in the ticket-granting ticket is the realm under which the ticket
6982 granting ticket was issued. It is possible for a single Kerberos
6983 server to support more than one realm. */
6985 auth_hdr := KRB_AP_REQ;
6986 tgt := auth_hdr.ticket;
6988 if (tgt.sname is not a TGT for local realm and is not req.sname) then
6989 error_out(KRB_AP_ERR_NOT_US);
6991 realm := realm_tgt_is_for(tgt);
6993 decode remainder of request;
6995 if (auth_hdr.authenticator.cksum is missing) then
6996 error_out(KRB_AP_ERR_INAPP_CKSUM);
7000 Section A.6. - 106 - Expires 11 January 1998
7008 Version 5 - Specification Revision 6
7011 if (auth_hdr.authenticator.cksum type is not supported) then
7012 error_out(KDC_ERR_SUMTYPE_NOSUPP);
7014 if (auth_hdr.authenticator.cksum is not both collision-proof and keyed) then
7015 error_out(KRB_AP_ERR_INAPP_CKSUM);
7018 set computed_checksum := checksum(req);
7019 if (computed_checksum != auth_hdr.authenticatory.cksum) then
7020 error_out(KRB_AP_ERR_MODIFIED);
7023 server := lookup(req.sname,realm);
7026 if (is_foreign_tgt_name(server)) then
7027 server := best_intermediate_tgs(server);
7029 /* no server in Database */
7030 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
7034 session := generate_random_session_key();
7037 use_etype := first supported etype in req.etypes;
7039 if (no support for req.etypes) then
7040 error_out(KDC_ERR_ETYPE_NOSUPP);
7043 new_tkt.vno := ticket version; /* = 5 */
7044 new_tkt.sname := req.sname;
7045 new_tkt.srealm := realm;
7046 reset all flags in new_tkt.flags;
7048 /* It should be noted that local policy may affect the */
7049 /* processing of any of these flags. For example, some */
7050 /* realms may refuse to issue renewable tickets */
7052 new_tkt.caddr := tgt.caddr;
7053 resp.caddr := NULL; /* We only include this if they change */
7054 if (req.kdc-options.FORWARDABLE is set) then
7055 if (tgt.flags.FORWARDABLE is reset) then
7056 error_out(KDC_ERR_BADOPTION);
7058 set new_tkt.flags.FORWARDABLE;
7060 if (req.kdc-options.FORWARDED is set) then
7061 if (tgt.flags.FORWARDABLE is reset) then
7062 error_out(KDC_ERR_BADOPTION);
7064 set new_tkt.flags.FORWARDED;
7067 Section A.6. - 107 - Expires 11 January 1998
7075 Version 5 - Specification Revision 6
7078 new_tkt.caddr := req.addresses;
7079 resp.caddr := req.addresses;
7081 if (tgt.flags.FORWARDED is set) then
7082 set new_tkt.flags.FORWARDED;
7085 if (req.kdc-options.PROXIABLE is set) then
7086 if (tgt.flags.PROXIABLE is reset)
7087 error_out(KDC_ERR_BADOPTION);
7089 set new_tkt.flags.PROXIABLE;
7091 if (req.kdc-options.PROXY is set) then
7092 if (tgt.flags.PROXIABLE is reset) then
7093 error_out(KDC_ERR_BADOPTION);
7095 set new_tkt.flags.PROXY;
7096 new_tkt.caddr := req.addresses;
7097 resp.caddr := req.addresses;
7100 if (req.kdc-options.ALLOW-POSTDATE is set) then
7101 if (tgt.flags.MAY-POSTDATE is reset)
7102 error_out(KDC_ERR_BADOPTION);
7104 set new_tkt.flags.MAY-POSTDATE;
7106 if (req.kdc-options.POSTDATED is set) then
7107 if (tgt.flags.MAY-POSTDATE is reset) then
7108 error_out(KDC_ERR_BADOPTION);
7110 set new_tkt.flags.POSTDATED;
7111 set new_tkt.flags.INVALID;
7112 if (against_postdate_policy(req.from)) then
7113 error_out(KDC_ERR_POLICY);
7115 new_tkt.starttime := req.from;
7119 if (req.kdc-options.VALIDATE is set) then
7120 if (tgt.flags.INVALID is reset) then
7121 error_out(KDC_ERR_POLICY);
7123 if (tgt.starttime > kdc_time) then
7124 error_out(KRB_AP_ERR_NYV);
7126 if (check_hot_list(tgt)) then
7127 error_out(KRB_AP_ERR_REPEAT);
7130 reset new_tkt.flags.INVALID;
7134 Section A.6. - 108 - Expires 11 January 1998
7142 Version 5 - Specification Revision 6
7145 if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW,
7146 and those already processed) is set) then
7147 error_out(KDC_ERR_BADOPTION);
7150 new_tkt.authtime := tgt.authtime;
7152 if (req.kdc-options.RENEW is set) then
7153 /* Note that if the endtime has already passed, the ticket would */
7154 /* have been rejected in the initial authentication stage, so */
7155 /* there is no need to check again here */
7156 if (tgt.flags.RENEWABLE is reset) then
7157 error_out(KDC_ERR_BADOPTION);
7159 if (tgt.renew-till >= kdc_time) then
7160 error_out(KRB_AP_ERR_TKT_EXPIRED);
7163 new_tkt.starttime := kdc_time;
7164 old_life := tgt.endttime - tgt.starttime;
7165 new_tkt.endtime := min(tgt.renew-till,
7166 new_tkt.starttime + old_life);
7168 new_tkt.starttime := kdc_time;
7169 if (req.till = 0) then
7174 new_tkt.endtime := min(till,
7175 new_tkt.starttime+client.max_life,
7176 new_tkt.starttime+server.max_life,
7177 new_tkt.starttime+max_life_for_realm,
7180 if ((req.kdc-options.RENEWABLE-OK is set) and
7181 (new_tkt.endtime < req.till) and
7182 (tgt.flags.RENEWABLE is set) then
7183 /* we set the RENEWABLE option for later processing */
7184 set req.kdc-options.RENEWABLE;
7185 req.rtime := min(req.till, tgt.renew-till);
7189 if (req.rtime = 0) then
7195 if ((req.kdc-options.RENEWABLE is set) and
7196 (tgt.flags.RENEWABLE is set)) then
7197 set new_tkt.flags.RENEWABLE;
7198 new_tkt.renew-till := min(rtime,
7201 Section A.6. - 109 - Expires 11 January 1998
7209 Version 5 - Specification Revision 6
7212 new_tkt.starttime+client.max_rlife,
7213 new_tkt.starttime+server.max_rlife,
7214 new_tkt.starttime+max_rlife_for_realm,
7217 new_tkt.renew-till := OMIT; /* leave the renew-till field out */
7219 if (req.enc-authorization-data is present) then
7220 decrypt req.enc-authorization-data into decrypted_authorization_data
7221 using auth_hdr.authenticator.subkey;
7222 if (decrypt_error()) then
7223 error_out(KRB_AP_ERR_BAD_INTEGRITY);
7226 new_tkt.authorization_data := req.auth_hdr.ticket.authorization_data +
7227 decrypted_authorization_data;
7229 new_tkt.key := session;
7230 new_tkt.crealm := tgt.crealm;
7231 new_tkt.cname := req.auth_hdr.ticket.cname;
7233 if (realm_tgt_is_for(tgt) := tgt.realm) then
7234 /* tgt issued by local realm */
7235 new_tkt.transited := tgt.transited;
7237 /* was issued for this realm by some other realm */
7238 if (tgt.transited.tr-type not supported) then
7239 error_out(KDC_ERR_TRTYPE_NOSUPP);
7241 new_tkt.transited := compress_transited(tgt.transited + tgt.realm)
7244 encode encrypted part of new_tkt into OCTET STRING;
7245 if (req.kdc-options.ENC-TKT-IN-SKEY is set) then
7246 if (server not specified) then
7247 server = req.second_ticket.client;
7249 if ((req.second_ticket is not a TGT) or
7250 (req.second_ticket.client != server)) then
7251 error_out(KDC_ERR_POLICY);
7254 new_tkt.enc-part := encrypt OCTET STRING using
7255 using etype_for_key(second-ticket.key), second-ticket.key;
7257 new_tkt.enc-part := encrypt OCTET STRING
7258 using etype_for_key(server.key), server.key, server.p_kvno;
7262 resp.msg-type := KRB_TGS_REP;
7263 resp.crealm := tgt.crealm;
7264 resp.cname := tgt.cname;
7268 Section A.6. - 110 - Expires 11 January 1998
7276 Version 5 - Specification Revision 6
7279 resp.ticket := new_tkt;
7281 resp.key := session;
7282 resp.nonce := req.nonce;
7283 resp.last-req := fetch_last_request_info(client);
7284 resp.flags := new_tkt.flags;
7286 resp.authtime := new_tkt.authtime;
7287 resp.starttime := new_tkt.starttime;
7288 resp.endtime := new_tkt.endtime;
7290 omit resp.key-expiration;
7292 resp.sname := new_tkt.sname;
7293 resp.realm := new_tkt.realm;
7295 if (new_tkt.flags.RENEWABLE) then
7296 resp.renew-till := new_tkt.renew-till;
7300 encode body of reply into OCTET STRING;
7302 if (req.padata.authenticator.subkey)
7303 resp.enc-part := encrypt OCTET STRING using use_etype,
7304 req.padata.authenticator.subkey;
7305 else resp.enc-part := encrypt OCTET STRING using use_etype, tgt.key;
7309 A.7. KRB_TGS_REP verification
7310 decode response into resp;
7312 if (resp.msg-type = KRB_ERROR) then
7313 process_error(resp);
7317 /* On error, discard the response, and zero the session key from
7318 the response immediately */
7320 if (req.padata.authenticator.subkey)
7321 unencrypted part of resp := decode of decrypt of resp.enc-part
7322 using resp.enc-part.etype and subkey;
7323 else unencrypted part of resp := decode of decrypt of resp.enc-part
7324 using resp.enc-part.etype and tgt's session key;
7325 if (common_as_rep_tgs_rep_checks fail) then
7330 check authorization_data as necessary;
7331 save_for_later(ticket,session,client,server,times,flags);
7335 Section A.7. - 111 - Expires 11 January 1998
7343 Version 5 - Specification Revision 6
7346 A.8. Authenticator generation
7347 body.authenticator-vno := authenticator vno; /* = 5 */
7348 body.cname, body.crealm := client name;
7349 if (supplying checksum) then
7350 body.cksum := checksum;
7353 body.ctime, body.cusec := system_time;
7354 if (selecting sub-session key) then
7355 select sub-session key;
7356 body.subkey := sub-session key;
7358 if (using sequence numbers) then
7359 select initial sequence number;
7360 body.seq-number := initial sequence;
7363 A.9. KRB_AP_REQ generation
7364 obtain ticket and session_key from cache;
7366 packet.pvno := protocol version; /* 5 */
7367 packet.msg-type := message type; /* KRB_AP_REQ */
7369 if (desired(MUTUAL_AUTHENTICATION)) then
7370 set packet.ap-options.MUTUAL-REQUIRED;
7372 reset packet.ap-options.MUTUAL-REQUIRED;
7374 if (using session key for ticket) then
7375 set packet.ap-options.USE-SESSION-KEY;
7377 reset packet.ap-options.USE-SESSION-KEY;
7379 packet.ticket := ticket; /* ticket */
7380 generate authenticator;
7381 encode authenticator into OCTET STRING;
7382 encrypt OCTET STRING into packet.authenticator using session_key;
7384 A.10. KRB_AP_REQ verification
7386 if (packet.pvno != 5) then
7387 either process using other protocol spec
7388 or error_out(KRB_AP_ERR_BADVERSION);
7390 if (packet.msg-type != KRB_AP_REQ) then
7391 error_out(KRB_AP_ERR_MSG_TYPE);
7393 if (packet.ticket.tkt_vno != 5) then
7394 either process using other protocol spec
7395 or error_out(KRB_AP_ERR_BADVERSION);
7397 if (packet.ap_options.USE-SESSION-KEY is set) then
7398 retrieve session key from ticket-granting ticket for
7399 packet.ticket.{sname,srealm,enc-part.etype};
7402 Section A.10. - 112 - Expires 11 January 1998
7410 Version 5 - Specification Revision 6
7414 retrieve service key for
7415 packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno};
7417 if (no_key_available) then
7418 if (cannot_find_specified_skvno) then
7419 error_out(KRB_AP_ERR_BADKEYVER);
7421 error_out(KRB_AP_ERR_NOKEY);
7424 decrypt packet.ticket.enc-part into decr_ticket using retrieved key;
7425 if (decryption_error()) then
7426 error_out(KRB_AP_ERR_BAD_INTEGRITY);
7428 decrypt packet.authenticator into decr_authenticator
7429 using decr_ticket.key;
7430 if (decryption_error()) then
7431 error_out(KRB_AP_ERR_BAD_INTEGRITY);
7433 if (decr_authenticator.{cname,crealm} !=
7434 decr_ticket.{cname,crealm}) then
7435 error_out(KRB_AP_ERR_BADMATCH);
7437 if (decr_ticket.caddr is present) then
7438 if (sender_address(packet) is not in decr_ticket.caddr) then
7439 error_out(KRB_AP_ERR_BADADDR);
7441 elseif (application requires addresses) then
7442 error_out(KRB_AP_ERR_BADADDR);
7444 if (not in_clock_skew(decr_authenticator.ctime,
7445 decr_authenticator.cusec)) then
7446 error_out(KRB_AP_ERR_SKEW);
7448 if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then
7449 error_out(KRB_AP_ERR_REPEAT);
7451 save_identifier(decr_authenticator.{ctime,cusec,cname,crealm});
7453 if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or
7454 (decr_ticket.flags.INVALID is set)) then
7455 /* it hasn't yet become valid */
7456 error_out(KRB_AP_ERR_TKT_NYV);
7458 if (system_time-decr_ticket.endtime > CLOCK_SKEW) then
7459 error_out(KRB_AP_ERR_TKT_EXPIRED);
7461 /* caller must check decr_ticket.flags for any pertinent details */
7462 return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED);
7464 A.11. KRB_AP_REP generation
7465 packet.pvno := protocol version; /* 5 */
7466 packet.msg-type := message type; /* KRB_AP_REP */
7469 Section A.11. - 113 - Expires 11 January 1998
7477 Version 5 - Specification Revision 6
7480 body.ctime := packet.ctime;
7481 body.cusec := packet.cusec;
7482 if (selecting sub-session key) then
7483 select sub-session key;
7484 body.subkey := sub-session key;
7486 if (using sequence numbers) then
7487 select initial sequence number;
7488 body.seq-number := initial sequence;
7491 encode body into OCTET STRING;
7493 select encryption type;
7494 encrypt OCTET STRING into packet.enc-part;
7496 A.12. KRB_AP_REP verification
7498 if (packet.pvno != 5) then
7499 either process using other protocol spec
7500 or error_out(KRB_AP_ERR_BADVERSION);
7502 if (packet.msg-type != KRB_AP_REP) then
7503 error_out(KRB_AP_ERR_MSG_TYPE);
7505 cleartext := decrypt(packet.enc-part) using ticket's session key;
7506 if (decryption_error()) then
7507 error_out(KRB_AP_ERR_BAD_INTEGRITY);
7509 if (cleartext.ctime != authenticator.ctime) then
7510 error_out(KRB_AP_ERR_MUT_FAIL);
7512 if (cleartext.cusec != authenticator.cusec) then
7513 error_out(KRB_AP_ERR_MUT_FAIL);
7515 if (cleartext.subkey is present) then
7516 save cleartext.subkey for future use;
7518 if (cleartext.seq-number is present) then
7519 save cleartext.seq-number for future verifications;
7521 return(AUTHENTICATION_SUCCEEDED);
7523 A.13. KRB_SAFE generation
7524 collect user data in buffer;
7526 /* assemble packet: */
7527 packet.pvno := protocol version; /* 5 */
7528 packet.msg-type := message type; /* KRB_SAFE */
7530 body.user-data := buffer; /* DATA */
7531 if (using timestamp) then
7533 body.timestamp, body.usec := system_time;
7536 Section A.13. - 114 - Expires 11 January 1998
7544 Version 5 - Specification Revision 6
7548 if (using sequence numbers) then
7549 body.seq-number := sequence number;
7551 body.s-address := sender host addresses;
7552 if (only one recipient) then
7553 body.r-address := recipient host address;
7555 checksum.cksumtype := checksum type;
7556 compute checksum over body;
7557 checksum.checksum := checksum value; /* checksum.checksum */
7558 packet.cksum := checksum;
7559 packet.safe-body := body;
7561 A.14. KRB_SAFE verification
7563 if (packet.pvno != 5) then
7564 either process using other protocol spec
7565 or error_out(KRB_AP_ERR_BADVERSION);
7567 if (packet.msg-type != KRB_SAFE) then
7568 error_out(KRB_AP_ERR_MSG_TYPE);
7570 if (packet.checksum.cksumtype is not both collision-proof and keyed) then
7571 error_out(KRB_AP_ERR_INAPP_CKSUM);
7573 if (safe_priv_common_checks_ok(packet)) then
7574 set computed_checksum := checksum(packet.body);
7575 if (computed_checksum != packet.checksum) then
7576 error_out(KRB_AP_ERR_MODIFIED);
7578 return (packet, PACKET_IS_GENUINE);
7580 return common_checks_error;
7583 A.15. KRB_SAFE and KRB_PRIV common checks
7584 if (packet.s-address != O/S_sender(packet)) then
7585 /* O/S report of sender not who claims to have sent it */
7586 error_out(KRB_AP_ERR_BADADDR);
7588 if ((packet.r-address is present) and
7589 (packet.r-address != local_host_address)) then
7590 /* was not sent to proper place */
7591 error_out(KRB_AP_ERR_BADADDR);
7593 if (((packet.timestamp is present) and
7594 (not in_clock_skew(packet.timestamp,packet.usec))) or
7595 (packet.timestamp is not present and timestamp expected)) then
7596 error_out(KRB_AP_ERR_SKEW);
7598 if (repeated(packet.timestamp,packet.usec,packet.s-address)) then
7599 error_out(KRB_AP_ERR_REPEAT);
7603 Section A.15. - 115 - Expires 11 January 1998
7611 Version 5 - Specification Revision 6
7614 if (((packet.seq-number is present) and
7615 ((not in_sequence(packet.seq-number)))) or
7616 (packet.seq-number is not present and sequence expected)) then
7617 error_out(KRB_AP_ERR_BADORDER);
7619 if (packet.timestamp not present and packet.seq-number not present) then
7620 error_out(KRB_AP_ERR_MODIFIED);
7623 save_identifier(packet.{timestamp,usec,s-address},
7624 sender_principal(packet));
7626 return PACKET_IS_OK;
7628 A.16. KRB_PRIV generation
7629 collect user data in buffer;
7631 /* assemble packet: */
7632 packet.pvno := protocol version; /* 5 */
7633 packet.msg-type := message type; /* KRB_PRIV */
7635 packet.enc-part.etype := encryption type;
7637 body.user-data := buffer;
7638 if (using timestamp) then
7640 body.timestamp, body.usec := system_time;
7642 if (using sequence numbers) then
7643 body.seq-number := sequence number;
7645 body.s-address := sender host addresses;
7646 if (only one recipient) then
7647 body.r-address := recipient host address;
7650 encode body into OCTET STRING;
7652 select encryption type;
7653 encrypt OCTET STRING into packet.enc-part.cipher;
7656 A.17. KRB_PRIV verification
7658 if (packet.pvno != 5) then
7659 either process using other protocol spec
7660 or error_out(KRB_AP_ERR_BADVERSION);
7662 if (packet.msg-type != KRB_PRIV) then
7663 error_out(KRB_AP_ERR_MSG_TYPE);
7666 cleartext := decrypt(packet.enc-part) using negotiated key;
7667 if (decryption_error()) then
7670 Section A.17. - 116 - Expires 11 January 1998
7678 Version 5 - Specification Revision 6
7681 error_out(KRB_AP_ERR_BAD_INTEGRITY);
7684 if (safe_priv_common_checks_ok(cleartext)) then
7685 return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED);
7687 return common_checks_error;
7690 A.18. KRB_CRED generation
7691 invoke KRB_TGS; /* obtain tickets to be provided to peer */
7693 /* assemble packet: */
7694 packet.pvno := protocol version; /* 5 */
7695 packet.msg-type := message type; /* KRB_CRED */
7697 for (tickets[n] in tickets to be forwarded) do
7698 packet.tickets[n] = tickets[n].ticket;
7701 packet.enc-part.etype := encryption type;
7703 for (ticket[n] in tickets to be forwarded) do
7704 body.ticket-info[n].key = tickets[n].session;
7705 body.ticket-info[n].prealm = tickets[n].crealm;
7706 body.ticket-info[n].pname = tickets[n].cname;
7707 body.ticket-info[n].flags = tickets[n].flags;
7708 body.ticket-info[n].authtime = tickets[n].authtime;
7709 body.ticket-info[n].starttime = tickets[n].starttime;
7710 body.ticket-info[n].endtime = tickets[n].endtime;
7711 body.ticket-info[n].renew-till = tickets[n].renew-till;
7712 body.ticket-info[n].srealm = tickets[n].srealm;
7713 body.ticket-info[n].sname = tickets[n].sname;
7714 body.ticket-info[n].caddr = tickets[n].caddr;
7718 body.timestamp, body.usec := system_time;
7720 if (using nonce) then
7721 body.nonce := nonce;
7724 if (using s-address) then
7725 body.s-address := sender host addresses;
7727 if (limited recipients) then
7728 body.r-address := recipient host address;
7731 encode body into OCTET STRING;
7733 select encryption type;
7734 encrypt OCTET STRING into packet.enc-part.cipher
7737 Section A.18. - 117 - Expires 11 January 1998
7745 Version 5 - Specification Revision 6
7748 using negotiated encryption key;
7751 A.19. KRB_CRED verification
7753 if (packet.pvno != 5) then
7754 either process using other protocol spec
7755 or error_out(KRB_AP_ERR_BADVERSION);
7757 if (packet.msg-type != KRB_CRED) then
7758 error_out(KRB_AP_ERR_MSG_TYPE);
7761 cleartext := decrypt(packet.enc-part) using negotiated key;
7762 if (decryption_error()) then
7763 error_out(KRB_AP_ERR_BAD_INTEGRITY);
7765 if ((packet.r-address is present or required) and
7766 (packet.s-address != O/S_sender(packet)) then
7767 /* O/S report of sender not who claims to have sent it */
7768 error_out(KRB_AP_ERR_BADADDR);
7770 if ((packet.r-address is present) and
7771 (packet.r-address != local_host_address)) then
7772 /* was not sent to proper place */
7773 error_out(KRB_AP_ERR_BADADDR);
7775 if (not in_clock_skew(packet.timestamp,packet.usec)) then
7776 error_out(KRB_AP_ERR_SKEW);
7778 if (repeated(packet.timestamp,packet.usec,packet.s-address)) then
7779 error_out(KRB_AP_ERR_REPEAT);
7781 if (packet.nonce is required or present) and
7782 (packet.nonce != expected-nonce) then
7783 error_out(KRB_AP_ERR_MODIFIED);
7786 for (ticket[n] in tickets that were forwarded) do
7787 save_for_later(ticket[n],key[n],principal[n],
7788 server[n],times[n],flags[n]);
7791 A.20. KRB_ERROR generation
7793 /* assemble packet: */
7794 packet.pvno := protocol version; /* 5 */
7795 packet.msg-type := message type; /* KRB_ERROR */
7798 packet.stime, packet.susec := system_time;
7799 packet.realm, packet.sname := server name;
7801 if (client time available) then
7804 Section A.20. - 118 - Expires 11 January 1998
7812 Version 5 - Specification Revision 6
7815 packet.ctime, packet.cusec := client_time;
7817 packet.error-code := error code;
7818 if (client name available) then
7819 packet.cname, packet.crealm := client name;
7821 if (error text available) then
7822 packet.e-text := error text;
7824 if (error data available) then
7825 packet.e-data := error data;
7871 - 119 - Expires 11 January 1998
7879 Version 5 - Specification Revision 6
7938 - cxx - Expires 11 January 1998
7954 Overview .............................................. 2
7956 Background ............................................ 2
7958 1. Introduction ....................................... 3
7960 1.1. Cross-Realm Operation ............................ 5
7962 1.2. Authorization .................................... 6
7964 1.3. Environmental assumptions ........................ 7
7966 1.4. Glossary of terms ................................ 8
7968 2. Ticket flag uses and requests ...................... 10
7970 2.1. Initial and pre-authenticated tickets ............ 10
7972 2.2. Invalid tickets .................................. 11
7974 2.3. Renewable tickets ................................ 11
7976 2.4. Postdated tickets ................................ 12
7978 2.5. Proxiable and proxy tickets ...................... 12
7980 2.6. Forwardable tickets .............................. 13
7982 2.7. Other KDC options ................................ 14
7984 3. Message Exchanges .................................. 14
7986 3.1. The Authentication Service Exchange .............. 14
7988 3.1.1. Generation of KRB_AS_REQ message ............... 16
7990 3.1.2. Receipt of KRB_AS_REQ message .................. 16
7992 3.1.3. Generation of KRB_AS_REP message ............... 16
7994 3.1.4. Generation of KRB_ERROR message ................ 19
7996 3.1.5. Receipt of KRB_AS_REP message .................. 19
7998 3.1.6. Receipt of KRB_ERROR message ................... 19
8000 3.2. The Client/Server Authentication Exchange ........ 19
8002 3.2.1. The KRB_AP_REQ message ......................... 20
8005 - i - Expires 11 January 1998
8013 Version 5 - Specification Revision 6
8016 3.2.2. Generation of a KRB_AP_REQ message ............. 20
8018 3.2.3. Receipt of KRB_AP_REQ message .................. 21
8020 3.2.4. Generation of a KRB_AP_REP message ............. 23
8022 3.2.5. Receipt of KRB_AP_REP message .................. 23
8024 3.2.6. Using the encryption key ....................... 24
8026 3.3. The Ticket-Granting Service (TGS) Exchange ....... 25
8028 3.3.1. Generation of KRB_TGS_REQ message .............. 26
8030 3.3.2. Receipt of KRB_TGS_REQ message ................. 27
8032 3.3.3. Generation of KRB_TGS_REP message .............. 28
8034 3.3.3.1. Checking for revoked tickets ................. 30
8036 3.3.3.2. Encoding the transited field ................. 30
8038 3.3.4. Receipt of KRB_TGS_REP message ................. 32
8040 3.4. The KRB_SAFE Exchange ............................ 32
8042 3.4.1. Generation of a KRB_SAFE message ............... 32
8044 3.4.2. Receipt of KRB_SAFE message .................... 33
8046 3.5. The KRB_PRIV Exchange ............................ 34
8048 3.5.1. Generation of a KRB_PRIV message ............... 34
8050 3.5.2. Receipt of KRB_PRIV message .................... 34
8052 3.6. The KRB_CRED Exchange ............................ 35
8054 3.6.1. Generation of a KRB_CRED message ............... 35
8056 3.6.2. Receipt of KRB_CRED message .................... 35
8058 4. The Kerberos Database .............................. 36
8060 4.1. Database contents ................................ 36
8062 4.2. Additional fields ................................ 37
8064 4.3. Frequently Changing Fields ....................... 38
8066 4.4. Site Constants ................................... 39
8068 5. Message Specifications ............................. 39
8072 - ii - Expires 11 January 1998
8080 Version 5 - Specification Revision 6
8083 5.1. ASN.1 Distinguished Encoding Representation ...... 39
8085 5.2. ASN.1 Base Definitions ........................... 40
8087 5.3. Tickets and Authenticators ....................... 43
8089 5.3.1. Tickets ........................................ 43
8091 5.3.2. Authenticators ................................. 52
8093 5.4. Specifications for the AS and TGS exchanges ...... 54
8095 5.4.1. KRB_KDC_REQ definition ......................... 54
8097 5.4.2. KRB_KDC_REP definition ......................... 61
8099 5.5. Client/Server (CS) message specifications ........ 64
8101 5.5.1. KRB_AP_REQ definition .......................... 64
8103 5.5.2. KRB_AP_REP definition .......................... 65
8105 5.5.3. Error message reply ............................ 67
8107 5.6. KRB_SAFE message specification ................... 67
8109 5.6.1. KRB_SAFE definition ............................ 67
8111 5.7. KRB_PRIV message specification ................... 68
8113 5.7.1. KRB_PRIV definition ............................ 68
8115 5.8. KRB_CRED message specification ................... 69
8117 5.8.1. KRB_CRED definition ............................ 70
8119 5.9. Error message specification ...................... 72
8121 5.9.1. KRB_ERROR definition ........................... 72
8123 6. Encryption and Checksum Specifications ............. 74
8125 6.1. Encryption Specifications ........................ 76
8127 6.2. Encryption Keys .................................. 78
8129 6.3. Encryption Systems ............................... 78
8131 6.3.1. The NULL Encryption System (null) .............. 78
8133 6.3.2. DES in CBC mode with a CRC-32 checksum (des-
8134 cbc-crc) .............................................. 79
8136 6.3.3. DES in CBC mode with an MD4 checksum (des-
8139 - iii - Expires 11 January 1998
8147 Version 5 - Specification Revision 6
8150 cbc-md4) .............................................. 79
8152 6.3.4. DES in CBC mode with an MD5 checksum (des-
8153 cbc-md5) .............................................. 79
8155 6.3.5. Triple DES EDE in outer CBC mode with an SHA1
8156 checksum (des3-cbc-sha1) .............................. 81
8158 6.4. Checksums ........................................ 83
8160 6.4.1. The CRC-32 Checksum (crc32) .................... 84
8162 6.4.2. The RSA MD4 Checksum (rsa-md4) ................. 84
8164 6.4.3. RSA MD4 Cryptographic Checksum Using DES
8165 (rsa-md4-des) ......................................... 84
8167 6.4.4. The RSA MD5 Checksum (rsa-md5) ................. 85
8169 6.4.5. RSA MD5 Cryptographic Checksum Using DES
8170 (rsa-md5-des) ......................................... 85
8172 6.4.6. DES cipher-block chained checksum (des-mac)
8174 6.4.7. RSA MD4 Cryptographic Checksum Using DES
8175 alternative (rsa-md4-des-k) ........................... 86
8177 6.4.8. DES cipher-block chained checksum alternative
8178 (des-mac-k) ........................................... 87
8180 7. Naming Constraints ................................. 87
8182 7.1. Realm Names ...................................... 87
8184 7.2. Principal Names .................................. 88
8186 7.2.1. Name of server principals ...................... 89
8188 8. Constants and other defined values ................. 90
8190 8.1. Host address types ............................... 90
8192 8.2. KDC messages ..................................... 91
8194 8.2.1. IP transport ................................... 91
8196 8.2.2. OSI transport .................................. 91
8198 8.2.3. Name of the TGS ................................ 92
8200 8.3. Protocol constants and associated values ......... 92
8202 9. Interoperability requirements ...................... 95
8206 - iv - Expires 11 January 1998
8214 Version 5 - Specification Revision 6
8217 9.1. Specification 1 .................................. 95
8219 9.2. Recommended KDC values ........................... 97
8221 10. REFERENCES ........................................ 98
8223 A. Pseudo-code for protocol processing ................ 100
8225 A.1. KRB_AS_REQ generation ............................ 100
8227 A.2. KRB_AS_REQ verification and KRB_AS_REP genera-
8228 tion .................................................. 100
8230 A.3. KRB_AS_REP verification .......................... 104
8232 A.4. KRB_AS_REP and KRB_TGS_REP common checks ......... 104
8234 A.5. KRB_TGS_REQ generation ........................... 105
8236 A.6. KRB_TGS_REQ verification and KRB_TGS_REP gen-
8237 eration ............................................... 106
8239 A.7. KRB_TGS_REP verification ......................... 111
8241 A.8. Authenticator generation ......................... 112
8243 A.9. KRB_AP_REQ generation ............................ 112
8245 A.10. KRB_AP_REQ verification ......................... 112
8247 A.11. KRB_AP_REP generation ........................... 113
8249 A.12. KRB_AP_REP verification ......................... 114
8251 A.13. KRB_SAFE generation ............................. 114
8253 A.14. KRB_SAFE verification ........................... 115
8255 A.15. KRB_SAFE and KRB_PRIV common checks ............. 115
8257 A.16. KRB_PRIV generation ............................. 116
8259 A.17. KRB_PRIV verification ........................... 116
8261 A.18. KRB_CRED generation ............................. 117
8263 A.19. KRB_CRED verification ........................... 118
8265 A.20. KRB_ERROR generation ............................ 118
8273 - v - Expires 11 January 1998
tuxillo's projects / dragonfly.git / blob