1 INTERNET-DRAFT Clifford Neuman
5 Expires December 25, 1999
6 draft-ietf-cat-kerberos-revisions-04.txt
8 The Kerberos Network Authentication Service (V5)
12 This document is an Internet-Draft and is in full conformance with all
13 provisions of Section 10 of RFC2026. Internet-Drafts are working documents
14 of the Internet Engineering Task Force (IETF), its areas, and its working
15 groups. Note that other groups may also distribute working documents as
18 Internet-Drafts are draft documents valid for a maximum of six months and
19 may be updated, replaced, or obsoleted by other documents at any time. It is
20 inappropriate to use Internet- Drafts as reference material or to cite them
21 other than as "work in progress."
23 The list of current Internet-Drafts can be accessed at
24 http://www.ietf.org/ietf/1id-abstracts.txt
26 The list of Internet-Draft Shadow Directories can be accessed at
27 http://www.ietf.org/shadow.html. To learn the current status of any
28 Internet-Draft, please check the '1id-abstracts.txt' listing contained in
29 the Internet-Drafts Shadow Directories.
31 The distribution of this memo is unlimited. It is filed as
32 draft-ietf-cat-kerberos-revisions-04.txt, and expires December 25th, 1999.
33 Please send comments to: krb-protocol@MIT.EDU
37 This document provides an overview and specification of Version 5 of the
38 Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol
39 and its intended use that require more detailed or clearer explanation than
40 was provided in RFC1510. This document is intended to provide a detailed
41 description of the protocol, suitable for implementation, together with
42 descriptions of the appropriate use of protocol messages and fields within
45 This document is not intended to describe Kerberos to the end user, system
46 administrator, or application developer. Higher level papers describing
47 Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88],
48 are available elsewhere.
52 This INTERNET-DRAFT describes the concepts and model upon which the Kerberos
53 network authentication system is based. It also specifies Version 5 of the
56 Neuman, Ts'o, Kohl Expires: 25 December,
59 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
62 The motivations, goals, assumptions, and rationale behind most design
63 decisions are treated cursorily; they are more fully described in a paper
64 available in IEEE communications [NT94] and earlier in the Kerberos portion
65 of the Athena Technical Plan [MNSS87]. The protocols have been a proposed
66 standard and are being considered for advancement for draft standard through
67 the IETF standard process. Comments are encouraged on the presentation, but
68 only minor refinements to the protocol as implemented or extensions that fit
69 within current protocol framework will be considered at this time.
71 Requests for addition to an electronic mailing list for discussion of
72 Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-request@MIT.EDU.
73 This mailing list is gatewayed onto the Usenet as the group
74 comp.protocols.kerberos. Requests for further information, including
75 documents and code availability, may be sent to info-kerberos@MIT.EDU.
79 The Kerberos model is based in part on Needham and Schroeder's trusted
80 third-party authentication protocol [NS78] and on modifications suggested by
81 Denning and Sacco [DS81]. The original design and implementation of Kerberos
82 Versions 1 through 4 was the work of two former Project Athena staff
83 members, Steve Miller of Digital Equipment Corporation and Clifford Neuman
84 (now at the Information Sciences Institute of the University of Southern
85 California), along with Jerome Saltzer, Technical Director of Project
86 Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other members
87 of Project Athena have also contributed to the work on Kerberos.
89 Version 5 of the Kerberos protocol (described in this document) has evolved
90 from Version 4 based on new requirements and desires for features not
91 available in Version 4. The design of Version 5 of the Kerberos protocol was
92 led by Clifford Neuman and John Kohl with much input from the community. The
93 development of the MIT reference implementation was led at MIT by John Kohl
94 and Theodore T'so, with help and contributed code from many others. Since
95 RFC1510 was issued, extensions and revisions to the protocol have been
96 proposed by many individuals. Some of these proposals are reflected in this
97 document. Where such changes involved significant effort, the document cites
98 the contribution of the proposer.
100 Reference implementations of both version 4 and version 5 of Kerberos are
101 publicly available and commercial implementations have been developed and
102 are widely used. Details on the differences between Kerberos Versions 4 and
103 5 can be found in [KNT92].
107 Kerberos provides a means of verifying the identities of principals, (e.g. a
108 workstation user or a network server) on an open (unprotected) network. This
109 is accomplished without relying on assertions by the host operating system,
110 without basing trust on host addresses, without requiring physical security
111 of all the hosts on the network, and under the assumption that packets
112 traveling along the network can be read, modified, and inserted at will[1].
113 Kerberos performs authentication under these conditions as a trusted
114 third-party authentication service by using conventional (shared secret key
115 [2] cryptography. Kerberos extensions have been proposed and implemented
116 that provide for the use of public key cryptography during certain phases of
117 the authentication protocol. These extensions provide for authentication of
119 Neuman, Ts'o, Kohl Expires: 25 December,
122 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
125 users registered with public key certification authorities, and allow the
126 system to provide certain benefits of public key cryptography in situations
127 where they are needed.
129 The basic Kerberos authentication process proceeds as follows: A client
130 sends a request to the authentication server (AS) requesting 'credentials'
131 for a given server. The AS responds with these credentials, encrypted in the
132 client's key. The credentials consist of 1) a 'ticket' for the server and 2)
133 a temporary encryption key (often called a "session key"). The client
134 transmits the ticket (which contains the client's identity and a copy of the
135 session key, all encrypted in the server's key) to the server. The session
136 key (now shared by the client and server) is used to authenticate the
137 client, and may optionally be used to authenticate the server. It may also
138 be used to encrypt further communication between the two parties or to
139 exchange a separate sub-session key to be used to encrypt further
142 Implementation of the basic protocol consists of one or more authentication
143 servers running on physically secure hosts. The authentication servers
144 maintain a database of principals (i.e., users and servers) and their secret
145 keys. Code libraries provide encryption and implement the Kerberos protocol.
146 In order to add authentication to its transactions, a typical network
147 application adds one or two calls to the Kerberos library directly or
148 through the Generic Security Services Application Programming Interface,
149 GSSAPI, described in separate document. These calls result in the
150 transmission of the necessary messages to achieve authentication.
152 The Kerberos protocol consists of several sub-protocols (or exchanges).
153 There are two basic methods by which a client can ask a Kerberos server for
154 credentials. In the first approach, the client sends a cleartext request for
155 a ticket for the desired server to the AS. The reply is sent encrypted in
156 the client's secret key. Usually this request is for a ticket-granting
157 ticket (TGT) which can later be used with the ticket-granting server (TGS).
158 In the second method, the client sends a request to the TGS. The client uses
159 the TGT to authenticate itself to the TGS in the same manner as if it were
160 contacting any other application server that requires Kerberos
161 authentication. The reply is encrypted in the session key from the TGT.
162 Though the protocol specification describes the AS and the TGS as separate
163 servers, they are implemented in practice as different protocol entry points
164 within a single Kerberos server.
166 Once obtained, credentials may be used to verify the identity of the
167 principals in a transaction, to ensure the integrity of messages exchanged
168 between them, or to preserve privacy of the messages. The application is
169 free to choose whatever protection may be necessary.
171 To verify the identities of the principals in a transaction, the client
172 transmits the ticket to the application server. Since the ticket is sent "in
173 the clear" (parts of it are encrypted, but this encryption doesn't thwart
174 replay) and might be intercepted and reused by an attacker, additional
175 information is sent to prove that the message originated with the principal
176 to whom the ticket was issued. This information (called the authenticator)
177 is encrypted in the session key, and includes a timestamp. The timestamp
178 proves that the message was recently generated and is not a replay.
179 Encrypting the authenticator in the session key proves that it was generated
180 by a party possessing the session key. Since no one except the requesting
181 principal and the server know the session key (it is never sent over the
182 network in the clear) this guarantees the identity of the client.
184 Neuman, Ts'o, Kohl Expires: 25 December,
187 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
190 The integrity of the messages exchanged between principals can also be
191 guaranteed using the session key (passed in the ticket and contained in the
192 credentials). This approach provides detection of both replay attacks and
193 message stream modification attacks. It is accomplished by generating and
194 transmitting a collision-proof checksum (elsewhere called a hash or digest
195 function) of the client's message, keyed with the session key. Privacy and
196 integrity of the messages exchanged between principals can be secured by
197 encrypting the data to be passed using the session key contained in the
198 ticket or the subsession key found in the authenticator.
200 The authentication exchanges mentioned above require read-only access to the
201 Kerberos database. Sometimes, however, the entries in the database must be
202 modified, such as when adding new principals or changing a principal's key.
203 This is done using a protocol between a client and a third Kerberos server,
204 the Kerberos Administration Server (KADM). There is also a protocol for
205 maintaining multiple copies of the Kerberos database. Neither of these
206 protocols are described in this document.
208 1.1. Cross-Realm Operation
210 The Kerberos protocol is designed to operate across organizational
211 boundaries. A client in one organization can be authenticated to a server in
212 another. Each organization wishing to run a Kerberos server establishes its
213 own 'realm'. The name of the realm in which a client is registered is part
214 of the client's name, and can be used by the end-service to decide whether
217 By establishing 'inter-realm' keys, the administrators of two realms can
218 allow a client authenticated in the local realm to prove its identity to
219 servers in other realms[3]. The exchange of inter-realm keys (a separate key
220 may be used for each direction) registers the ticket-granting service of
221 each realm as a principal in the other realm. A client is then able to
222 obtain a ticket-granting ticket for the remote realm's ticket-granting
223 service from its local realm. When that ticket-granting ticket is used, the
224 remote ticket-granting service uses the inter-realm key (which usually
225 differs from its own normal TGS key) to decrypt the ticket-granting ticket,
226 and is thus certain that it was issued by the client's own TGS. Tickets
227 issued by the remote ticket-granting service will indicate to the
228 end-service that the client was authenticated from another realm.
230 A realm is said to communicate with another realm if the two realms share an
231 inter-realm key, or if the local realm shares an inter-realm key with an
232 intermediate realm that communicates with the remote realm. An
233 authentication path is the sequence of intermediate realms that are
234 transited in communicating from one realm to another.
236 Realms are typically organized hierarchically. Each realm shares a key with
237 its parent and a different key with each child. If an inter-realm key is not
238 directly shared by two realms, the hierarchical organization allows an
239 authentication path to be easily constructed. If a hierarchical organization
240 is not used, it may be necessary to consult a database in order to construct
241 an authentication path between realms.
243 Although realms are typically hierarchical, intermediate realms may be
244 bypassed to achieve cross-realm authentication through alternate
245 authentication paths (these might be established to make communication
246 between two realms more efficient). It is important for the end-service to
248 Neuman, Ts'o, Kohl Expires: 25 December,
251 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
254 know which realms were transited when deciding how much faith to place in
255 the authentication process. To facilitate this decision, a field in each
256 ticket contains the names of the realms that were involved in authenticating
259 The application server is ultimately responsible for accepting or rejecting
260 authentication and should check the transited field. The application server
261 may choose to rely on the KDC for the application server's realm to check
262 the transited field. The application server's KDC will set the
263 TRANSITED-POLICY-CHECKED flag in this case. The KDC's for intermediate
264 realms may also check the transited field as they issue
265 ticket-granting-tickets for other realms, but they are encouraged not to do
266 so. A client may request that the KDC's not check the transited field by
267 setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but not
268 required to honor this flag.
272 As an authentication service, Kerberos provides a means of verifying the
273 identity of principals on a network. Authentication is usually useful
274 primarily as a first step in the process of authorization, determining
275 whether a client may use a service, which objects the client is allowed to
276 access, and the type of access allowed for each. Kerberos does not, by
277 itself, provide authorization. Possession of a client ticket for a service
278 provides only for authentication of the client to that service, and in the
279 absence of a separate authorization procedure, it should not be considered
280 by an application as authorizing the use of that service.
282 Such separate authorization methods may be implemented as application
283 specific access control functions and may be based on files such as the
284 application server, or on separately issued authorization credentials such
285 as those based on proxies [Neu93] , or on other authorization services.
287 Applications should not be modified to accept the issuance of a service
288 ticket by the Kerberos server (even by an modified Kerberos server) as
289 granting authority to use the service, since such applications may become
290 vulnerable to the bypass of this authorization check in an environment if
291 they interoperate with other KDCs or where other options for application
292 authentication (e.g. the PKTAPP proposal) are provided.
294 1.3. Environmental assumptions
296 Kerberos imposes a few assumptions on the environment in which it can
299 * 'Denial of service' attacks are not solved with Kerberos. There are
300 places in these protocols where an intruder can prevent an application
301 from participating in the proper authentication steps. Detection and
302 solution of such attacks (some of which can appear to be nnot-uncommon
303 'normal' failure modes for the system) is usually best left to the
304 human administrators and users.
305 * Principals must keep their secret keys secret. If an intruder somehow
306 steals a principal's key, it will be able to masquerade as that
307 principal or impersonate any server to the legitimate principal.
308 * 'Password guessing' attacks are not solved by Kerberos. If a user
309 chooses a poor password, it is possible for an attacker to successfully
310 mount an offline dictionary attack by repeatedly attempting to decrypt,
311 with successive entries from a dictionary, messages obtained which are
312 encrypted under a key derived from the user's password.
314 Neuman, Ts'o, Kohl Expires: 25 December,
317 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
320 * Each host on the network must have a clock which is 'loosely
321 synchronized' to the time of the other hosts; this synchronization is
322 used to reduce the bookkeeping needs of application servers when they
323 do replay detection. The degree of "looseness" can be configured on a
324 per-server basis, but is typically on the order of 5 minutes. If the
325 clocks are synchronized over the network, the clock synchronization
326 protocol must itself be secured from network attackers.
327 * Principal identifiers are not recycled on a short-term basis. A typical
328 mode of access control will use access control lists (ACLs) to grant
329 permissions to particular principals. If a stale ACL entry remains for
330 a deleted principal and the principal identifier is reused, the new
331 principal will inherit rights specified in the stale ACL entry. By not
332 re-using principal identifiers, the danger of inadvertent access is
335 1.4. Glossary of terms
337 Below is a list of terms used throughout this document.
340 Verifying the claimed identity of a principal.
341 Authentication header
342 A record containing a Ticket and an Authenticator to be presented to a
343 server as part of the authentication process.
345 A sequence of intermediate realms transited in the authentication
346 process when communicating from one realm to another.
348 A record containing information that can be shown to have been recently
349 generated using the session key known only by the client and server.
351 The process of determining whether a client may use a service, which
352 objects the client is allowed to access, and the type of access allowed
355 A token that grants the bearer permission to access an object or
356 service. In Kerberos, this might be a ticket whose use is restricted by
357 the contents of the authorization data field, but which lists no
358 network addresses, together with the session key necessary to use the
361 The output of an encryption function. Encryption transforms plaintext
364 A process that makes use of a network service on behalf of a user. Note
365 that in some cases a Server may itself be a client of some other server
366 (e.g. a print server may be a client of a file server).
368 A ticket plus the secret session key necessary to successfully use that
369 ticket in an authentication exchange.
371 Key Distribution Center, a network service that supplies tickets and
372 temporary session keys; or an instance of that service or the host on
373 which it runs. The KDC services both initial ticket and ticket-granting
374 ticket requests. The initial ticket portion is sometimes referred to as
375 the Authentication Server (or service). The ticket-granting ticket
376 portion is sometimes referred to as the ticket-granting server (or
379 Neuman, Ts'o, Kohl Expires: 25 December,
382 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
386 Aside from the 3-headed dog guarding Hades, the name given to Project
387 Athena's authentication service, the protocol used by that service, or
388 the code used to implement the authentication service.
390 The input to an encryption function or the output of a decryption
391 function. Decryption transforms ciphertext into plaintext.
393 A uniquely named client or server instance that participates in a
394 network communication.
396 The name used to uniquely identify each different principal.
398 To encipher a record containing several fields in such a way that the
399 fields cannot be individually replaced without either knowledge of the
400 encryption key or leaving evidence of tampering.
402 An encryption key shared by a principal and the KDC, distributed
403 outside the bounds of the system, with a long lifetime. In the case of
404 a human user's principal, the secret key is derived from a password.
406 A particular Principal which provides a resource to network clients.
407 The server is sometimes refered to as the Application Server.
409 A resource provided to network clients; often provided by more than one
410 server (for example, remote file service).
412 A temporary encryption key used between two principals, with a lifetime
413 limited to the duration of a single login "session".
415 A temporary encryption key used between two principals, selected and
416 exchanged by the principals using the session key, and with a lifetime
417 limited to the duration of a single association.
419 A record that helps a client authenticate itself to a server; it
420 contains the client's identity, a session key, a timestamp, and other
421 information, all sealed using the server's secret key. It only serves
422 to authenticate a client when presented along with a fresh
425 2. Ticket flag uses and requests
427 Each Kerberos ticket contains a set of flags which are used to indicate
428 various attributes of that ticket. Most flags may be requested by a client
429 when the ticket is obtained; some are automatically turned on and off by a
430 Kerberos server as required. The following sections explain what the various
431 flags mean, and gives examples of reasons to use such a flag.
433 2.1. Initial and pre-authenticated tickets
435 The INITIAL flag indicates that a ticket was issued using the AS protocol
436 and not issued based on a ticket-granting ticket. Application servers that
437 want to require the demonstrated knowledge of a client's secret key (e.g. a
438 password-changing program) can insist that this flag be set in any tickets
439 they accept, and thus be assured that the client's key was recently
440 presented to the application client.
443 Neuman, Ts'o, Kohl Expires: 25 December,
446 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
449 The PRE-AUTHENT and HW-AUTHENT flags provide addition information about the
450 initial authentication, regardless of whether the current ticket was issued
451 directly (in which case INITIAL will also be set) or issued on the basis of
452 a ticket-granting ticket (in which case the INITIAL flag is clear, but the
453 PRE-AUTHENT and HW-AUTHENT flags are carried forward from the
454 ticket-granting ticket).
458 The INVALID flag indicates that a ticket is invalid. Application servers
459 must reject tickets which have this flag set. A postdated ticket will
460 usually be issued in this form. Invalid tickets must be validated by the KDC
461 before use, by presenting them to the KDC in a TGS request with the VALIDATE
462 option specified. The KDC will only validate tickets after their starttime
463 has passed. The validation is required so that postdated tickets which have
464 been stolen before their starttime can be rendered permanently invalid
465 (through a hot-list mechanism) (see section 3.3.3.1).
467 2.3. Renewable tickets
469 Applications may desire to hold tickets which can be valid for long periods
470 of time. However, this can expose their credentials to potential theft for
471 equally long periods, and those stolen credentials would be valid until the
472 expiration time of the ticket(s). Simply using short-lived tickets and
473 obtaining new ones periodically would require the client to have long-term
474 access to its secret key, an even greater risk. Renewable tickets can be
475 used to mitigate the consequences of theft. Renewable tickets have two
476 "expiration times": the first is when the current instance of the ticket
477 expires, and the second is the latest permissible value for an individual
478 expiration time. An application client must periodically (i.e. before it
479 expires) present a renewable ticket to the KDC, with the RENEW option set in
480 the KDC request. The KDC will issue a new ticket with a new session key and
481 a later expiration time. All other fields of the ticket are left unmodified
482 by the renewal process. When the latest permissible expiration time arrives,
483 the ticket expires permanently. At each renewal, the KDC may consult a
484 hot-list to determine if the ticket had been reported stolen since its last
485 renewal; it will refuse to renew such stolen tickets, and thus the usable
486 lifetime of stolen tickets is reduced.
488 The RENEWABLE flag in a ticket is normally only interpreted by the
489 ticket-granting service (discussed below in section 3.3). It can usually be
490 ignored by application servers. However, some particularly careful
491 application servers may wish to disallow renewable tickets.
493 If a renewable ticket is not renewed by its expiration time, the KDC will
494 not renew the ticket. The RENEWABLE flag is reset by default, but a client
495 may request it be set by setting the RENEWABLE option in the KRB_AS_REQ
496 message. If it is set, then the renew-till field in the ticket contains the
497 time after which the ticket may not be renewed.
500 Neuman, Ts'o, Kohl Expires: 25 December,
503 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
506 2.4. Postdated tickets
508 Applications may occasionally need to obtain tickets for use much later,
509 e.g. a batch submission system would need tickets to be valid at the time
510 the batch job is serviced. However, it is dangerous to hold valid tickets in
511 a batch queue, since they will be on-line longer and more prone to theft.
512 Postdated tickets provide a way to obtain these tickets from the KDC at job
513 submission time, but to leave them "dormant" until they are activated and
514 validated by a further request of the KDC. If a ticket theft were reported
515 in the interim, the KDC would refuse to validate the ticket, and the thief
518 The MAY-POSTDATE flag in a ticket is normally only interpreted by the
519 ticket-granting service. It can be ignored by application servers. This flag
520 must be set in a ticket-granting ticket in order to issue a postdated ticket
521 based on the presented ticket. It is reset by default; it may be requested
522 by a client by setting the ALLOW-POSTDATE option in the KRB_AS_REQ message.
523 This flag does not allow a client to obtain a postdated ticket-granting
524 ticket; postdated ticket-granting tickets can only by obtained by requesting
525 the postdating in the KRB_AS_REQ message. The life (endtime-starttime) of a
526 postdated ticket will be the remaining life of the ticket-granting ticket at
527 the time of the request, unless the RENEWABLE option is also set, in which
528 case it can be the full life (endtime-starttime) of the ticket-granting
529 ticket. The KDC may limit how far in the future a ticket may be postdated.
531 The POSTDATED flag indicates that a ticket has been postdated. The
532 application server can check the authtime field in the ticket to see when
533 the original authentication occurred. Some services may choose to reject
534 postdated tickets, or they may only accept them within a certain period
535 after the original authentication. When the KDC issues a POSTDATED ticket,
536 it will also be marked as INVALID, so that the application client must
537 present the ticket to the KDC to be validated before use.
539 2.5. Proxiable and proxy tickets
541 At times it may be necessary for a principal to allow a service to perform
542 an operation on its behalf. The service must be able to take on the identity
543 of the client, but only for a particular purpose. A principal can allow a
544 service to take on the principal's identity for a particular purpose by
547 The process of granting a proxy using the proxy and proxiable flags is used
548 to provide credentials for use with specific services. Though conceptually
549 also a proxy, user's wishing to delegate their identity for ANY purpose must
550 use the ticket forwarding mechanism described in the next section to forward
551 a ticket granting ticket.
553 The PROXIABLE flag in a ticket is normally only interpreted by the
554 ticket-granting service. It can be ignored by application servers. When set,
555 this flag tells the ticket-granting server that it is OK to issue a new
556 ticket (but not a ticket-granting ticket) with a different network address
557 based on this ticket. This flag is set if requested by the client on initial
558 authentication. By default, the client will request that it be set when
559 requesting a ticket granting ticket, and reset when requesting any other
563 Neuman, Ts'o, Kohl Expires: 25 December,
566 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
569 This flag allows a client to pass a proxy to a server to perform a remote
570 request on its behalf, e.g. a print service client can give the print server
571 a proxy to access the client's files on a particular file server in order to
572 satisfy a print request.
574 In order to complicate the use of stolen credentials, Kerberos tickets are
575 usually valid from only those network addresses specifically included in the
576 ticket[4]. When granting a proxy, the client must specify the new network
577 address from which the proxy is to be used, or indicate that the proxy is to
578 be issued for use from any address.
580 The PROXY flag is set in a ticket by the TGS when it issues a proxy ticket.
581 Application servers may check this flag and at their option they may require
582 additional authentication from the agent presenting the proxy in order to
583 provide an audit trail.
585 2.6. Forwardable tickets
587 Authentication forwarding is an instance of a proxy where the service is
588 granted complete use of the client's identity. An example where it might be
589 used is when a user logs in to a remote system and wants authentication to
590 work from that system as if the login were local.
592 The FORWARDABLE flag in a ticket is normally only interpreted by the
593 ticket-granting service. It can be ignored by application servers. The
594 FORWARDABLE flag has an interpretation similar to that of the PROXIABLE
595 flag, except ticket-granting tickets may also be issued with different
596 network addresses. This flag is reset by default, but users may request that
597 it be set by setting the FORWARDABLE option in the AS request when they
598 request their initial ticket- granting ticket.
600 This flag allows for authentication forwarding without requiring the user to
601 enter a password again. If the flag is not set, then authentication
602 forwarding is not permitted, but the same result can still be achieved if
603 the user engages in the AS exchange specifying the requested network
604 addresses and supplies a password.
606 The FORWARDED flag is set by the TGS when a client presents a ticket with
607 the FORWARDABLE flag set and requests a forwarded ticket by specifying the
608 FORWARDED KDC option and supplying a set of addresses for the new ticket. It
609 is also set in all tickets issued based on tickets with the FORWARDED flag
610 set. Application servers may choose to process FORWARDED tickets differently
611 than non-FORWARDED tickets.
613 2.7. Other KDC options
615 There are two additional options which may be set in a client's request of
616 the KDC. The RENEWABLE-OK option indicates that the client will accept a
617 renewable ticket if a ticket with the requested life cannot otherwise be
618 provided. If a ticket with the requested life cannot be provided, then the
619 KDC may issue a renewable ticket with a renew-till equal to the the
620 requested endtime. The value of the renew-till field may still be adjusted
621 by site-determined limits or limits imposed by the individual principal or
624 The ENC-TKT-IN-SKEY option is honored only by the ticket-granting service.
625 It indicates that the ticket to be issued for the end server is to be
626 encrypted in the session key from the a additional second ticket-granting
627 ticket provided with the request. See section 3.3.3 for specific details.
630 Neuman, Ts'o, Kohl Expires: 25 December,
633 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
638 The following sections describe the interactions between network clients and
639 servers and the messages involved in those exchanges.
641 3.1. The Authentication Service Exchange
644 Message direction Message type Section
645 1. Client to Kerberos KRB_AS_REQ 5.4.1
646 2. Kerberos to client KRB_AS_REP or 5.4.2
649 The Authentication Service (AS) Exchange between the client and the Kerberos
650 Authentication Server is initiated by a client when it wishes to obtain
651 authentication credentials for a given server but currently holds no
652 credentials. In its basic form, the client's secret key is used for
653 encryption and decryption. This exchange is typically used at the initiation
654 of a login session to obtain credentials for a Ticket-Granting Server which
655 will subsequently be used to obtain credentials for other servers (see
656 section 3.3) without requiring further use of the client's secret key. This
657 exchange is also used to request credentials for services which must not be
658 mediated through the Ticket-Granting Service, but rather require a
659 principal's secret key, such as the password-changing service[5]. This
660 exchange does not by itself provide any assurance of the the identity of the
663 The exchange consists of two messages: KRB_AS_REQ from the client to
664 Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these
665 messages are described in sections 5.4.1, 5.4.2, and 5.9.1.
667 In the request, the client sends (in cleartext) its own identity and the
668 identity of the server for which it is requesting credentials. The response,
669 KRB_AS_REP, contains a ticket for the client to present to the server, and a
670 session key that will be shared by the client and the server. The session
671 key and additional information are encrypted in the client's secret key. The
672 KRB_AS_REP message contains information which can be used to detect replays,
673 and to associate it with the message to which it replies. Various errors can
674 occur; these are indicated by an error response (KRB_ERROR) instead of the
675 KRB_AS_REP response. The error message is not encrypted. The KRB_ERROR
676 message contains information which can be used to associate it with the
677 message to which it replies. The lack of encryption in the KRB_ERROR message
678 precludes the ability to detect replays, fabrications, or modifications of
681 Without preautentication, the authentication server does not know whether
682 the client is actually the principal named in the request. It simply sends a
683 reply without knowing or caring whether they are the same. This is
684 acceptable because nobody but the principal whose identity was given in the
685 request will be able to use the reply. Its critical information is encrypted
686 in that principal's key. The initial request supports an optional field that
687 can be used to pass additional information that might be needed for the
688 initial exchange. This field may be used for preauthentication as described
692 Neuman, Ts'o, Kohl Expires: 25 December,
695 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
698 3.1.1. Generation of KRB_AS_REQ message
700 The client may specify a number of options in the initial request. Among
701 these options are whether pre-authentication is to be performed; whether the
702 requested ticket is to be renewable, proxiable, or forwardable; whether it
703 should be postdated or allow postdating of derivative tickets; and whether a
704 renewable ticket will be accepted in lieu of a non-renewable ticket if the
705 requested ticket expiration date cannot be satisfied by a non-renewable
706 ticket (due to configuration constraints; see section 4). See section A.1
709 The client prepares the KRB_AS_REQ message and sends it to the KDC.
711 3.1.2. Receipt of KRB_AS_REQ message
713 If all goes well, processing the KRB_AS_REQ message will result in the
714 creation of a ticket for the client to present to the server. The format for
715 the ticket is described in section 5.3.1. The contents of the ticket are
716 determined as follows.
718 3.1.3. Generation of KRB_AS_REP message
720 The authentication server looks up the client and server principals named in
721 the KRB_AS_REQ in its database, extracting their respective keys. If
722 required, the server pre-authenticates the request, and if the
723 pre-authentication check fails, an error message with the code
724 KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate the
725 requested encryption type, an error message with code KDC_ERR_ETYPE_NOSUPP
726 is returned. Otherwise it generates a 'random' session key[7].
728 If there are multiple encryption keys registered for a client in the
729 Kerberos database (or if the key registered supports multiple encryption
730 types; e.g. DES-CBC-CRC and DES-CBC-MD5), then the etype field from the AS
731 request is used by the KDC to select the encryption method to be used for
732 encrypting the response to the client. If there is more than one supported,
733 strong encryption type in the etype list, the first valid etype for which an
734 encryption key is available is used. The encryption method used to respond
735 to a TGS request is taken from the keytype of the session key found in the
736 ticket granting ticket. [***I will change the example keytypes to be 3DES
737 based examples 7/14***]
739 When the etype field is present in a KDC request, whether an AS or TGS
740 request, the KDC will attempt to assign the type of the random session key
741 from the list of methods in the etype field. The KDC will select the
742 appropriate type using the list of methods provided together with
743 information from the Kerberos database indicating acceptable encryption
744 methods for the application server. The KDC will not issue tickets with a
745 weak session key encryption type.
747 If the requested start time is absent, indicates a time in the past, or is
748 within the window of acceptable clock skew for the KDC and the POSTDATE
749 option has not been specified, then the start time of the ticket is set to
750 the authentication server's current time. If it indicates a time in the
751 future beyond the acceptable clock skew, but the POSTDATED option has not
752 been specified then the error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise
753 the requested start time is checked against the policy of the local realm
754 (the administrator might decide to prohibit certain types or ranges of
755 postdated tickets), and if acceptable, the ticket's start time is set as
757 Neuman, Ts'o, Kohl Expires: 25 December,
760 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
763 requested and the INVALID flag is set in the new ticket. The postdated
764 ticket must be validated before use by presenting it to the KDC after the
765 start time has been reached.
767 The expiration time of the ticket will be set to the minimum of the
770 * The expiration time (endtime) requested in the KRB_AS_REQ message.
771 * The ticket's start time plus the maximum allowable lifetime associated
772 with the client principal (the authentication server's database
773 includes a maximum ticket lifetime field in each principal's record;
775 * The ticket's start time plus the maximum allowable lifetime associated
776 with the server principal.
777 * The ticket's start time plus the maximum lifetime set by the policy of
780 If the requested expiration time minus the start time (as determined above)
781 is less than a site-determined minimum lifetime, an error message with code
782 KDC_ERR_NEVER_VALID is returned. If the requested expiration time for the
783 ticket exceeds what was determined as above, and if the 'RENEWABLE-OK'
784 option was requested, then the 'RENEWABLE' flag is set in the new ticket,
785 and the renew-till value is set as if the 'RENEWABLE' option were requested
786 (the field and option names are described fully in section 5.4.1).
788 If the RENEWABLE option has been requested or if the RENEWABLE-OK option has
789 been set and a renewable ticket is to be issued, then the renew-till field
790 is set to the minimum of:
792 * Its requested value.
793 * The start time of the ticket plus the minimum of the two maximum
794 renewable lifetimes associated with the principals' database entries.
795 * The start time of the ticket plus the maximum renewable lifetime set by
796 the policy of the local realm.
798 The flags field of the new ticket will have the following options set if
799 they have been requested and if the policy of the local realm allows:
800 FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. If the new
801 ticket is post-dated (the start time is in the future), its INVALID flag
804 If all of the above succeed, the server formats a KRB_AS_REP message (see
805 section 5.4.2), copying the addresses in the request into the caddr of the
806 response, placing any required pre-authentication data into the padata of
807 the response, and encrypts the ciphertext part in the client's key using the
808 requested encryption method, and sends it to the client. See section A.2 for
811 3.1.4. Generation of KRB_ERROR message
813 Several errors can occur, and the Authentication Server responds by
814 returning an error message, KRB_ERROR, to the client, with the error-code
815 and e-text fields set to appropriate values. The error message contents and
816 details are described in Section 5.9.1.
819 Neuman, Ts'o, Kohl Expires: 25 December,
822 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
825 3.1.5. Receipt of KRB_AS_REP message
827 If the reply message type is KRB_AS_REP, then the client verifies that the
828 cname and crealm fields in the cleartext portion of the reply match what it
829 requested. If any padata fields are present, they may be used to derive the
830 proper secret key to decrypt the message. The client decrypts the encrypted
831 part of the response using its secret key, verifies that the nonce in the
832 encrypted part matches the nonce it supplied in its request (to detect
833 replays). It also verifies that the sname and srealm in the response match
834 those in the request (or are otherwise expected values), and that the host
835 address field is also correct. It then stores the ticket, session key, start
836 and expiration times, and other information for later use. The
837 key-expiration field from the encrypted part of the response may be checked
838 to notify the user of impending key expiration (the client program could
839 then suggest remedial action, such as a password change). See section A.3
842 Proper decryption of the KRB_AS_REP message is not sufficient to verify the
843 identity of the user; the user and an attacker could cooperate to generate a
844 KRB_AS_REP format message which decrypts properly but is not from the proper
845 KDC. If the host wishes to verify the identity of the user, it must require
846 the user to present application credentials which can be verified using a
847 securely-stored secret key for the host. If those credentials can be
848 verified, then the identity of the user can be assured.
850 3.1.6. Receipt of KRB_ERROR message
852 If the reply message type is KRB_ERROR, then the client interprets it as an
853 error and performs whatever application-specific tasks are necessary to
856 3.2. The Client/Server Authentication Exchange
859 Message direction Message type Section
860 Client to Application server KRB_AP_REQ 5.5.1
861 [optional] Application server to client KRB_AP_REP or 5.5.2
864 The client/server authentication (CS) exchange is used by network
865 applications to authenticate the client to the server and vice versa. The
866 client must have already acquired credentials for the server using the AS or
869 3.2.1. The KRB_AP_REQ message
871 The KRB_AP_REQ contains authentication information which should be part of
872 the first message in an authenticated transaction. It contains a ticket, an
873 authenticator, and some additional bookkeeping information (see section
874 5.5.1 for the exact format). The ticket by itself is insufficient to
875 authenticate a client, since tickets are passed across the network in
876 cleartext[DS90], so the authenticator is used to prevent invalid replay of
877 tickets by proving to the server that the client knows the session key of
878 the ticket and thus is entitled to use the ticket. The KRB_AP_REQ message is
879 referred to elsewhere as the 'authentication header.'
882 Neuman, Ts'o, Kohl Expires: 25 December,
885 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
888 3.2.2. Generation of a KRB_AP_REQ message
890 When a client wishes to initiate authentication to a server, it obtains
891 (either through a credentials cache, the AS exchange, or the TGS exchange) a
892 ticket and session key for the desired service. The client may re-use any
893 tickets it holds until they expire. To use a ticket the client constructs a
894 new Authenticator from the the system time, its name, and optionally an
895 application specific checksum, an initial sequence number to be used in
896 KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in
897 negotiations for a session key unique to this particular session.
898 Authenticators may not be re-used and will be rejected if replayed to a
899 server[LGDSR87]. If a sequence number is to be included, it should be
900 randomly chosen so that even after many messages have been exchanged it is
901 not likely to collide with other sequence numbers in use.
903 The client may indicate a requirement of mutual authentication or the use of
904 a session-key based ticket by setting the appropriate flag(s) in the
905 ap-options field of the message.
907 The Authenticator is encrypted in the session key and combined with the
908 ticket to form the KRB_AP_REQ message which is then sent to the end server
909 along with any additional application-specific information. See section A.9
912 3.2.3. Receipt of KRB_AP_REQ message
914 Authentication is based on the server's current time of day (clocks must be
915 loosely synchronized), the authenticator, and the ticket. Several errors are
916 possible. If an error occurs, the server is expected to reply to the client
917 with a KRB_ERROR message. This message may be encapsulated in the
918 application protocol if its 'raw' form is not acceptable to the protocol.
919 The format of error messages is described in section 5.9.1.
921 The algorithm for verifying authentication information is as follows. If the
922 message type is not KRB_AP_REQ, the server returns the KRB_AP_ERR_MSG_TYPE
923 error. If the key version indicated by the Ticket in the KRB_AP_REQ is not
924 one the server can use (e.g., it indicates an old key, and the server no
925 longer possesses a copy of the old key), the KRB_AP_ERR_BADKEYVER error is
926 returned. If the USE-SESSION-KEY flag is set in the ap-options field, it
927 indicates to the server that the ticket is encrypted in the session key from
928 the server's ticket-granting ticket rather than its secret key[10]. Since it
929 is possible for the server to be registered in multiple realms, with
930 different keys in each, the srealm field in the unencrypted portion of the
931 ticket in the KRB_AP_REQ is used to specify which secret key the server
932 should use to decrypt that ticket. The KRB_AP_ERR_NOKEY error code is
933 returned if the server doesn't have the proper key to decipher the ticket.
935 The ticket is decrypted using the version of the server's key specified by
936 the ticket. If the decryption routines detect a modification of the ticket
937 (each encryption system must provide safeguards to detect modified
938 ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY error is returned
939 (chances are good that different keys were used to encrypt and decrypt).
941 The authenticator is decrypted using the session key extracted from the
942 decrypted ticket. If decryption shows it to have been modified, the
943 KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the client
944 from the ticket are compared against the same fields in the authenticator.
945 If they don't match, the KRB_AP_ERR_BADMATCH error is returned (they might
947 Neuman, Ts'o, Kohl Expires: 25 December,
950 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
953 not match, for example, if the wrong session key was used to encrypt the
954 authenticator). The addresses in the ticket (if any) are then searched for
955 an address matching the operating-system reported address of the client. If
956 no match is found or the server insists on ticket addresses but none are
957 present in the ticket, the KRB_AP_ERR_BADADDR error is returned.
959 If the local (server) time and the client time in the authenticator differ
960 by more than the allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW
961 error is returned. If the server name, along with the client name, time and
962 microsecond fields from the Authenticator match any recently-seen such
963 tuples, the KRB_AP_ERR_REPEAT error is returned[11]. The server must
964 remember any authenticator presented within the allowable clock skew, so
965 that a replay attempt is guaranteed to fail. If a server loses track of any
966 authenticator presented within the allowable clock skew, it must reject all
967 requests until the clock skew interval has passed. This assures that any
968 lost or re-played authenticators will fall outside the allowable clock skew
969 and can no longer be successfully replayed (If this is not done, an attacker
970 could conceivably record the ticket and authenticator sent over the network
971 to a server, then disable the client's host, pose as the disabled host, and
972 replay the ticket and authenticator to subvert the authentication.). If a
973 sequence number is provided in the authenticator, the server saves it for
974 later use in processing KRB_SAFE and/or KRB_PRIV messages. If a subkey is
975 present, the server either saves it for later use or uses it to help
976 generate its own choice for a subkey to be returned in a KRB_AP_REP message.
978 The server computes the age of the ticket: local (server) time minus the
979 start time inside the Ticket. If the start time is later than the current
980 time by more than the allowable clock skew or if the INVALID flag is set in
981 the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Otherwise, if the
982 current time is later than end time by more than the allowable clock skew,
983 the KRB_AP_ERR_TKT_EXPIRED error is returned.
985 If all these checks succeed without an error, the server is assured that the
986 client possesses the credentials of the principal named in the ticket and
987 thus, the client has been authenticated to the server. See section A.10 for
990 Passing these checks provides only authentication of the named principal; it
991 does not imply authorization to use the named service. Applications must
992 make a separate authorization decisions based upon the authenticated name of
993 the user, the requested operation, local acces control information such as
994 that contained in a .k5login or .k5users file, and possibly a separate
995 distributed authorization service.
997 3.2.4. Generation of a KRB_AP_REP message
999 Typically, a client's request will include both the authentication
1000 information and its initial request in the same message, and the server need
1001 not explicitly reply to the KRB_AP_REQ. However, if mutual authentication
1002 (not only authenticating the client to the server, but also the server to
1003 the client) is being performed, the KRB_AP_REQ message will have
1004 MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message is
1005 required in response. As with the error message, this message may be
1006 encapsulated in the application protocol if its "raw" form is not acceptable
1007 to the application's protocol. The timestamp and microsecond field used in
1008 the reply must be the client's timestamp and microsecond field (as provided
1009 in the authenticator)[12]. If a sequence number is to be included, it should
1010 be randomly chosen as described above for the authenticator. A subkey may be
1012 Neuman, Ts'o, Kohl Expires: 25 December,
1015 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
1018 included if the server desires to negotiate a different subkey. The
1019 KRB_AP_REP message is encrypted in the session key extracted from the
1020 ticket. See section A.11 for pseudocode.
1022 3.2.5. Receipt of KRB_AP_REP message
1024 If a KRB_AP_REP message is returned, the client uses the session key from
1025 the credentials obtained for the server[13] to decrypt the message, and
1026 verifies that the timestamp and microsecond fields match those in the
1027 Authenticator it sent to the server. If they match, then the client is
1028 assured that the server is genuine. The sequence number and subkey (if
1029 present) are retained for later use. See section A.12 for pseudocode.
1031 3.2.6. Using the encryption key
1033 After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and server
1034 share an encryption key which can be used by the application. The 'true
1035 session key' to be used for KRB_PRIV, KRB_SAFE, or other
1036 application-specific uses may be chosen by the application based on the
1037 subkeys in the KRB_AP_REP message and the authenticator[14]. In some cases,
1038 the use of this session key will be implicit in the protocol; in others the
1039 method of use must be chosen from several alternatives. We leave the
1040 protocol negotiations of how to use the key (e.g. selecting an encryption or
1041 checksum type) to the application programmer; the Kerberos protocol does not
1042 constrain the implementation options, but an example of how this might be
1045 One way that an application may choose to negotiate a key to be used for
1046 subequent integrity and privacy protection is for the client to propose a
1047 key in the subkey field of the authenticator. The server can then choose a
1048 key using the proposed key from the client as input, returning the new
1049 subkey in the subkey field of the application reply. This key could then be
1050 used for subsequent communication. To make this example more concrete, if
1051 the encryption method in use required a 56 bit key, and for whatever reason,
1052 one of the parties was prevented from using a key with more than 40 unknown
1053 bits, this method would allow the the party which is prevented from using
1054 more than 40 bits to either propose (if the client) an initial key with a
1055 known quantity for 16 of those bits, or to mask 16 of the bits (if the
1056 server) with the known quantity. The application implementor is warned,
1057 however, that this is only an example, and that an analysis of the
1058 particular crytosystem to be used, and the reasons for limiting the key
1059 length, must be made before deciding whether it is acceptable to mask bits
1062 With both the one-way and mutual authentication exchanges, the peers should
1063 take care not to send sensitive information to each other without proper
1064 assurances. In particular, applications that require privacy or integrity
1065 should use the KRB_AP_REP response from the server to client to assure both
1066 client and server of their peer's identity. If an application protocol
1067 requires privacy of its messages, it can use the KRB_PRIV message (section
1068 3.5). The KRB_SAFE message (section 3.4) can be used to assure integrity.
1071 Neuman, Ts'o, Kohl Expires: 25 December,
1074 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
1077 3.3. The Ticket-Granting Service (TGS) Exchange
1080 Message direction Message type Section
1081 1. Client to Kerberos KRB_TGS_REQ 5.4.1
1082 2. Kerberos to client KRB_TGS_REP or 5.4.2
1085 The TGS exchange between a client and the Kerberos Ticket-Granting Server is
1086 initiated by a client when it wishes to obtain authentication credentials
1087 for a given server (which might be registered in a remote realm), when it
1088 wishes to renew or validate an existing ticket, or when it wishes to obtain
1089 a proxy ticket. In the first case, the client must already have acquired a
1090 ticket for the Ticket-Granting Service using the AS exchange (the
1091 ticket-granting ticket is usually obtained when a client initially
1092 authenticates to the system, such as when a user logs in). The message
1093 format for the TGS exchange is almost identical to that for the AS exchange.
1094 The primary difference is that encryption and decryption in the TGS exchange
1095 does not take place under the client's key. Instead, the session key from
1096 the ticket-granting ticket or renewable ticket, or sub-session key from an
1097 Authenticator is used. As is the case for all application servers, expired
1098 tickets are not accepted by the TGS, so once a renewable or ticket-granting
1099 ticket expires, the client must use a separate exchange to obtain valid
1102 The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from the
1103 client to the Kerberos Ticket-Granting Server, and a reply (KRB_TGS_REP or
1104 KRB_ERROR). The KRB_TGS_REQ message includes information authenticating the
1105 client plus a request for credentials. The authentication information
1106 consists of the authentication header (KRB_AP_REQ) which includes the
1107 client's previously obtained ticket-granting, renewable, or invalid ticket.
1108 In the ticket-granting ticket and proxy cases, the request may include one
1109 or more of: a list of network addresses, a collection of typed authorization
1110 data to be sealed in the ticket for authorization use by the application
1111 server, or additional tickets (the use of which are described later). The
1112 TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted in the
1113 session key from the ticket-granting ticket or renewable ticket, or if
1114 present, in the sub-session key from the Authenticator (part of the
1115 authentication header). The KRB_ERROR message contains an error code and
1116 text explaining what went wrong. The KRB_ERROR message is not encrypted. The
1117 KRB_TGS_REP message contains information which can be used to detect
1118 replays, and to associate it with the message to which it replies. The
1119 KRB_ERROR message also contains information which can be used to associate
1120 it with the message to which it replies, but the lack of encryption in the
1121 KRB_ERROR message precludes the ability to detect replays or fabrications of
1124 3.3.1. Generation of KRB_TGS_REQ message
1126 Before sending a request to the ticket-granting service, the client must
1127 determine in which realm the application server is registered[15]. If the
1128 client does not already possess a ticket-granting ticket for the appropriate
1129 realm, then one must be obtained. This is first attempted by requesting a
1130 ticket-granting ticket for the destination realm from a Kerberos server for
1131 which the client does posess a ticket-granting ticket (using the KRB_TGS_REQ
1132 message recursively). The Kerberos server may return a TGT for the desired
1133 realm in which case one can proceed. Alternatively, the Kerberos server may
1134 return a TGT for a realm which is 'closer' to the desired realm (further
1136 Neuman, Ts'o, Kohl Expires: 25 December,
1139 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
1142 along the standard hierarchical path), in which case this step must be
1143 repeated with a Kerberos server in the realm specified in the returned TGT.
1144 If neither are returned, then the request must be retried with a Kerberos
1145 server for a realm higher in the hierarchy. This request will itself require
1146 a ticket-granting ticket for the higher realm which must be obtained by
1147 recursively applying these directions.
1149 Once the client obtains a ticket-granting ticket for the appropriate realm,
1150 it determines which Kerberos servers serve that realm, and contacts one. The
1151 list might be obtained through a configuration file or network service or it
1152 may be generated from the name of the realm; as long as the secret keys
1153 exchanged by realms are kept secret, only denial of service results from
1154 using a false Kerberos server.
1156 As in the AS exchange, the client may specify a number of options in the
1157 KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ message, providing
1158 an authentication header as an element of the padata field, and including
1159 the same fields as used in the KRB_AS_REQ message along with several
1160 optional fields: the enc-authorization-data field for application server use
1161 and additional tickets required by some options.
1163 In preparing the authentication header, the client can select a sub-session
1164 key under which the response from the Kerberos server will be encrypted[16].
1165 If the sub-session key is not specified, the session key from the
1166 ticket-granting ticket will be used. If the enc-authorization-data is
1167 present, it must be encrypted in the sub-session key, if present, from the
1168 authenticator portion of the authentication header, or if not present, using
1169 the session key from the ticket-granting ticket.
1171 Once prepared, the message is sent to a Kerberos server for the destination
1172 realm. See section A.5 for pseudocode.
1174 3.3.2. Receipt of KRB_TGS_REQ message
1176 The KRB_TGS_REQ message is processed in a manner similar to the KRB_AS_REQ
1177 message, but there are many additional checks to be performed. First, the
1178 Kerberos server must determine which server the accompanying ticket is for
1179 and it must select the appropriate key to decrypt it. For a normal
1180 KRB_TGS_REQ message, it will be for the ticket granting service, and the
1181 TGS's key will be used. If the TGT was issued by another realm, then the
1182 appropriate inter-realm key must be used. If the accompanying ticket is not
1183 a ticket granting ticket for the current realm, but is for an application
1184 server in the current realm, the RENEW, VALIDATE, or PROXY options are
1185 specified in the request, and the server for which a ticket is requested is
1186 the server named in the accompanying ticket, then the KDC will decrypt the
1187 ticket in the authentication header using the key of the server for which it
1188 was issued. If no ticket can be found in the padata field, the
1189 KDC_ERR_PADATA_TYPE_NOSUPP error is returned.
1191 Once the accompanying ticket has been decrypted, the user-supplied checksum
1192 in the Authenticator must be verified against the contents of the request,
1193 and the message rejected if the checksums do not match (with an error code
1194 of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or not
1195 collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM). If the
1196 checksum type is not supported, the KDC_ERR_SUMTYPE_NOSUPP error is
1197 returned. If the authorization-data are present, they are decrypted using
1198 the sub-session key from the Authenticator.
1200 If any of the decryptions indicate failed integrity checks, the
1201 KRB_AP_ERR_BAD_INTEGRITY error is returned.
1203 Neuman, Ts'o, Kohl Expires: 25 December,
1206 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
1209 3.3.3. Generation of KRB_TGS_REP message
1211 The KRB_TGS_REP message shares its format with the KRB_AS_REP (KRB_KDC_REP),
1212 but with its type field set to KRB_TGS_REP. The detailed specification is in
1215 The response will include a ticket for the requested server. The Kerberos
1216 database is queried to retrieve the record for the requested server
1217 (including the key with which the ticket will be encrypted). If the request
1218 is for a ticket granting ticket for a remote realm, and if no key is shared
1219 with the requested realm, then the Kerberos server will select the realm
1220 "closest" to the requested realm with which it does share a key, and use
1221 that realm instead. This is the only case where the response from the KDC
1222 will be for a different server than that requested by the client.
1224 By default, the address field, the client's name and realm, the list of
1225 transited realms, the time of initial authentication, the expiration time,
1226 and the authorization data of the newly-issued ticket will be copied from
1227 the ticket-granting ticket (TGT) or renewable ticket. If the transited field
1228 needs to be updated, but the transited type is not supported, the
1229 KDC_ERR_TRTYPE_NOSUPP error is returned.
1231 If the request specifies an endtime, then the endtime of the new ticket is
1232 set to the minimum of (a) that request, (b) the endtime from the TGT, and
1233 (c) the starttime of the TGT plus the minimum of the maximum life for the
1234 application server and the maximum life for the local realm (the maximum
1235 life for the requesting principal was already applied when the TGT was
1236 issued). If the new ticket is to be a renewal, then the endtime above is
1237 replaced by the minimum of (a) the value of the renew_till field of the
1238 ticket and (b) the starttime for the new ticket plus the life
1239 (endtime-starttime) of the old ticket.
1241 If the FORWARDED option has been requested, then the resulting ticket will
1242 contain the addresses specified by the client. This option will only be
1243 honored if the FORWARDABLE flag is set in the TGT. The PROXY option is
1244 similar; the resulting ticket will contain the addresses specified by the
1245 client. It will be honored only if the PROXIABLE flag in the TGT is set. The
1246 PROXY option will not be honored on requests for additional ticket-granting
1249 If the requested start time is absent, indicates a time in the past, or is
1250 within the window of acceptable clock skew for the KDC and the POSTDATE
1251 option has not been specified, then the start time of the ticket is set to
1252 the authentication server's current time. If it indicates a time in the
1253 future beyond the acceptable clock skew, but the POSTDATED option has not
1254 been specified or the MAY-POSTDATE flag is not set in the TGT, then the
1255 error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the ticket-granting
1256 ticket has the MAY-POSTDATE flag set, then the resulting ticket will be
1257 postdated and the requested starttime is checked against the policy of the
1258 local realm. If acceptable, the ticket's start time is set as requested, and
1259 the INVALID flag is set. The postdated ticket must be validated before use
1260 by presenting it to the KDC after the starttime has been reached. However,
1261 in no case may the starttime, endtime, or renew-till time of a newly-issued
1262 postdated ticket extend beyond the renew-till time of the ticket-granting
1266 Neuman, Ts'o, Kohl Expires: 25 December,
1269 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
1272 If the ENC-TKT-IN-SKEY option has been specified and an additional ticket
1273 has been included in the request, the KDC will decrypt the additional ticket
1274 using the key for the server to which the additional ticket was issued and
1275 verify that it is a ticket-granting ticket. If the name of the requested
1276 server is missing from the request, the name of the client in the additional
1277 ticket will be used. Otherwise the name of the requested server will be
1278 compared to the name of the client in the additional ticket and if
1279 different, the request will be rejected. If the request succeeds, the
1280 session key from the additional ticket will be used to encrypt the new
1281 ticket that is issued instead of using the key of the server for which the
1282 new ticket will be used[17].
1284 If the name of the server in the ticket that is presented to the KDC as part
1285 of the authentication header is not that of the ticket-granting server
1286 itself, the server is registered in the realm of the KDC, and the RENEW
1287 option is requested, then the KDC will verify that the RENEWABLE flag is set
1288 in the ticket, that the INVALID flag is not set in the ticket, and that the
1289 renew_till time is still in the future. If the VALIDATE option is rqeuested,
1290 the KDC will check that the starttime has passed and the INVALID flag is
1291 set. If the PROXY option is requested, then the KDC will check that the
1292 PROXIABLE flag is set in the ticket. If the tests succeed, and the ticket
1293 passes the hotlist check described in the next paragraph, the KDC will issue
1294 the appropriate new ticket.
1296 3.3.3.1. Checking for revoked tickets
1298 Whenever a request is made to the ticket-granting server, the presented
1299 ticket(s) is(are) checked against a hot-list of tickets which have been
1300 canceled. This hot-list might be implemented by storing a range of issue
1301 timestamps for 'suspect tickets'; if a presented ticket had an authtime in
1302 that range, it would be rejected. In this way, a stolen ticket-granting
1303 ticket or renewable ticket cannot be used to gain additional tickets
1304 (renewals or otherwise) once the theft has been reported. Any normal ticket
1305 obtained before it was reported stolen will still be valid (because they
1306 require no interaction with the KDC), but only until their normal expiration
1309 The ciphertext part of the response in the KRB_TGS_REP message is encrypted
1310 in the sub-session key from the Authenticator, if present, or the session
1311 key key from the ticket-granting ticket. It is not encrypted using the
1312 client's secret key. Furthermore, the client's key's expiration date and the
1313 key version number fields are left out since these values are stored along
1314 with the client's database record, and that record is not needed to satisfy
1315 a request based on a ticket-granting ticket. See section A.6 for pseudocode.
1317 3.3.3.2. Encoding the transited field
1319 If the identity of the server in the TGT that is presented to the KDC as
1320 part of the authentication header is that of the ticket-granting service,
1321 but the TGT was issued from another realm, the KDC will look up the
1322 inter-realm key shared with that realm and use that key to decrypt the
1323 ticket. If the ticket is valid, then the KDC will honor the request, subject
1324 to the constraints outlined above in the section describing the AS exchange.
1325 The realm part of the client's identity will be taken from the
1326 ticket-granting ticket. The name of the realm that issued the
1327 ticket-granting ticket will be added to the transited field of the ticket to
1328 be issued. This is accomplished by reading the transited field from the
1329 ticket-granting ticket (which is treated as an unordered set of realm
1331 Neuman, Ts'o, Kohl Expires: 25 December,
1334 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
1337 names), adding the new realm to the set, then constructing and writing out
1338 its encoded (shorthand) form (this may involve a rearrangement of the
1341 Note that the ticket-granting service does not add the name of its own
1342 realm. Instead, its responsibility is to add the name of the previous realm.
1343 This prevents a malicious Kerberos server from intentionally leaving out its
1344 own name (it could, however, omit other realms' names).
1346 The names of neither the local realm nor the principal's realm are to be
1347 included in the transited field. They appear elsewhere in the ticket and
1348 both are known to have taken part in authenticating the principal. Since the
1349 endpoints are not included, both local and single-hop inter-realm
1350 authentication result in a transited field that is empty.
1352 Because the name of each realm transited is added to this field, it might
1353 potentially be very long. To decrease the length of this field, its contents
1354 are encoded. The initially supported encoding is optimized for the normal
1355 case of inter-realm communication: a hierarchical arrangement of realms
1356 using either domain or X.500 style realm names. This encoding (called
1357 DOMAIN-X500-COMPRESS) is now described.
1359 Realm names in the transited field are separated by a ",". The ",", "\",
1360 trailing "."s, and leading spaces (" ") are special characters, and if they
1361 are part of a realm name, they must be quoted in the transited field by
1362 preced- ing them with a "\".
1364 A realm name ending with a "." is interpreted as being prepended to the
1365 previous realm. For example, we can encode traversal of EDU, MIT.EDU,
1366 ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as:
1368 "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
1370 Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, that they
1371 would not be included in this field, and we would have:
1373 "EDU,MIT.,WASHINGTON.EDU"
1375 A realm name beginning with a "/" is interpreted as being appended to the
1376 previous realm[18]. If it is to stand by itself, then it should be preceded
1377 by a space (" "). For example, we can encode traversal of /COM/HP/APOLLO,
1378 /COM/HP, /COM, and /COM/DEC as:
1380 "/COM,/HP,/APOLLO, /COM/DEC".
1382 Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they
1383 they would not be included in this field, and we would have:
1387 A null subfield preceding or following a "," indicates that all realms
1388 between the previous realm and the next realm have been traversed[19]. Thus,
1389 "," means that all realms along the path between the client and the server
1390 have been traversed. ",EDU, /COM," means that that all realms from the
1391 client's realm up to EDU (in a domain style hierarchy) have been traversed,
1392 and that everything from /COM down to the server's realm in an X.500 style
1393 has also been traversed. This could occur if the EDU realm in one hierarchy
1394 shares an inter-realm key directly with the /COM realm in another hierarchy.
1397 Neuman, Ts'o, Kohl Expires: 25 December,
1400 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
1403 3.3.4. Receipt of KRB_TGS_REP message
1405 When the KRB_TGS_REP is received by the client, it is processed in the same
1406 manner as the KRB_AS_REP processing described above. The primary difference
1407 is that the ciphertext part of the response must be decrypted using the
1408 session key from the ticket-granting ticket rather than the client's secret
1409 key. See section A.7 for pseudocode.
1411 3.4. The KRB_SAFE Exchange
1413 The KRB_SAFE message may be used by clients requiring the ability to detect
1414 modifications of messages they exchange. It achieves this by including a
1415 keyed collision-proof checksum of the user data and some control
1416 information. The checksum is keyed with an encryption key (usually the last
1417 key negotiated via subkeys, or the session key if no negotiation has
1420 3.4.1. Generation of a KRB_SAFE message
1422 When an application wishes to send a KRB_SAFE message, it collects its data
1423 and the appropriate control information and computes a checksum over them.
1424 The checksum algorithm should be a keyed one-way hash function (such as the
1425 RSA- MD5-DES checksum algorithm specified in section 6.4.5, or the DES MAC),
1426 generated using the sub-session key if present, or the session key.
1427 Different algorithms may be selected by changing the checksum type in the
1428 message. Unkeyed or non-collision-proof checksums are not suitable for this
1431 The control information for the KRB_SAFE message includes both a timestamp
1432 and a sequence number. The designer of an application using the KRB_SAFE
1433 message must choose at least one of the two mechanisms. This choice should
1434 be based on the needs of the application protocol.
1436 Sequence numbers are useful when all messages sent will be received by one's
1437 peer. Connection state is presently required to maintain the session key, so
1438 maintaining the next sequence number should not present an additional
1441 If the application protocol is expected to tolerate lost messages without
1442 them being resent, the use of the timestamp is the appropriate replay
1443 detection mechanism. Using timestamps is also the appropriate mechanism for
1444 multi-cast protocols where all of one's peers share a common sub-session
1445 key, but some messages will be sent to a subset of one's peers.
1447 After computing the checksum, the client then transmits the information and
1448 checksum to the recipient in the message format specified in section 5.6.1.
1450 3.4.2. Receipt of KRB_SAFE message
1452 When an application receives a KRB_SAFE message, it verifies it as follows.
1453 If any error occurs, an error code is reported for use by the application.
1455 The message is first checked by verifying that the protocol version and type
1456 fields match the current version and KRB_SAFE, respectively. A mismatch
1457 generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The
1458 application verifies that the checksum used is a collision-proof keyed
1459 checksum, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. If
1460 the sender's address was included in the control information, the recipient
1462 Neuman, Ts'o, Kohl Expires: 25 December,
1465 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
1468 verifies that the operating system's report of the sender's address matches
1469 the sender's address in the message, and (if a recipient address is
1470 specified or the recipient requires an address) that one of the recipient's
1471 addresses appears as the recipient's address in the message. A failed match
1472 for either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp and
1473 usec and/or the sequence number fields are checked. If timestamp and usec
1474 are expected and not present, or they are present but not current, the
1475 KRB_AP_ERR_SKEW error is generated. If the server name, along with the
1476 client name, time and microsecond fields from the Authenticator match any
1477 recently-seen (sent or received[20] ) such tuples, the KRB_AP_ERR_REPEAT
1478 error is generated. If an incorrect sequence number is included, or a
1479 sequence number is expected but not present, the KRB_AP_ERR_BADORDER error
1480 is generated. If neither a time-stamp and usec or a sequence number is
1481 present, a KRB_AP_ERR_MODIFIED error is generated. Finally, the checksum is
1482 computed over the data and control information, and if it doesn't match the
1483 received checksum, a KRB_AP_ERR_MODIFIED error is generated.
1485 If all the checks succeed, the application is assured that the message was
1486 generated by its peer and was not modi- fied in transit.
1488 3.5. The KRB_PRIV Exchange
1490 The KRB_PRIV message may be used by clients requiring confidentiality and
1491 the ability to detect modifications of exchanged messages. It achieves this
1492 by encrypting the messages and adding control information.
1494 3.5.1. Generation of a KRB_PRIV message
1496 When an application wishes to send a KRB_PRIV message, it collects its data
1497 and the appropriate control information (specified in section 5.7.1) and
1498 encrypts them under an encryption key (usually the last key negotiated via
1499 subkeys, or the session key if no negotiation has occured). As part of the
1500 control information, the client must choose to use either a timestamp or a
1501 sequence number (or both); see the discussion in section 3.4.1 for
1502 guidelines on which to use. After the user data and control information are
1503 encrypted, the client transmits the ciphertext and some 'envelope'
1504 information to the recipient.
1506 3.5.2. Receipt of KRB_PRIV message
1508 When an application receives a KRB_PRIV message, it verifies it as follows.
1509 If any error occurs, an error code is reported for use by the application.
1511 The message is first checked by verifying that the protocol version and type
1512 fields match the current version and KRB_PRIV, respectively. A mismatch
1513 generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The
1514 application then decrypts the ciphertext and processes the resultant
1515 plaintext. If decryption shows the data to have been modified, a
1516 KRB_AP_ERR_BAD_INTEGRITY error is generated. If the sender's address was
1517 included in the control information, the recipient verifies that the
1518 operating system's report of the sender's address matches the sender's
1519 address in the message, and (if a recipient address is specified or the
1520 recipient requires an address) that one of the recipient's addresses appears
1521 as the recipient's address in the message. A failed match for either case
1522 generates a KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the
1523 sequence number fields are checked. If timestamp and usec are expected and
1524 not present, or they are present but not current, the KRB_AP_ERR_SKEW error
1525 is generated. If the server name, along with the client name, time and
1527 Neuman, Ts'o, Kohl Expires: 25 December,
1530 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
1533 microsecond fields from the Authenticator match any recently-seen such
1534 tuples, the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence
1535 number is included, or a sequence number is expected but not present, the
1536 KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and usec or
1537 a sequence number is present, a KRB_AP_ERR_MODIFIED error is generated.
1539 If all the checks succeed, the application can assume the message was
1540 generated by its peer, and was securely transmitted (without intruders able
1541 to see the unencrypted contents).
1543 3.6. The KRB_CRED Exchange
1545 The KRB_CRED message may be used by clients requiring the ability to send
1546 Kerberos credentials from one host to another. It achieves this by sending
1547 the tickets together with encrypted data containing the session keys and
1548 other information associated with the tickets.
1550 3.6.1. Generation of a KRB_CRED message
1552 When an application wishes to send a KRB_CRED message it first (using the
1553 KRB_TGS exchange) obtains credentials to be sent to the remote host. It then
1554 constructs a KRB_CRED message using the ticket or tickets so obtained,
1555 placing the session key needed to use each ticket in the key field of the
1556 corresponding KrbCredInfo sequence of the encrypted part of the the KRB_CRED
1559 Other information associated with each ticket and obtained during the
1560 KRB_TGS exchange is also placed in the corresponding KrbCredInfo sequence in
1561 the encrypted part of the KRB_CRED message. The current time and, if
1562 specifically required by the application the nonce, s-address, and r-address
1563 fields, are placed in the encrypted part of the KRB_CRED message which is
1564 then encrypted under an encryption key previosuly exchanged in the KRB_AP
1565 exchange (usually the last key negotiated via subkeys, or the session key if
1566 no negotiation has occured).
1568 3.6.2. Receipt of KRB_CRED message
1570 When an application receives a KRB_CRED message, it verifies it. If any
1571 error occurs, an error code is reported for use by the application. The
1572 message is verified by checking that the protocol version and type fields
1573 match the current version and KRB_CRED, respectively. A mismatch generates a
1574 KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then
1575 decrypts the ciphertext and processes the resultant plaintext. If decryption
1576 shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is
1579 If present or required, the recipient verifies that the operating system's
1580 report of the sender's address matches the sender's address in the message,
1581 and that one of the recipient's addresses appears as the recipient's address
1582 in the message. A failed match for either case generates a
1583 KRB_AP_ERR_BADADDR error. The timestamp and usec fields (and the nonce field
1584 if required) are checked next. If the timestamp and usec are not present, or
1585 they are present but not current, the KRB_AP_ERR_SKEW error is generated.
1587 If all the checks succeed, the application stores each of the new tickets in
1588 its ticket cache together with the session key and other information in the
1589 corresponding KrbCredInfo sequence from the encrypted part of the KRB_CRED
1593 Neuman, Ts'o, Kohl Expires: 25 December,
1596 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
1599 4. The Kerberos Database
1601 The Kerberos server must have access to a database contain- ing the
1602 principal identifiers and secret keys of principals to be authenticated[21].
1604 4.1. Database contents
1606 A database entry should contain at least the following fields:
1610 name Principal's identifier
1611 key Principal's secret key
1612 p_kvno Principal's key version
1613 max_life Maximum lifetime for Tickets
1614 max_renewable_life Maximum total lifetime for renewable Tickets
1616 The name field is an encoding of the principal's identifier. The key field
1617 contains an encryption key. This key is the principal's secret key. (The key
1618 can be encrypted before storage under a Kerberos "master key" to protect it
1619 in case the database is compromised but the master key is not. In that case,
1620 an extra field must be added to indicate the master key version used, see
1621 below.) The p_kvno field is the key version number of the principal's secret
1622 key. The max_life field contains the maximum allowable lifetime (endtime -
1623 starttime) for any Ticket issued for this principal. The max_renewable_life
1624 field contains the maximum allowable total lifetime for any renewable Ticket
1625 issued for this principal. (See section 3.1 for a description of how these
1626 lifetimes are used in determining the lifetime of a given Ticket.)
1628 A server may provide KDC service to several realms, as long as the database
1629 representation provides a mechanism to distinguish between principal records
1630 with identifiers which differ only in the realm name.
1632 When an application server's key changes, if the change is routine (i.e. not
1633 the result of disclosure of the old key), the old key should be retained by
1634 the server until all tickets that had been issued using that key have
1635 expired. Because of this, it is possible for several keys to be active for a
1636 single principal. Ciphertext encrypted in a principal's key is always tagged
1637 with the version of the key that was used for encryption, to help the
1638 recipient find the proper key for decryption.
1640 When more than one key is active for a particular principal, the principal
1641 will have more than one record in the Kerberos database. The keys and key
1642 version numbers will differ between the records (the rest of the fields may
1643 or may not be the same). Whenever Kerberos issues a ticket, or responds to a
1644 request for initial authentication, the most recent key (known by the
1645 Kerberos server) will be used for encryption. This is the key with the
1646 highest key version number.
1649 Neuman, Ts'o, Kohl Expires: 25 December,
1652 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
1655 4.2. Additional fields
1657 Project Athena's KDC implementation uses additional fields in its database:
1661 K_kvno Kerberos' key version
1662 expiration Expiration date for entry
1663 attributes Bit field of attributes
1664 mod_date Timestamp of last modification
1665 mod_name Modifying principal's identifier
1667 The K_kvno field indicates the key version of the Kerberos master key under
1668 which the principal's secret key is encrypted.
1670 After an entry's expiration date has passed, the KDC will return an error to
1671 any client attempting to gain tickets as or for the principal. (A database
1672 may want to maintain two expiration dates: one for the principal, and one
1673 for the principal's current key. This allows password aging to work
1674 independently of the principal's expiration date. However, due to the
1675 limited space in the responses, the KDC must combine the key expiration and
1676 principal expiration date into a single value called 'key_exp', which is
1677 used as a hint to the user to take administrative action.)
1679 The attributes field is a bitfield used to govern the operations involving
1680 the principal. This field might be useful in conjunction with user
1681 registration procedures, for site-specific policy implementations (Project
1682 Athena currently uses it for their user registration process controlled by
1683 the system-wide database service, Moira [LGDSR87]), to identify whether a
1684 principal can play the role of a client or server or both, to note whether a
1685 server is appropriate trusted to recieve credentials delegated by a client,
1686 or to identify the 'string to key' conversion algorithm used for a
1687 principal's key[22]. Other bits are used to indicate that certain ticket
1688 options should not be allowed in tickets encrypted under a principal's key
1689 (one bit each): Disallow issuing postdated tickets, disallow issuing
1690 forwardable tickets, disallow issuing tickets based on TGT authentication,
1691 disallow issuing renewable tickets, disallow issuing proxiable tickets, and
1692 disallow issuing tickets for which the principal is the server.
1694 The mod_date field contains the time of last modification of the entry, and
1695 the mod_name field contains the name of the principal which last modified
1698 4.3. Frequently Changing Fields
1700 Some KDC implementations may wish to maintain the last time that a request
1701 was made by a particular principal. Information that might be maintained
1702 includes the time of the last request, the time of the last request for a
1703 ticket-granting ticket, the time of the last use of a ticket-granting
1704 ticket, or other times. This information can then be returned to the user in
1705 the last-req field (see section 5.2).
1707 Other frequently changing information that can be maintained is the latest
1708 expiration time for any tickets that have been issued using each key. This
1709 field would be used to indicate how long old keys must remain valid to allow
1710 the continued use of outstanding tickets.
1713 Neuman, Ts'o, Kohl Expires: 25 December,
1716 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
1721 The KDC implementation should have the following configurable constants or
1722 options, to allow an administrator to make and enforce policy decisions:
1724 * The minimum supported lifetime (used to determine whether the
1725 KDC_ERR_NEVER_VALID error should be returned). This constant should
1726 reflect reasonable expectations of round-trip time to the KDC,
1727 encryption/decryption time, and processing time by the client and
1728 target server, and it should allow for a minimum 'useful' lifetime.
1729 * The maximum allowable total (renewable) lifetime of a ticket
1730 (renew_till - starttime).
1731 * The maximum allowable lifetime of a ticket (endtime - starttime).
1732 * Whether to allow the issue of tickets with empty address fields
1733 (including the ability to specify that such tickets may only be issued
1734 if the request specifies some authorization_data).
1735 * Whether proxiable, forwardable, renewable or post-datable tickets are
1738 5. Message Specifications
1740 The following sections describe the exact contents and encoding of protocol
1741 messages and objects. The ASN.1 base definitions are presented in the first
1742 subsection. The remaining subsections specify the protocol objects (tickets
1743 and authenticators) and messages. Specification of encryption and checksum
1744 techniques, and the fields related to them, appear in section 6.
1746 Optional field in ASN.1 sequences
1748 For optional integer value and date fields in ASN.1 sequences where a
1749 default value has been specified, certain default values will not be allowed
1750 in the encoding because these values will always be represented through
1751 defaulting by the absence of the optional field. For example, one will not
1752 send a microsecond zero value because one must make sure that there is only
1753 one way to encode this value.
1755 Additional fields in ASN.1 sequences
1757 Implementations receiving Kerberos messages with additional fields present
1758 in ASN.1 sequences should carry the those fields through, unmodified, when
1759 the message is forwarded. Implementations should not drop such fields if the
1760 sequence is reencoded.
1762 5.1. ASN.1 Distinguished Encoding Representation
1764 All uses of ASN.1 in Kerberos shall use the Distinguished Encoding
1765 Representation of the data elements as described in the X.509 specification,
1766 section 8.7 [X509-88].
1768 5.3. ASN.1 Base Definitions
1770 The following ASN.1 base definitions are used in the rest of this section.
1771 Note that since the underscore character (_) is not permitted in ASN.1
1772 names, the hyphen (-) is used in its place for the purposes of ASN.1 names.
1774 Realm ::= GeneralString
1775 PrincipalName ::= SEQUENCE {
1776 name-type[0] INTEGER,
1777 name-string[1] SEQUENCE OF GeneralString
1780 Neuman, Ts'o, Kohl Expires: 25 December,
1783 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
1786 Kerberos realms are encoded as GeneralStrings. Realms shall not contain a
1787 character with the code 0 (the ASCII NUL). Most realms will usually consist
1788 of several components separated by periods (.), in the style of Internet
1789 Domain Names, or separated by slashes (/) in the style of X.500 names.
1790 Acceptable forms for realm names are specified in section 7. A PrincipalName
1791 is a typed sequence of components consisting of the following sub-fields:
1794 This field specifies the type of name that follows. Pre-defined values
1795 for this field are specified in section 7.2. The name-type should be
1796 treated as a hint. Ignoring the name type, no two names can be the same
1797 (i.e. at least one of the components, or the realm, must be different).
1798 This constraint may be eliminated in the future.
1800 This field encodes a sequence of components that form a name, each
1801 component encoded as a GeneralString. Taken together, a PrincipalName
1802 and a Realm form a principal identifier. Most PrincipalNames will have
1803 only a few components (typically one or two).
1805 KerberosTime ::= GeneralizedTime
1806 -- Specifying UTC time zone (Z)
1808 The timestamps used in Kerberos are encoded as GeneralizedTimes. An encoding
1809 shall specify the UTC time zone (Z) and shall not include any fractional
1810 portions of the seconds. It further shall not include any separators.
1811 Example: The only valid format for UTC time 6 minutes, 27 seconds after 9 pm
1812 on 6 November 1985 is 19851106210627Z.
1814 HostAddress ::= SEQUENCE {
1815 addr-type[0] INTEGER,
1816 address[1] OCTET STRING
1819 HostAddresses ::= SEQUENCE OF HostAddress
1821 The host adddress encodings consists of two fields:
1824 This field specifies the type of address that follows. Pre-defined
1825 values for this field are specified in section 8.1.
1827 This field encodes a single address of type addr-type.
1829 The two forms differ slightly. HostAddress contains exactly one address;
1830 HostAddresses contains a sequence of possibly many addresses.
1832 AuthorizationData ::= SEQUENCE OF SEQUENCE {
1834 ad-data[1] OCTET STRING
1838 This field contains authorization data to be interpreted according to
1839 the value of the corresponding ad-type field.
1841 This field specifies the format for the ad-data subfield. All negative
1842 values are reserved for local use. Non-negative values are reserved for
1846 Neuman, Ts'o, Kohl Expires: 25 December,
1849 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
1852 Each sequence of type and data is refered to as an authorization element.
1853 Elements may be application specific, however, there is a common set of
1854 recursive elements that should be understood by all implementations. These
1855 elements contain other elements embedded within them, and the interpretation
1856 of the encapsulating element determines which of the embedded elements must
1857 be interpreted, and which may be ignored. Definitions for these common
1858 elements may be found in Appendix B.
1860 TicketExtensions ::= SEQUENCE OF SEQUENCE {
1862 te-data[1] OCTET STRING
1866 This field contains opaque data that must be caried with the ticket to
1867 support extensions to the Kerberos protocol including but not limited
1868 to some forms of inter-realm key exchange and plaintext authorization
1869 data. See appendix C for some common uses of this field.
1871 This field specifies the format for the te-data subfield. All negative
1872 values are reserved for local use. Non-negative values are reserved for
1875 APOptions ::= BIT STRING
1877 -- use-session-key(1),
1878 -- mutual-required(2)
1880 TicketFlags ::= BIT STRING
1893 -- transited-policy-checked(12),
1894 -- ok-as-delegate(13)
1896 KDCOptions ::= BIT STRING
1902 -- allow-postdate(5),
1909 Neuman, Ts'o, Kohl Expires: 25 December,
1912 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
1918 -- disable-transited-check(26),
1919 -- renewable-ok(27),
1920 -- enc-tkt-in-skey(28),
1924 ASN.1 Bit strings have a length and a value. When used in Kerberos for the
1925 APOptions, TicketFlags, and KDCOptions, the length of the bit string on
1926 generated values should be the smallest number of bits needed to include the
1927 highest order bit that is set (1), but in no case less than 32 bits. The
1928 ASN.1 representation of the bit strings uses unnamed bits, with the meaning
1929 of the individual bits defined by the comments in the specification above.
1930 Implementations should accept values of bit strings of any length and treat
1931 the value of flags corresponding to bits beyond the end of the bit string as
1932 if the bit were reset (0). Comparison of bit strings of different length
1933 should treat the smaller string as if it were padded with zeros beyond the
1934 high order bits to the length of the longer string[23].
1936 LastReq ::= SEQUENCE OF SEQUENCE {
1938 lr-value[1] KerberosTime
1942 This field indicates how the following lr-value field is to be
1943 interpreted. Negative values indicate that the information pertains
1944 only to the responding server. Non-negative values pertain to all
1945 servers for the realm. If the lr-type field is zero (0), then no
1946 information is conveyed by the lr-value subfield. If the absolute value
1947 of the lr-type field is one (1), then the lr-value subfield is the time
1948 of last initial request for a TGT. If it is two (2), then the lr-value
1949 subfield is the time of last initial request. If it is three (3), then
1950 the lr-value subfield is the time of issue for the newest
1951 ticket-granting ticket used. If it is four (4), then the lr-value
1952 subfield is the time of the last renewal. If it is five (5), then the
1953 lr-value subfield is the time of last request (of any type). If it is
1954 (6), then the lr-value subfield is the time when the password will
1957 This field contains the time of the last request. the time must be
1958 interpreted according to the contents of the accompanying lr-type
1961 See section 6 for the definitions of Checksum, ChecksumType, EncryptedData,
1962 EncryptionKey, EncryptionType, and KeyType.
1964 5.3. Tickets and Authenticators
1966 This section describes the format and encryption parameters for tickets and
1967 authenticators. When a ticket or authenticator is included in a protocol
1968 message it is treated as an opaque object.
1971 Neuman, Ts'o, Kohl Expires: 25 December,
1974 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
1979 A ticket is a record that helps a client authenticate to a service. A Ticket
1980 contains the following information:
1982 Ticket ::= [APPLICATION 1] SEQUENCE {
1985 sname[2] PrincipalName,
1986 enc-part[3] EncryptedData,
1987 extensions[4] TicketExtensions OPTIONAL
1990 -- Encrypted part of ticket
1991 EncTicketPart ::= [APPLICATION 3] SEQUENCE {
1992 flags[0] TicketFlags,
1993 key[1] EncryptionKey,
1995 cname[3] PrincipalName,
1996 transited[4] TransitedEncoding,
1997 authtime[5] KerberosTime,
1998 starttime[6] KerberosTime OPTIONAL,
1999 endtime[7] KerberosTime,
2000 renew-till[8] KerberosTime OPTIONAL,
2001 caddr[9] HostAddresses OPTIONAL,
2002 authorization-data[10] AuthorizationData OPTIONAL
2004 -- encoded Transited field
2005 TransitedEncoding ::= SEQUENCE {
2006 tr-type[0] INTEGER, -- must be
2008 contents[1] OCTET STRING
2011 The encoding of EncTicketPart is encrypted in the key shared by Kerberos and
2012 the end server (the server's secret key). See section 6 for the format of
2016 This field specifies the version number for the ticket format. This
2017 document describes version number 5.
2019 This field specifies the realm that issued a ticket. It also serves to
2020 identify the realm part of the server's principal identifier. Since a
2021 Kerberos server can only issue tickets for servers within its realm,
2022 the two will always be identical.
2024 This field specifies all components of the name part of the server's
2025 identity, including those parts that identify a specific instance of a
2028 This field holds the encrypted encoding of the EncTicketPart sequence.
2030 [*** This change is still subject to discussion. Several alternatives
2031 for this - including none at all - will be distributed to the cat and
2032 krb-protocol mailing lists before the Oslo IETF, and an alternative
2033 will be selected and the spec modified by 7/14/99 ***] This optional
2034 field contains a sequence of extentions that may be used to carry
2035 information that must be carried with the ticket to support several
2037 Neuman, Ts'o, Kohl Expires: 25 December,
2040 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
2043 extensions, including but not limited to plaintext authorization data,
2044 tokens for exchanging inter-realm keys, and other information that must
2045 be associated with a ticket for use by the application server. See
2046 Appendix C for definitions of some common extensions.
2048 Note that some older versions of Kerberos did not support this field.
2049 Because this is an optional field it will not break older clients, but
2050 older clients might strip this field from the ticket before sending it
2051 to the application server. This limits the usefulness of this ticket
2052 field to environments where the ticket will not be parsed and
2053 reconstructed by these older Kerberos clients.
2055 If it is known that the client will strip this field from the ticket,
2056 as an interim measure the KDC may append this field to the end of the
2057 enc-part of the ticket and append a traler indicating the lenght of the
2058 appended extensions field. (this paragraph is open for discussion,
2059 including the form of the traler).
2061 This field indicates which of various options were used or requested
2062 when the ticket was issued. It is a bit-field, where the selected
2063 options are indicated by the bit being set (1), and the unselected
2064 options and reserved fields being reset (0). Bit 0 is the most
2065 significant bit. The encoding of the bits is specified in section 5.2.
2066 The flags are described in more detail above in section 2. The meanings
2069 Bit(s) Name Description
2072 Reserved for future expansion of this
2076 The FORWARDABLE flag is normally only
2077 interpreted by the TGS, and can be
2078 ignored by end servers. When set, this
2079 flag tells the ticket-granting server
2080 that it is OK to issue a new ticket-
2081 granting ticket with a different network
2082 address based on the presented ticket.
2085 When set, this flag indicates that the
2086 ticket has either been forwarded or was
2087 issued based on authentication involving
2088 a forwarded ticket-granting ticket.
2091 The PROXIABLE flag is normally only
2092 interpreted by the TGS, and can be
2093 ignored by end servers. The PROXIABLE
2094 flag has an interpretation identical to
2095 that of the FORWARDABLE flag, except
2096 that the PROXIABLE flag tells the
2097 ticket-granting server that only non-
2098 ticket-granting tickets may be issued
2099 with different network addresses.
2102 Neuman, Ts'o, Kohl Expires: 25 December,
2105 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
2109 When set, this flag indicates that a
2113 The MAY-POSTDATE flag is normally only
2114 interpreted by the TGS, and can be
2115 ignored by end servers. This flag tells
2116 the ticket-granting server that a post-
2117 dated ticket may be issued based on this
2118 ticket-granting ticket.
2121 This flag indicates that this ticket has
2122 been postdated. The end-service can
2123 check the authtime field to see when the
2124 original authentication occurred.
2127 This flag indicates that a ticket is
2128 invalid, and it must be validated by the
2129 KDC before use. Application servers
2130 must reject tickets which have this flag
2134 The RENEWABLE flag is normally only
2135 interpreted by the TGS, and can usually
2136 be ignored by end servers (some particu-
2137 larly careful servers may wish to disal-
2138 low renewable tickets). A renewable
2139 ticket can be used to obtain a replace-
2140 ment ticket that expires at a later
2144 This flag indicates that this ticket was
2145 issued using the AS protocol, and not
2146 issued based on a ticket-granting
2150 This flag indicates that during initial
2151 authentication, the client was authenti-
2152 cated by the KDC before a ticket was
2153 issued. The strength of the pre-
2154 authentication method is not indicated,
2155 but is acceptable to the KDC.
2158 This flag indicates that the protocol
2159 employed for initial authentication
2160 required the use of hardware expected to
2161 be possessed solely by the named client.
2162 The hardware authentication method is
2163 selected by the KDC and the strength of
2164 the method is not indicated.
2167 Neuman, Ts'o, Kohl Expires: 25 December,
2170 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
2173 12 TRANSITED This flag indicates that the KDC for the
2174 POLICY-CHECKED realm has checked the transited field
2175 against a realm defined policy for
2176 trusted certifiers. If this flag is
2177 reset (0), then the application server
2178 must check the transited field itself,
2179 and if unable to do so it must reject
2180 the authentication. If the flag is set
2181 (1) then the application server may skip
2182 its own validation of the transited
2183 field, relying on the validation
2184 performed by the KDC. At its option the
2185 application server may still apply its
2186 own validation based on a separate
2187 policy for acceptance.
2189 13 OK-AS-DELEGATE This flag indicates that the server (not
2190 the client) specified in the ticket has
2191 been determined by policy of the realm
2192 to be a suitable recipient of
2193 delegation. A client can use the
2194 presence of this flag to help it make a
2195 decision whether to delegate credentials
2196 (either grant a proxy or a forwarded
2197 ticket granting ticket) to this server.
2198 The client is free to ignore the value
2199 of this flag. When setting this flag,
2200 an administrator should consider the
2201 Security and placement of the server on
2202 which the service will run, as well as
2203 whether the service requires the use of
2204 delegated credentials.
2207 This flag indicates that the principal
2208 named in the ticket is a generic princi-
2209 pal for the realm and does not identify
2210 the individual using the ticket. The
2211 purpose of the ticket is only to
2212 securely distribute a session key, and
2213 not to identify the user. Subsequent
2214 requests using the same ticket and ses-
2215 sion may be considered as originating
2216 from the same user, but requests with
2217 the same username but a different ticket
2218 are likely to originate from different
2222 Reserved for future use.
2225 This field exists in the ticket and the KDC response and is used to
2226 pass the session key from Kerberos to the application server and the
2227 client. The field's encoding is described in section 6.2.
2229 This field contains the name of the realm in which the client is
2230 registered and in which initial authentication took place.
2232 Neuman, Ts'o, Kohl Expires: 25 December,
2235 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
2239 This field contains the name part of the client's principal identifier.
2241 This field lists the names of the Kerberos realms that took part in
2242 authenticating the user to whom this ticket was issued. It does not
2243 specify the order in which the realms were transited. See section
2244 3.3.3.2 for details on how this field encodes the traversed realms.
2245 When the names of CA's are to be embedded inthe transited field (as
2246 specified for some extentions to the protocol), the X.500 names of the
2247 CA's should be mapped into items in the transited field using the
2248 mapping defined by RFC2253.
2250 This field indicates the time of initial authentication for the named
2251 principal. It is the time of issue for the original ticket on which
2252 this ticket is based. It is included in the ticket to provide
2253 additional information to the end service, and to provide the necessary
2254 information for implementation of a `hot list' service at the KDC. An
2255 end service that is particularly paranoid could refuse to accept
2256 tickets for which the initial authentication occurred "too far" in the
2257 past. This field is also returned as part of the response from the KDC.
2258 When returned as part of the response to initial authentication
2259 (KRB_AS_REP), this is the current time on the Ker- beros server[24].
2261 This field in the ticket specifies the time after which the ticket is
2262 valid. Together with endtime, this field specifies the life of the
2263 ticket. If it is absent from the ticket, its value should be treated as
2264 that of the authtime field.
2266 This field contains the time after which the ticket will not be honored
2267 (its expiration time). Note that individual services may place their
2268 own limits on the life of a ticket and may reject tickets which have
2269 not yet expired. As such, this is really an upper bound on the
2270 expiration time for the ticket.
2272 This field is only present in tickets that have the RENEWABLE flag set
2273 in the flags field. It indicates the maximum endtime that may be
2274 included in a renewal. It can be thought of as the absolute expiration
2275 time for the ticket, including all renewals.
2277 This field in a ticket contains zero (if omitted) or more (if present)
2278 host addresses. These are the addresses from which the ticket can be
2279 used. If there are no addresses, the ticket can be used from any
2280 location. The decision by the KDC to issue or by the end server to
2281 accept zero-address tickets is a policy decision and is left to the
2282 Kerberos and end-service administrators; they may refuse to issue or
2283 accept such tickets. The suggested and default policy, however, is that
2284 such tickets will only be issued or accepted when additional
2285 information that can be used to restrict the use of the ticket is
2286 included in the authorization_data field. Such a ticket is a
2289 Network addresses are included in the ticket to make it harder for an
2290 attacker to use stolen credentials. Because the session key is not sent
2291 over the network in cleartext, credentials can't be stolen simply by
2292 listening to the network; an attacker has to gain access to the session
2293 key (perhaps through operating system security breaches or a careless
2294 user's unattended session) to make use of stolen tickets.
2297 Neuman, Ts'o, Kohl Expires: 25 December,
2300 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
2303 It is important to note that the network address from which a
2304 connection is received cannot be reliably determined. Even if it could
2305 be, an attacker who has compromised the client's workstation could use
2306 the credentials from there. Including the network addresses only makes
2307 it more difficult, not impossible, for an attacker to walk off with
2308 stolen credentials and then use them from a "safe" location.
2310 The authorization-data field is used to pass authorization data from
2311 the principal on whose behalf a ticket was issued to the application
2312 service. If no authorization data is included, this field will be left
2313 out. Experience has shown that the name of this field is confusing, and
2314 that a better name for this field would be restrictions. Unfortunately,
2315 it is not possible to change the name of this field at this time.
2317 This field contains restrictions on any authority obtained on the basis
2318 of authentication using the ticket. It is possible for any principal in
2319 posession of credentials to add entries to the authorization data field
2320 since these entries further restrict what can be done with the ticket.
2321 Such additions can be made by specifying the additional entries when a
2322 new ticket is obtained during the TGS exchange, or they may be added
2323 during chained delegation using the authorization data field of the
2326 Because entries may be added to this field by the holder of
2327 credentials, it is not allowable for the presence of an entry in the
2328 authorization data field of a ticket to amplify the priveleges one
2329 would obtain from using a ticket.
2331 The data in this field may be specific to the end service; the field
2332 will contain the names of service specific objects, and the rights to
2333 those objects. The format for this field is described in section 5.2.
2334 Although Kerberos is not concerned with the format of the contents of
2335 the sub-fields, it does carry type information (ad-type).
2337 By using the authorization_data field, a principal is able to issue a
2338 proxy that is valid for a specific purpose. For example, a client
2339 wishing to print a file can obtain a file server proxy to be passed to
2340 the print server. By specifying the name of the file in the
2341 authorization_data field, the file server knows that the print server
2342 can only use the client's rights when accessing the particular file to
2345 A separate service providing authorization or certifying group
2346 membership may be built using the authorization-data field. In this
2347 case, the entity granting authorization (not the authorized entity),
2348 obtains a ticket in its own name (e.g. the ticket is issued in the name
2349 of a privelege server), and this entity adds restrictions on its own
2350 authority and delegates the restricted authority through a proxy to the
2351 client. The client would then present this authorization credential to
2352 the application server separately from the authentication exchange.
2354 Similarly, if one specifies the authorization-data field of a proxy and
2355 leaves the host addresses blank, the resulting ticket and session key
2356 can be treated as a capability. See [Neu93] for some suggested uses of
2359 The authorization-data field is optional and does not have to be
2360 included in a ticket.
2363 Neuman, Ts'o, Kohl Expires: 25 December,
2366 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
2369 5.3.2. Authenticators
2371 An authenticator is a record sent with a ticket to a server to certify the
2372 client's knowledge of the encryption key in the ticket, to help the server
2373 detect replays, and to help choose a "true session key" to use with the
2374 particular session. The encoding is encrypted in the ticket's session key
2375 shared by the client and the server:
2377 -- Unencrypted authenticator
2378 Authenticator ::= [APPLICATION 2] SEQUENCE {
2379 authenticator-vno[0] INTEGER,
2381 cname[2] PrincipalName,
2382 cksum[3] Checksum OPTIONAL,
2384 ctime[5] KerberosTime,
2385 subkey[6] EncryptionKey OPTIONAL,
2386 seq-number[7] INTEGER OPTIONAL,
2387 authorization-data[8] AuthorizationData OPTIONAL
2391 This field specifies the version number for the format of the
2392 authenticator. This document specifies version 5.
2394 These fields are the same as those described for the ticket in section
2397 This field contains a checksum of the the applica- tion data that
2398 accompanies the KRB_AP_REQ.
2400 This field contains the microsecond part of the client's timestamp. Its
2401 value (before encryption) ranges from 0 to 999999. It often appears
2402 along with ctime. The two fields are used together to specify a
2403 reasonably accurate timestamp.
2405 This field contains the current time on the client's host.
2407 This field contains the client's choice for an encryption key which is
2408 to be used to protect this specific application session. Unless an
2409 application specifies otherwise, if this field is left out the session
2410 key from the ticket will be used.
2412 This optional field includes the initial sequence number to be used by
2413 the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to
2414 detect replays (It may also be used by application specific messages).
2415 When included in the authenticator this field specifies the initial
2416 sequence number for messages from the client to the server. When
2417 included in the AP-REP message, the initial sequence number is that for
2418 messages from the server to the client. When used in KRB_PRIV or
2419 KRB_SAFE messages, it is incremented by one after each message is sent.
2420 Sequence numbers fall in the range of 0 through 2^32 - 1 and wrap to
2421 zero following the value 2^32 - 1.
2423 For sequence numbers to adequately support the detection of replays
2424 they should be non-repeating, even across connection boundaries. The
2425 initial sequence number should be random and uniformly distributed
2427 Neuman, Ts'o, Kohl Expires: 25 December,
2430 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
2433 across the full space of possible sequence numbers, so that it cannot
2434 be guessed by an attacker and so that it and the successive sequence
2435 numbers do not repeat other sequences.
2437 This field is the same as described for the ticket in section 5.3.1. It
2438 is optional and will only appear when additional restrictions are to be
2439 placed on the use of a ticket, beyond those carried in the ticket
2442 5.4. Specifications for the AS and TGS exchanges
2444 This section specifies the format of the messages used in the exchange
2445 between the client and the Kerberos server. The format of possible error
2446 messages appears in section 5.9.1.
2448 5.4.1. KRB_KDC_REQ definition
2450 The KRB_KDC_REQ message has no type of its own. Instead, its type is one of
2451 KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is for an initial
2452 ticket or an additional ticket. In either case, the message is sent from the
2453 client to the Authentication Server to request credentials for a service.
2455 The message fields are:
2457 AS-REQ ::= [APPLICATION 10] KDC-REQ
2458 TGS-REQ ::= [APPLICATION 12] KDC-REQ
2460 KDC-REQ ::= SEQUENCE {
2462 msg-type[2] INTEGER,
2463 padata[3] SEQUENCE OF PA-DATA OPTIONAL,
2464 req-body[4] KDC-REQ-BODY
2467 PA-DATA ::= SEQUENCE {
2468 padata-type[1] INTEGER,
2469 padata-value[2] OCTET STRING,
2470 -- might be encoded AP-REQ
2473 KDC-REQ-BODY ::= SEQUENCE {
2474 kdc-options[0] KDCOptions,
2475 cname[1] PrincipalName OPTIONAL,
2476 -- Used only in AS-REQ
2477 realm[2] Realm, -- Server's realm
2478 -- Also client's in AS-REQ
2479 sname[3] PrincipalName OPTIONAL,
2480 from[4] KerberosTime OPTIONAL,
2481 till[5] KerberosTime OPTIONAL,
2482 rtime[6] KerberosTime OPTIONAL,
2484 etype[8] SEQUENCE OF INTEGER,
2486 -- in preference order
2487 addresses[9] HostAddresses OPTIONAL,
2488 enc-authorization-data[10] EncryptedData OPTIONAL,
2489 -- Encrypted AuthorizationData
2491 additional-tickets[11] SEQUENCE OF Ticket OPTIONAL
2495 Neuman, Ts'o, Kohl Expires: 25 December,
2498 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
2501 The fields in this message are:
2504 This field is included in each message, and specifies the protocol
2505 version number. This document specifies protocol version 5.
2507 This field indicates the type of a protocol message. It will almost
2508 always be the same as the application identifier associated with a
2509 message. It is included to make the identifier more readily accessible
2510 to the application. For the KDC-REQ message, this type will be
2511 KRB_AS_REQ or KRB_TGS_REQ.
2513 The padata (pre-authentication data) field contains a sequence of
2514 authentication information which may be needed before credentials can
2515 be issued or decrypted. In the case of requests for additional tickets
2516 (KRB_TGS_REQ), this field will include an element with padata-type of
2517 PA-TGS-REQ and data of an authentication header (ticket-granting ticket
2518 and authenticator). The checksum in the authenticator (which must be
2519 collision-proof) is to be computed over the KDC-REQ-BODY encoding. In
2520 most requests for initial authentication (KRB_AS_REQ) and most replies
2521 (KDC-REP), the padata field will be left out.
2523 This field may also contain information needed by certain extensions to
2524 the Kerberos protocol. For example, it might be used to initially
2525 verify the identity of a client before any response is returned. This
2526 is accomplished with a padata field with padata-type equal to
2527 PA-ENC-TIMESTAMP and padata-value defined as follows:
2529 padata-type ::= PA-ENC-TIMESTAMP
2530 padata-value ::= EncryptedData -- PA-ENC-TS-ENC
2532 PA-ENC-TS-ENC ::= SEQUENCE {
2533 patimestamp[0] KerberosTime, -- client's time
2534 pausec[1] INTEGER OPTIONAL
2537 with patimestamp containing the client's time and pausec containing the
2538 microseconds which may be omitted if a client will not generate more
2539 than one request per second. The ciphertext (padata-value) consists of
2540 the PA-ENC-TS-ENC sequence, encrypted using the client's secret key.
2542 [use-specified-kvno item is here for discussion and may be removed] It
2543 may also be used by the client to specify the version of a key that is
2544 being used for accompanying preauthentication, and/or which should be
2545 used to encrypt the reply from the KDC.
2547 PA-USE-SPECIFIED-KVNO ::= Integer
2549 The KDC should only accept and abide by the value of the
2550 use-specified-kvno preauthentication data field when the specified key
2551 is still valid and until use of a new key is confirmed. This situation
2552 is likely to occur primarily during the period during which an updated
2553 key is propagating to other KDC's in a realm.
2555 The padata field can also contain information needed to help the KDC or
2556 the client select the key needed for generating or decrypting the
2557 response. This form of the padata is useful for supporting the use of
2558 certain token cards with Kerberos. The details of such extensions are
2559 specified in separate documents. See [Pat92] for additional uses of
2562 Neuman, Ts'o, Kohl Expires: 25 December,
2565 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
2569 The padata-type element of the padata field indicates the way that the
2570 padata-value element is to be interpreted. Negative values of
2571 padata-type are reserved for unregistered use; non-negative values are
2572 used for a registered interpretation of the element type.
2574 This field is a placeholder delimiting the extent of the remaining
2575 fields. If a checksum is to be calculated over the request, it is
2576 calculated over an encoding of the KDC-REQ-BODY sequence which is
2577 enclosed within the req-body field.
2579 This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the
2580 KDC and indicates the flags that the client wants set on the tickets as
2581 well as other information that is to modify the behavior of the KDC.
2582 Where appropriate, the name of an option may be the same as the flag
2583 that is set by that option. Although in most case, the bit in the
2584 options field will be the same as that in the flags field, this is not
2585 guaranteed, so it is not acceptable to simply copy the options field to
2586 the flags field. There are various checks that must be made before
2587 honoring an option anyway.
2589 The kdc_options field is a bit-field, where the selected options are
2590 indicated by the bit being set (1), and the unselected options and
2591 reserved fields being reset (0). The encoding of the bits is specified
2592 in section 5.2. The options are described in more detail above in
2593 section 2. The meanings of the options are:
2595 Bit(s) Name Description
2597 Reserved for future expansion of
2602 The FORWARDABLE option indicates
2604 the ticket to be issued is to have
2606 forwardable flag set. It may only
2608 set on the initial request, or in a
2610 sequent request if the
2612 ticket on which it is based is also
2617 The FORWARDED option is only
2621 server and will only be honored if
2623 ticket-granting ticket in the
2625 has its FORWARDABLE bit set.
2627 option indicates that this is a
2629 for forwarding. The address(es) of
2631 host from which the resulting ticket
2633 to be valid are included in
2635 addresses field of the request.
2638 Neuman, Ts'o, Kohl Expires: 25 December,
2641 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
2645 The PROXIABLE option indicates that
2647 ticket to be issued is to have its
2649 iable flag set. It may only be set
2651 the initial request, or in a
2653 request if the ticket-granting ticket
2655 which it is based is also proxiable.
2658 The PROXY option indicates that this
2660 a request for a proxy. This option
2662 only be honored if the
2664 ticket in the request has its
2666 bit set. The address(es) of the
2668 from which the resulting ticket is to
2670 valid are included in the
2672 field of the request.
2675 The ALLOW-POSTDATE option indicates
2677 the ticket to be issued is to have
2679 MAY-POSTDATE flag set. It may only
2681 set on the initial request, or in a
2683 sequent request if the
2685 ticket on which it is based also has
2687 MAY-POSTDATE flag set.
2690 The POSTDATED option indicates that
2692 is a request for a postdated
2694 This option will only be honored if
2696 ticket-granting ticket on which it
2698 based has its MAY-POSTDATE flag
2700 The resulting ticket will also have
2702 INVALID flag set, and that flag may
2704 reset by a subsequent request to the
2706 after the starttime in the ticket
2711 This option is presently unused.
2714 The RENEWABLE option indicates that
2716 ticket to be issued is to have
2718 RENEWABLE flag set. It may only be
2720 on the initial request, or when
2722 ticket-granting ticket on which
2724 request is based is also renewable.
2726 this option is requested, then the
2728 field in the request contains
2730 desired absolute expiration time for
2735 These options are presently unused.
2738 Neuman, Ts'o, Kohl Expires: 25 December,
2741 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
2744 14 REQUEST-ANONYMOUS
2745 The REQUEST-ANONYMOUS option
2747 that the ticket to be issued is not
2749 identify the user to which it
2751 issued. Instead, the principal
2753 ier is to be generic, as specified
2755 the policy of the realm (e.g.
2757 anonymous@realm). The purpose of
2759 ticket is only to securely distribute
2761 session key, and not to identify
2763 user. The ANONYMOUS flag on the
2765 to be returned should be set. If
2767 local realms policy does not
2769 anonymous credentials, the request is
2774 Reserved for future use.
2776 26 DISABLE-TRANSITED-CHECK
2777 By default the KDC will check the
2778 transited field of a ticket-granting-
2779 ticket against the policy of the local
2780 realm before it will issue derivative
2781 tickets based on the ticket granting
2782 ticket. If this flag is set in the
2783 request, checking of the transited
2785 is disabled. Tickets issued without
2787 performance of this check will be
2789 by the reset (0) value of the
2790 TRANSITED-POLICY-CHECKED flag,
2791 indicating to the application server
2792 that the tranisted field must be
2794 locally. KDC's are encouraged but not
2795 required to honor the
2796 DISABLE-TRANSITED-CHECK option.
2799 The RENEWABLE-OK option indicates that
2801 renewable ticket will be acceptable if
2803 ticket with the requested life
2805 otherwise be provided. If a ticket
2807 the requested life cannot be
2809 then a renewable ticket may be
2811 with a renew-till equal to the
2813 requested endtime. The value of
2815 renew-till field may still be limited
2817 local limits, or limits selected by
2819 individual principal or server.
2822 This option is used only by the
2824 granting service. The
2826 option indicates that the ticket for
2828 end server is to be encrypted in
2830 session key from the additional
2832 granting ticket provided.
2835 Neuman, Ts'o, Kohl Expires: 25 December,
2838 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
2842 Reserved for future use.
2845 This option is used only by the
2847 granting service. The RENEW
2849 indicates that the present request
2851 for a renewal. The ticket provided
2853 encrypted in the secret key for
2855 server on which it is valid.
2857 option will only be honored if
2859 ticket to be renewed has its
2861 flag set and if the time in its
2863 till field has not passed. The
2865 to be renewed is passed in the
2867 field as part of the
2872 This option is used only by the
2874 granting service. The VALIDATE
2876 indicates that the request is to
2878 date a postdated ticket. It will
2880 be honored if the ticket presented
2882 postdated, presently has its
2884 flag set, and would be otherwise
2886 at this time. A ticket cannot be
2888 dated before its starttime. The
2890 presented for validation is encrypted
2892 the key of the server for which it
2894 valid and is passed in the padata
2896 as part of the authentication header.
2899 These fields are the same as those described for the ticket in section
2900 5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY option is
2901 specified. If absent, the name of the server is taken from the name of
2902 the client in the ticket passed as additional-tickets.
2903 enc-authorization-data
2904 The enc-authorization-data, if present (and it can only be present in
2905 the TGS_REQ form), is an encoding of the desired authorization-data
2906 encrypted under the sub-session key if present in the Authenticator, or
2907 alternatively from the session key in the ticket-granting ticket, both
2908 from the padata field in the KRB_AP_REQ.
2910 This field specifies the realm part of the server's principal
2911 identifier. In the AS exchange, this is also the realm part of the
2912 client's principal identifier.
2914 This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket
2915 requests when the requested ticket is to be postdated. It specifies the
2916 desired start time for the requested ticket. If this field is omitted
2917 then the KDC should use the current time instead.
2919 This field contains the expiration date requested by the client in a
2920 ticket request. It is optional and if omitted the requested ticket is
2921 to have the maximum endtime permitted according to KDC policy for the
2922 parties to the authentication exchange as limited by expiration date of
2923 the ticket granting ticket or other preauthentication credentials.
2925 Neuman, Ts'o, Kohl Expires: 25 December,
2928 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
2932 This field is the requested renew-till time sent from a client to the
2933 KDC in a ticket request. It is optional.
2935 This field is part of the KDC request and response. It it intended to
2936 hold a random number generated by the client. If the same number is
2937 included in the encrypted response from the KDC, it provides evidence
2938 that the response is fresh and has not been replayed by an attacker.
2939 Nonces must never be re-used. Ideally, it should be generated randomly,
2940 but if the correct time is known, it may suffice[25].
2942 This field specifies the desired encryption algorithm to be used in the
2945 This field is included in the initial request for tickets, and
2946 optionally included in requests for additional tickets from the
2947 ticket-granting server. It specifies the addresses from which the
2948 requested ticket is to be valid. Normally it includes the addresses for
2949 the client's host. If a proxy is requested, this field will contain
2950 other addresses. The contents of this field are usually copied by the
2951 KDC into the caddr field of the resulting ticket.
2953 Additional tickets may be optionally included in a request to the
2954 ticket-granting server. If the ENC-TKT-IN-SKEY option has been
2955 specified, then the session key from the additional ticket will be used
2956 in place of the server's key to encrypt the new ticket. If more than
2957 one option which requires additional tickets has been specified, then
2958 the additional tickets are used in the order specified by the ordering
2959 of the options bits (see kdc-options, above).
2961 The application code will be either ten (10) or twelve (12) depending on
2962 whether the request is for an initial ticket (AS-REQ) or for an additional
2965 The optional fields (addresses, authorization-data and additional-tickets)
2966 are only included if necessary to perform the operation specified in the
2969 It should be noted that in KRB_TGS_REQ, the protocol version number appears
2970 twice and two different message types appear: the KRB_TGS_REQ message
2971 contains these fields as does the authentication header (KRB_AP_REQ) that is
2972 passed in the padata field.
2974 5.4.2. KRB_KDC_REP definition
2976 The KRB_KDC_REP message format is used for the reply from the KDC for either
2977 an initial (AS) request or a subsequent (TGS) request. There is no message
2978 type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or
2979 KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply
2980 depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in
2981 the client's secret key, and the client's key version number is included in
2982 the key version number for the encrypted data. For KRB_TGS_REP, the
2983 ciphertext is encrypted in the sub-session key from the Authenticator, or if
2984 absent, the session key from the ticket-granting ticket used in the request.
2985 In that case, no version number will be present in the EncryptedData
2989 Neuman, Ts'o, Kohl Expires: 25 December,
2992 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
2995 The KRB_KDC_REP message contains the following fields:
2997 AS-REP ::= [APPLICATION 11] KDC-REP
2998 TGS-REP ::= [APPLICATION 13] KDC-REP
3000 KDC-REP ::= SEQUENCE {
3002 msg-type[1] INTEGER,
3003 padata[2] SEQUENCE OF PA-DATA OPTIONAL,
3005 cname[4] PrincipalName,
3007 enc-part[6] EncryptedData
3010 EncASRepPart ::= [APPLICATION 25[27]] EncKDCRepPart
3011 EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart
3013 EncKDCRepPart ::= SEQUENCE {
3014 key[0] EncryptionKey,
3015 last-req[1] LastReq,
3017 key-expiration[3] KerberosTime OPTIONAL,
3018 flags[4] TicketFlags,
3019 authtime[5] KerberosTime,
3020 starttime[6] KerberosTime OPTIONAL,
3021 endtime[7] KerberosTime,
3022 renew-till[8] KerberosTime OPTIONAL,
3024 sname[10] PrincipalName,
3025 caddr[11] HostAddresses OPTIONAL
3029 These fields are described above in section 5.4.1. msg-type is either
3030 KRB_AS_REP or KRB_TGS_REP.
3032 This field is described in detail in section 5.4.1. One possible use
3033 for this field is to encode an alternate "mix-in" string to be used
3034 with a string-to-key algorithm (such as is described in section 6.3.2).
3035 This ability is useful to ease transitions if a realm name needs to
3036 change (e.g. when a company is acquired); in such a case all existing
3037 password-derived entries in the KDC database would be flagged as
3038 needing a special mix-in string until the next password change.
3039 crealm, cname, srealm and sname
3040 These fields are the same as those described for the ticket in section
3043 The newly-issued ticket, from section 5.3.1.
3045 This field is a place holder for the ciphertext and related information
3046 that forms the encrypted part of a message. The description of the
3047 encrypted part of the message follows each appearance of this field.
3048 The encrypted part is encoded as described in section 6.1.
3050 This field is the same as described for the ticket in section 5.3.1.
3052 Neuman, Ts'o, Kohl Expires: 25 December,
3055 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
3059 This field is returned by the KDC and specifies the time(s) of the last
3060 request by a principal. Depending on what information is available,
3061 this might be the last time that a request for a ticket-granting ticket
3062 was made, or the last time that a request based on a ticket-granting
3063 ticket was successful. It also might cover all servers for a realm, or
3064 just the particular server. Some implementations may display this
3065 information to the user to aid in discovering unauthorized use of one's
3066 identity. It is similar in spirit to the last login time displayed when
3067 logging into timesharing systems.
3069 This field is described above in section 5.4.1.
3071 The key-expiration field is part of the response from the KDC and
3072 specifies the time that the client's secret key is due to expire. The
3073 expiration might be the result of password aging or an account
3074 expiration. This field will usually be left out of the TGS reply since
3075 the response to the TGS request is encrypted in a session key and no
3076 client information need be retrieved from the KDC database. It is up to
3077 the application client (usually the login program) to take appropriate
3078 action (such as notifying the user) if the expiration time is imminent.
3079 flags, authtime, starttime, endtime, renew-till and caddr
3080 These fields are duplicates of those found in the encrypted portion of
3081 the attached ticket (see section 5.3.1), provided so the client may
3082 verify they match the intended request and to assist in proper ticket
3083 caching. If the message is of type KRB_TGS_REP, the caddr field will
3084 only be filled in if the request was for a proxy or forwarded ticket,
3085 or if the user is substituting a subset of the addresses from the
3086 ticket granting ticket. If the client-requested addresses are not
3087 present or not used, then the addresses contained in the ticket will be
3088 the same as those included in the ticket-granting ticket.
3090 5.5. Client/Server (CS) message specifications
3092 This section specifies the format of the messages used for the
3093 authentication of the client to the application server.
3095 5.5.1. KRB_AP_REQ definition
3097 The KRB_AP_REQ message contains the Kerberos protocol version number, the
3098 message type KRB_AP_REQ, an options field to indicate any options in use,
3099 and the ticket and authenticator themselves. The KRB_AP_REQ message is often
3100 referred to as the 'authentication header'.
3102 AP-REQ ::= [APPLICATION 14] SEQUENCE {
3104 msg-type[1] INTEGER,
3105 ap-options[2] APOptions,
3107 authenticator[4] EncryptedData
3110 APOptions ::= BIT STRING {
3117 Neuman, Ts'o, Kohl Expires: 25 December,
3120 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
3124 These fields are described above in section 5.4.1. msg-type is
3127 This field appears in the application request (KRB_AP_REQ) and affects
3128 the way the request is processed. It is a bit-field, where the selected
3129 options are indicated by the bit being set (1), and the unselected
3130 options and reserved fields being reset (0). The encoding of the bits
3131 is specified in section 5.2. The meanings of the options are:
3133 Bit(s) Name Description
3136 Reserved for future expansion of this
3140 The USE-SESSION-KEY option indicates
3141 that the ticket the client is presenting
3142 to a server is encrypted in the session
3143 key from the server's ticket-granting
3144 ticket. When this option is not speci-
3145 fied, the ticket is encrypted in the
3146 server's secret key.
3149 The MUTUAL-REQUIRED option tells the
3150 server that the client requires mutual
3151 authentication, and that it must respond
3152 with a KRB_AP_REP message.
3155 Reserved for future use.
3158 This field is a ticket authenticating the client to the server.
3160 This contains the authenticator, which includes the client's choice of
3161 a subkey. Its encoding is described in section 5.3.2.
3163 5.5.2. KRB_AP_REP definition
3165 The KRB_AP_REP message contains the Kerberos protocol version number, the
3166 message type, and an encrypted time- stamp. The message is sent in in
3167 response to an application request (KRB_AP_REQ) where the mutual
3168 authentication option has been selected in the ap-options field.
3170 AP-REP ::= [APPLICATION 15] SEQUENCE {
3172 msg-type[1] INTEGER,
3173 enc-part[2] EncryptedData
3176 EncAPRepPart ::= [APPLICATION 27[29]] SEQUENCE {
3177 ctime[0] KerberosTime,
3179 subkey[2] EncryptionKey OPTIONAL,
3180 seq-number[3] INTEGER OPTIONAL
3183 Neuman, Ts'o, Kohl Expires: 25 December,
3186 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
3189 The encoded EncAPRepPart is encrypted in the shared session key of the
3190 ticket. The optional subkey field can be used in an application-arranged
3191 negotiation to choose a per association session key.
3194 These fields are described above in section 5.4.1. msg-type is
3197 This field is described above in section 5.4.2.
3199 This field contains the current time on the client's host.
3201 This field contains the microsecond part of the client's timestamp.
3203 This field contains an encryption key which is to be used to protect
3204 this specific application session. See section 3.2.6 for specifics on
3205 how this field is used to negotiate a key. Unless an application
3206 specifies otherwise, if this field is left out, the sub-session key
3207 from the authenticator, or if also left out, the session key from the
3208 ticket will be used.
3210 5.5.3. Error message reply
3212 If an error occurs while processing the application request, the KRB_ERROR
3213 message will be sent in response. See section 5.9.1 for the format of the
3214 error message. The cname and crealm fields may be left out if the server
3215 cannot determine their appropriate values from the corresponding KRB_AP_REQ
3216 message. If the authenticator was decipherable, the ctime and cusec fields
3217 will contain the values from it.
3219 5.6. KRB_SAFE message specification
3221 This section specifies the format of a message that can be used by either
3222 side (client or server) of an application to send a tamper-proof message to
3223 its peer. It presumes that a session key has previously been exchanged (for
3224 example, by using the KRB_AP_REQ/KRB_AP_REP messages).
3226 5.6.1. KRB_SAFE definition
3228 The KRB_SAFE message contains user data along with a collision-proof
3229 checksum keyed with the last encryption key negotiated via subkeys, or the
3230 session key if no negotiation has occured. The message fields are:
3232 KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
3234 msg-type[1] INTEGER,
3235 safe-body[2] KRB-SAFE-BODY,
3239 KRB-SAFE-BODY ::= SEQUENCE {
3240 user-data[0] OCTET STRING,
3241 timestamp[1] KerberosTime OPTIONAL,
3242 usec[2] INTEGER OPTIONAL,
3243 seq-number[3] INTEGER OPTIONAL,
3244 s-address[4] HostAddress OPTIONAL,
3245 r-address[5] HostAddress OPTIONAL
3249 Neuman, Ts'o, Kohl Expires: 25 December,
3252 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
3256 These fields are described above in section 5.4.1. msg-type is
3259 This field is a placeholder for the body of the KRB-SAFE message.
3261 This field contains the checksum of the application data. Checksum
3262 details are described in section 6.4. The checksum is computed over the
3263 encoding of the KRB-SAFE sequence. First, the cksum is zeroed and the
3264 checksum is computed over the encoding of the KRB-SAFE sequence, then
3265 the checksum is set to the result of that computation, and finally the
3266 KRB-SAFE sequence is encoded again.
3268 This field is part of the KRB_SAFE and KRB_PRIV messages and contain
3269 the application specific data that is being passed from the sender to
3272 This field is part of the KRB_SAFE and KRB_PRIV messages. Its contents
3273 are the current time as known by the sender of the message. By checking
3274 the timestamp, the recipient of the message is able to make sure that
3275 it was recently generated, and is not a replay.
3277 This field is part of the KRB_SAFE and KRB_PRIV headers. It contains
3278 the microsecond part of the timestamp.
3280 This field is described above in section 5.3.2.
3282 This field specifies the address in use by the sender of the message.
3283 It may be omitted if not required by the application protocol. The
3284 application designer considering omission of this field is warned, that
3285 the inclusion of this address prevents some kinds of replay attacks
3286 (e.g., reflection attacks) and that it is only acceptable to omit this
3287 address if there is sufficient information in the integrity protected
3288 part of the application message for the recipient to unambiguously
3289 determine if it was the intended recipient.
3291 This field specifies the address in use by the recipient of the
3292 message. It may be omitted for some uses (such as broadcast protocols),
3293 but the recipient may arbitrarily reject such messages. This field
3294 along with s-address can be used to help detect messages which have
3295 been incorrectly or maliciously delivered to the wrong recipient.
3297 5.7. KRB_PRIV message specification
3299 This section specifies the format of a message that can be used by either
3300 side (client or server) of an application to securely and privately send a
3301 message to its peer. It presumes that a session key has previously been
3302 exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages).
3304 5.7.1. KRB_PRIV definition
3306 The KRB_PRIV message contains user data encrypted in the Session Key. The
3309 KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
3311 msg-type[1] INTEGER,
3312 enc-part[3] EncryptedData
3316 Neuman, Ts'o, Kohl Expires: 25 December,
3319 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
3322 EncKrbPrivPart ::= [APPLICATION 28[31]] SEQUENCE {
3323 user-data[0] OCTET STRING,
3324 timestamp[1] KerberosTime OPTIONAL,
3325 usec[2] INTEGER OPTIONAL,
3326 seq-number[3] INTEGER OPTIONAL,
3327 s-address[4] HostAddress OPTIONAL, -- sender's
3329 r-address[5] HostAddress OPTIONAL -- recip's
3334 These fields are described above in section 5.4.1. msg-type is
3337 This field holds an encoding of the EncKrbPrivPart sequence encrypted
3338 under the session key[32]. This encrypted encoding is used for the
3339 enc-part field of the KRB-PRIV message. See section 6 for the format of
3341 user-data, timestamp, usec, s-address and r-address
3342 These fields are described above in section 5.6.1.
3344 This field is described above in section 5.3.2.
3346 5.8. KRB_CRED message specification
3348 This section specifies the format of a message that can be used to send
3349 Kerberos credentials from one principal to another. It is presented here to
3350 encourage a common mechanism to be used by applications when forwarding
3351 tickets or providing proxies to subordinate servers. It presumes that a
3352 session key has already been exchanged perhaps by using the
3353 KRB_AP_REQ/KRB_AP_REP messages.
3355 5.8.1. KRB_CRED definition
3357 The KRB_CRED message contains a sequence of tickets to be sent and
3358 information needed to use the tickets, including the session key from each.
3359 The information needed to use the tickets is encrypted under an encryption
3360 key previously exchanged or transferred alongside the KRB_CRED message. The
3363 KRB-CRED ::= [APPLICATION 22] SEQUENCE {
3365 msg-type[1] INTEGER, -- KRB_CRED
3366 tickets[2] SEQUENCE OF Ticket,
3367 enc-part[3] EncryptedData
3370 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
3371 ticket-info[0] SEQUENCE OF KrbCredInfo,
3372 nonce[1] INTEGER OPTIONAL,
3373 timestamp[2] KerberosTime OPTIONAL,
3374 usec[3] INTEGER OPTIONAL,
3375 s-address[4] HostAddress OPTIONAL,
3376 r-address[5] HostAddress OPTIONAL
3379 KrbCredInfo ::= SEQUENCE {
3380 key[0] EncryptionKey,
3381 prealm[1] Realm OPTIONAL,
3383 Neuman, Ts'o, Kohl Expires: 25 December,
3386 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
3389 pname[2] PrincipalName OPTIONAL,
3390 flags[3] TicketFlags OPTIONAL,
3391 authtime[4] KerberosTime OPTIONAL,
3392 starttime[5] KerberosTime OPTIONAL,
3393 endtime[6] KerberosTime OPTIONAL
3394 renew-till[7] KerberosTime OPTIONAL,
3395 srealm[8] Realm OPTIONAL,
3396 sname[9] PrincipalName OPTIONAL,
3397 caddr[10] HostAddresses OPTIONAL
3401 These fields are described above in section 5.4.1. msg-type is
3404 These are the tickets obtained from the KDC specifically for use by the
3405 intended recipient. Successive tickets are paired with the
3406 corresponding KrbCredInfo sequence from the enc-part of the KRB-CRED
3409 This field holds an encoding of the EncKrbCredPart sequence encrypted
3410 under the session key shared between the sender and the intended
3411 recipient. This encrypted encoding is used for the enc-part field of
3412 the KRB-CRED message. See section 6 for the format of the ciphertext.
3414 If practical, an application may require the inclusion of a nonce
3415 generated by the recipient of the message. If the same value is
3416 included as the nonce in the message, it provides evidence that the
3417 message is fresh and has not been replayed by an attacker. A nonce must
3418 never be re-used; it should be generated randomly by the recipient of
3419 the message and provided to the sender of the message in an application
3422 These fields specify the time that the KRB-CRED message was generated.
3423 The time is used to provide assurance that the message is fresh.
3424 s-address and r-address
3425 These fields are described above in section 5.6.1. They are used
3426 optionally to provide additional assurance of the integrity of the
3429 This field exists in the corresponding ticket passed by the KRB-CRED
3430 message and is used to pass the session key from the sender to the
3431 intended recipient. The field's encoding is described in section 6.2.
3433 The following fields are optional. If present, they can be associated with
3434 the credentials in the remote ticket file. If left out, then it is assumed
3435 that the recipient of the credentials already knows their value.
3438 The name and realm of the delegated principal identity.
3439 flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr
3440 These fields contain the values of the correspond- ing fields from the
3441 ticket found in the ticket field. Descriptions of the fields are
3442 identical to the descriptions in the KDC-REP message.
3445 Neuman, Ts'o, Kohl Expires: 25 December,
3448 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
3451 5.9. Error message specification
3453 This section specifies the format for the KRB_ERROR message. The fields
3454 included in the message are intended to return as much information as
3455 possible about an error. It is not expected that all the information
3456 required by the fields will be available for all types of errors. If the
3457 appropriate information is not available when the message is composed, the
3458 corresponding field will be left out of the message.
3460 Note that since the KRB_ERROR message is only optionally integrity
3461 protected, it is quite possible for an intruder to synthesize or modify such
3462 a message. In particular, this means that unless appropriate integrity
3463 protection mechanisms have been applied to the KRB_ERROR message, the client
3464 should not use any fields in this message for security-critical purposes,
3465 such as setting a system clock or generating a fresh authenticator. The
3466 message can be useful, however, for advising a user on the reason for some
3469 5.9.1. KRB_ERROR definition
3471 The KRB_ERROR message consists of the following fields:
3473 KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
3475 msg-type[1] INTEGER,
3476 ctime[2] KerberosTime OPTIONAL,
3477 cusec[3] INTEGER OPTIONAL,
3478 stime[4] KerberosTime,
3480 error-code[6] INTEGER,
3481 crealm[7] Realm OPTIONAL,
3482 cname[8] PrincipalName OPTIONAL,
3483 realm[9] Realm, -- Correct realm
3484 sname[10] PrincipalName, -- Correct name
3485 e-text[11] GeneralString OPTIONAL,
3486 e-data[12] OCTET STRING OPTIONAL,
3487 e-cksum[13] Checksum OPTIONAL,
3488 (*REMOVE7/14*) e-typed-data[14] SEQUENCE of ETypedData
3493 These fields are described above in section 5.4.1. msg-type is
3496 This field is described above in section 5.4.1.
3498 This field is described above in section 5.5.2.
3500 This field contains the current time on the server. It is of type
3503 This field contains the microsecond part of the server's timestamp. Its
3504 value ranges from 0 to 999999. It appears along with stime. The two
3505 fields are used in conjunction to specify a reasonably accurate
3508 Neuman, Ts'o, Kohl Expires: 25 December,
3511 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
3515 This field contains the error code returned by Kerberos or the server
3516 when a request fails. To interpret the value of this field see the list
3517 of error codes in section 8. Implementations are encouraged to provide
3518 for national language support in the display of error messages.
3519 crealm, cname, srealm and sname
3520 These fields are described above in section 5.3.1.
3522 This field contains additional text to help explain the error code
3523 associated with the failed request (for example, it might include a
3524 principal name which was unknown).
3526 This field contains additional data about the error for use by the
3527 application to help it recover from or handle the error. If present,
3528 this field will contain the encoding of a sequence of TypedData
3529 (TYPED-DATA below), unless the errorcode is KDC_ERR_PREAUTH_REQUIRED,
3530 in which case it will contain the encoding of a sequence of of padata
3531 fields (METHOD-DATA below), each corresponding to an acceptable
3532 pre-authentication method and optionally containing data for the
3535 TYPED-DATA ::= SEQUENCE of TypeData
3536 METHOD-DATA ::= SEQUENCE of PA-DATA
3538 TypedData ::= SEQUENCE {
3539 data-type[0] INTEGER,
3540 data-value[1] OCTET STRING OPTIONAL
3543 Note that e-data-types have been reserved for all PA data types defined
3544 prior to July 1999. For the KDC_ERR_PREAUTH_REQUIRED message, when
3545 using new PA data types defined in July 1999 or later, the METHOD-DATA
3546 sequence must itself be encapsulated in an TypedData element of type
3547 TD-PADATA. All new implementations interpreting the METHOD-DATA field
3548 for the KDC_ERR_PREAUTH_REQUIRED message must accept a type of
3549 TD-PADATA, extract the typed data field and interpret the use any
3550 elements encapsulated in the TD-PADATA elements as if they were present
3551 in the METHOD-DATA sequence.
3553 This field contains an optional checksum for the KRB-ERROR message. The
3554 checksum is calculated over the Kerberos ASN.1 encoding of the
3555 KRB-ERROR message with the checksum absent. The checksum is then added
3556 to the KRB-ERROR structure and the message is re-encoded. The Checksum
3557 should be calculated using the session key from the ticket granting
3558 ticket or service ticket, where available. If the error is in response
3559 to a TGS or AP request, the checksum should be calculated uing the the
3560 session key from the client's ticket. If the error is in response to an
3561 AS request, then the checksum should be calulated using the client's
3562 secret key ONLY if there has been suitable preauthentication to prove
3563 knowledge of the secret key by the client[33]. If a checksum can not be
3564 computed because the key to be used is not available, no checksum will
3567 [***Will be deleted 7/14***] This field contains optional data that may
3568 be used to help the client recover from the indicated error. [This
3569 could contain the METHOD-DATA specified since I don't think anyone
3570 actually uses it yet. It could also contain the PA-DATA sequence for
3571 the preauth required error if we had a clear way to transition to the
3573 Neuman, Ts'o, Kohl Expires: 25 December,
3576 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
3579 use of this field from the use of the untyped e-data field.] For
3580 example, this field may specify the key version of the key used to
3581 verify preauthentication:
3583 e-data-type := 20 -- Key version number
3584 e-data-value := Integer -- Key version number used to
3585 verify preauthentication
3587 6. Encryption and Checksum Specifications
3589 The Kerberos protocols described in this document are designed to use stream
3590 encryption ciphers, which can be simulated using commonly available block
3591 encryption ciphers, such as the Data Encryption Standard, [DES77] in
3592 conjunction with block chaining and checksum methods [DESM80]. Encryption is
3593 used to prove the identities of the network entities participating in
3594 message exchanges. The Key Distribution Center for each realm is trusted by
3595 all principals registered in that realm to store a secret key in confidence.
3596 Proof of knowledge of this secret key is used to verify the authenticity of
3597 a principal. [*** Discussion above will change to use 3DES as example
3600 The KDC uses the principal's secret key (in the AS exchange) or a shared
3601 session key (in the TGS exchange) to encrypt responses to ticket requests;
3602 the ability to obtain the secret key or session key implies the knowledge of
3603 the appropriate keys and the identity of the KDC. The ability of a principal
3604 to decrypt the KDC response and present a Ticket and a properly formed
3605 Authenticator (generated with the session key from the KDC response) to a
3606 service verifies the identity of the principal; likewise the ability of the
3607 service to extract the session key from the Ticket and prove its knowledge
3608 thereof in a response verifies the identity of the service.
3610 The Kerberos protocols generally assume that the encryption used is secure
3611 from cryptanalysis; however, in some cases, the order of fields in the
3612 encrypted portions of messages are arranged to minimize the effects of
3613 poorly chosen keys. It is still important to choose good keys. If keys are
3614 derived from user-typed passwords, those passwords need to be well chosen to
3615 make brute force attacks more difficult. Poorly chosen keys still make easy
3616 targets for intruders.
3618 The following sections specify the encryption and checksum mechanisms
3619 currently defined for Kerberos. The encodings, chaining, and padding
3620 requirements for each are described. For encryption methods, it is often
3621 desirable to place random information (often referred to as a confounder) at
3622 the start of the message. The requirements for a confounder are specified
3623 with each encryption mechanism.
3625 Some encryption systems use a block-chaining method to improve the the
3626 security characteristics of the ciphertext. However, these chaining methods
3627 often don't provide an integrity check upon decryption. Such systems (such
3628 as DES in CBC mode) must be augmented with a checksum of the plain-text
3629 which can be verified at decryption and used to detect any tampering or
3630 damage. Such checksums should be good at detecting burst errors in the
3631 input. If any damage is detected, the decryption routine is expected to
3632 return an error indicating the failure of an integrity check. Each
3633 encryption type is expected to provide and verify an appropriate checksum.
3634 The specification of each encryption method sets out its checksum
3638 Neuman, Ts'o, Kohl Expires: 25 December,
3641 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
3644 Finally, where a key is to be derived from a user's password, an algorithm
3645 for converting the password to a key of the appropriate type is included. It
3646 is desirable for the string to key function to be one-way, and for the
3647 mapping to be different in different realms. This is important because users
3648 who are registered in more than one realm will often use the same password
3649 in each, and it is desirable that an attacker compromising the Kerberos
3650 server in one realm not obtain or derive the user's key in another.
3652 For an discussion of the integrity characteristics of the candidate
3653 encryption and checksum methods considered for Kerberos, the reader is
3656 6.1. Encryption Specifications
3658 The following ASN.1 definition describes all encrypted messages. The
3659 enc-part field which appears in the unencrypted part of messages in section
3660 5 is a sequence consisting of an encryption type, an optional key version
3661 number, and the ciphertext.
3663 EncryptedData ::= SEQUENCE {
3664 etype[0] INTEGER, -- EncryptionType
3665 kvno[1] INTEGER OPTIONAL,
3666 cipher[2] OCTET STRING -- ciphertext
3670 This field identifies which encryption algorithm was used to encipher
3671 the cipher. Detailed specifications for selected encryption types
3672 appear later in this section.
3674 This field contains the version number of the key under which data is
3675 encrypted. It is only present in messages encrypted under long lasting
3676 keys, such as principals' secret keys.
3678 This field contains the enciphered text, encoded as an OCTET STRING.
3680 The cipher field is generated by applying the specified encryption algorithm
3681 to data composed of the message and algorithm-specific inputs. Encryption
3682 mechanisms defined for use with Kerberos must take sufficient measures to
3683 guarantee the integrity of the plaintext, and we recommend they also take
3684 measures to protect against precomputed dictionary attacks. If the
3685 encryption algorithm is not itself capable of doing so, the protections can
3686 often be enhanced by adding a checksum and a confounder.
3688 The suggested format for the data to be encrypted includes a confounder, a
3689 checksum, the encoded plaintext, and any necessary padding. The msg-seq
3690 field contains the part of the protocol message described in section 5 which
3691 is to be encrypted. The confounder, checksum, and padding are all untagged
3692 and untyped, and their length is exactly sufficient to hold the appropriate
3693 item. The type and length is implicit and specified by the particular
3694 encryption type being used (etype). The format for the data to be encrypted
3695 is described in the following diagram:
3698 Neuman, Ts'o, Kohl Expires: 25 December,
3701 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
3704 +-----------+----------+-------------+-----+
3705 |confounder | check | msg-seq | pad |
3706 +-----------+----------+-------------+-----+
3708 The format cannot be described in ASN.1, but for those who prefer an
3709 ASN.1-like notation:
3711 CipherText ::= ENCRYPTED SEQUENCE {
3712 confounder[0] UNTAGGED[35] OCTET STRING(conf_length) OPTIONAL,
3713 check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL,
3714 msg-seq[2] MsgSequence,
3715 pad UNTAGGED OCTET STRING(pad_length) OPTIONAL
3718 One generates a random confounder of the appropriate length, placing it in
3719 confounder; zeroes out check; calculates the appropriate checksum over
3720 confounder, check, and msg-seq, placing the result in check; adds the
3721 necessary padding; then encrypts using the specified encryption type and the
3724 Unless otherwise specified, a definition of an encryption algorithm that
3725 specifies a checksum, a length for the confounder field, or an octet
3726 boundary for padding uses this ciphertext format[36]. Those fields which are
3727 not specified will be omitted.
3729 In the interest of allowing all implementations using a particular
3730 encryption type to communicate with all others using that type, the
3731 specification of an encryption type defines any checksum that is needed as
3732 part of the encryption process. If an alternative checksum is to be used, a
3733 new encryption type must be defined.
3735 Some cryptosystems require additional information beyond the key and the
3736 data to be encrypted. For example, DES, when used in cipher-block-chaining
3737 mode, requires an initialization vector. If required, the description for
3738 each encryption type must specify the source of such additional information.
3739 6.2. Encryption Keys
3741 The sequence below shows the encoding of an encryption key:
3743 EncryptionKey ::= SEQUENCE {
3745 keyvalue[1] OCTET STRING
3749 This field specifies the type of encryption that is to be performed
3750 using the key that follows in the keyvalue field. It will always
3751 correspond to the etype to be used to generate or decode the
3752 EncryptedData. In cases when multiple algorithms use a common kind of
3753 key (e.g., if the encryption algorithm uses an alternate checksum
3754 algorithm for an integrity check, or a different chaining mechanism),
3755 the keytype provides information needed to determine which algorithm is
3758 This field contains the key itself, encoded as an octet string.
3760 All negative values for the encryption key type are reserved for local use.
3761 All non-negative values are reserved for officially assigned type fields and
3765 Neuman, Ts'o, Kohl Expires: 25 December,
3768 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
3771 6.3. Encryption Systems
3773 6.3.1. The NULL Encryption System (null)
3775 If no encryption is in use, the encryption system is said to be the NULL
3776 encryption system. In the NULL encryption system there is no checksum,
3777 confounder or padding. The ciphertext is simply the plaintext. The NULL Key
3778 is used by the null encryption system and is zero octets in length, with
3781 6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc)
3783 The des-cbc-crc encryption mode encrypts information under the Data
3784 Encryption Standard [DES77] using the cipher block chaining mode [DESM80]. A
3785 CRC-32 checksum (described in ISO 3309 [ISO3309]) is applied to the
3786 confounder and message sequence (msg-seq) and placed in the cksum field. DES
3787 blocks are 8 bytes. As a result, the data to be encrypted (the concatenation
3788 of confounder, checksum, and message) must be padded to an 8 byte boundary
3789 before encryption. The details of the encryption of this data are identical
3790 to those for the des-cbc-md5 encryption mode.
3792 Note that, since the CRC-32 checksum is not collision-proof, an attacker
3793 could use a probabilistic chosen-plaintext attack to generate a valid
3794 message even if a confounder is used [SG92]. The use of collision-proof
3795 checksums is recommended for environments where such attacks represent a
3796 significant threat. The use of the CRC-32 as the checksum for ticket or
3797 authenticator is no longer mandated as an interoperability requirement for
3798 Kerberos Version 5 Specification 1 (See section 9.1 for specific details).
3800 6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4)
3802 The des-cbc-md4 encryption mode encrypts information under the Data
3803 Encryption Standard [DES77] using the cipher block chaining mode [DESM80].
3804 An MD4 checksum (described in [MD492]) is applied to the confounder and
3805 message sequence (msg-seq) and placed in the cksum field. DES blocks are 8
3806 bytes. As a result, the data to be encrypted (the concatenation of
3807 confounder, checksum, and message) must be padded to an 8 byte boundary
3808 before encryption. The details of the encryption of this data are identical
3809 to those for the des-cbc-md5 encryption mode.
3811 6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5)
3813 The des-cbc-md5 encryption mode encrypts information under the Data
3814 Encryption Standard [DES77] using the cipher block chaining mode [DESM80].
3815 An MD5 checksum (described in [MD5-92].) is applied to the confounder and
3816 message sequence (msg-seq) and placed in the cksum field. DES blocks are 8
3817 bytes. As a result, the data to be encrypted (the concatenation of
3818 confounder, checksum, and message) must be padded to an 8 byte boundary
3821 Plaintext and DES ciphtertext are encoded as blocks of 8 octets which are
3822 concatenated to make the 64-bit inputs for the DES algorithms. The first
3823 octet supplies the 8 most significant bits (with the octet's MSbit used as
3824 the DES input block's MSbit, etc.), the second octet the next 8 bits, ...,
3825 and the eighth octet supplies the 8 least significant bits.
3828 Neuman, Ts'o, Kohl Expires: 25 December,
3831 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
3834 Encryption under DES using cipher block chaining requires an additional
3835 input in the form of an initialization vector. Unless otherwise specified,
3836 zero should be used as the initialization vector. Kerberos' use of DES
3837 requires an 8 octet confounder.
3839 The DES specifications identify some 'weak' and 'semi-weak' keys; those keys
3840 shall not be used for encrypting messages for use in Kerberos. Additionally,
3841 because of the way that keys are derived for the encryption of checksums,
3842 keys shall not be used that yield 'weak' or 'semi-weak' keys when
3843 eXclusive-ORed with the hexadecimal constant F0F0F0F0F0F0F0F0.
3845 A DES key is 8 octets of data, with keytype one (1). This consists of 56
3846 bits of key, and 8 parity bits (one per octet). The key is encoded as a
3847 series of 8 octets written in MSB-first order. The bits within the key are
3848 also encoded in MSB order. For example, if the encryption key is
3849 (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where
3850 B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the parity
3851 bits, the first octet of the key would be B1,B2,...,B7,P1 (with B1 as the
3852 MSbit). [See the FIPS 81 introduction for reference.]
3854 String to key transformation
3856 To generate a DES key from a text string (password), a "salt" is
3857 concatenated to the text string, and then padded with ASCII nulls to an 8
3858 byte boundary. This "salt" is normally the realm and each component of the
3859 principal's name appended. However, sometimes different salts are used ---
3860 for example, when a realm is renamed, or if a user changes her username, or
3861 for compatibility with Kerberos V4 (whose string-to-key algorithm uses a
3862 null string for the salt). This string is then fan-folded and eXclusive-ORed
3863 with itself to form an 8 byte DES key. Before eXclusive-ORing a block, every
3864 byte is shifted one bit to the left to leave the lowest bit zero. The key is
3865 the "corrected" by correcting the parity on the key, and if the key matches
3866 a 'weak' or 'semi-weak' key as described in the DES specification, it is
3867 eXclusive-ORed with the constant 00000000000000F0. This key is then used to
3868 generate a DES CBC checksum on the initial string (with the salt appended).
3869 The result of the CBC checksum is the "corrected" as described above to form
3870 the result which is return as the key. Pseudocode follows:
3872 name_to_default_salt(realm, name) {
3874 for(each component in name) {
3880 key_correction(key) {
3882 if (is_weak_key_key(key))
3887 string_to_key(string,salt) {
3893 Neuman, Ts'o, Kohl Expires: 25 December,
3896 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
3899 pad(s); /* with nulls to 8 byte boundary */
3900 for(8byteblock in s) {
3906 left shift every byte in 8byteblock one bit;
3907 tempkey = tempkey XOR 8byteblock;
3909 tempkey = key_correction(tempkey);
3910 key = key_correction(DES-CBC-check(s,tempkey));
3914 6.3.5. Triple DES with HMAC-SHA1 Kerberos Encryption Type with Key
3915 Derivation [Horowitz]
3917 [*** Note that there are several 3DES varients in use in different Kerberos
3918 implemenations, updates to this section will be sent to the cat list and
3919 krb-protocol list prior to the Oslo IETF, including the key derivation and
3920 non-key derivation varients ***] NOTE: This description currently refers to
3921 documents, the contents of which might be bettered included by value in this
3922 spec. The description below was provided by Marc Horowitz, and the form in
3923 which it will finally appear is yet to be determined. This description is
3924 included in this version of the draft because it does describe the
3925 implemenation ready for use with the MIT implementation. Note also that the
3926 encryption identifier has been left unspecified here because the value from
3927 Marc Horowitz's spec conflicted with some other impmenentations implemented
3928 based on perevious versions of the specification.
3930 This encryption type is based on the Triple DES cryptosystem, the HMAC-SHA1
3931 [Krawczyk96] message authentication algorithm, and key derivation for
3932 Kerberos V5 [HorowitzB96].
3934 The des3-cbc-hmac-sha1 encryption type has been assigned the value ??. The
3935 hmac-sha1-des3 checksum type has been assigned the value 12.
3937 Encryption Type des3-cbc-hmac-sha1
3939 EncryptedData using this type must be generated as described in
3940 [Horowitz96]. The encryption algorithm is Triple DES in Outer-CBC mode. The
3941 keyed hash algorithm is HMAC-SHA1. Unless otherwise specified, a zero IV
3942 must be used. If the length of the input data is not a multiple of the block
3943 size, zero octets must be used to pad the plaintext to the next eight-octet
3944 boundary. The counfounder must be eight random octets (one block).
3946 Checksum Type hmac-sha1-des3
3948 Checksums using this type must be generated as described in [Horowitz96].
3949 The keyed hash algorithm is HMAC-SHA1.
3953 The EncryptionKey value is 24 octets long. The 7 most significant bits of
3954 each octet contain key bits, and the least significant bit is the inverse of
3955 the xor of the key bits.
3958 Neuman, Ts'o, Kohl Expires: 25 December,
3961 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
3964 For the purposes of key derivation, the block size is 64 bits, and the key
3965 size is 168 bits. The 168 bits output by key derivation are converted to an
3966 EncryptionKey value as follows. First, the 168 bits are divided into three
3967 groups of 56 bits, which are expanded individually into 64 bits as follows:
3970 9 10 11 12 13 14 15 p
3971 17 18 19 20 21 22 23 p
3972 25 26 27 28 29 30 31 p
3973 33 34 35 36 37 38 39 p
3974 41 42 43 44 45 46 47 p
3975 49 50 51 52 53 54 55 p
3976 56 48 40 32 24 16 8 p
3978 The "p" bits are parity bits computed over the data bits. The output of the
3979 three expansions are concatenated to form the EncryptionKey value.
3981 When the HMAC-SHA1 of a string is computed, the key is used in the
3986 In the Kerberos protocol, cryptographic keys are used in a number of places.
3987 In order to minimize the effect of compromising a key, it is desirable to
3988 use a different key for each of these places. Key derivation [Horowitz96]
3989 can be used to construct different keys for each operation from the keys
3990 transported on the network. For this to be possible, a small change to the
3991 specification is necessary.
3993 This section specifies a profile for the use of key derivation [Horowitz96]
3994 with Kerberos. For each place where a key is used, a ``key usage'' must is
3995 specified for that purpose. The key, key usage, and encryption/checksum type
3996 together describe the transformation from plaintext to ciphertext, or
3997 plaintext to checksum.
4001 This is a complete list of places keys are used in the kerberos protocol,
4002 with key usage values and RFC 1510 section numbers:
4004 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the
4005 client key (section 5.4.1)
4006 2. AS-REP Ticket and TGS-REP Ticket (includes tgs session key or
4007 application session key), encrypted with the service key
4009 3. AS-REP encrypted part (includes tgs session key or application
4010 session key), encrypted with the client key (section 5.4.2)
4011 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
4012 session key (section 5.4.1)
4013 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
4014 authenticator subkey (section 5.4.1)
4015 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed
4016 with the tgs session key (sections 5.3.2, 5.4.1)
4017 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs
4018 authenticator subkey), encrypted with the tgs session key
4020 8. TGS-REP encrypted part (includes application session key),
4021 encrypted with the tgs session key (section 5.4.2)
4023 Neuman, Ts'o, Kohl Expires: 25 December,
4026 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
4029 9. TGS-REP encrypted part (includes application session key),
4030 encrypted with the tgs authenticator subkey (section 5.4.2)
4031 10. AP-REQ Authenticator cksum, keyed with the application session
4033 11. AP-REQ Authenticator (includes application authenticator
4034 subkey), encrypted with the application session key (section
4036 12. AP-REP encrypted part (includes application session subkey),
4037 encrypted with the application session key (section 5.5.2)
4038 13. KRB-PRIV encrypted part, encrypted with a key chosen by the
4039 application (section 5.7.1)
4040 14. KRB-CRED encrypted part, encrypted with a key chosen by the
4041 application (section 5.6.1)
4042 15. KRB-SAVE cksum, keyed with a key chosen by the application
4044 18. KRB-ERROR checksum (e-cksum in section 5.9.1)
4045 19. AD-KDCIssued checksum (ad-checksum in appendix B.1)
4046 20. Checksum for Mandatory Ticket Extensions (appendix B.6)
4047 21. Checksum in Authorization Data in Ticket Extensions (appendix B.7)
4049 Key usage values between 1024 and 2047 (inclusive) are reserved for
4050 application use. Applications should use even values for encryption and odd
4051 values for checksums within this range.
4053 A few of these key usages need a little clarification. A service which
4054 receives an AP-REQ has no way to know if the enclosed Ticket was part of an
4055 AS-REP or TGS-REP. Therefore, key usage 2 must always be used for generating
4056 a Ticket, whether it is in response to an AS- REQ or TGS-REQ.
4058 There might exist other documents which define protocols in terms of the
4059 RFC1510 encryption types or checksum types. Such documents would not know
4060 about key usages. In order that these documents continue to be meaningful
4061 until they are updated, key usages 1024 and 1025 must be used to derive keys
4062 for encryption and checksums, respectively. New protocols defined in terms
4063 of the Kerberos encryption and checksum types should use their own key
4064 usages. Key usages may be registered with IANA to avoid conflicts. Key
4065 usages must be unsigned 32 bit integers. Zero is not permitted.
4067 Defining Cryptosystems Using Key Derivation
4069 Kerberos requires that the ciphertext component of EncryptedData be
4070 tamper-resistant as well as confidential. This implies encryption and
4071 integrity functions, which must each use their own separate keys. So, for
4072 each key usage, two keys must be generated, one for encryption (Ke), and one
4075 Ke = DK(protocol key, key usage | 0xAA)
4076 Ki = DK(protocol key, key usage | 0x55)
4078 where the protocol key is from the EncryptionKey from the wire protocol, and
4079 the key usage is represented as a 32 bit integer in network byte order. The
4080 ciphertest must be generated from the plaintext as follows:
4082 ciphertext = E(Ke, confounder | plaintext | padding) |
4083 H(Ki, confounder | plaintext | padding)
4085 The confounder and padding are specific to the encryption algorithm E.
4088 Neuman, Ts'o, Kohl Expires: 25 December,
4091 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
4094 When generating a checksum only, there is no need for a confounder or
4095 padding. Again, a new key (Kc) must be used. Checksums must be generated
4096 from the plaintext as follows:
4098 Kc = DK(protocol key, key usage | 0x99)
4100 MAC = H(Kc, plaintext)
4102 Note that each enctype is described by an encryption algorithm E and a keyed
4103 hash algorithm H, and each checksum type is described by a keyed hash
4104 algorithm H. HMAC, with an appropriate hash, is recommended for use as H.
4106 Key Derivation from Passwords
4108 The well-known constant for password key derivation must be the byte string
4109 {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values correspond to the
4110 ASCII encoding for the string "kerberos".
4114 The following is the ASN.1 definition used for a checksum:
4116 Checksum ::= SEQUENCE {
4117 cksumtype[0] INTEGER,
4118 checksum[1] OCTET STRING
4122 This field indicates the algorithm used to generate the accompanying
4125 This field contains the checksum itself, encoded as an octet string.
4127 Detailed specification of selected checksum types appear later in this
4128 section. Negative values for the checksum type are reserved for local use.
4129 All non-negative values are reserved for officially assigned type fields and
4132 Checksums used by Kerberos can be classified by two properties: whether they
4133 are collision-proof, and whether they are keyed. It is infeasible to find
4134 two plaintexts which generate the same checksum value for a collision-proof
4135 checksum. A key is required to perturb or initialize the algorithm in a
4136 keyed checksum. To prevent message-stream modification by an active
4137 attacker, unkeyed checksums should only be used when the checksum and
4138 message will be subsequently encrypted (e.g. the checksums defined as part
4139 of the encryption algorithms covered earlier in this section).
4141 Collision-proof checksums can be made tamper-proof if the checksum value is
4142 encrypted before inclusion in a message. In such cases, the composition of
4143 the checksum and the encryption algorithm must be considered a separate
4144 checksum algorithm (e.g. RSA-MD5 encrypted using DES is a new checksum
4145 algorithm of type RSA-MD5-DES). For most keyed checksums, as well as for the
4146 encrypted forms of unkeyed collision-proof checksums, Kerberos prepends a
4147 confounder before the checksum is calculated.
4150 Neuman, Ts'o, Kohl Expires: 25 December,
4153 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
4156 6.4.1. The CRC-32 Checksum (crc32)
4158 The CRC-32 checksum calculates a checksum based on a cyclic redundancy check
4159 as described in ISO 3309 [ISO3309]. The resulting checksum is four (4)
4160 octets in length. The CRC-32 is neither keyed nor collision-proof. The use
4161 of this checksum is not recommended. An attacker using a probabilistic
4162 chosen-plaintext attack as described in [SG92] might be able to generate an
4163 alternative message that satisfies the checksum. The use of collision-proof
4164 checksums is recommended for environments where such attacks represent a
4167 6.4.2. The RSA MD4 Checksum (rsa-md4)
4169 The RSA-MD4 checksum calculates a checksum using the RSA MD4 algorithm
4170 [MD4-92]. The algorithm takes as input an input message of arbitrary length
4171 and produces as output a 128-bit (16 octet) checksum. RSA-MD4 is believed to
4174 6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4-des)
4176 The RSA-MD4-DES checksum calculates a keyed collision-proof checksum by
4177 prepending an 8 octet confounder before the text, applying the RSA MD4
4178 checksum algorithm, and encrypting the confounder and the checksum using DES
4179 in cipher-block-chaining (CBC) mode using a variant of the key, where the
4180 variant is computed by eXclusive-ORing the key with the constant
4181 F0F0F0F0F0F0F0F0[39]. The initialization vector should be zero. The
4182 resulting checksum is 24 octets long (8 octets of which are redundant). This
4183 checksum is tamper-proof and believed to be collision-proof.
4185 The DES specifications identify some weak keys' and 'semi-weak keys'; those
4186 keys shall not be used for generating RSA-MD4 checksums for use in Kerberos.
4188 The format for the checksum is described in the follow- ing diagram:
4190 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4191 | des-cbc(confounder + rsa-md4(confounder+msg),key=var(key),iv=0) |
4192 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4194 The format cannot be described in ASN.1, but for those who prefer an
4195 ASN.1-like notation:
4197 rsa-md4-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE {
4198 confounder[0] UNTAGGED OCTET STRING(8),
4199 check[1] UNTAGGED OCTET STRING(16)
4202 6.4.4. The RSA MD5 Checksum (rsa-md5)
4204 The RSA-MD5 checksum calculates a checksum using the RSA MD5 algorithm.
4205 [MD5-92]. The algorithm takes as input an input message of arbitrary length
4206 and produces as output a 128-bit (16 octet) checksum. RSA-MD5 is believed to
4209 6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5-des)
4211 The RSA-MD5-DES checksum calculates a keyed collision-proof checksum by
4212 prepending an 8 octet confounder before the text, applying the RSA MD5
4213 checksum algorithm, and encrypting the confounder and the checksum using DES
4215 Neuman, Ts'o, Kohl Expires: 25 December,
4218 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
4221 in cipher-block-chaining (CBC) mode using a variant of the key, where the
4222 variant is computed by eXclusive-ORing the key with the hexadecimal constant
4223 F0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting
4224 checksum is 24 octets long (8 octets of which are redundant). This checksum
4225 is tamper-proof and believed to be collision-proof.
4227 The DES specifications identify some 'weak keys' and 'semi-weak keys'; those
4228 keys shall not be used for encrypting RSA-MD5 checksums for use in Kerberos.
4230 The format for the checksum is described in the following diagram:
4232 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4233 | des-cbc(confounder + rsa-md5(confounder+msg),key=var(key),iv=0) |
4234 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4236 The format cannot be described in ASN.1, but for those who prefer an
4237 ASN.1-like notation:
4239 rsa-md5-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE {
4240 confounder[0] UNTAGGED OCTET STRING(8),
4241 check[1] UNTAGGED OCTET STRING(16)
4244 6.4.6. DES cipher-block chained checksum (des-mac)
4246 The DES-MAC checksum is computed by prepending an 8 octet confounder to the
4247 plaintext, performing a DES CBC-mode encryption on the result using the key
4248 and an initialization vector of zero, taking the last block of the
4249 ciphertext, prepending the same confounder and encrypting the pair using DES
4250 in cipher-block-chaining (CBC) mode using a a variant of the key, where the
4251 variant is computed by eXclusive-ORing the key with the hexadecimal constant
4252 F0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting
4253 checksum is 128 bits (16 octets) long, 64 bits of which are redundant. This
4254 checksum is tamper-proof and collision-proof.
4256 The format for the checksum is described in the following diagram:
4258 +--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
4259 | des-cbc(confounder + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) |
4260 +--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
4262 The format cannot be described in ASN.1, but for those who prefer an
4263 ASN.1-like notation:
4265 des-mac-checksum ::= ENCRYPTED UNTAGGED SEQUENCE {
4266 confounder[0] UNTAGGED OCTET STRING(8),
4267 check[1] UNTAGGED OCTET STRING(8)
4270 The DES specifications identify some 'weak' and 'semi-weak' keys; those keys
4271 shall not be used for generating DES-MAC checksums for use in Kerberos, nor
4272 shall a key be used whose variant is 'weak' or 'semi-weak'.
4274 6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative (rsa-md4-des-k)
4276 The RSA-MD4-DES-K checksum calculates a keyed collision-proof checksum by
4277 applying the RSA MD4 checksum algorithm and encrypting the results using DES
4278 in cipher-block-chaining (CBC) mode using a DES key as both key and
4280 Neuman, Ts'o, Kohl Expires: 25 December,
4283 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
4286 initialization vector. The resulting checksum is 16 octets long. This
4287 checksum is tamper-proof and believed to be collision-proof. Note that this
4288 checksum type is the old method for encoding the RSA-MD4-DES checksum and it
4289 is no longer recommended.
4291 6.4.8. DES cipher-block chained checksum alternative (des-mac-k)
4293 The DES-MAC-K checksum is computed by performing a DES CBC-mode encryption
4294 of the plaintext, and using the last block of the ciphertext as the checksum
4295 value. It is keyed with an encryption key and an initialization vector; any
4296 uses which do not specify an additional initialization vector will use the
4297 key as both key and initialization vector. The resulting checksum is 64 bits
4298 (8 octets) long. This checksum is tamper-proof and collision-proof. Note
4299 that this checksum type is the old method for encoding the DES-MAC checksum
4300 and it is no longer recommended. The DES specifications identify some 'weak
4301 keys' and 'semi-weak keys'; those keys shall not be used for generating
4302 DES-MAC checksums for use in Kerberos.
4304 7. Naming Constraints
4308 Although realm names are encoded as GeneralStrings and although a realm can
4309 technically select any name it chooses, interoperability across realm
4310 boundaries requires agreement on how realm names are to be assigned, and
4311 what information they imply.
4313 To enforce these conventions, each realm must conform to the conventions
4314 itself, and it must require that any realms with which inter-realm keys are
4315 shared also conform to the conventions and require the same from its
4318 Kerberos realm names are case sensitive. Realm names that differ only in the
4319 case of the characters are not equivalent. There are presently four styles
4320 of realm names: domain, X500, other, and reserved. Examples of each style
4323 domain: ATHENA.MIT.EDU (example)
4324 X500: C=US/O=OSF (example)
4325 other: NAMETYPE:rest/of.name=without-restrictions (example)
4326 reserved: reserved, but will not conflict with above
4328 Domain names must look like domain names: they consist of components
4329 separated by periods (.) and they contain neither colons (:) nor slashes
4330 (/). Domain names must be converted to upper case when used as realm names.
4332 X.500 names contain an equal (=) and cannot contain a colon (:) before the
4333 equal. The realm names for X.500 names will be string representations of the
4334 names with components separated by slashes. Leading and trailing slashes
4335 will not be included.
4337 Names that fall into the other category must begin with a prefix that
4338 contains no equal (=) or period (.) and the prefix must be followed by a
4339 colon (:) and the rest of the name. All prefixes must be assigned before
4340 they may be used. Presently none are assigned.
4343 Neuman, Ts'o, Kohl Expires: 25 December,
4346 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
4349 The reserved category includes strings which do not fall into the first
4350 three categories. All names in this category are reserved. It is unlikely
4351 that names will be assigned to this category unless there is a very strong
4352 argument for not using the 'other' category.
4354 These rules guarantee that there will be no conflicts between the various
4355 name styles. The following additional constraints apply to the assignment of
4356 realm names in the domain and X.500 categories: the name of a realm for the
4357 domain or X.500 formats must either be used by the organization owning (to
4358 whom it was assigned) an Internet domain name or X.500 name, or in the case
4359 that no such names are registered, authority to use a realm name may be
4360 derived from the authority of the parent realm. For example, if there is no
4361 domain name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can
4362 authorize the creation of a realm with that name.
4364 This is acceptable because the organization to which the parent is assigned
4365 is presumably the organization authorized to assign names to its children in
4366 the X.500 and domain name systems as well. If the parent assigns a realm
4367 name without also registering it in the domain name or X.500 hierarchy, it
4368 is the parent's responsibility to make sure that there will not in the
4369 future exists a name identical to the realm name of the child unless it is
4370 assigned to the same entity as the realm name.
4372 7.2. Principal Names
4374 As was the case for realm names, conventions are needed to ensure that all
4375 agree on what information is implied by a principal name. The name-type
4376 field that is part of the principal name indicates the kind of information
4377 implied by the name. The name-type should be treated as a hint. Ignoring the
4378 name type, no two names can be the same (i.e. at least one of the
4379 components, or the realm, must be different). The following name types are
4382 name-type value meaning
4384 NT-UNKNOWN 0 Name type not known
4385 NT-PRINCIPAL 1 General principal name (e.g. username, or DCE
4387 NT-SRV-INST 2 Service and other unique instance (krbtgt)
4388 NT-SRV-HST 3 Service with host name as instance (telnet,
4390 NT-SRV-XHST 4 Service with slash-separated host name components
4392 NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 1779]
4394 When a name implies no information other than its uniqueness at a particular
4395 time the name type PRINCIPAL should be used. The principal name type should
4396 be used for users, and it might also be used for a unique server. If the
4397 name is a unique machine generated ID that is guaranteed never to be
4398 reassigned then the name type of UID should be used (note that it is
4399 generally a bad idea to reassign names of any type since stale entries might
4400 remain in access control lists).
4402 If the first component of a name identifies a service and the remaining
4403 components identify an instance of the service in a server specified manner,
4404 then the name type of SRV-INST should be used. An example of this name type
4405 is the Kerberos ticket-granting service whose name has a first component of
4406 krbtgt and a second component identifying the realm for which the ticket is
4410 Neuman, Ts'o, Kohl Expires: 25 December,
4413 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
4416 If instance is a single component following the service name and the
4417 instance identifies the host on which the server is running, then the name
4418 type SRV-HST should be used. This type is typically used for Internet
4419 services such as telnet and the Berkeley R commands. If the separate
4420 components of the host name appear as successive components following the
4421 name of the service, then the name type SRV-XHST should be used. This type
4422 might be used to identify servers on hosts with X.500 names where the slash
4423 (/) might otherwise be ambiguous.
4425 A name type of NT-X500-PRINCIPAL should be used when a name from an X.509
4426 certificiate is translated into a Kerberos name. The encoding of the X.509
4427 name as a Kerberos principal shall conform to the encoding rules specified
4430 A name type of UNKNOWN should be used when the form of the name is not
4431 known. When comparing names, a name of type UNKNOWN will match principals
4432 authenticated with names of any type. A principal authenticated with a name
4433 of type UNKNOWN, however, will only match other names of type UNKNOWN.
4435 Names of any type with an initial component of 'krbtgt' are reserved for the
4436 Kerberos ticket granting service. See section 8.2.3 for the form of such
4439 7.2.1. Name of server principals
4441 The principal identifier for a server on a host will generally be composed
4442 of two parts: (1) the realm of the KDC with which the server is registered,
4443 and (2) a two-component name of type NT-SRV-HST if the host name is an
4444 Internet domain name or a multi-component name of type NT-SRV-XHST if the
4445 name of the host is of a form such as X.500 that allows slash (/)
4446 separators. The first component of the two- or multi-component name will
4447 identify the service and the latter components will identify the host. Where
4448 the name of the host is not case sensitive (for example, with Internet
4449 domain names) the name of the host must be lower case. If specified by the
4450 application protocol for services such as telnet and the Berkeley R commands
4451 which run with system privileges, the first component may be the string
4452 'host' instead of a service specific identifier. When a host has an official
4453 name and one or more aliases, the official name of the host must be used
4454 when constructing the name of the server principal.
4456 8. Constants and other defined values
4458 8.1. Host address types
4460 All negative values for the host address type are reserved for local use.
4461 All non-negative values are reserved for officially assigned type fields and
4464 The values of the types for the following addresses are chosen to match the
4465 defined address family constants in the Berkeley Standard Distributions of
4466 Unix. They can be found in with symbolic names AF_xxx (where xxx is an
4467 abbreviation of the address family name).
4469 Internet (IPv4) Addresses
4471 Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in MSB
4472 order. The type of IPv4 addresses is two (2).
4475 Neuman, Ts'o, Kohl Expires: 25 December,
4478 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
4481 Internet (IPv6) Addresses [Westerlund]
4483 IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. The
4484 type of IPv6 addresses is twenty-four (24). [RFC1883] [RFC1884]. The
4485 following addresses (see [RFC1884]) MUST not appear in any Kerberos packet:
4487 * the Unspecified Address
4488 * the Loopback Address
4489 * Link-Local addresses
4491 IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2.
4495 CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB order.
4496 The type of CHAOSnet addresses is five (5).
4500 ISO addresses are variable-length. The type of ISO addresses is seven (7).
4502 Xerox Network Services (XNS) addresses
4504 XNS addresses are 48-bit (6-octet) quantities, encoded in MSB order. The
4505 type of XNS addresses is six (6).
4507 AppleTalk Datagram Delivery Protocol (DDP) addresses
4509 AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit network
4510 number. The first octet of the address is the node number; the remaining two
4511 octets encode the network number in MSB order. The type of AppleTalk DDP
4512 addresses is sixteen (16).
4514 DECnet Phase IV addresses
4516 DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. The
4517 type of DECnet Phase IV addresses is twelve (12).
4521 Netbios addresses are 16-octet addresses typically composed of 1 to 15
4522 characters, trailing blank (ascii char 20) filled, with a 16th octet of 0x0.
4523 The type of Netbios addresses is 20 (0x14).
4527 8.2.1. UDP/IP transport
4529 When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request using UDP
4530 IP transport, the client shall send a UDP datagram containing only an
4531 encoding of the request to port 88 (decimal) at the KDC's IP address; the
4532 KDC will respond with a reply datagram containing only an encoding of the
4533 reply message (either a KRB_ERROR or a KRB_KDC_REP) to the sending port at
4534 the sender's IP address. Kerberos servers supporting IP transport must
4535 accept UDP requests on port 88 (decimal). The response to a request made
4536 through UDP/IP transport must also use UDP/IP transport.
4539 Neuman, Ts'o, Kohl Expires: 25 December,
4542 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
4545 8.2.2. TCP/IP transport [Westerlund,Danielsson]
4547 Kerberos servers (KDC's) should accept TCP requests on port 88 (decimal) and
4548 clients should support the sending of TCP requests on port 88 (decimal).
4549 When the KRB_KDC_REQ message is sent to the KDC over a TCP stream, a new
4550 connection will be established for each authentication exchange (request and
4551 response). The KRB_KDC_REP or KRB_ERROR message will be returned to the
4552 client on the same TCP stream that was established for the request. The
4553 response to a request made through TCP/IP transport must also use TCP/IP
4554 transport. Implementors should note that some extentions to the Kerberos
4555 protocol will not work if any implementation not supporting the TCP
4556 transport is involved (client or KDC). Implementors are strongly urged to
4557 support the TCP transport on both the client and server and are advised that
4558 the current notation of "should" support will likely change in the future to
4559 must support. The KDC may close the TCP stream after sending a response, but
4560 may leave the stream open if it expects a followup - in which case it may
4561 close the stream at any time if resource constratints or other factors make
4562 it desirable to do so. Care must be taken in managing TCP/IP connections
4563 with the KDC to prevent denial of service attacks based on the number of
4564 TCP/IP connections with the KDC that remain open. If multiple exchanges with
4565 the KDC are needed for certain forms of preauthentication, multiple TCP
4566 connections may be required. A client may close the stream after receiving
4567 response, and should close the stream if it does not expect to send followup
4568 messages. The client must be prepared to have the stream closed by the KDC
4569 at anytime, in which case it must simply connect again when it is ready to
4570 send subsequent messages.
4572 The first four octets of the TCP stream used to transmit the request request
4573 will encode in network byte order the length of the request (KRB_KDC_REQ),
4574 and the length will be followed by the request itself. The response will
4575 similarly be preceeded by a 4 octet encoding in network byte order of the
4576 length of the KRB_KDC_REP or the KRB_ERROR message and will be followed by
4577 the KRB_KDC_REP or the KRB_ERROR response. If the sign bit is set on the
4578 integer represented by the first 4 octets, then the next 4 octets will be
4579 read, extending the length of the field by another 4 octets (less the sign
4580 bit which is reserved for future expansion).
4582 8.2.3. OSI transport
4584 During authentication of an OSI client to an OSI server, the mutual
4585 authentication of an OSI server to an OSI client, the transfer of
4586 credentials from an OSI client to an OSI server, or during exchange of
4587 private or integrity checked messages, Kerberos protocol messages may be
4588 treated as opaque objects and the type of the authentication mechanism will
4591 OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1),
4592 security(5),kerberosv5(2)}
4594 Depending on the situation, the opaque object will be an authentication
4595 header (KRB_AP_REQ), an authentication reply (KRB_AP_REP), a safe message
4596 (KRB_SAFE), a private message (KRB_PRIV), or a credentials message
4597 (KRB_CRED). The opaque data contains an application code as specified in the
4598 ASN.1 description for each message. The application code may be used by
4599 Kerberos to determine the message type.
4602 Neuman, Ts'o, Kohl Expires: 25 December,
4605 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
4608 8.2.3. Name of the TGS
4610 The principal identifier of the ticket-granting service shall be composed of
4611 three parts: (1) the realm of the KDC issuing the TGS ticket (2) a two-part
4612 name of type NT-SRV-INST, with the first part "krbtgt" and the second part
4613 the name of the realm which will accept the ticket-granting ticket. For
4614 example, a ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be
4615 used to get tickets from the ATHENA.MIT.EDU KDC has a principal identifier
4616 of "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A
4617 ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be used to get
4618 tickets from the MIT.EDU realm has a principal identifier of
4619 "ATHENA.MIT.EDU" (realm), ("krbtgt", "MIT.EDU") (name).
4621 8.3. Protocol constants and associated values
4623 The following tables list constants used in the protocol and defines their
4624 meanings. Ranges are specified in the "specification" section that limit the
4625 values of constants for which values are defined here. This allows
4626 implementations to make assumptions about the maximum values that will be
4627 received for these constants. Implementation receiving values outside the
4628 range specified in the "specification" section may reject the request, but
4629 they must recover cleanly.
4631 Encryption type etype value block size minimum pad size confounder
4638 des3-cbc-md5 5 8 0 8
4640 des3-cbc-sha1 7 8 0 8
4642 (old-pkinit-will-remove)
4643 dsaWithSHA1-CmsOID 9 (pkinit)
4644 md5WithRSAEncryption-CmsOID 10 (pkinit)
4645 sha1WithRSAEncryption-CmsOID 11 (pkinit)
4646 rc2CBC-EnvOID 12 (pkinit)
4647 rsaEncryption-EnvOID 13 (pkinit from PKCS#1
4649 rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1
4651 des-ede3-cbc-Env-OID 15 (pkinit)
4652 des3kd-cbc-sha1 ?? 8 0 8
4653 ENCTYPE_PK_CROSS 48 (reserved for pkcross)
4656 Checksum type sumtype value checksum size
4666 hmac-sha1-des3 12 20 (I had this as 10, is it
4670 Neuman, Ts'o, Kohl Expires: 25 December,
4673 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
4676 padata type padata-type value
4683 PA-SANDIA-SECUREID 6
4686 PA-CYBERSAFE-SECUREID 9
4689 SAM-CHALLENGE 12 (sam/otp)
4690 SAM-RESPONSE 13 (sam/otp)
4691 PA-PK-AS-REQ 14 (pkinit)
4692 PA-PK-AS-REP 15 (pkinit)
4693 PA-PK-AS-SIGN 16 (***remove on 7/14***)
4694 PA-PK-KEY-REQ 17 (***remove on 7/14***)
4695 PA-PK-KEY-REP 18 (***remove on 7/14***)
4696 PA-USE-SPECIFIED-KVNO 20
4697 SAM-REDIRECT 21 (sam/otp)
4698 PA-GET-FROM-TYPED-DATA 22
4700 data-type value form of typed-data
4704 TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS
4705 TD-KRB-PRINCIPAL 102
4707 TD-TRUSTED-CERTIFIERS 104
4708 TD-CERTIFICATE-INDEX 105
4710 authorization data type ad-type value
4712 AD-INTENDED-FOR-SERVER 2
4713 AD-INTENDED-FOR-APPLICATION-CLASS 3
4716 AD-MANDATORY-TICKET-EXTENSIONS 6
4717 AD-IN-TICKET-EXTENSIONS 7
4718 reserved values 8-63
4722 Ticket Extension Types
4724 TE-TYPE-NULL 0 Null ticket extension
4725 TE-TYPE-EXTERNAL-ADATA 1 Integrity protected authorization data
4726 2 TE-TYPE-PKCROSS-KDC (I have reservations)
4727 TE-TYPE-PKCROSS-CLIENT 3 PKCROSS cross realm key ticket
4728 TE-TYPE-CYBERSAFE-EXT 4 Assigned to CyberSafe Corp
4729 5 TE-TYPE-DEST-HOST (I have reservations)
4732 Neuman, Ts'o, Kohl Expires: 25 December,
4735 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
4738 alternate authentication type method-type value
4739 reserved values 0-63
4740 ATT-CHALLENGE-RESPONSE 64
4742 transited encoding type tr-type value
4743 DOMAIN-X500-COMPRESS 1
4744 reserved values all others
4746 Label Value Meaning or MIT code
4748 pvno 5 current Kerberos protocol version number
4752 KRB_AS_REQ 10 Request for initial authentication
4753 KRB_AS_REP 11 Response to KRB_AS_REQ request
4754 KRB_TGS_REQ 12 Request for authentication based on TGT
4755 KRB_TGS_REP 13 Response to KRB_TGS_REQ request
4756 KRB_AP_REQ 14 application request to server
4757 KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL
4758 KRB_SAFE 20 Safe (checksummed) application message
4759 KRB_PRIV 21 Private (encrypted) application message
4760 KRB_CRED 22 Private (encrypted) message to forward
4762 KRB_ERROR 30 Error response
4766 KRB_NT_UNKNOWN 0 Name type not known
4767 KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for
4769 KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt)
4770 KRB_NT_SRV_HST 3 Service with host name as instance (telnet,
4772 KRB_NT_SRV_XHST 4 Service with host as remaining components
4773 KRB_NT_UID 5 Unique ID
4774 KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distingished name [RFC 2253]
4778 KDC_ERR_NONE 0 No error
4779 KDC_ERR_NAME_EXP 1 Client's entry in database has expired
4780 KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired
4781 KDC_ERR_BAD_PVNO 3 Requested protocol version # not
4783 KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key
4784 KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key
4785 KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database
4786 KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database
4787 KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database
4788 KDC_ERR_NULL_KEY 9 The client or server has a null key
4789 KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating
4790 KDC_ERR_NEVER_VALID 11 Requested start time is later than end
4792 KDC_ERR_POLICY 12 KDC policy rejects request
4793 KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option
4794 KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type
4795 KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type
4796 KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type
4797 KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type
4798 KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked
4799 KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked
4800 KDC_ERR_TGT_REVOKED 20 TGT has been revoked
4802 Neuman, Ts'o, Kohl Expires: 25 December,
4805 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
4808 KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later
4809 KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later
4810 KDC_ERR_KEY_EXPIRED 23 Password has expired - change password
4811 KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was
4813 KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired
4815 KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match
4816 KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user
4818 KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path
4819 KDC_ERR_SVC_UNAVAILABLE 29 A service is not available
4820 KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field
4822 KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired
4823 KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid
4824 KRB_AP_ERR_REPEAT 34 Request is a replay
4825 KRB_AP_ERR_NOT_US 35 The ticket isn't for us
4826 KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match
4827 KRB_AP_ERR_SKEW 37 Clock skew too great
4828 KRB_AP_ERR_BADADDR 38 Incorrect net address
4829 KRB_AP_ERR_BADVERSION 39 Protocol version mismatch
4830 KRB_AP_ERR_MSG_TYPE 40 Invalid msg type
4831 KRB_AP_ERR_MODIFIED 41 Message stream modified
4832 KRB_AP_ERR_BADORDER 42 Message out of order
4833 KRB_AP_ERR_BADKEYVER 44 Specified version of key is not
4835 KRB_AP_ERR_NOKEY 45 Service key not available
4836 KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed
4837 KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction
4838 KRB_AP_ERR_METHOD 48 Alternative authentication method
4840 KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message
4841 KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in
4843 KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path
4844 KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP, retry with TCP
4845 KRB_ERR_GENERIC 60 Generic error (description in e-text)
4846 KRB_ERR_FIELD_TOOLONG 61 Field is too long for this
4848 KDC_ERROR_CLIENT_NOT_TRUSTED 62 (pkinit)
4849 KDC_ERROR_KDC_NOT_TRUSTED 63 (pkinit)
4850 KDC_ERROR_INVALID_SIG 64 (pkinit)
4851 KDC_ERR_KEY_TOO_WEAK 65 (pkinit)
4852 KDC_ERR_CERTIFICATE_MISMATCH 66 (pkinit)
4853 KRB_AP_ERR_NO_TGT 67 (user-to-user)
4854 KDC_ERR_WRONG_REALM 68 (user-to-user)
4855 KRB_AP_ERR_USER_TO_USER_REQUIRED 69 (user-to-user)
4856 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 (pkinit)
4857 KDC_ERR_INVALID_CERTIFICATE 71 (pkinit)
4858 KDC_ERR_REVOKED_CERTIFICATE 72 (pkinit)
4859 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 (pkinit)
4860 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 (pkinit)
4861 KDC_ERR_CLIENT_NAME_MISMATCH 75 (pkinit)
4862 KDC_ERR_KDC_NAME_MISMATCH 76 (pkinit)
4864 9. Interoperability requirements
4866 Version 5 of the Kerberos protocol supports a myriad of options. Among these
4867 are multiple encryption and checksum types, alternative encoding schemes for
4868 the transited field, optional mechanisms for pre-authentication, the
4869 handling of tickets with no addresses, options for mutual authentication,
4870 user to user authentication, support for proxies, forwarding, postdating,
4871 and renewing tickets, the format of realm names, and the handling of
4875 Neuman, Ts'o, Kohl Expires: 25 December,
4878 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
4881 In order to ensure the interoperability of realms, it is necessary to define
4882 a minimal configuration which must be supported by all implementations. This
4883 minimal configuration is subject to change as technology does. For example,
4884 if at some later date it is discovered that one of the required encryption
4885 or checksum algorithms is not secure, it will be replaced.
4887 9.1. Specification 2
4889 This section defines the second specification of these options.
4890 Implementations which are configured in this way can be said to support
4891 Kerberos Version 5 Specification 2 (5.1). Specification 1 (depricated) may
4892 be found in RFC1510.
4896 TCP/IP and UDP/IP transport must be supported by KDCs claiming conformance
4897 to specification 2. Kerberos clients claiming conformance to specification 2
4898 must support UDP/IP transport for messages with the KDC and should support
4901 Encryption and checksum methods
4903 The following encryption and checksum mechanisms must be supported.
4904 Implementations may support other mechanisms as well, but the additional
4905 mechanisms may only be used when communicating with principals known to also
4906 support them: This list is to be determined. [***This section will change,
4907 and alternatives will be sent to the cat and krb-protocol list prior to the
4908 Oslo IETF - change will be made 7/14/99 ***]
4910 Encryption: DES-CBC-MD5
4911 Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5
4915 All implementations must understand hierarchical realms in both the Internet
4916 Domain and the X.500 style. When a ticket granting ticket for an unknown
4917 realm is requested, the KDC must be able to determine the names of the
4918 intermediate realms between the KDCs realm and the requested realm.
4920 Transited field encoding
4922 DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported.
4923 Alternative encodings may be supported, but they may be used only when that
4924 encoding is supported by ALL intermediate realms.
4926 Pre-authentication methods
4928 The TGS-REQ method must be supported. The TGS-REQ method is not used on the
4929 initial request. The PA-ENC-TIMESTAMP method must be supported by clients
4930 but whether it is enabled by default may be determined on a realm by realm
4931 basis. If not used in the initial request and the error
4932 KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an
4933 acceptable method, the client should retry the initial request using the
4934 PA-ENC-TIMESTAMP preauthentication method. Servers need not support the
4935 PA-ENC-TIMESTAMP method, but if not supported the server should ignore the
4936 presence of PA-ENC-TIMESTAMP pre-authentication in a request.
4939 Neuman, Ts'o, Kohl Expires: 25 December,
4942 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
4945 Mutual authentication
4947 Mutual authentication (via the KRB_AP_REP message) must be supported.
4949 Ticket addresses and flags
4951 All KDC's must pass on tickets that carry no addresses (i.e. if a TGT
4952 contains no addresses, the KDC will return derivative tickets), but each
4953 realm may set its own policy for issuing such tickets, and each application
4954 server will set its own policy with respect to accepting them.
4956 Proxies and forwarded tickets must be supported. Individual realms and
4957 application servers can set their own policy on when such tickets will be
4960 All implementations must recognize renewable and postdated tickets, but need
4961 not actually implement them. If these options are not supported, the
4962 starttime and endtime in the ticket shall specify a ticket's entire useful
4963 life. When a postdated ticket is decoded by a server, all implementations
4964 shall make the presence of the postdated flag visible to the calling server.
4966 User-to-user authentication
4968 Support for user to user authentication (via the ENC-TKT-IN-SKEY KDC option)
4969 must be provided by implementations, but individual realms may decide as a
4970 matter of policy to reject such requests on a per-principal or realm-wide
4975 Implementations must pass all authorization data subfields from
4976 ticket-granting tickets to any derivative tickets unless directed to
4977 suppress a subfield as part of the definition of that registered subfield
4978 type (it is never incorrect to pass on a subfield, and no registered
4979 subfield types presently specify suppression at the KDC).
4981 Implementations must make the contents of any authorization data subfields
4982 available to the server when a ticket is used. Implementations are not
4983 required to allow clients to specify the contents of the authorization data
4988 All protocol constants are constrained to 32 bit (signed) values unless
4989 further constrained by the protocol definition. This limit is provided to
4990 allow implementations to make assumptions about the maximum values that will
4991 be received for these constants. Implementation receiving values outside
4992 this range may reject the request, but they must recover cleanly.
4994 9.2. Recommended KDC values
4996 Following is a list of recommended values for a KDC implementation, based on
4997 the list of suggested configuration constants (see section 4.4).
4999 minimum lifetime 5 minutes
5000 maximum renewable lifetime 1 week
5001 maximum ticket lifetime 1 day
5002 empty addresses only when suitable restrictions appear
5003 in authorization data
5004 proxiable, etc. Allowed.
5007 Neuman, Ts'o, Kohl Expires: 25 December,
5010 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
5015 [NT94] B. Clifford Neuman and Theodore Y. Ts'o, "An Authenti-
5016 cation Service for Computer Networks," IEEE Communica-
5017 tions Magazine, Vol. 32(9), pp. 33-38 (September 1994).
5019 [MNSS87] S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H.
5020 Saltzer, Section E.2.1: Kerberos Authentication and
5021 Authorization System, M.I.T. Project Athena, Cambridge,
5022 Massachusetts (December 21, 1987).
5024 [SNS88] J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Ker-
5025 beros: An Authentication Service for Open Network Sys-
5026 tems," pp. 191-202 in Usenix Conference Proceedings,
5027 Dallas, Texas (February, 1988).
5029 [NS78] Roger M. Needham and Michael D. Schroeder, "Using
5030 Encryption for Authentication in Large Networks of Com-
5031 puters," Communications of the ACM, Vol. 21(12),
5032 pp. 993-999 (December, 1978).
5034 [DS81] Dorothy E. Denning and Giovanni Maria Sacco, "Time-
5035 stamps in Key Distribution Protocols," Communications
5036 of the ACM, Vol. 24(8), pp. 533-536 (August 1981).
5038 [KNT92] John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o,
5039 "The Evolution of the Kerberos Authentication Service,"
5040 in an IEEE Computer Society Text soon to be published
5043 [Neu93] B. Clifford Neuman, "Proxy-Based Authorization and
5044 Accounting for Distributed Systems," in Proceedings of
5045 the 13th International Conference on Distributed Com-
5046 puting Systems, Pittsburgh, PA (May, 1993).
5048 [DS90] Don Davis and Ralph Swick, "Workstation Services and
5049 Kerberos Authentication at Project Athena," Technical
5050 Memorandum TM-424, MIT Laboratory for Computer Science
5053 [LGDSR87] P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E. Som-
5054 merfeld, and K. Raeburn, Section E.1: Service Manage-
5055 ment System, M.I.T. Project Athena, Cambridge, Mas-
5058 [X509-88] CCITT, Recommendation X.509: The Directory Authentica-
5059 tion Framework, December 1988.
5061 [Pat92]. J. Pato, Using Pre-Authentication to Avoid Password
5062 Guessing Attacks, Open Software Foundation DCE Request
5063 for Comments 26 (December 1992).
5065 [DES77] National Bureau of Standards, U.S. Department of Com-
5066 merce, "Data Encryption Standard," Federal Information
5067 Processing Standards Publication 46, Washington, DC
5071 Neuman, Ts'o, Kohl Expires: 25 December,
5074 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
5077 [DESM80] National Bureau of Standards, U.S. Department of Com-
5078 merce, "DES Modes of Operation," Federal Information
5079 Processing Standards Publication 81, Springfield, VA
5082 [SG92] Stuart G. Stubblebine and Virgil D. Gligor, "On Message
5083 Integrity in Cryptographic Protocols," in Proceedings
5084 of the IEEE Symposium on Research in Security and
5085 Privacy, Oakland, California (May 1992).
5087 [IS3309] International Organization for Standardization, "ISO
5088 Information Processing Systems - Data Communication -
5089 High-Level Data Link Control Procedure - Frame Struc-
5090 ture," IS 3309 (October 1984). 3rd Edition.
5092 [MD4-92] R. Rivest, "The MD4 Message Digest Algorithm," RFC
5093 1320, MIT Laboratory for Computer Science (April
5096 [MD5-92] R. Rivest, "The MD5 Message Digest Algorithm," RFC
5097 1321, MIT Laboratory for Computer Science (April
5100 [KBC96] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed-
5101 Hashing for Message Authentication," Working Draft
5102 draft-ietf-ipsec-hmac-md5-01.txt, (August 1996).
5104 [Horowitz96] Horowitz, M., "Key Derivation for Authentication,
5105 Integrity, and Privacy", draft-horowitz-key-derivation-02.txt,
5108 [HorowitzB96] Horowitz, M., "Key Derivation for Kerberos V5", draft-
5109 horowitz-kerb-key-derivation-01.txt, September 1998.
5111 [Krawczyk96] Krawczyk, H., Bellare, and M., Canetti, R., "HMAC:
5112 Keyed-Hashing for Message Authentication", draft-ietf-ipsec-hmac-
5113 md5-01.txt, August, 1996.
5116 Neuman, Ts'o, Kohl Expires: 25 December,
5119 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
5122 A. Pseudo-code for protocol processing
5124 This appendix provides pseudo-code describing how the messages are to be
5125 constructed and interpreted by clients and servers.
5127 A.1. KRB_AS_REQ generation
5129 request.pvno := protocol version; /* pvno = 5 */
5130 request.msg-type := message type; /* type = KRB_AS_REQ */
5132 if(pa_enc_timestamp_required) then
5133 request.padata.padata-type = PA-ENC-TIMESTAMP;
5135 padata-body.patimestamp,pausec = system_time;
5136 encrypt padata-body into request.padata.padata-value
5137 using client.key; /* derived from password */
5140 body.kdc-options := users's preferences;
5141 body.cname := user's name;
5142 body.realm := user's realm;
5143 body.sname := service's name; /* usually "krbtgt", "localrealm" */
5144 if (body.kdc-options.POSTDATED is set) then
5145 body.from := requested starting time;
5149 body.till := requested end time;
5150 if (body.kdc-options.RENEWABLE is set) then
5151 body.rtime := requested final renewal time;
5153 body.nonce := random_nonce();
5154 body.etype := requested etypes;
5155 if (user supplied addresses) then
5156 body.addresses := user's addresses;
5158 omit body.addresses;
5160 omit body.enc-authorization-data;
5161 request.req-body := body;
5163 kerberos := lookup(name of local kerberos server (or servers));
5164 send(packet,kerberos);
5168 retry or use alternate server;
5172 Neuman, Ts'o, Kohl Expires: 25 December,
5175 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
5178 A.2. KRB_AS_REQ verification and KRB_AS_REP generation
5180 decode message into req;
5182 client := lookup(req.cname,req.realm);
5183 server := lookup(req.sname,req.realm);
5186 kdc_time := system_time.seconds;
5189 /* no client in Database */
5190 error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN);
5193 /* no server in Database */
5194 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
5197 if(client.pa_enc_timestamp_required and
5198 pa_enc_timestamp not present) then
5199 error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP));
5202 if(pa_enc_timestamp present) then
5203 decrypt req.padata-value into decrypted_enc_timestamp
5205 using auth_hdr.authenticator.subkey;
5206 if (decrypt_error()) then
5207 error_out(KRB_AP_ERR_BAD_INTEGRITY);
5208 if(decrypted_enc_timestamp is not within allowable skew)
5210 error_out(KDC_ERR_PREAUTH_FAILED);
5212 if(decrypted_enc_timestamp and usec is replay)
5213 error_out(KDC_ERR_PREAUTH_FAILED);
5215 add decrypted_enc_timestamp and usec to replay cache;
5218 use_etype := first supported etype in req.etypes;
5220 if (no support for req.etypes) then
5221 error_out(KDC_ERR_ETYPE_NOSUPP);
5224 new_tkt.vno := ticket version; /* = 5 */
5225 new_tkt.sname := req.sname;
5226 new_tkt.srealm := req.srealm;
5227 reset all flags in new_tkt.flags;
5229 /* It should be noted that local policy may affect the */
5230 /* processing of any of these flags. For example, some */
5231 /* realms may refuse to issue renewable tickets */
5233 if (req.kdc-options.FORWARDABLE is set) then
5234 set new_tkt.flags.FORWARDABLE;
5236 if (req.kdc-options.PROXIABLE is set) then
5238 Neuman, Ts'o, Kohl Expires: 25 December,
5241 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
5244 set new_tkt.flags.PROXIABLE;
5247 if (req.kdc-options.ALLOW-POSTDATE is set) then
5248 set new_tkt.flags.MAY-POSTDATE;
5250 if ((req.kdc-options.RENEW is set) or
5251 (req.kdc-options.VALIDATE is set) or
5252 (req.kdc-options.PROXY is set) or
5253 (req.kdc-options.FORWARDED is set) or
5254 (req.kdc-options.ENC-TKT-IN-SKEY is set)) then
5255 error_out(KDC_ERR_BADOPTION);
5258 new_tkt.session := random_session_key();
5259 new_tkt.cname := req.cname;
5260 new_tkt.crealm := req.crealm;
5261 new_tkt.transited := empty_transited_field();
5263 new_tkt.authtime := kdc_time;
5265 if (req.kdc-options.POSTDATED is set) then
5266 if (against_postdate_policy(req.from)) then
5267 error_out(KDC_ERR_POLICY);
5269 set new_tkt.flags.POSTDATED;
5270 set new_tkt.flags.INVALID;
5271 new_tkt.starttime := req.from;
5273 omit new_tkt.starttime; /* treated as authtime when omitted */
5275 if (req.till = 0) then
5281 new_tkt.endtime := min(till,
5282 new_tkt.starttime+client.max_life,
5283 new_tkt.starttime+server.max_life,
5284 new_tkt.starttime+max_life_for_realm);
5286 if ((req.kdc-options.RENEWABLE-OK is set) and
5287 (new_tkt.endtime < req.till)) then
5288 /* we set the RENEWABLE option for later processing */
5289 set req.kdc-options.RENEWABLE;
5290 req.rtime := req.till;
5293 if (req.rtime = 0) then
5299 if (req.kdc-options.RENEWABLE is set) then
5300 set new_tkt.flags.RENEWABLE;
5301 new_tkt.renew-till := min(rtime,
5303 Neuman, Ts'o, Kohl Expires: 25 December,
5306 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
5309 new_tkt.starttime+client.max_rlife,
5310 new_tkt.starttime+server.max_rlife,
5311 new_tkt.starttime+max_rlife_for_realm);
5313 omit new_tkt.renew-till; /* only present if RENEWABLE */
5316 if (req.addresses) then
5317 new_tkt.caddr := req.addresses;
5322 new_tkt.authorization_data := empty_authorization_data();
5324 encode to-be-encrypted part of ticket into OCTET STRING;
5325 new_tkt.enc-part := encrypt OCTET STRING
5326 using etype_for_key(server.key), server.key, server.p_kvno;
5328 /* Start processing the response */
5331 resp.msg-type := KRB_AS_REP;
5332 resp.cname := req.cname;
5333 resp.crealm := req.realm;
5334 resp.ticket := new_tkt;
5336 resp.key := new_tkt.session;
5337 resp.last-req := fetch_last_request_info(client);
5338 resp.nonce := req.nonce;
5339 resp.key-expiration := client.expiration;
5340 resp.flags := new_tkt.flags;
5342 resp.authtime := new_tkt.authtime;
5343 resp.starttime := new_tkt.starttime;
5344 resp.endtime := new_tkt.endtime;
5346 if (new_tkt.flags.RENEWABLE) then
5347 resp.renew-till := new_tkt.renew-till;
5350 resp.realm := new_tkt.realm;
5351 resp.sname := new_tkt.sname;
5353 resp.caddr := new_tkt.caddr;
5355 encode body of reply into OCTET STRING;
5357 resp.enc-part := encrypt OCTET STRING
5358 using use_etype, client.key, client.p_kvno;
5362 Neuman, Ts'o, Kohl Expires: 25 December,
5365 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
5368 A.3. KRB_AS_REP verification
5370 decode response into resp;
5372 if (resp.msg-type = KRB_ERROR) then
5373 if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) then
5374 set pa_enc_timestamp_required;
5377 process_error(resp);
5381 /* On error, discard the response, and zero the session key */
5382 /* from the response immediately */
5384 key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype,
5386 unencrypted part of resp := decode of decrypt of resp.enc-part
5387 using resp.enc-part.etype and key;
5390 if (common_as_rep_tgs_rep_checks fail) then
5395 if near(resp.princ_exp) then
5396 print(warning message);
5398 save_for_later(ticket,session,client,server,times,flags);
5400 A.4. KRB_AS_REP and KRB_TGS_REP common checks
5402 if (decryption_error() or
5403 (req.cname != resp.cname) or
5404 (req.realm != resp.crealm) or
5405 (req.sname != resp.sname) or
5406 (req.realm != resp.realm) or
5407 (req.nonce != resp.nonce) or
5408 (req.addresses != resp.caddr)) then
5410 return KRB_AP_ERR_MODIFIED;
5413 /* make sure no flags are set that shouldn't be, and that all that
5415 /* should be are set
5417 if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then
5419 return KRB_AP_ERR_MODIFIED;
5422 if ((req.from = 0) and
5423 (resp.starttime is not within allowable skew)) then
5425 return KRB_AP_ERR_SKEW;
5427 if ((req.from != 0) and (req.from != resp.starttime)) then
5429 Neuman, Ts'o, Kohl Expires: 25 December,
5432 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
5436 return KRB_AP_ERR_MODIFIED;
5438 if ((req.till != 0) and (resp.endtime > req.till)) then
5440 return KRB_AP_ERR_MODIFIED;
5443 if ((req.kdc-options.RENEWABLE is set) and
5444 (req.rtime != 0) and (resp.renew-till > req.rtime)) then
5446 return KRB_AP_ERR_MODIFIED;
5448 if ((req.kdc-options.RENEWABLE-OK is set) and
5449 (resp.flags.RENEWABLE) and
5451 (resp.renew-till > req.till)) then
5453 return KRB_AP_ERR_MODIFIED;
5456 A.5. KRB_TGS_REQ generation
5458 /* Note that make_application_request might have to recursivly
5460 /* call this routine to get the appropriate ticket-granting ticket
5463 request.pvno := protocol version; /* pvno = 5 */
5464 request.msg-type := message type; /* type = KRB_TGS_REQ */
5466 body.kdc-options := users's preferences;
5467 /* If the TGT is not for the realm of the end-server */
5468 /* then the sname will be for a TGT for the end-realm */
5469 /* and the realm of the requested ticket (body.realm) */
5470 /* will be that of the TGS to which the TGT we are */
5471 /* sending applies */
5472 body.sname := service's name;
5473 body.realm := service's realm;
5475 if (body.kdc-options.POSTDATED is set) then
5476 body.from := requested starting time;
5480 body.till := requested end time;
5481 if (body.kdc-options.RENEWABLE is set) then
5482 body.rtime := requested final renewal time;
5484 body.nonce := random_nonce();
5485 body.etype := requested etypes;
5486 if (user supplied addresses) then
5487 body.addresses := user's addresses;
5489 omit body.addresses;
5492 body.enc-authorization-data := user-supplied data;
5493 if (body.kdc-options.ENC-TKT-IN-SKEY) then
5494 body.additional-tickets_ticket := second TGT;
5496 Neuman, Ts'o, Kohl Expires: 25 December,
5499 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
5504 request.req-body := body;
5505 check := generate_checksum (req.body,checksumtype);
5507 request.padata[0].padata-type := PA-TGS-REQ;
5508 request.padata[0].padata-value := create a KRB_AP_REQ using
5509 the TGT and checksum
5511 /* add in any other padata as required/supplied */
5513 kerberos := lookup(name of local kerberose server (or servers));
5514 send(packet,kerberos);
5518 retry or use alternate server;
5521 A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation
5523 /* note that reading the application request requires first
5524 determining the server for which a ticket was issued, and choosing
5526 correct key for decryption. The name of the server appears in the
5527 plaintext part of the ticket. */
5529 if (no KRB_AP_REQ in req.padata) then
5530 error_out(KDC_ERR_PADATA_TYPE_NOSUPP);
5532 verify KRB_AP_REQ in req.padata;
5534 /* Note that the realm in which the Kerberos server is operating is
5535 determined by the instance from the ticket-granting ticket. The
5537 in the ticket-granting ticket is the realm under which the ticket
5538 granting ticket was issued. It is possible for a single Kerberos
5539 server to support more than one realm. */
5541 auth_hdr := KRB_AP_REQ;
5542 tgt := auth_hdr.ticket;
5544 if (tgt.sname is not a TGT for local realm and is not req.sname)
5546 error_out(KRB_AP_ERR_NOT_US);
5548 realm := realm_tgt_is_for(tgt);
5550 decode remainder of request;
5552 if (auth_hdr.authenticator.cksum is missing) then
5553 error_out(KRB_AP_ERR_INAPP_CKSUM);
5556 if (auth_hdr.authenticator.cksum type is not supported) then
5557 error_out(KDC_ERR_SUMTYPE_NOSUPP);
5559 if (auth_hdr.authenticator.cksum is not both collision-proof and
5561 error_out(KRB_AP_ERR_INAPP_CKSUM);
5564 Neuman, Ts'o, Kohl Expires: 25 December,
5567 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
5570 set computed_checksum := checksum(req);
5571 if (computed_checksum != auth_hdr.authenticatory.cksum) then
5572 error_out(KRB_AP_ERR_MODIFIED);
5575 server := lookup(req.sname,realm);
5578 if (is_foreign_tgt_name(req.sname)) then
5579 server := best_intermediate_tgs(req.sname);
5581 /* no server in Database */
5582 error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
5586 session := generate_random_session_key();
5588 use_etype := first supported etype in req.etypes;
5590 if (no support for req.etypes) then
5591 error_out(KDC_ERR_ETYPE_NOSUPP);
5594 new_tkt.vno := ticket version; /* = 5 */
5595 new_tkt.sname := req.sname;
5596 new_tkt.srealm := realm;
5597 reset all flags in new_tkt.flags;
5599 /* It should be noted that local policy may affect the */
5600 /* processing of any of these flags. For example, some */
5601 /* realms may refuse to issue renewable tickets */
5603 new_tkt.caddr := tgt.caddr;
5604 resp.caddr := NULL; /* We only include this if they change */
5605 if (req.kdc-options.FORWARDABLE is set) then
5606 if (tgt.flags.FORWARDABLE is reset) then
5607 error_out(KDC_ERR_BADOPTION);
5609 set new_tkt.flags.FORWARDABLE;
5611 if (req.kdc-options.FORWARDED is set) then
5612 if (tgt.flags.FORWARDABLE is reset) then
5613 error_out(KDC_ERR_BADOPTION);
5615 set new_tkt.flags.FORWARDED;
5616 new_tkt.caddr := req.addresses;
5617 resp.caddr := req.addresses;
5619 if (tgt.flags.FORWARDED is set) then
5620 set new_tkt.flags.FORWARDED;
5623 if (req.kdc-options.PROXIABLE is set) then
5624 if (tgt.flags.PROXIABLE is reset)
5625 error_out(KDC_ERR_BADOPTION);
5628 Neuman, Ts'o, Kohl Expires: 25 December,
5631 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
5634 set new_tkt.flags.PROXIABLE;
5636 if (req.kdc-options.PROXY is set) then
5637 if (tgt.flags.PROXIABLE is reset) then
5638 error_out(KDC_ERR_BADOPTION);
5640 set new_tkt.flags.PROXY;
5641 new_tkt.caddr := req.addresses;
5642 resp.caddr := req.addresses;
5645 if (req.kdc-options.ALLOW-POSTDATE is set) then
5646 if (tgt.flags.MAY-POSTDATE is reset)
5647 error_out(KDC_ERR_BADOPTION);
5649 set new_tkt.flags.MAY-POSTDATE;
5651 if (req.kdc-options.POSTDATED is set) then
5652 if (tgt.flags.MAY-POSTDATE is reset) then
5653 error_out(KDC_ERR_BADOPTION);
5655 set new_tkt.flags.POSTDATED;
5656 set new_tkt.flags.INVALID;
5657 if (against_postdate_policy(req.from)) then
5658 error_out(KDC_ERR_POLICY);
5660 new_tkt.starttime := req.from;
5663 if (req.kdc-options.VALIDATE is set) then
5664 if (tgt.flags.INVALID is reset) then
5665 error_out(KDC_ERR_POLICY);
5667 if (tgt.starttime > kdc_time) then
5668 error_out(KRB_AP_ERR_NYV);
5670 if (check_hot_list(tgt)) then
5671 error_out(KRB_AP_ERR_REPEAT);
5674 reset new_tkt.flags.INVALID;
5677 if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW,
5678 and those already processed) is set) then
5679 error_out(KDC_ERR_BADOPTION);
5682 new_tkt.authtime := tgt.authtime;
5684 if (req.kdc-options.RENEW is set) then
5685 /* Note that if the endtime has already passed, the ticket would
5687 /* have been rejected in the initial authentication stage, so
5689 /* there is no need to check again here
5691 if (tgt.flags.RENEWABLE is reset) then
5692 error_out(KDC_ERR_BADOPTION);
5694 if (tgt.renew-till < kdc_time) then
5696 Neuman, Ts'o, Kohl Expires: 25 December,
5699 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
5702 error_out(KRB_AP_ERR_TKT_EXPIRED);
5705 new_tkt.starttime := kdc_time;
5706 old_life := tgt.endttime - tgt.starttime;
5707 new_tkt.endtime := min(tgt.renew-till,
5708 new_tkt.starttime + old_life);
5710 new_tkt.starttime := kdc_time;
5711 if (req.till = 0) then
5716 new_tkt.endtime := min(till,
5717 new_tkt.starttime+client.max_life,
5718 new_tkt.starttime+server.max_life,
5719 new_tkt.starttime+max_life_for_realm,
5722 if ((req.kdc-options.RENEWABLE-OK is set) and
5723 (new_tkt.endtime < req.till) and
5724 (tgt.flags.RENEWABLE is set) then
5725 /* we set the RENEWABLE option for later processing
5727 set req.kdc-options.RENEWABLE;
5728 req.rtime := min(req.till, tgt.renew-till);
5732 if (req.rtime = 0) then
5738 if ((req.kdc-options.RENEWABLE is set) and
5739 (tgt.flags.RENEWABLE is set)) then
5740 set new_tkt.flags.RENEWABLE;
5741 new_tkt.renew-till := min(rtime,
5742 new_tkt.starttime+client.max_rlife,
5743 new_tkt.starttime+server.max_rlife,
5744 new_tkt.starttime+max_rlife_for_realm,
5747 new_tkt.renew-till := OMIT; /* leave the renew-till field out
5750 if (req.enc-authorization-data is present) then
5751 decrypt req.enc-authorization-data into
5752 decrypted_authorization_data
5753 using auth_hdr.authenticator.subkey;
5754 if (decrypt_error()) then
5755 error_out(KRB_AP_ERR_BAD_INTEGRITY);
5758 new_tkt.authorization_data := req.auth_hdr.ticket.authorization_data
5760 decrypted_authorization_data;
5762 new_tkt.key := session;
5763 new_tkt.crealm := tgt.crealm;
5765 Neuman, Ts'o, Kohl Expires: 25 December,
5768 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
5771 new_tkt.cname := req.auth_hdr.ticket.cname;
5773 if (realm_tgt_is_for(tgt) := tgt.realm) then
5774 /* tgt issued by local realm */
5775 new_tkt.transited := tgt.transited;
5777 /* was issued for this realm by some other realm */
5778 if (tgt.transited.tr-type not supported) then
5779 error_out(KDC_ERR_TRTYPE_NOSUPP);
5781 new_tkt.transited := compress_transited(tgt.transited +
5783 /* Don't check tranited field if TGT for foreign realm,
5784 * or requested not to check */
5785 if (is_not_foreign_tgt_name(new_tkt.server)
5786 && req.kdc-options.DISABLE-TRANSITED-CHECK not set) then
5787 /* Check it, so end-server does not have to
5788 * but don't fail, end-server may still accept it */
5789 if (check_transited_field(new_tkt.transited) == OK)
5790 set new_tkt.flags.TRANSITED-POLICY-CHECKED;
5795 encode encrypted part of new_tkt into OCTET STRING;
5796 if (req.kdc-options.ENC-TKT-IN-SKEY is set) then
5797 if (server not specified) then
5798 server = req.second_ticket.client;
5800 if ((req.second_ticket is not a TGT) or
5801 (req.second_ticket.client != server)) then
5802 error_out(KDC_ERR_POLICY);
5805 new_tkt.enc-part := encrypt OCTET STRING using
5806 using etype_for_key(second-ticket.key), second-ticket.key;
5808 new_tkt.enc-part := encrypt OCTET STRING
5809 using etype_for_key(server.key), server.key, server.p_kvno;
5813 resp.msg-type := KRB_TGS_REP;
5814 resp.crealm := tgt.crealm;
5815 resp.cname := tgt.cname;
5816 resp.ticket := new_tkt;
5818 resp.key := session;
5819 resp.nonce := req.nonce;
5820 resp.last-req := fetch_last_request_info(client);
5821 resp.flags := new_tkt.flags;
5823 resp.authtime := new_tkt.authtime;
5824 resp.starttime := new_tkt.starttime;
5825 resp.endtime := new_tkt.endtime;
5827 omit resp.key-expiration;
5829 resp.sname := new_tkt.sname;
5831 Neuman, Ts'o, Kohl Expires: 25 December,
5834 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
5837 resp.realm := new_tkt.realm;
5839 if (new_tkt.flags.RENEWABLE) then
5840 resp.renew-till := new_tkt.renew-till;
5843 encode body of reply into OCTET STRING;
5845 if (req.padata.authenticator.subkey)
5846 resp.enc-part := encrypt OCTET STRING using use_etype,
5847 req.padata.authenticator.subkey;
5848 else resp.enc-part := encrypt OCTET STRING using use_etype, tgt.key;
5852 A.7. KRB_TGS_REP verification
5854 decode response into resp;
5856 if (resp.msg-type = KRB_ERROR) then
5857 process_error(resp);
5861 /* On error, discard the response, and zero the session key from
5862 the response immediately */
5864 if (req.padata.authenticator.subkey)
5865 unencrypted part of resp := decode of decrypt of
5867 using resp.enc-part.etype and subkey;
5868 else unencrypted part of resp := decode of decrypt of resp.enc-part
5869 using resp.enc-part.etype and tgt's session key;
5870 if (common_as_rep_tgs_rep_checks fail) then
5875 check authorization_data as necessary;
5876 save_for_later(ticket,session,client,server,times,flags);
5878 A.8. Authenticator generation
5880 body.authenticator-vno := authenticator vno; /* = 5 */
5881 body.cname, body.crealm := client name;
5882 if (supplying checksum) then
5883 body.cksum := checksum;
5886 body.ctime, body.cusec := system_time;
5887 if (selecting sub-session key) then
5888 select sub-session key;
5889 body.subkey := sub-session key;
5891 if (using sequence numbers) then
5892 select initial sequence number;
5893 body.seq-number := initial sequence;
5897 Neuman, Ts'o, Kohl Expires: 25 December,
5900 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
5903 A.9. KRB_AP_REQ generation
5905 obtain ticket and session_key from cache;
5907 packet.pvno := protocol version; /* 5 */
5908 packet.msg-type := message type; /* KRB_AP_REQ */
5910 if (desired(MUTUAL_AUTHENTICATION)) then
5911 set packet.ap-options.MUTUAL-REQUIRED;
5913 reset packet.ap-options.MUTUAL-REQUIRED;
5915 if (using session key for ticket) then
5916 set packet.ap-options.USE-SESSION-KEY;
5918 reset packet.ap-options.USE-SESSION-KEY;
5920 packet.ticket := ticket; /* ticket */
5921 generate authenticator;
5922 encode authenticator into OCTET STRING;
5923 encrypt OCTET STRING into packet.authenticator using session_key;
5925 A.10. KRB_AP_REQ verification
5928 if (packet.pvno != 5) then
5929 either process using other protocol spec
5930 or error_out(KRB_AP_ERR_BADVERSION);
5932 if (packet.msg-type != KRB_AP_REQ) then
5933 error_out(KRB_AP_ERR_MSG_TYPE);
5935 if (packet.ticket.tkt_vno != 5) then
5936 either process using other protocol spec
5937 or error_out(KRB_AP_ERR_BADVERSION);
5939 if (packet.ap_options.USE-SESSION-KEY is set) then
5940 retrieve session key from ticket-granting ticket for
5941 packet.ticket.{sname,srealm,enc-part.etype};
5943 retrieve service key for
5944 packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno};
5946 if (no_key_available) then
5947 if (cannot_find_specified_skvno) then
5948 error_out(KRB_AP_ERR_BADKEYVER);
5950 error_out(KRB_AP_ERR_NOKEY);
5953 decrypt packet.ticket.enc-part into decr_ticket using retrieved key;
5954 if (decryption_error()) then
5955 error_out(KRB_AP_ERR_BAD_INTEGRITY);
5957 decrypt packet.authenticator into decr_authenticator
5958 using decr_ticket.key;
5959 if (decryption_error()) then
5960 error_out(KRB_AP_ERR_BAD_INTEGRITY);
5962 Neuman, Ts'o, Kohl Expires: 25 December,
5965 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
5969 if (decr_authenticator.{cname,crealm} !=
5970 decr_ticket.{cname,crealm}) then
5971 error_out(KRB_AP_ERR_BADMATCH);
5973 if (decr_ticket.caddr is present) then
5974 if (sender_address(packet) is not in decr_ticket.caddr) then
5975 error_out(KRB_AP_ERR_BADADDR);
5977 elseif (application requires addresses) then
5978 error_out(KRB_AP_ERR_BADADDR);
5980 if (not in_clock_skew(decr_authenticator.ctime,
5981 decr_authenticator.cusec)) then
5982 error_out(KRB_AP_ERR_SKEW);
5984 if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then
5985 error_out(KRB_AP_ERR_REPEAT);
5987 save_identifier(decr_authenticator.{ctime,cusec,cname,crealm});
5989 if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or
5990 (decr_ticket.flags.INVALID is set)) then
5991 /* it hasn't yet become valid */
5992 error_out(KRB_AP_ERR_TKT_NYV);
5994 if (system_time-decr_ticket.endtime > CLOCK_SKEW) then
5995 error_out(KRB_AP_ERR_TKT_EXPIRED);
5997 if (decr_ticket.transited) then
5998 /* caller may ignore the TRANSITED-POLICY-CHECKED and do
6000 if (decr_ticket.flags.TRANSITED-POLICY-CHECKED not set) then
6001 if (check_transited_field(decr_ticket.transited) then
6002 error_out(KDC_AP_PATH_NOT_ACCPETED);
6006 /* caller must check decr_ticket.flags for any pertinent details */
6007 return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED);
6010 Neuman, Ts'o, Kohl Expires: 25 December,
6013 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
6016 A.11. KRB_AP_REP generation
6018 packet.pvno := protocol version; /* 5 */
6019 packet.msg-type := message type; /* KRB_AP_REP */
6021 body.ctime := packet.ctime;
6022 body.cusec := packet.cusec;
6023 if (selecting sub-session key) then
6024 select sub-session key;
6025 body.subkey := sub-session key;
6027 if (using sequence numbers) then
6028 select initial sequence number;
6029 body.seq-number := initial sequence;
6032 encode body into OCTET STRING;
6034 select encryption type;
6035 encrypt OCTET STRING into packet.enc-part;
6037 A.12. KRB_AP_REP verification
6040 if (packet.pvno != 5) then
6041 either process using other protocol spec
6042 or error_out(KRB_AP_ERR_BADVERSION);
6044 if (packet.msg-type != KRB_AP_REP) then
6045 error_out(KRB_AP_ERR_MSG_TYPE);
6047 cleartext := decrypt(packet.enc-part) using ticket's session key;
6048 if (decryption_error()) then
6049 error_out(KRB_AP_ERR_BAD_INTEGRITY);
6051 if (cleartext.ctime != authenticator.ctime) then
6052 error_out(KRB_AP_ERR_MUT_FAIL);
6054 if (cleartext.cusec != authenticator.cusec) then
6055 error_out(KRB_AP_ERR_MUT_FAIL);
6057 if (cleartext.subkey is present) then
6058 save cleartext.subkey for future use;
6060 if (cleartext.seq-number is present) then
6061 save cleartext.seq-number for future verifications;
6063 return(AUTHENTICATION_SUCCEEDED);
6066 Neuman, Ts'o, Kohl Expires: 25 December,
6069 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
6072 A.13. KRB_SAFE generation
6074 collect user data in buffer;
6076 /* assemble packet: */
6077 packet.pvno := protocol version; /* 5 */
6078 packet.msg-type := message type; /* KRB_SAFE */
6080 body.user-data := buffer; /* DATA */
6081 if (using timestamp) then
6083 body.timestamp, body.usec := system_time;
6085 if (using sequence numbers) then
6086 body.seq-number := sequence number;
6088 body.s-address := sender host addresses;
6089 if (only one recipient) then
6090 body.r-address := recipient host address;
6092 checksum.cksumtype := checksum type;
6093 compute checksum over body;
6094 checksum.checksum := checksum value; /* checksum.checksum */
6095 packet.cksum := checksum;
6096 packet.safe-body := body;
6098 A.14. KRB_SAFE verification
6101 if (packet.pvno != 5) then
6102 either process using other protocol spec
6103 or error_out(KRB_AP_ERR_BADVERSION);
6105 if (packet.msg-type != KRB_SAFE) then
6106 error_out(KRB_AP_ERR_MSG_TYPE);
6108 if (packet.checksum.cksumtype is not both collision-proof
6110 error_out(KRB_AP_ERR_INAPP_CKSUM);
6112 if (safe_priv_common_checks_ok(packet)) then
6113 set computed_checksum := checksum(packet.body);
6114 if (computed_checksum != packet.checksum) then
6115 error_out(KRB_AP_ERR_MODIFIED);
6117 return (packet, PACKET_IS_GENUINE);
6119 return common_checks_error;
6122 A.15. KRB_SAFE and KRB_PRIV common checks
6124 if (packet.s-address != O/S_sender(packet)) then
6125 /* O/S report of sender not who claims to have sent it */
6126 error_out(KRB_AP_ERR_BADADDR);
6128 if ((packet.r-address is present) and
6129 (packet.r-address != local_host_address)) then
6131 Neuman, Ts'o, Kohl Expires: 25 December,
6134 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
6137 /* was not sent to proper place */
6138 error_out(KRB_AP_ERR_BADADDR);
6140 if (((packet.timestamp is present) and
6141 (not in_clock_skew(packet.timestamp,packet.usec))) or
6142 (packet.timestamp is not present and timestamp expected)) then
6143 error_out(KRB_AP_ERR_SKEW);
6145 if (repeated(packet.timestamp,packet.usec,packet.s-address)) then
6146 error_out(KRB_AP_ERR_REPEAT);
6149 if (((packet.seq-number is present) and
6150 ((not in_sequence(packet.seq-number)))) or
6151 (packet.seq-number is not present and sequence expected)) then
6152 error_out(KRB_AP_ERR_BADORDER);
6154 if (packet.timestamp not present and packet.seq-number
6156 error_out(KRB_AP_ERR_MODIFIED);
6159 save_identifier(packet.{timestamp,usec,s-address},
6160 sender_principal(packet));
6162 return PACKET_IS_OK;
6164 A.16. KRB_PRIV generation
6166 collect user data in buffer;
6168 /* assemble packet: */
6169 packet.pvno := protocol version; /* 5 */
6170 packet.msg-type := message type; /* KRB_PRIV */
6172 packet.enc-part.etype := encryption type;
6174 body.user-data := buffer;
6175 if (using timestamp) then
6177 body.timestamp, body.usec := system_time;
6179 if (using sequence numbers) then
6180 body.seq-number := sequence number;
6182 body.s-address := sender host addresses;
6183 if (only one recipient) then
6184 body.r-address := recipient host address;
6187 encode body into OCTET STRING;
6189 select encryption type;
6190 encrypt OCTET STRING into packet.enc-part.cipher;
6193 Neuman, Ts'o, Kohl Expires: 25 December,
6196 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
6199 A.17. KRB_PRIV verification
6202 if (packet.pvno != 5) then
6203 either process using other protocol spec
6204 or error_out(KRB_AP_ERR_BADVERSION);
6206 if (packet.msg-type != KRB_PRIV) then
6207 error_out(KRB_AP_ERR_MSG_TYPE);
6210 cleartext := decrypt(packet.enc-part) using negotiated key;
6211 if (decryption_error()) then
6212 error_out(KRB_AP_ERR_BAD_INTEGRITY);
6215 if (safe_priv_common_checks_ok(cleartext)) then
6216 return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED);
6218 return common_checks_error;
6221 A.18. KRB_CRED generation
6223 invoke KRB_TGS; /* obtain tickets to be provided to peer */
6225 /* assemble packet: */
6226 packet.pvno := protocol version; /* 5 */
6227 packet.msg-type := message type; /* KRB_CRED */
6229 for (tickets[n] in tickets to be forwarded) do
6230 packet.tickets[n] = tickets[n].ticket;
6233 packet.enc-part.etype := encryption type;
6235 for (ticket[n] in tickets to be forwarded) do
6236 body.ticket-info[n].key = tickets[n].session;
6237 body.ticket-info[n].prealm = tickets[n].crealm;
6238 body.ticket-info[n].pname = tickets[n].cname;
6239 body.ticket-info[n].flags = tickets[n].flags;
6240 body.ticket-info[n].authtime = tickets[n].authtime;
6241 body.ticket-info[n].starttime = tickets[n].starttime;
6242 body.ticket-info[n].endtime = tickets[n].endtime;
6243 body.ticket-info[n].renew-till = tickets[n].renew-till;
6244 body.ticket-info[n].srealm = tickets[n].srealm;
6245 body.ticket-info[n].sname = tickets[n].sname;
6246 body.ticket-info[n].caddr = tickets[n].caddr;
6250 body.timestamp, body.usec := system_time;
6252 if (using nonce) then
6253 body.nonce := nonce;
6256 if (using s-address) then
6258 Neuman, Ts'o, Kohl Expires: 25 December,
6261 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
6264 body.s-address := sender host addresses;
6266 if (limited recipients) then
6267 body.r-address := recipient host address;
6270 encode body into OCTET STRING;
6272 select encryption type;
6273 encrypt OCTET STRING into packet.enc-part.cipher
6274 using negotiated encryption key;
6276 A.19. KRB_CRED verification
6279 if (packet.pvno != 5) then
6280 either process using other protocol spec
6281 or error_out(KRB_AP_ERR_BADVERSION);
6283 if (packet.msg-type != KRB_CRED) then
6284 error_out(KRB_AP_ERR_MSG_TYPE);
6287 cleartext := decrypt(packet.enc-part) using negotiated key;
6288 if (decryption_error()) then
6289 error_out(KRB_AP_ERR_BAD_INTEGRITY);
6291 if ((packet.r-address is present or required) and
6292 (packet.s-address != O/S_sender(packet)) then
6293 /* O/S report of sender not who claims to have sent it */
6294 error_out(KRB_AP_ERR_BADADDR);
6296 if ((packet.r-address is present) and
6297 (packet.r-address != local_host_address)) then
6298 /* was not sent to proper place */
6299 error_out(KRB_AP_ERR_BADADDR);
6301 if (not in_clock_skew(packet.timestamp,packet.usec)) then
6302 error_out(KRB_AP_ERR_SKEW);
6304 if (repeated(packet.timestamp,packet.usec,packet.s-address)) then
6305 error_out(KRB_AP_ERR_REPEAT);
6307 if (packet.nonce is required or present) and
6308 (packet.nonce != expected-nonce) then
6309 error_out(KRB_AP_ERR_MODIFIED);
6312 for (ticket[n] in tickets that were forwarded) do
6313 save_for_later(ticket[n],key[n],principal[n],
6314 server[n],times[n],flags[n]);
6318 Neuman, Ts'o, Kohl Expires: 25 December,
6321 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
6324 A.20. KRB_ERROR generation
6326 /* assemble packet: */
6327 packet.pvno := protocol version; /* 5 */
6328 packet.msg-type := message type; /* KRB_ERROR */
6331 packet.stime, packet.susec := system_time;
6332 packet.realm, packet.sname := server name;
6334 if (client time available) then
6335 packet.ctime, packet.cusec := client_time;
6337 packet.error-code := error code;
6338 if (client name available) then
6339 packet.cname, packet.crealm := client name;
6341 if (error text available) then
6342 packet.e-text := error text;
6344 if (error data available) then
6345 packet.e-data := error data;
6349 Neuman, Ts'o, Kohl Expires: 25 December,
6352 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
6355 B. Definition of common authorization data elements
6357 This appendix contains the definitions of common authorization data
6358 elements. These common authorization data elements are recursivly defined,
6359 meaning the ad-data for these types will itself contain a sequence of
6360 authorization data whose interpretation is affected by the encapsulating
6361 element. Depending on the meaning of the encapsulating element, the
6362 encapsulated elements may be ignored, might be interpreted as issued
6363 directly by the KDC, or they might be stored in a separate plaintext part of
6364 the ticket. The types of the encapsulating elements are specified as part of
6365 the Kerberos specification because the behavior based on these values should
6366 be understood across implementations whereas other elements need only be
6367 understood by the applications which they affect.
6369 In the definitions that follow, the value of the ad-type for the element
6370 will be specified in the subsection number, and the value of the ad-data
6371 will be as shown in the ASN.1 structure that follows the subsection heading.
6375 AD-IF-RELEVANT AuthorizationData
6377 AD elements encapsulated within the if-relevant element are intended for
6378 interpretation only by application servers that understand the particular
6379 ad-type of the embedded element. Application servers that do not understand
6380 the type of an element embedded within the if-relevant element may ignore
6381 the uninterpretable element. This element promotes interoperability across
6382 implementations which may have local extensions for authorization.
6384 B.2. Intended for server
6386 AD-INTENDED-FOR-SERVER SEQUENCE {
6387 intended-server[0] SEQUENCE OF PrincipalName
6388 elements[1] AuthorizationData
6391 AD elements encapsulated within the intended-for-server element may be
6392 ignored if the application server is not in the list of principal names of
6393 intended servers. Further, a KDC issuing a ticket for an application server
6394 can remove this element if the application server is not in the list of
6397 Application servers should check for their principal name in the
6398 intended-server field of this element. If their principal name is not found,
6399 this element should be ignored. If found, then the encapsulated elements
6400 should be evaluated in the same manner as if they were present in the top
6401 level authorization data field. Applications and application servers that do
6402 not implement this element should reject tickets that contain authorization
6403 data elements of this type.
6406 Neuman, Ts'o, Kohl Expires: 25 December,
6409 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
6412 B.3. Intended for application class
6414 AD-INTENDED-FOR-APPLICATION-CLASS SEQUENCE { intended-application-class[0]
6415 SEQUENCE OF GeneralString elements[1] AuthorizationData } AD elements
6416 encapsulated within the intended-for-application-class element may be
6417 ignored if the application server is not in one of the named classes of
6418 application servers. Examples of application server classes include
6419 "FILESYSTEM", and other kinds of servers.
6421 This element and the elements it encapulates may be safely ignored by
6422 applications, application servers, and KDCs that do not implement this
6427 AD-KDCIssued SEQUENCE {
6428 ad-checksum[0] Checksum,
6429 i-realm[1] Realm OPTIONAL,
6430 i-sname[2] PrincipalName OPTIONAL,
6431 elements[3] AuthorizationData.
6435 A checksum over the elements field using a cryptographic checksum
6436 method that is identical to the checksum used to protect the ticket
6437 itself (i.e. using the same hash function and the same encryption
6438 algorithm used to encrypt the ticket) and using a key derived from the
6439 same key used to protect the ticket.
6441 The name of the issuing principal if different from the KDC itself.
6442 This field would be used when the KDC can verify the authenticity of
6443 elements signed by the issuing principal and it allows this KDC to
6444 notify the application server of the validity of those elements.
6446 A sequence of authorization data elements issued by the KDC.
6448 The KDC-issued ad-data field is intended to provide a means for Kerberos
6449 principal credentials to embed within themselves privilege attributes and
6450 other mechanisms for positive authorization, amplifying the priveleges of
6451 the principal beyond what can be done using a credentials without such an
6454 This can not be provided without this element because the definition of the
6455 authorization-data field allows elements to be added at will by the bearer
6456 of a TGT at the time that they request service tickets and elements may also
6457 be added to a delegated ticket by inclusion in the authenticator.
6459 For KDC-issued elements this is prevented because the elements are signed by
6460 the KDC by including a checksum encrypted using the server's key (the same
6461 key used to encrypt the ticket - or a key derived from that key). Elements
6462 encapsulated with in the KDC-issued element will be ignored by the
6463 application server if this "signature" is not present. Further, elements
6464 encapsulated within this element from a ticket granting ticket may be
6465 interpreted by the KDC, and used as a basis according to policy for
6466 including new signed elements within derivative tickets, but they will not
6467 be copied to a derivative ticket directly. If they are copied directly to a
6468 derivative ticket by a KDC that is not aware of this element, the signature
6469 will not be correct for the application ticket elements, and the field will
6470 be ignored by the application server.
6472 This element and the elements it encapulates may be safely ignored by
6473 applications, application servers, and KDCs that do not implement this
6477 Neuman, Ts'o, Kohl Expires: 25 December,
6480 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
6485 AD-AND-OR SEQUENCE {
6486 condition-count[0] INTEGER,
6487 elements[1] AuthorizationData
6490 When restrictive AD elements encapsulated within the and-or element are
6491 encountered, only the number specified in condition-count of the
6492 encapsulated conditions must be met in order to satisfy this element. This
6493 element may be used to implement an "or" operation by setting the
6494 condition-count field to 1, and it may specify an "and" operation by setting
6495 the condition count to the number of embedded elements. Application servers
6496 that do not implement this element must reject tickets that contain
6497 authorization data elements of this type.
6499 B.6. Mandatory ticket extensions
6501 AD-Mandatory-Ticket-Extensions Checksum
6503 An authorization data element of type mandatory-ticket-extensions specifies
6504 a collision-proof checksum using the same hash algorithm used to protect the
6505 integrity of the ticket itself. This checksum will be calculated over an
6506 individual extension field. If there are more than one extension, multiple
6507 Mandatory-Ticket-Extensions authorization data elements may be present, each
6508 with a checksum for a different extension field. This restriction indicates
6509 that the ticket should not be accepted if a ticket extension is not present
6510 in the ticket for which the checksum does not match that checksum specified
6511 in the authorization data element. Application servers that do not implement
6512 this element must reject tickets that contain authorization data elements of
6515 B.7. Authorization Data in ticket extensions
6517 AD-IN-Ticket-Extensions Checksum
6519 An authorization data element of type in-ticket-extensions specifies a
6520 collision-proof checksum using the same hash algorithm used to protect the
6521 integrity of the ticket itself. This checksum is calculated over a separate
6522 external AuthorizationData field carried in the ticket extensions.
6523 Application servers that do not implement this element must reject tickets
6524 that contain authorization data elements of this type. Application servers
6525 that do implement this element will search the ticket extensions for
6526 authorization data fields, calculate the specified checksum over each
6527 authorization data field and look for one matching the checksum in this
6528 in-ticket-extensions element. If not found, then the ticket must be
6529 rejected. If found, the corresponding authorization data elements will be
6530 interpreted in the same manner as if they were contained in the top level
6531 authorization data field.
6533 Note that if multiple external authorization data fields are present in a
6534 ticket, each will have a corresponding element of type in-ticket-extensions
6535 in the top level authorization data field, and the external entries will be
6536 linked to the corresponding element by their checksums.
6539 Neuman, Ts'o, Kohl Expires: 25 December,
6542 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
6545 C. Definition of common ticket extensions
6547 This appendix contains the definitions of common ticket extensions. Support
6548 for these extensions is optional. However, certain extensions have
6549 associated authorization data elements that may require rejection of a
6550 ticket containing an extension by application servers that do not implement
6551 the particular extension. Other extensions have been defined beyond those
6552 described in this specification. Such extensions are described elswhere and
6553 for some of those extensions the reserved number may be found in the list of
6556 It is known that older versions of Kerberos did not support this field, and
6557 that some clients will strip this field from a ticket when they parse and
6558 then reassemble a ticket as it is passed to the application servers. The
6559 presence of the extension will not break such clients, but any functionaly
6560 dependent on the extensions will not work when such tickets are handled by
6561 old clients. In such situations, some implementation may use alternate
6562 methods to transmit the information in the extensions field.
6564 C.1. Null ticket extension
6566 TE-NullExtension OctetString -- The empty Octet String
6568 The te-data field in the null ticket extension is an octet string of lenght
6569 zero. This extension may be included in a ticket granting ticket so that the
6570 KDC can determine on presentation of the ticket granting ticket whether the
6571 client software will strip the extensions field.
6573 C.2. External Authorization Data
6575 TE-ExternalAuthorizationData AuthorizationData
6577 The te-data field in the external authorization data ticket extension is
6578 field of type AuthorizationData containing one or more authorization data
6579 elements. If present, a corresponding authorization data element will be
6580 present in the primary authorization data for the ticket and that element
6581 will contain a checksum of the external authorization data ticket extension.
6582 ------------------------------------------------------------------------
6583 [TM] Project Athena, Athena, and Kerberos are trademarks of the
6584 Massachusetts Institute of Technology (MIT). No commercial use of these
6585 trademarks may be made without prior written permission of MIT.
6587 [1] Note, however, that many applications use Kerberos' functions only upon
6588 the initiation of a stream-based network connection. Unless an application
6589 subsequently provides integrity protection for the data stream, the identity
6590 verification applies only to the initiation of the connection, and does not
6591 guarantee that subsequent messages on the connection originate from the same
6594 [2] Secret and private are often used interchangeably in the literature. In
6595 our usage, it takes two (or more) to share a secret, thus a shared DES key
6596 is a secret key. Something is only private when no one but its owner knows
6597 it. Thus, in public key cryptosystems, one has a public and a private key.
6599 [3] Of course, with appropriate permission the client could arrange
6600 registration of a separately-named prin- cipal in a remote realm, and engage
6601 in normal exchanges with that realm's services. However, for even small
6602 numbers of clients this becomes cumbersome, and more automatic methods as
6603 described here are necessary.
6606 Neuman, Ts'o, Kohl Expires: 25 December,
6609 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
6612 [4] Though it is permissible to request or issue tick- ets with no network
6613 addresses specified.
6615 [5] The password-changing request must not be honored unless the requester
6616 can provide the old password (the user's current secret key). Otherwise, it
6617 would be possible for someone to walk up to an unattended ses- sion and
6618 change another user's password.
6620 [6] To authenticate a user logging on to a local system, the credentials
6621 obtained in the AS exchange may first be used in a TGS exchange to obtain
6622 credentials for a local server. Those credentials must then be verified by a
6623 local server through successful completion of the Client/Server exchange.
6625 [7] "Random" means that, among other things, it should be impossible to
6626 guess the next session key based on knowledge of past session keys. This can
6627 only be achieved in a pseudo-random number generator if it is based on
6628 cryptographic principles. It is more desirable to use a truly random number
6629 generator, such as one based on measurements of random physical phenomena.
6631 [8] Tickets contain both an encrypted and unencrypted portion, so cleartext
6632 here refers to the entire unit, which can be copied from one message and
6633 replayed in another without any cryptographic skill.
6635 [9] Note that this can make applications based on unreliable transports
6636 difficult to code correctly. If the transport might deliver duplicated
6637 messages, either a new authenticator must be generated for each retry, or
6638 the application server must match requests and replies and replay the first
6639 reply in response to a detected duplicate.
6641 [10] This is used for user-to-user authentication as described in [8].
6643 [11] Note that the rejection here is restricted to authenticators from the
6644 same principal to the same server. Other client principals communicating
6645 with the same server principal should not be have their authenticators
6646 rejected if the time and microsecond fields happen to match some other
6647 client's authenticator.
6649 [12] In the Kerberos version 4 protocol, the timestamp in the reply was the
6650 client's timestamp plus one. This is not necessary in version 5 because
6651 version 5 messages are formatted in such a way that it is not possible to
6652 create the reply by judicious message surgery (even in encrypted form)
6653 without knowledge of the appropriate encryption keys.
6655 [13] Note that for encrypting the KRB_AP_REP message, the sub-session key is
6656 not used, even if present in the Authenticator.
6658 [14] Implementations of the protocol may wish to provide routines to choose
6659 subkeys based on session keys and random numbers and to generate a
6660 negotiated key to be returned in the KRB_AP_REP message.
6662 [15]This can be accomplished in several ways. It might be known beforehand
6663 (since the realm is part of the principal identifier), it might be stored in
6664 a nameserver, or it might be obtained from a configura- tion file. If the
6665 realm to be used is obtained from a nameserver, there is a danger of being
6666 spoofed if the nameservice providing the realm name is not authenti- cated.
6667 This might result in the use of a realm which has been compromised, and
6668 would result in an attacker's ability to compromise the authentication of
6669 the application server to the client.
6672 Neuman, Ts'o, Kohl Expires: 25 December,
6675 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
6678 [16] If the client selects a sub-session key, care must be taken to ensure
6679 the randomness of the selected sub- session key. One approach would be to
6680 generate a random number and XOR it with the session key from the
6681 ticket-granting ticket.
6683 [17] This allows easy implementation of user-to-user authentication [8],
6684 which uses ticket-granting ticket session keys in lieu of secret server keys
6685 in situa- tions where such secret keys could be easily comprom- ised.
6687 [18] For the purpose of appending, the realm preceding the first listed
6688 realm is considered to be the null realm ("").
6690 [19] For the purpose of interpreting null subfields, the client's realm is
6691 considered to precede those in the transited field, and the server's realm
6692 is considered to follow them.
6694 [20] This means that a client and server running on the same host and
6695 communicating with one another using the KRB_SAFE messages should not share
6696 a common replay cache to detect KRB_SAFE replays.
6698 [21] The implementation of the Kerberos server need not combine the database
6699 and the server on the same machine; it is feasible to store the principal
6700 database in, say, a network name service, as long as the entries stored
6701 therein are protected from disclosure to and modification by unauthorized
6702 parties. However, we recommend against such strategies, as they can make
6703 system management and threat analysis quite complex.
6705 [22] See the discussion of the padata field in section 5.4.2 for details on
6706 why this can be useful.
6708 [23] Warning for implementations that unpack and repack data structures
6709 during the generation and verification of embedded checksums: Because any
6710 checksums applied to data structures must be checked against the original
6711 data the length of bit strings must be preserved within a data structure
6712 between the time that a checksum is generated through transmission to the
6713 time that the checksum is verified.
6715 [24] It is NOT recommended that this time value be used to adjust the
6716 workstation's clock since the workstation cannot reliably determine that
6717 such a KRB_AS_REP actually came from the proper KDC in a timely manner.
6719 [25] Note, however, that if the time is used as the nonce, one must make
6720 sure that the workstation time is monotonically increasing. If the time is
6721 ever reset backwards, there is a small, but finite, probability that a nonce
6724 [27] An application code in the encrypted part of a message provides an
6725 additional check that the message was decrypted properly.
6727 [29] An application code in the encrypted part of a message provides an
6728 additional check that the message was decrypted properly.
6730 [31] An application code in the encrypted part of a message provides an
6731 additional check that the message was decrypted properly.
6734 Neuman, Ts'o, Kohl Expires: 25 December,
6737 INTERNET-DRAFT draft-ietf-cat-kerberos-revisions-04 June 25,
6740 [32] If supported by the encryption method in use, an initialization vector
6741 may be passed to the encryption procedure, in order to achieve proper cipher
6742 chaining. The initialization vector might come from the last block of the
6743 ciphertext from the previous KRB_PRIV message, but it is the application's
6744 choice whether or not to use such an initialization vector. If left out, the
6745 default initialization vector for the encryption algorithm will be used.
6747 [33] This prevents an attacker who generates an incorrect AS request from
6748 obtaining verifiable plaintext for use in an off-line password guessing
6751 [35] In the above specification, UNTAGGED OCTET STRING(length) is the
6752 notation for an octet string with its tag and length removed. It is not a
6753 valid ASN.1 type. The tag bits and length must be removed from the
6754 confounder since the purpose of the confounder is so that the message starts
6755 with random data, but the tag and its length are fixed. For other fields,
6756 the length and tag would be redundant if they were included because they are
6757 specified by the encryption type. [36] The ordering of the fields in the
6758 CipherText is important. Additionally, messages encoded in this format must
6759 include a length as part of the msg-seq field. This allows the recipient to
6760 verify that the message has not been truncated. Without a length, an
6761 attacker could use a chosen plaintext attack to generate a message which
6762 could be truncated, while leaving the checksum intact. Note that if the
6763 msg-seq is an encoding of an ASN.1 SEQUENCE or OCTET STRING, then the length
6764 is part of that encoding.
6766 [37] In some cases, it may be necessary to use a different "mix-in" string
6767 for compatibility reasons; see the discussion of padata in section 5.4.2.
6769 [38] In some cases, it may be necessary to use a different "mix-in" string
6770 for compatibility reasons; see the discussion of padata in section 5.4.2.
6772 [39] A variant of the key is used to limit the use of a key to a particular
6773 function, separating the functions of generating a checksum from other
6774 encryption performed using the session key. The constant F0F0F0F0F0F0F0F0
6775 was chosen because it maintains key parity. The properties of DES precluded
6776 the use of the complement. The same constant is used for similar purpose in
6777 the Message Integrity Check in the Privacy Enhanced Mail standard.
6779 [40] This error carries additional information in the e- data field. The
6780 contents of the e-data field for this message is described in section 5.9.1.