7
Network Working Group J. Kohl
8
Request for Comments: 1510 Digital Equipment Corporation
14
The Kerberos Network Authentication Service (V5)
18
This RFC specifies an Internet standards track protocol for the
19
Internet community, and requests discussion and suggestions for
20
improvements. Please refer to the current edition of the "Internet
21
Official Protocol Standards" for the standardization state and status
22
of this protocol. Distribution of this memo is unlimited.
26
This document gives an overview and specification of Version 5 of the
27
protocol for the Kerberos network authentication system. Version 4,
28
described elsewhere [1,2], is presently in production use at MIT's
29
Project Athena, and at other Internet sites.
33
Project Athena, Athena, Athena MUSE, Discuss, Hesiod, Kerberos,
34
Moira, and Zephyr are trademarks of the Massachusetts Institute of
35
Technology (MIT). No commercial use of these trademarks may be made
36
without prior written permission of MIT.
38
This RFC describes the concepts and model upon which the Kerberos
39
network authentication system is based. It also specifies Version 5
40
of the Kerberos protocol.
42
The motivations, goals, assumptions, and rationale behind most design
43
decisions are treated cursorily; for Version 4 they are fully
44
described in the Kerberos portion of the Athena Technical Plan [1].
45
The protocols are under review, and are not being submitted for
46
consideration as an Internet standard at this time. Comments are
47
encouraged. Requests for addition to an electronic mailing list for
48
discussion of Kerberos, kerberos@MIT.EDU, may be addressed to
49
kerberos-request@MIT.EDU. This mailing list is gatewayed onto the
50
Usenet as the group comp.protocols.kerberos. Requests for further
51
information, including documents and code availability, may be sent
52
to info-kerberos@MIT.EDU.
58
Kohl & Neuman [Page 1]
60
RFC 1510 Kerberos September 1993
65
The Kerberos model is based in part on Needham and Schroeder's
66
trusted third-party authentication protocol [3] and on modifications
67
suggested by Denning and Sacco [4]. The original design and
68
implementation of Kerberos Versions 1 through 4 was the work of two
69
former Project Athena staff members, Steve Miller of Digital
70
Equipment Corporation and Clifford Neuman (now at the Information
71
Sciences Institute of the University of Southern California), along
72
with Jerome Saltzer, Technical Director of Project Athena, and
73
Jeffrey Schiller, MIT Campus Network Manager. Many other members of
74
Project Athena have also contributed to the work on Kerberos.
75
Version 4 is publicly available, and has seen wide use across the
78
Version 5 (described in this document) has evolved from Version 4
79
based on new requirements and desires for features not available in
80
Version 4. Details on the differences between Kerberos Versions 4
81
and 5 can be found in [5].
85
1. Introduction ....................................... 5
86
1.1. Cross-Realm Operation ............................ 7
87
1.2. Environmental assumptions ........................ 8
88
1.3. Glossary of terms ................................ 9
89
2. Ticket flag uses and requests ...................... 12
90
2.1. Initial and pre-authenticated tickets ............ 12
91
2.2. Invalid tickets .................................. 12
92
2.3. Renewable tickets ................................ 12
93
2.4. Postdated tickets ................................ 13
94
2.5. Proxiable and proxy tickets ...................... 14
95
2.6. Forwardable tickets .............................. 15
96
2.7. Other KDC options ................................ 15
97
3. Message Exchanges .................................. 16
98
3.1. The Authentication Service Exchange .............. 16
99
3.1.1. Generation of KRB_AS_REQ message ............... 17
100
3.1.2. Receipt of KRB_AS_REQ message .................. 17
101
3.1.3. Generation of KRB_AS_REP message ............... 17
102
3.1.4. Generation of KRB_ERROR message ................ 19
103
3.1.5. Receipt of KRB_AS_REP message .................. 19
104
3.1.6. Receipt of KRB_ERROR message ................... 20
105
3.2. The Client/Server Authentication Exchange ........ 20
106
3.2.1. The KRB_AP_REQ message ......................... 20
107
3.2.2. Generation of a KRB_AP_REQ message ............. 20
108
3.2.3. Receipt of KRB_AP_REQ message .................. 21
109
3.2.4. Generation of a KRB_AP_REP message ............. 23
110
3.2.5. Receipt of KRB_AP_REP message .................. 23
114
Kohl & Neuman [Page 2]
116
RFC 1510 Kerberos September 1993
119
3.2.6. Using the encryption key ....................... 24
120
3.3. The Ticket-Granting Service (TGS) Exchange ....... 24
121
3.3.1. Generation of KRB_TGS_REQ message .............. 25
122
3.3.2. Receipt of KRB_TGS_REQ message ................. 26
123
3.3.3. Generation of KRB_TGS_REP message .............. 27
124
3.3.3.1. Encoding the transited field ................. 29
125
3.3.4. Receipt of KRB_TGS_REP message ................. 31
126
3.4. The KRB_SAFE Exchange ............................ 31
127
3.4.1. Generation of a KRB_SAFE message ............... 31
128
3.4.2. Receipt of KRB_SAFE message .................... 32
129
3.5. The KRB_PRIV Exchange ............................ 33
130
3.5.1. Generation of a KRB_PRIV message ............... 33
131
3.5.2. Receipt of KRB_PRIV message .................... 33
132
3.6. The KRB_CRED Exchange ............................ 34
133
3.6.1. Generation of a KRB_CRED message ............... 34
134
3.6.2. Receipt of KRB_CRED message .................... 34
135
4. The Kerberos Database .............................. 35
136
4.1. Database contents ................................ 35
137
4.2. Additional fields ................................ 36
138
4.3. Frequently Changing Fields ....................... 37
139
4.4. Site Constants ................................... 37
140
5. Message Specifications ............................. 38
141
5.1. ASN.1 Distinguished Encoding Representation ...... 38
142
5.2. ASN.1 Base Definitions ........................... 38
143
5.3. Tickets and Authenticators ....................... 42
144
5.3.1. Tickets ........................................ 42
145
5.3.2. Authenticators ................................. 47
146
5.4. Specifications for the AS and TGS exchanges ...... 49
147
5.4.1. KRB_KDC_REQ definition ......................... 49
148
5.4.2. KRB_KDC_REP definition ......................... 56
149
5.5. Client/Server (CS) message specifications ........ 58
150
5.5.1. KRB_AP_REQ definition .......................... 58
151
5.5.2. KRB_AP_REP definition .......................... 60
152
5.5.3. Error message reply ............................ 61
153
5.6. KRB_SAFE message specification ................... 61
154
5.6.1. KRB_SAFE definition ............................ 61
155
5.7. KRB_PRIV message specification ................... 62
156
5.7.1. KRB_PRIV definition ............................ 62
157
5.8. KRB_CRED message specification ................... 63
158
5.8.1. KRB_CRED definition ............................ 63
159
5.9. Error message specification ...................... 65
160
5.9.1. KRB_ERROR definition ........................... 66
161
6. Encryption and Checksum Specifications ............. 67
162
6.1. Encryption Specifications ........................ 68
163
6.2. Encryption Keys .................................. 71
164
6.3. Encryption Systems ............................... 71
165
6.3.1. The NULL Encryption System (null) .............. 71
166
6.3.2. DES in CBC mode with a CRC-32 checksum (descbc-crc)71
170
Kohl & Neuman [Page 3]
172
RFC 1510 Kerberos September 1993
175
6.3.3. DES in CBC mode with an MD4 checksum (descbc-md4) 72
176
6.3.4. DES in CBC mode with an MD5 checksum (descbc-md5) 72
177
6.4. Checksums ........................................ 74
178
6.4.1. The CRC-32 Checksum (crc32) .................... 74
179
6.4.2. The RSA MD4 Checksum (rsa-md4) ................. 75
180
6.4.3. RSA MD4 Cryptographic Checksum Using DES
181
(rsa-md4-des) ......................................... 75
182
6.4.4. The RSA MD5 Checksum (rsa-md5) ................. 76
183
6.4.5. RSA MD5 Cryptographic Checksum Using DES
184
(rsa-md5-des) ......................................... 76
185
6.4.6. DES cipher-block chained checksum (des-mac)
186
6.4.7. RSA MD4 Cryptographic Checksum Using DES
187
alternative (rsa-md4-des-k) ........................... 77
188
6.4.8. DES cipher-block chained checksum alternative
189
(des-mac-k) ........................................... 77
190
7. Naming Constraints ................................. 78
191
7.1. Realm Names ...................................... 77
192
7.2. Principal Names .................................. 79
193
7.2.1. Name of server principals ...................... 80
194
8. Constants and other defined values ................. 80
195
8.1. Host address types ............................... 80
196
8.2. KDC messages ..................................... 81
197
8.2.1. IP transport ................................... 81
198
8.2.2. OSI transport .................................. 82
199
8.2.3. Name of the TGS ................................ 82
200
8.3. Protocol constants and associated values ......... 82
201
9. Interoperability requirements ...................... 86
202
9.1. Specification 1 .................................. 86
203
9.2. Recommended KDC values ........................... 88
204
10. Acknowledgments ................................... 88
205
11. References ........................................ 89
206
12. Security Considerations ........................... 90
207
13. Authors' Addresses ................................ 90
208
A. Pseudo-code for protocol processing ................ 91
209
A.1. KRB_AS_REQ generation ............................ 91
210
A.2. KRB_AS_REQ verification and KRB_AS_REP generation 92
211
A.3. KRB_AS_REP verification .......................... 95
212
A.4. KRB_AS_REP and KRB_TGS_REP common checks ......... 96
213
A.5. KRB_TGS_REQ generation ........................... 97
214
A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation 98
215
A.7. KRB_TGS_REP verification ......................... 104
216
A.8. Authenticator generation ......................... 104
217
A.9. KRB_AP_REQ generation ............................ 105
218
A.10. KRB_AP_REQ verification ......................... 105
219
A.11. KRB_AP_REP generation ........................... 106
220
A.12. KRB_AP_REP verification ......................... 107
221
A.13. KRB_SAFE generation ............................. 107
222
A.14. KRB_SAFE verification ........................... 108
226
Kohl & Neuman [Page 4]
228
RFC 1510 Kerberos September 1993
231
A.15. KRB_SAFE and KRB_PRIV common checks ............. 108
232
A.16. KRB_PRIV generation ............................. 109
233
A.17. KRB_PRIV verification ........................... 110
234
A.18. KRB_CRED generation ............................. 110
235
A.19. KRB_CRED verification ........................... 111
236
A.20. KRB_ERROR generation ............................ 112
240
Kerberos provides a means of verifying the identities of principals,
241
(e.g., a workstation user or a network server) on an open
242
(unprotected) network. This is accomplished without relying on
243
authentication by the host operating system, without basing trust on
244
host addresses, without requiring physical security of all the hosts
245
on the network, and under the assumption that packets traveling along
246
the network can be read, modified, and inserted at will. (Note,
247
however, that many applications use Kerberos' functions only upon the
248
initiation of a stream-based network connection, and assume the
249
absence of any "hijackers" who might subvert such a connection. Such
250
use implicitly trusts the host addresses involved.) Kerberos
251
performs authentication under these conditions as a trusted third-
252
party authentication service by using conventional cryptography,
253
i.e., shared secret key. (shared secret key - Secret and private are
254
often used interchangeably in the literature. In our usage, it takes
255
two (or more) to share a secret, thus a shared DES key is a secret
256
key. Something is only private when no one but its owner knows it.
257
Thus, in public key cryptosystems, one has a public and a private
260
The authentication process proceeds as follows: A client sends a
261
request to the authentication server (AS) requesting "credentials"
262
for a given server. The AS responds with these credentials,
263
encrypted in the client's key. The credentials consist of 1) a
264
"ticket" for the server and 2) a temporary encryption key (often
265
called a "session key"). The client transmits the ticket (which
266
contains the client's identity and a copy of the session key, all
267
encrypted in the server's key) to the server. The session key (now
268
shared by the client and server) is used to authenticate the client,
269
and may optionally be used to authenticate the server. It may also
270
be used to encrypt further communication between the two parties or
271
to exchange a separate sub-session key to be used to encrypt further
274
The implementation consists of one or more authentication servers
275
running on physically secure hosts. The authentication servers
276
maintain a database of principals (i.e., users and servers) and their
277
secret keys. Code libraries provide encryption and implement the
278
Kerberos protocol. In order to add authentication to its
282
Kohl & Neuman [Page 5]
284
RFC 1510 Kerberos September 1993
287
transactions, a typical network application adds one or two calls to
288
the Kerberos library, which results in the transmission of the
289
necessary messages to achieve authentication.
291
The Kerberos protocol consists of several sub-protocols (or
292
exchanges). There are two methods by which a client can ask a
293
Kerberos server for credentials. In the first approach, the client
294
sends a cleartext request for a ticket for the desired server to the
295
AS. The reply is sent encrypted in the client's secret key. Usually
296
this request is for a ticket-granting ticket (TGT) which can later be
297
used with the ticket-granting server (TGS). In the second method,
298
the client sends a request to the TGS. The client sends the TGT to
299
the TGS in the same manner as if it were contacting any other
300
application server which requires Kerberos credentials. The reply is
301
encrypted in the session key from the TGT.
303
Once obtained, credentials may be used to verify the identity of the
304
principals in a transaction, to ensure the integrity of messages
305
exchanged between them, or to preserve privacy of the messages. The
306
application is free to choose whatever protection may be necessary.
308
To verify the identities of the principals in a transaction, the
309
client transmits the ticket to the server. Since the ticket is sent
310
"in the clear" (parts of it are encrypted, but this encryption
311
doesn't thwart replay) and might be intercepted and reused by an
312
attacker, additional information is sent to prove that the message
313
was originated by the principal to whom the ticket was issued. This
314
information (called the authenticator) is encrypted in the session
315
key, and includes a timestamp. The timestamp proves that the message
316
was recently generated and is not a replay. Encrypting the
317
authenticator in the session key proves that it was generated by a
318
party possessing the session key. Since no one except the requesting
319
principal and the server know the session key (it is never sent over
320
the network in the clear) this guarantees the identity of the client.
322
The integrity of the messages exchanged between principals can also
323
be guaranteed using the session key (passed in the ticket and
324
contained in the credentials). This approach provides detection of
325
both replay attacks and message stream modification attacks. It is
326
accomplished by generating and transmitting a collision-proof
327
checksum (elsewhere called a hash or digest function) of the client's
328
message, keyed with the session key. Privacy and integrity of the
329
messages exchanged between principals can be secured by encrypting
330
the data to be passed using the session key passed in the ticket, and
331
contained in the credentials.
333
The authentication exchanges mentioned above require read-only access
334
to the Kerberos database. Sometimes, however, the entries in the
338
Kohl & Neuman [Page 6]
340
RFC 1510 Kerberos September 1993
343
database must be modified, such as when adding new principals or
344
changing a principal's key. This is done using a protocol between a
345
client and a third Kerberos server, the Kerberos Administration
346
Server (KADM). The administration protocol is not described in this
347
document. There is also a protocol for maintaining multiple copies of
348
the Kerberos database, but this can be considered an implementation
349
detail and may vary to support different database technologies.
351
1.1. Cross-Realm Operation
353
The Kerberos protocol is designed to operate across organizational
354
boundaries. A client in one organization can be authenticated to a
355
server in another. Each organization wishing to run a Kerberos
356
server establishes its own "realm". The name of the realm in which a
357
client is registered is part of the client's name, and can be used by
358
the end-service to decide whether to honor a request.
360
By establishing "inter-realm" keys, the administrators of two realms
361
can allow a client authenticated in the local realm to use its
362
authentication remotely (Of course, with appropriate permission the
363
client could arrange registration of a separately-named principal in
364
a remote realm, and engage in normal exchanges with that realm's
365
services. However, for even small numbers of clients this becomes
366
cumbersome, and more automatic methods as described here are
367
necessary). The exchange of inter-realm keys (a separate key may be
368
used for each direction) registers the ticket-granting service of
369
each realm as a principal in the other realm. A client is then able
370
to obtain a ticket-granting ticket for the remote realm's ticket-
371
granting service from its local realm. When that ticket-granting
372
ticket is used, the remote ticket-granting service uses the inter-
373
realm key (which usually differs from its own normal TGS key) to
374
decrypt the ticket-granting ticket, and is thus certain that it was
375
issued by the client's own TGS. Tickets issued by the remote ticket-
376
granting service will indicate to the end-service that the client was
377
authenticated from another realm.
379
A realm is said to communicate with another realm if the two realms
380
share an inter-realm key, or if the local realm shares an inter-realm
381
key with an intermediate realm that communicates with the remote
382
realm. An authentication path is the sequence of intermediate realms
383
that are transited in communicating from one realm to another.
385
Realms are typically organized hierarchically. Each realm shares a
386
key with its parent and a different key with each child. If an
387
inter-realm key is not directly shared by two realms, the
388
hierarchical organization allows an authentication path to be easily
389
constructed. If a hierarchical organization is not used, it may be
390
necessary to consult some database in order to construct an
394
Kohl & Neuman [Page 7]
396
RFC 1510 Kerberos September 1993
399
authentication path between realms.
401
Although realms are typically hierarchical, intermediate realms may
402
be bypassed to achieve cross-realm authentication through alternate
403
authentication paths (these might be established to make
404
communication between two realms more efficient). It is important
405
for the end-service to know which realms were transited when deciding
406
how much faith to place in the authentication process. To facilitate
407
this decision, a field in each ticket contains the names of the
408
realms that were involved in authenticating the client.
410
1.2. Environmental assumptions
412
Kerberos imposes a few assumptions on the environment in which it can
415
+ "Denial of service" attacks are not solved with Kerberos. There
416
are places in these protocols where an intruder intruder can
417
prevent an application from participating in the proper
418
authentication steps. Detection and solution of such attacks
419
(some of which can appear to be not-uncommon "normal" failure
420
modes for the system) is usually best left to the human
421
administrators and users.
423
+ Principals must keep their secret keys secret. If an intruder
424
somehow steals a principal's key, it will be able to masquerade
425
as that principal or impersonate any server to the legitimate
428
+ "Password guessing" attacks are not solved by Kerberos. If a
429
user chooses a poor password, it is possible for an attacker to
430
successfully mount an offline dictionary attack by repeatedly
431
attempting to decrypt, with successive entries from a
432
dictionary, messages obtained which are encrypted under a key
433
derived from the user's password.
435
+ Each host on the network must have a clock which is "loosely
436
synchronized" to the time of the other hosts; this
437
synchronization is used to reduce the bookkeeping needs of
438
application servers when they do replay detection. The degree
439
of "looseness" can be configured on a per-server basis. If the
440
clocks are synchronized over the network, the clock
441
synchronization protocol must itself be secured from network
444
+ Principal identifiers are not recycled on a short-term basis. A
445
typical mode of access control will use access control lists
446
(ACLs) to grant permissions to particular principals. If a
450
Kohl & Neuman [Page 8]
452
RFC 1510 Kerberos September 1993
455
stale ACL entry remains for a deleted principal and the
456
principal identifier is reused, the new principal will inherit
457
rights specified in the stale ACL entry. By not re-using
458
principal identifiers, the danger of inadvertent access is
461
1.3. Glossary of terms
463
Below is a list of terms used throughout this document.
466
Authentication Verifying the claimed identity of a
470
Authentication header A record containing a Ticket and an
471
Authenticator to be presented to a
472
server as part of the authentication
476
Authentication path A sequence of intermediate realms transited
477
in the authentication process when
478
communicating from one realm to another.
480
Authenticator A record containing information that can
481
be shown to have been recently generated
482
using the session key known only by the
486
Authorization The process of determining whether a
487
client may use a service, which objects
488
the client is allowed to access, and the
489
type of access allowed for each.
492
Capability A token that grants the bearer permission
493
to access an object or service. In
494
Kerberos, this might be a ticket whose
495
use is restricted by the contents of the
496
authorization data field, but which
497
lists no network addresses, together
498
with the session key necessary to use
506
Kohl & Neuman [Page 9]
508
RFC 1510 Kerberos September 1993
511
Ciphertext The output of an encryption function.
512
Encryption transforms plaintext into
516
Client A process that makes use of a network
517
service on behalf of a user. Note that
518
in some cases a Server may itself be a
519
client of some other server (e.g., a
520
print server may be a client of a file
524
Credentials A ticket plus the secret session key
525
necessary to successfully use that
526
ticket in an authentication exchange.
529
KDC Key Distribution Center, a network service
530
that supplies tickets and temporary
531
session keys; or an instance of that
532
service or the host on which it runs.
533
The KDC services both initial ticket and
534
ticket-granting ticket requests. The
535
initial ticket portion is sometimes
536
referred to as the Authentication Server
537
(or service). The ticket-granting
538
ticket portion is sometimes referred to
539
as the ticket-granting server (or service).
541
Kerberos Aside from the 3-headed dog guarding
542
Hades, the name given to Project
543
Athena's authentication service, the
544
protocol used by that service, or the
545
code used to implement the authentication
549
Plaintext The input to an encryption function or
550
the output of a decryption function.
551
Decryption transforms ciphertext into
555
Principal A uniquely named client or server
556
instance that participates in a network
562
Kohl & Neuman [Page 10]
564
RFC 1510 Kerberos September 1993
567
Principal identifier The name used to uniquely identify each
571
Seal To encipher a record containing several
572
fields in such a way that the fields
573
cannot be individually replaced without
574
either knowledge of the encryption key
575
or leaving evidence of tampering.
578
Secret key An encryption key shared by a principal
579
and the KDC, distributed outside the
580
bounds of the system, with a long lifetime.
581
In the case of a human user's
582
principal, the secret key is derived
586
Server A particular Principal which provides a
587
resource to network clients.
590
Service A resource provided to network clients;
591
often provided by more than one server
592
(for example, remote file service).
595
Session key A temporary encryption key used between
596
two principals, with a lifetime limited
597
to the duration of a single login "session".
600
Sub-session key A temporary encryption key used between
601
two principals, selected and exchanged
602
by the principals using the session key,
603
and with a lifetime limited to the duration
604
of a single association.
607
Ticket A record that helps a client authenticate
608
itself to a server; it contains the
609
client's identity, a session key, a
610
timestamp, and other information, all
611
sealed using the server's secret key.
612
It only serves to authenticate a client
613
when presented along with a fresh
618
Kohl & Neuman [Page 11]
620
RFC 1510 Kerberos September 1993
623
2. Ticket flag uses and requests
625
Each Kerberos ticket contains a set of flags which are used to
626
indicate various attributes of that ticket. Most flags may be
627
requested by a client when the ticket is obtained; some are
628
automatically turned on and off by a Kerberos server as required.
629
The following sections explain what the various flags mean, and gives
630
examples of reasons to use such a flag.
632
2.1. Initial and pre-authenticated tickets
634
The INITIAL flag indicates that a ticket was issued using the AS
635
protocol and not issued based on a ticket-granting ticket.
636
Application servers that want to require the knowledge of a client's
637
secret key (e.g., a passwordchanging program) can insist that this
638
flag be set in any tickets they accept, and thus be assured that the
639
client's key was recently presented to the application client.
641
The PRE-AUTHENT and HW-AUTHENT flags provide addition information
642
about the initial authentication, regardless of whether the current
643
ticket was issued directly (in which case INITIAL will also be set)
644
or issued on the basis of a ticket-granting ticket (in which case the
645
INITIAL flag is clear, but the PRE-AUTHENT and HW-AUTHENT flags are
646
carried forward from the ticket-granting ticket).
650
The INVALID flag indicates that a ticket is invalid. Application
651
servers must reject tickets which have this flag set. A postdated
652
ticket will usually be issued in this form. Invalid tickets must be
653
validated by the KDC before use, by presenting them to the KDC in a
654
TGS request with the VALIDATE option specified. The KDC will only
655
validate tickets after their starttime has passed. The validation is
656
required so that postdated tickets which have been stolen before
657
their starttime can be rendered permanently invalid (through a hot-
660
2.3. Renewable tickets
662
Applications may desire to hold tickets which can be valid for long
663
periods of time. However, this can expose their credentials to
664
potential theft for equally long periods, and those stolen
665
credentials would be valid until the expiration time of the
666
ticket(s). Simply using shortlived tickets and obtaining new ones
667
periodically would require the client to have long-term access to its
668
secret key, an even greater risk. Renewable tickets can be used to
669
mitigate the consequences of theft. Renewable tickets have two
670
"expiration times": the first is when the current instance of the
674
Kohl & Neuman [Page 12]
676
RFC 1510 Kerberos September 1993
679
ticket expires, and the second is the latest permissible value for an
680
individual expiration time. An application client must periodically
681
(i.e., before it expires) present a renewable ticket to the KDC, with
682
the RENEW option set in the KDC request. The KDC will issue a new
683
ticket with a new session key and a later expiration time. All other
684
fields of the ticket are left unmodified by the renewal process.
685
When the latest permissible expiration time arrives, the ticket
686
expires permanently. At each renewal, the KDC may consult a hot-list
687
to determine if the ticket had been reported stolen since its last
688
renewal; it will refuse to renew such stolen tickets, and thus the
689
usable lifetime of stolen tickets is reduced.
691
The RENEWABLE flag in a ticket is normally only interpreted by the
692
ticket-granting service (discussed below in section 3.3). It can
693
usually be ignored by application servers. However, some
694
particularly careful application servers may wish to disallow
697
If a renewable ticket is not renewed by its expiration time, the KDC
698
will not renew the ticket. The RENEWABLE flag is reset by default,
699
but a client may request it be set by setting the RENEWABLE option
700
in the KRB_AS_REQ message. If it is set, then the renew-till field
701
in the ticket contains the time after which the ticket may not be
704
2.4. Postdated tickets
706
Applications may occasionally need to obtain tickets for use much
707
later, e.g., a batch submission system would need tickets to be valid
708
at the time the batch job is serviced. However, it is dangerous to
709
hold valid tickets in a batch queue, since they will be on-line
710
longer and more prone to theft. Postdated tickets provide a way to
711
obtain these tickets from the KDC at job submission time, but to
712
leave them "dormant" until they are activated and validated by a
713
further request of the KDC. If a ticket theft were reported in the
714
interim, the KDC would refuse to validate the ticket, and the thief
717
The MAY-POSTDATE flag in a ticket is normally only interpreted by the
718
ticket-granting service. It can be ignored by application servers.
719
This flag must be set in a ticket-granting ticket in order to issue a
720
postdated ticket based on the presented ticket. It is reset by
721
default; it may be requested by a client by setting the ALLOW-
722
POSTDATE option in the KRB_AS_REQ message. This flag does not allow
723
a client to obtain a postdated ticket-granting ticket; postdated
724
ticket-granting tickets can only by obtained by requesting the
725
postdating in the KRB_AS_REQ message. The life (endtime-starttime)
726
of a postdated ticket will be the remaining life of the ticket-
730
Kohl & Neuman [Page 13]
732
RFC 1510 Kerberos September 1993
735
granting ticket at the time of the request, unless the RENEWABLE
736
option is also set, in which case it can be the full life (endtime-
737
starttime) of the ticket-granting ticket. The KDC may limit how far
738
in the future a ticket may be postdated.
740
The POSTDATED flag indicates that a ticket has been postdated. The
741
application server can check the authtime field in the ticket to see
742
when the original authentication occurred. Some services may choose
743
to reject postdated tickets, or they may only accept them within a
744
certain period after the original authentication. When the KDC issues
745
a POSTDATED ticket, it will also be marked as INVALID, so that the
746
application client must present the ticket to the KDC to be validated
749
2.5. Proxiable and proxy tickets
751
At times it may be necessary for a principal to allow a service to
752
perform an operation on its behalf. The service must be able to take
753
on the identity of the client, but only for a particular purpose. A
754
principal can allow a service to take on the principal's identity for
755
a particular purpose by granting it a proxy.
757
The PROXIABLE flag in a ticket is normally only interpreted by the
758
ticket-granting service. It can be ignored by application servers.
759
When set, this flag tells the ticket-granting server that it is OK to
760
issue a new ticket (but not a ticket-granting ticket) with a
761
different network address based on this ticket. This flag is set by
764
This flag allows a client to pass a proxy to a server to perform a
765
remote request on its behalf, e.g., a print service client can give
766
the print server a proxy to access the client's files on a particular
767
file server in order to satisfy a print request.
769
In order to complicate the use of stolen credentials, Kerberos
770
tickets are usually valid from only those network addresses
771
specifically included in the ticket (It is permissible to request or
772
issue tickets with no network addresses specified, but we do not
773
recommend it). For this reason, a client wishing to grant a proxy
774
must request a new ticket valid for the network address of the
775
service to be granted the proxy.
777
The PROXY flag is set in a ticket by the TGS when it issues a
778
proxy ticket. Application servers may check this flag and require
779
additional authentication from the agent presenting the proxy in
780
order to provide an audit trail.
786
Kohl & Neuman [Page 14]
788
RFC 1510 Kerberos September 1993
791
2.6. Forwardable tickets
793
Authentication forwarding is an instance of the proxy case where the
794
service is granted complete use of the client's identity. An example
795
where it might be used is when a user logs in to a remote system and
796
wants authentication to work from that system as if the login were
799
The FORWARDABLE flag in a ticket is normally only interpreted by the
800
ticket-granting service. It can be ignored by application servers.
801
The FORWARDABLE flag has an interpretation similar to that of the
802
PROXIABLE flag, except ticket-granting tickets may also be issued
803
with different network addresses. This flag is reset by default, but
804
users may request that it be set by setting the FORWARDABLE option in
805
the AS request when they request their initial ticket-granting
808
This flag allows for authentication forwarding without requiring the
809
user to enter a password again. If the flag is not set, then
810
authentication forwarding is not permitted, but the same end result
811
can still be achieved if the user engages in the AS exchange with the
812
requested network addresses and supplies a password.
814
The FORWARDED flag is set by the TGS when a client presents a ticket
815
with the FORWARDABLE flag set and requests it be set by specifying
816
the FORWARDED KDC option and supplying a set of addresses for the new
817
ticket. It is also set in all tickets issued based on tickets with
818
the FORWARDED flag set. Application servers may wish to process
819
FORWARDED tickets differently than non-FORWARDED tickets.
821
2.7. Other KDC options
823
There are two additional options which may be set in a client's
824
request of the KDC. The RENEWABLE-OK option indicates that the
825
client will accept a renewable ticket if a ticket with the requested
826
life cannot otherwise be provided. If a ticket with the requested
827
life cannot be provided, then the KDC may issue a renewable ticket
828
with a renew-till equal to the the requested endtime. The value of
829
the renew-till field may still be adjusted by site-determined limits
830
or limits imposed by the individual principal or server.
832
The ENC-TKT-IN-SKEY option is honored only by the ticket-granting
833
service. It indicates that the to-be-issued ticket for the end
834
server is to be encrypted in the session key from the additional
835
ticket-granting ticket provided with the request. See section 3.3.3
836
for specific details.
842
Kohl & Neuman [Page 15]
844
RFC 1510 Kerberos September 1993
849
The following sections describe the interactions between network
850
clients and servers and the messages involved in those exchanges.
852
3.1. The Authentication Service Exchange
856
Message direction Message type Section
857
1. Client to Kerberos KRB_AS_REQ 5.4.1
858
2. Kerberos to client KRB_AS_REP or 5.4.2
861
The Authentication Service (AS) Exchange between the client and the
862
Kerberos Authentication Server is usually initiated by a client when
863
it wishes to obtain authentication credentials for a given server but
864
currently holds no credentials. The client's secret key is used for
865
encryption and decryption. This exchange is typically used at the
866
initiation of a login session, to obtain credentials for a Ticket-
867
Granting Server, which will subsequently be used to obtain
868
credentials for other servers (see section 3.3) without requiring
869
further use of the client's secret key. This exchange is also used
870
to request credentials for services which must not be mediated
871
through the Ticket-Granting Service, but rather require a principal's
872
secret key, such as the password-changing service. (The password-
873
changing request must not be honored unless the requester can provide
874
the old password (the user's current secret key). Otherwise, it
875
would be possible for someone to walk up to an unattended session and
876
change another user's password.) This exchange does not by itself
877
provide any assurance of the the identity of the user. (To
878
authenticate a user logging on to a local system, the credentials
879
obtained in the AS exchange may first be used in a TGS exchange to
880
obtain credentials for a local server. Those credentials must then
881
be verified by the local server through successful completion of the
882
Client/Server exchange.)
884
The exchange consists of two messages: KRB_AS_REQ from the client to
885
Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these
886
messages are described in sections 5.4.1, 5.4.2, and 5.9.1.
888
In the request, the client sends (in cleartext) its own identity and
889
the identity of the server for which it is requesting credentials.
890
The response, KRB_AS_REP, contains a ticket for the client to present
891
to the server, and a session key that will be shared by the client
892
and the server. The session key and additional information are
893
encrypted in the client's secret key. The KRB_AS_REP message
894
contains information which can be used to detect replays, and to
898
Kohl & Neuman [Page 16]
900
RFC 1510 Kerberos September 1993
903
associate it with the message to which it replies. Various errors
904
can occur; these are indicated by an error response (KRB_ERROR)
905
instead of the KRB_AS_REP response. The error message is not
906
encrypted. The KRB_ERROR message also contains information which can
907
be used to associate it with the message to which it replies. The
908
lack of encryption in the KRB_ERROR message precludes the ability to
909
detect replays or fabrications of such messages.
911
In the normal case the authentication server does not know whether
912
the client is actually the principal named in the request. It simply
913
sends a reply without knowing or caring whether they are the same.
914
This is acceptable because nobody but the principal whose identity
915
was given in the request will be able to use the reply. Its critical
916
information is encrypted in that principal's key. The initial
917
request supports an optional field that can be used to pass
918
additional information that might be needed for the initial exchange.
919
This field may be used for preauthentication if desired, but the
920
mechanism is not currently specified.
922
3.1.1. Generation of KRB_AS_REQ message
924
The client may specify a number of options in the initial request.
925
Among these options are whether preauthentication is to be performed;
926
whether the requested ticket is to be renewable, proxiable, or
927
forwardable; whether it should be postdated or allow postdating of
928
derivative tickets; and whether a renewable ticket will be accepted
929
in lieu of a non-renewable ticket if the requested ticket expiration
930
date cannot be satisfied by a nonrenewable ticket (due to
931
configuration constraints; see section 4). See section A.1 for
934
The client prepares the KRB_AS_REQ message and sends it to the KDC.
936
3.1.2. Receipt of KRB_AS_REQ message
938
If all goes well, processing the KRB_AS_REQ message will result in
939
the creation of a ticket for the client to present to the server.
940
The format for the ticket is described in section 5.3.1. The
941
contents of the ticket are determined as follows.
943
3.1.3. Generation of KRB_AS_REP message
945
The authentication server looks up the client and server principals
946
named in the KRB_AS_REQ in its database, extracting their respective
947
keys. If required, the server pre-authenticates the request, and if
948
the pre-authentication check fails, an error message with the code
949
KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate
950
the requested encryption type, an error message with code
954
Kohl & Neuman [Page 17]
956
RFC 1510 Kerberos September 1993
959
KDC_ERR_ETYPE_NOSUPP is returned. Otherwise it generates a "random"
960
session key ("Random" means that, among other things, it should be
961
impossible to guess the next session key based on knowledge of past
962
session keys. This can only be achieved in a pseudo-random number
963
generator if it is based on cryptographic principles. It would be
964
more desirable to use a truly random number generator, such as one
965
based on measurements of random physical phenomena.).
967
If the requested start time is absent or indicates a time in the
968
past, then the start time of the ticket is set to the authentication
969
server's current time. If it indicates a time in the future, but the
970
POSTDATED option has not been specified, then the error
971
KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the requested start
972
time is checked against the policy of the local realm (the
973
administrator might decide to prohibit certain types or ranges of
974
postdated tickets), and if acceptable, the ticket's start time is set
975
as requested and the INVALID flag is set in the new ticket. The
976
postdated ticket must be validated before use by presenting it to the
977
KDC after the start time has been reached.
979
The expiration time of the ticket will be set to the minimum of the
982
+The expiration time (endtime) requested in the KRB_AS_REQ
985
+The ticket's start time plus the maximum allowable lifetime
986
associated with the client principal (the authentication
987
server's database includes a maximum ticket lifetime field
988
in each principal's record; see section 4).
990
+The ticket's start time plus the maximum allowable lifetime
991
associated with the server principal.
993
+The ticket's start time plus the maximum lifetime set by
994
the policy of the local realm.
996
If the requested expiration time minus the start time (as determined
997
above) is less than a site-determined minimum lifetime, an error
998
message with code KDC_ERR_NEVER_VALID is returned. If the requested
999
expiration time for the ticket exceeds what was determined as above,
1000
and if the "RENEWABLE-OK" option was requested, then the "RENEWABLE"
1001
flag is set in the new ticket, and the renew-till value is set as if
1002
the "RENEWABLE" option were requested (the field and option names are
1003
described fully in section 5.4.1). If the RENEWABLE option has been
1004
requested or if the RENEWABLE-OK option has been set and a renewable
1005
ticket is to be issued, then the renew-till field is set to the
1010
Kohl & Neuman [Page 18]
1012
RFC 1510 Kerberos September 1993
1015
+Its requested value.
1017
+The start time of the ticket plus the minimum of the two
1018
maximum renewable lifetimes associated with the principals'
1021
+The start time of the ticket plus the maximum renewable
1022
lifetime set by the policy of the local realm.
1024
The flags field of the new ticket will have the following options set
1025
if they have been requested and if the policy of the local realm
1026
allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE.
1027
If the new ticket is postdated (the start time is in the future), its
1028
INVALID flag will also be set.
1030
If all of the above succeed, the server formats a KRB_AS_REP message
1031
(see section 5.4.2), copying the addresses in the request into the
1032
caddr of the response, placing any required pre-authentication data
1033
into the padata of the response, and encrypts the ciphertext part in
1034
the client's key using the requested encryption method, and sends it
1035
to the client. See section A.2 for pseudocode.
1037
3.1.4. Generation of KRB_ERROR message
1039
Several errors can occur, and the Authentication Server responds by
1040
returning an error message, KRB_ERROR, to the client, with the
1041
error-code and e-text fields set to appropriate values. The error
1042
message contents and details are described in Section 5.9.1.
1044
3.1.5. Receipt of KRB_AS_REP message
1046
If the reply message type is KRB_AS_REP, then the client verifies
1047
that the cname and crealm fields in the cleartext portion of the
1048
reply match what it requested. If any padata fields are present,
1049
they may be used to derive the proper secret key to decrypt the
1050
message. The client decrypts the encrypted part of the response
1051
using its secret key, verifies that the nonce in the encrypted part
1052
matches the nonce it supplied in its request (to detect replays). It
1053
also verifies that the sname and srealm in the response match those
1054
in the request, and that the host address field is also correct. It
1055
then stores the ticket, session key, start and expiration times, and
1056
other information for later use. The key-expiration field from the
1057
encrypted part of the response may be checked to notify the user of
1058
impending key expiration (the client program could then suggest
1059
remedial action, such as a password change). See section A.3 for
1062
Proper decryption of the KRB_AS_REP message is not sufficient to
1066
Kohl & Neuman [Page 19]
1068
RFC 1510 Kerberos September 1993
1071
verify the identity of the user; the user and an attacker could
1072
cooperate to generate a KRB_AS_REP format message which decrypts
1073
properly but is not from the proper KDC. If the host wishes to
1074
verify the identity of the user, it must require the user to present
1075
application credentials which can be verified using a securely-stored
1076
secret key. If those credentials can be verified, then the identity
1077
of the user can be assured.
1079
3.1.6. Receipt of KRB_ERROR message
1081
If the reply message type is KRB_ERROR, then the client interprets it
1082
as an error and performs whatever application-specific tasks are
1083
necessary to recover.
1085
3.2. The Client/Server Authentication Exchange
1089
Message direction Message type Section
1090
Client to Application server KRB_AP_REQ 5.5.1
1091
[optional] Application server to client KRB_AP_REP or 5.5.2
1094
The client/server authentication (CS) exchange is used by network
1095
applications to authenticate the client to the server and vice versa.
1096
The client must have already acquired credentials for the server
1097
using the AS or TGS exchange.
1099
3.2.1. The KRB_AP_REQ message
1101
The KRB_AP_REQ contains authentication information which should be
1102
part of the first message in an authenticated transaction. It
1103
contains a ticket, an authenticator, and some additional bookkeeping
1104
information (see section 5.5.1 for the exact format). The ticket by
1105
itself is insufficient to authenticate a client, since tickets are
1106
passed across the network in cleartext(Tickets contain both an
1107
encrypted and unencrypted portion, so cleartext here refers to the
1108
entire unit, which can be copied from one message and replayed in
1109
another without any cryptographic skill.), so the authenticator is
1110
used to prevent invalid replay of tickets by proving to the server
1111
that the client knows the session key of the ticket and thus is
1112
entitled to use it. The KRB_AP_REQ message is referred to elsewhere
1113
as the "authentication header."
1115
3.2.2. Generation of a KRB_AP_REQ message
1117
When a client wishes to initiate authentication to a server, it
1118
obtains (either through a credentials cache, the AS exchange, or the
1122
Kohl & Neuman [Page 20]
1124
RFC 1510 Kerberos September 1993
1127
TGS exchange) a ticket and session key for the desired service. The
1128
client may re-use any tickets it holds until they expire. The client
1129
then constructs a new Authenticator from the the system time, its
1130
name, and optionally an application specific checksum, an initial
1131
sequence number to be used in KRB_SAFE or KRB_PRIV messages, and/or a
1132
session subkey to be used in negotiations for a session key unique to
1133
this particular session. Authenticators may not be re-used and will
1134
be rejected if replayed to a server (Note that this can make
1135
applications based on unreliable transports difficult to code
1136
correctly, if the transport might deliver duplicated messages. In
1137
such cases, a new authenticator must be generated for each retry.).
1138
If a sequence number is to be included, it should be randomly chosen
1139
so that even after many messages have been exchanged it is not likely
1140
to collide with other sequence numbers in use.
1142
The client may indicate a requirement of mutual authentication or the
1143
use of a session-key based ticket by setting the appropriate flag(s)
1144
in the ap-options field of the message.
1146
The Authenticator is encrypted in the session key and combined with
1147
the ticket to form the KRB_AP_REQ message which is then sent to the
1148
end server along with any additional application-specific
1149
information. See section A.9 for pseudocode.
1151
3.2.3. Receipt of KRB_AP_REQ message
1153
Authentication is based on the server's current time of day (clocks
1154
must be loosely synchronized), the authenticator, and the ticket.
1155
Several errors are possible. If an error occurs, the server is
1156
expected to reply to the client with a KRB_ERROR message. This
1157
message may be encapsulated in the application protocol if its "raw"
1158
form is not acceptable to the protocol. The format of error messages
1159
is described in section 5.9.1.
1161
The algorithm for verifying authentication information is as follows.
1162
If the message type is not KRB_AP_REQ, the server returns the
1163
KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the Ticket
1164
in the KRB_AP_REQ is not one the server can use (e.g., it indicates
1165
an old key, and the server no longer possesses a copy of the old
1166
key), the KRB_AP_ERR_BADKEYVER error is returned. If the USE-
1167
SESSION-KEY flag is set in the ap-options field, it indicates to the
1168
server that the ticket is encrypted in the session key from the
1169
server's ticket-granting ticket rather than its secret key (This is
1170
used for user-to-user authentication as described in [6]). Since it
1171
is possible for the server to be registered in multiple realms, with
1172
different keys in each, the srealm field in the unencrypted portion
1173
of the ticket in the KRB_AP_REQ is used to specify which secret key
1174
the server should use to decrypt that ticket. The KRB_AP_ERR_NOKEY
1178
Kohl & Neuman [Page 21]
1180
RFC 1510 Kerberos September 1993
1183
error code is returned if the server doesn't have the proper key to
1184
decipher the ticket.
1186
The ticket is decrypted using the version of the server's key
1187
specified by the ticket. If the decryption routines detect a
1188
modification of the ticket (each encryption system must provide
1189
safeguards to detect modified ciphertext; see section 6), the
1190
KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that
1191
different keys were used to encrypt and decrypt).
1193
The authenticator is decrypted using the session key extracted from
1194
the decrypted ticket. If decryption shows it to have been modified,
1195
the KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm
1196
of the client from the ticket are compared against the same fields in
1197
the authenticator. If they don't match, the KRB_AP_ERR_BADMATCH
1198
error is returned (they might not match, for example, if the wrong
1199
session key was used to encrypt the authenticator). The addresses in
1200
the ticket (if any) are then searched for an address matching the
1201
operating-system reported address of the client. If no match is
1202
found or the server insists on ticket addresses but none are present
1203
in the ticket, the KRB_AP_ERR_BADADDR error is returned.
1205
If the local (server) time and the client time in the authenticator
1206
differ by more than the allowable clock skew (e.g., 5 minutes), the
1207
KRB_AP_ERR_SKEW error is returned. If the server name, along with
1208
the client name, time and microsecond fields from the Authenticator
1209
match any recently-seen such tuples, the KRB_AP_ERR_REPEAT error is
1210
returned (Note that the rejection here is restricted to
1211
authenticators from the same principal to the same server. Other
1212
client principals communicating with the same server principal should
1213
not be have their authenticators rejected if the time and microsecond
1214
fields happen to match some other client's authenticator.). The
1215
server must remember any authenticator presented within the allowable
1216
clock skew, so that a replay attempt is guaranteed to fail. If a
1217
server loses track of any authenticator presented within the
1218
allowable clock skew, it must reject all requests until the clock
1219
skew interval has passed. This assures that any lost or re-played
1220
authenticators will fall outside the allowable clock skew and can no
1221
longer be successfully replayed (If this is not done, an attacker
1222
could conceivably record the ticket and authenticator sent over the
1223
network to a server, then disable the client's host, pose as the
1224
disabled host, and replay the ticket and authenticator to subvert the
1225
authentication.). If a sequence number is provided in the
1226
authenticator, the server saves it for later use in processing
1227
KRB_SAFE and/or KRB_PRIV messages. If a subkey is present, the
1228
server either saves it for later use or uses it to help generate its
1229
own choice for a subkey to be returned in a KRB_AP_REP message.
1234
Kohl & Neuman [Page 22]
1236
RFC 1510 Kerberos September 1993
1239
The server computes the age of the ticket: local (server) time minus
1240
the start time inside the Ticket. If the start time is later than
1241
the current time by more than the allowable clock skew or if the
1242
INVALID flag is set in the ticket, the KRB_AP_ERR_TKT_NYV error is
1243
returned. Otherwise, if the current time is later than end time by
1244
more than the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error
1247
If all these checks succeed without an error, the server is assured
1248
that the client possesses the credentials of the principal named in
1249
the ticket and thus, the client has been authenticated to the server.
1250
See section A.10 for pseudocode.
1252
3.2.4. Generation of a KRB_AP_REP message
1254
Typically, a client's request will include both the authentication
1255
information and its initial request in the same message, and the
1256
server need not explicitly reply to the KRB_AP_REQ. However, if
1257
mutual authentication (not only authenticating the client to the
1258
server, but also the server to the client) is being performed, the
1259
KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options
1260
field, and a KRB_AP_REP message is required in response. As with the
1261
error message, this message may be encapsulated in the application
1262
protocol if its "raw" form is not acceptable to the application's
1263
protocol. The timestamp and microsecond field used in the reply must
1264
be the client's timestamp and microsecond field (as provided in the
1265
authenticator). [Note: In the Kerberos version 4 protocol, the
1266
timestamp in the reply was the client's timestamp plus one. This is
1267
not necessary in version 5 because version 5 messages are formatted
1268
in such a way that it is not possible to create the reply by
1269
judicious message surgery (even in encrypted form) without knowledge
1270
of the appropriate encryption keys.] If a sequence number is to be
1271
included, it should be randomly chosen as described above for the
1272
authenticator. A subkey may be included if the server desires to
1273
negotiate a different subkey. The KRB_AP_REP message is encrypted in
1274
the session key extracted from the ticket. See section A.11 for
1277
3.2.5. Receipt of KRB_AP_REP message
1279
If a KRB_AP_REP message is returned, the client uses the session key
1280
from the credentials obtained for the server (Note that for
1281
encrypting the KRB_AP_REP message, the sub-session key is not used,
1282
even if present in the Authenticator.) to decrypt the message, and
1283
verifies that the timestamp and microsecond fields match those in the
1284
Authenticator it sent to the server. If they match, then the client
1285
is assured that the server is genuine. The sequence number and subkey
1286
(if present) are retained for later use. See section A.12 for
1290
Kohl & Neuman [Page 23]
1292
RFC 1510 Kerberos September 1993
1297
3.2.6. Using the encryption key
1299
After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and
1300
server share an encryption key which can be used by the application.
1301
The "true session key" to be used for KRB_PRIV, KRB_SAFE, or other
1302
application-specific uses may be chosen by the application based on
1303
the subkeys in the KRB_AP_REP message and the authenticator
1304
(Implementations of the protocol may wish to provide routines to
1305
choose subkeys based on session keys and random numbers and to
1306
orchestrate a negotiated key to be returned in the KRB_AP_REP
1307
message.). In some cases, the use of this session key will be
1308
implicit in the protocol; in others the method of use must be chosen
1309
from a several alternatives. We leave the protocol negotiations of
1310
how to use the key (e.g., selecting an encryption or checksum type)
1311
to the application programmer; the Kerberos protocol does not
1312
constrain the implementation options.
1314
With both the one-way and mutual authentication exchanges, the peers
1315
should take care not to send sensitive information to each other
1316
without proper assurances. In particular, applications that require
1317
privacy or integrity should use the KRB_AP_REP or KRB_ERROR responses
1318
from the server to client to assure both client and server of their
1319
peer's identity. If an application protocol requires privacy of its
1320
messages, it can use the KRB_PRIV message (section 3.5). The KRB_SAFE
1321
message (section 3.4) can be used to assure integrity.
1323
3.3. The Ticket-Granting Service (TGS) Exchange
1327
Message direction Message type Section
1328
1. Client to Kerberos KRB_TGS_REQ 5.4.1
1329
2. Kerberos to client KRB_TGS_REP or 5.4.2
1332
The TGS exchange between a client and the Kerberos Ticket-Granting
1333
Server is initiated by a client when it wishes to obtain
1334
authentication credentials for a given server (which might be
1335
registered in a remote realm), when it wishes to renew or validate an
1336
existing ticket, or when it wishes to obtain a proxy ticket. In the
1337
first case, the client must already have acquired a ticket for the
1338
Ticket-Granting Service using the AS exchange (the ticket-granting
1339
ticket is usually obtained when a client initially authenticates to
1340
the system, such as when a user logs in). The message format for the
1341
TGS exchange is almost identical to that for the AS exchange. The
1342
primary difference is that encryption and decryption in the TGS
1346
Kohl & Neuman [Page 24]
1348
RFC 1510 Kerberos September 1993
1351
exchange does not take place under the client's key. Instead, the
1352
session key from the ticket-granting ticket or renewable ticket, or
1353
sub-session key from an Authenticator is used. As is the case for
1354
all application servers, expired tickets are not accepted by the TGS,
1355
so once a renewable or ticket-granting ticket expires, the client
1356
must use a separate exchange to obtain valid tickets.
1358
The TGS exchange consists of two messages: A request (KRB_TGS_REQ)
1359
from the client to the Kerberos Ticket-Granting Server, and a reply
1360
(KRB_TGS_REP or KRB_ERROR). The KRB_TGS_REQ message includes
1361
information authenticating the client plus a request for credentials.
1362
The authentication information consists of the authentication header
1363
(KRB_AP_REQ) which includes the client's previously obtained ticket-
1364
granting, renewable, or invalid ticket. In the ticket-granting
1365
ticket and proxy cases, the request may include one or more of: a
1366
list of network addresses, a collection of typed authorization data
1367
to be sealed in the ticket for authorization use by the application
1368
server, or additional tickets (the use of which are described later).
1369
The TGS reply (KRB_TGS_REP) contains the requested credentials,
1370
encrypted in the session key from the ticket-granting ticket or
1371
renewable ticket, or if present, in the subsession key from the
1372
Authenticator (part of the authentication header). The KRB_ERROR
1373
message contains an error code and text explaining what went wrong.
1374
The KRB_ERROR message is not encrypted. The KRB_TGS_REP message
1375
contains information which can be used to detect replays, and to
1376
associate it with the message to which it replies. The KRB_ERROR
1377
message also contains information which can be used to associate it
1378
with the message to which it replies, but the lack of encryption in
1379
the KRB_ERROR message precludes the ability to detect replays or
1380
fabrications of such messages.
1382
3.3.1. Generation of KRB_TGS_REQ message
1384
Before sending a request to the ticket-granting service, the client
1385
must determine in which realm the application server is registered
1386
[Note: This can be accomplished in several ways. It might be known
1387
beforehand (since the realm is part of the principal identifier), or
1388
it might be stored in a nameserver. Presently, however, this
1389
information is obtained from a configuration file. If the realm to
1390
be used is obtained from a nameserver, there is a danger of being
1391
spoofed if the nameservice providing the realm name is not
1392
authenticated. This might result in the use of a realm which has
1393
been compromised, and would result in an attacker's ability to
1394
compromise the authentication of the application server to the
1395
client.]. If the client does not already possess a ticket-granting
1396
ticket for the appropriate realm, then one must be obtained. This is
1397
first attempted by requesting a ticket-granting ticket for the
1398
destination realm from the local Kerberos server (using the
1402
Kohl & Neuman [Page 25]
1404
RFC 1510 Kerberos September 1993
1407
KRB_TGS_REQ message recursively). The Kerberos server may return a
1408
TGT for the desired realm in which case one can proceed.
1409
Alternatively, the Kerberos server may return a TGT for a realm which
1410
is "closer" to the desired realm (further along the standard
1411
hierarchical path), in which case this step must be repeated with a
1412
Kerberos server in the realm specified in the returned TGT. If
1413
neither are returned, then the request must be retried with a
1414
Kerberos server for a realm higher in the hierarchy. This request
1415
will itself require a ticket-granting ticket for the higher realm
1416
which must be obtained by recursively applying these directions.
1418
Once the client obtains a ticket-granting ticket for the appropriate
1419
realm, it determines which Kerberos servers serve that realm, and
1420
contacts one. The list might be obtained through a configuration file
1421
or network service; as long as the secret keys exchanged by realms
1422
are kept secret, only denial of service results from a false Kerberos
1425
As in the AS exchange, the client may specify a number of options in
1426
the KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ
1427
message, providing an authentication header as an element of the
1428
padata field, and including the same fields as used in the KRB_AS_REQ
1429
message along with several optional fields: the enc-authorization-
1430
data field for application server use and additional tickets required
1433
In preparing the authentication header, the client can select a sub-
1434
session key under which the response from the Kerberos server will be
1435
encrypted (If the client selects a sub-session key, care must be
1436
taken to ensure the randomness of the selected subsession key. One
1437
approach would be to generate a random number and XOR it with the
1438
session key from the ticket-granting ticket.). If the sub-session key
1439
is not specified, the session key from the ticket-granting ticket
1440
will be used. If the enc-authorization-data is present, it must be
1441
encrypted in the sub-session key, if present, from the authenticator
1442
portion of the authentication header, or if not present in the
1443
session key from the ticket-granting ticket.
1445
Once prepared, the message is sent to a Kerberos server for the
1446
destination realm. See section A.5 for pseudocode.
1448
3.3.2. Receipt of KRB_TGS_REQ message
1450
The KRB_TGS_REQ message is processed in a manner similar to the
1451
KRB_AS_REQ message, but there are many additional checks to be
1452
performed. First, the Kerberos server must determine which server
1453
the accompanying ticket is for and it must select the appropriate key
1454
to decrypt it. For a normal KRB_TGS_REQ message, it will be for the
1458
Kohl & Neuman [Page 26]
1460
RFC 1510 Kerberos September 1993
1463
ticket granting service, and the TGS's key will be used. If the TGT
1464
was issued by another realm, then the appropriate inter-realm key
1465
must be used. If the accompanying ticket is not a ticket granting
1466
ticket for the current realm, but is for an application server in the
1467
current realm, the RENEW, VALIDATE, or PROXY options are specified in
1468
the request, and the server for which a ticket is requested is the
1469
server named in the accompanying ticket, then the KDC will decrypt
1470
the ticket in the authentication header using the key of the server
1471
for which it was issued. If no ticket can be found in the padata
1472
field, the KDC_ERR_PADATA_TYPE_NOSUPP error is returned.
1474
Once the accompanying ticket has been decrypted, the user-supplied
1475
checksum in the Authenticator must be verified against the contents
1476
of the request, and the message rejected if the checksums do not
1477
match (with an error code of KRB_AP_ERR_MODIFIED) or if the checksum
1478
is not keyed or not collision-proof (with an error code of
1479
KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported, the
1480
KDC_ERR_SUMTYPE_NOSUPP error is returned. If the authorization-data
1481
are present, they are decrypted using the sub-session key from the
1484
If any of the decryptions indicate failed integrity checks, the
1485
KRB_AP_ERR_BAD_INTEGRITY error is returned.
1487
3.3.3. Generation of KRB_TGS_REP message
1489
The KRB_TGS_REP message shares its format with the KRB_AS_REP
1490
(KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The
1491
detailed specification is in section 5.4.2.
1493
The response will include a ticket for the requested server. The
1494
Kerberos database is queried to retrieve the record for the requested
1495
server (including the key with which the ticket will be encrypted).
1496
If the request is for a ticket granting ticket for a remote realm,
1497
and if no key is shared with the requested realm, then the Kerberos
1498
server will select the realm "closest" to the requested realm with
1499
which it does share a key, and use that realm instead. This is the
1500
only case where the response from the KDC will be for a different
1501
server than that requested by the client.
1503
By default, the address field, the client's name and realm, the list
1504
of transited realms, the time of initial authentication, the
1505
expiration time, and the authorization data of the newly-issued
1506
ticket will be copied from the ticket-granting ticket (TGT) or
1507
renewable ticket. If the transited field needs to be updated, but
1508
the transited type is not supported, the KDC_ERR_TRTYPE_NOSUPP error
1514
Kohl & Neuman [Page 27]
1516
RFC 1510 Kerberos September 1993
1519
If the request specifies an endtime, then the endtime of the new
1520
ticket is set to the minimum of (a) that request, (b) the endtime
1521
from the TGT, and (c) the starttime of the TGT plus the minimum of
1522
the maximum life for the application server and the maximum life for
1523
the local realm (the maximum life for the requesting principal was
1524
already applied when the TGT was issued). If the new ticket is to be
1525
a renewal, then the endtime above is replaced by the minimum of (a)
1526
the value of the renew_till field of the ticket and (b) the starttime
1527
for the new ticket plus the life (endtimestarttime) of the old
1530
If the FORWARDED option has been requested, then the resulting ticket
1531
will contain the addresses specified by the client. This option will
1532
only be honored if the FORWARDABLE flag is set in the TGT. The PROXY
1533
option is similar; the resulting ticket will contain the addresses
1534
specified by the client. It will be honored only if the PROXIABLE
1535
flag in the TGT is set. The PROXY option will not be honored on
1536
requests for additional ticket-granting tickets.
1538
If the requested start time is absent or indicates a time in the
1539
past, then the start time of the ticket is set to the authentication
1540
server's current time. If it indicates a time in the future, but the
1541
POSTDATED option has not been specified or the MAY-POSTDATE flag is
1542
not set in the TGT, then the error KDC_ERR_CANNOT_POSTDATE is
1543
returned. Otherwise, if the ticket-granting ticket has the
1544
MAYPOSTDATE flag set, then the resulting ticket will be postdated and
1545
the requested starttime is checked against the policy of the local
1546
realm. If acceptable, the ticket's start time is set as requested,
1547
and the INVALID flag is set. The postdated ticket must be validated
1548
before use by presenting it to the KDC after the starttime has been
1549
reached. However, in no case may the starttime, endtime, or renew-
1550
till time of a newly-issued postdated ticket extend beyond the
1551
renew-till time of the ticket-granting ticket.
1553
If the ENC-TKT-IN-SKEY option has been specified and an additional
1554
ticket has been included in the request, the KDC will decrypt the
1555
additional ticket using the key for the server to which the
1556
additional ticket was issued and verify that it is a ticket-granting
1557
ticket. If the name of the requested server is missing from the
1558
request, the name of the client in the additional ticket will be
1559
used. Otherwise the name of the requested server will be compared to
1560
the name of the client in the additional ticket and if different, the
1561
request will be rejected. If the request succeeds, the session key
1562
from the additional ticket will be used to encrypt the new ticket
1563
that is issued instead of using the key of the server for which the
1564
new ticket will be used (This allows easy implementation of user-to-
1565
user authentication [6], which uses ticket-granting ticket session
1566
keys in lieu of secret server keys in situations where such secret
1570
Kohl & Neuman [Page 28]
1572
RFC 1510 Kerberos September 1993
1575
keys could be easily compromised.).
1577
If the name of the server in the ticket that is presented to the KDC
1578
as part of the authentication header is not that of the ticket-
1579
granting server itself, and the server is registered in the realm of
1580
the KDC, If the RENEW option is requested, then the KDC will verify
1581
that the RENEWABLE flag is set in the ticket and that the renew_till
1582
time is still in the future. If the VALIDATE option is rqeuested,
1583
the KDC will check that the starttime has passed and the INVALID flag
1584
is set. If the PROXY option is requested, then the KDC will check
1585
that the PROXIABLE flag is set in the ticket. If the tests succeed,
1586
the KDC will issue the appropriate new ticket.
1588
Whenever a request is made to the ticket-granting server, the
1589
presented ticket(s) is(are) checked against a hot-list of tickets
1590
which have been canceled. This hot-list might be implemented by
1591
storing a range of issue dates for "suspect tickets"; if a presented
1592
ticket had an authtime in that range, it would be rejected. In this
1593
way, a stolen ticket-granting ticket or renewable ticket cannot be
1594
used to gain additional tickets (renewals or otherwise) once the
1595
theft has been reported. Any normal ticket obtained before it was
1596
reported stolen will still be valid (because they require no
1597
interaction with the KDC), but only until their normal expiration
1600
The ciphertext part of the response in the KRB_TGS_REP message is
1601
encrypted in the sub-session key from the Authenticator, if present,
1602
or the session key key from the ticket-granting ticket. It is not
1603
encrypted using the client's secret key. Furthermore, the client's
1604
key's expiration date and the key version number fields are left out
1605
since these values are stored along with the client's database
1606
record, and that record is not needed to satisfy a request based on a
1607
ticket-granting ticket. See section A.6 for pseudocode.
1609
3.3.3.1. Encoding the transited field
1611
If the identity of the server in the TGT that is presented to the KDC
1612
as part of the authentication header is that of the ticket-granting
1613
service, but the TGT was issued from another realm, the KDC will look
1614
up the inter-realm key shared with that realm and use that key to
1615
decrypt the ticket. If the ticket is valid, then the KDC will honor
1616
the request, subject to the constraints outlined above in the section
1617
describing the AS exchange. The realm part of the client's identity
1618
will be taken from the ticket-granting ticket. The name of the realm
1619
that issued the ticket-granting ticket will be added to the transited
1620
field of the ticket to be issued. This is accomplished by reading
1621
the transited field from the ticket-granting ticket (which is treated
1622
as an unordered set of realm names), adding the new realm to the set,
1626
Kohl & Neuman [Page 29]
1628
RFC 1510 Kerberos September 1993
1631
then constructing and writing out its encoded (shorthand) form (this
1632
may involve a rearrangement of the existing encoding).
1634
Note that the ticket-granting service does not add the name of its
1635
own realm. Instead, its responsibility is to add the name of the
1636
previous realm. This prevents a malicious Kerberos server from
1637
intentionally leaving out its own name (it could, however, omit other
1640
The names of neither the local realm nor the principal's realm are to
1641
be included in the transited field. They appear elsewhere in the
1642
ticket and both are known to have taken part in authenticating the
1643
principal. Since the endpoints are not included, both local and
1644
single-hop inter-realm authentication result in a transited field
1647
Because the name of each realm transited is added to this field,
1648
it might potentially be very long. To decrease the length of this
1649
field, its contents are encoded. The initially supported encoding is
1650
optimized for the normal case of inter-realm communication: a
1651
hierarchical arrangement of realms using either domain or X.500 style
1652
realm names. This encoding (called DOMAIN-X500-COMPRESS) is now
1655
Realm names in the transited field are separated by a ",". The ",",
1656
"\", trailing "."s, and leading spaces (" ") are special characters,
1657
and if they are part of a realm name, they must be quoted in the
1658
transited field by preceding them with a "\".
1660
A realm name ending with a "." is interpreted as being prepended to
1661
the previous realm. For example, we can encode traversal of EDU,
1662
MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as:
1664
"EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
1666
Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were endpoints,
1667
that they would not be included in this field, and we would have:
1669
"EDU,MIT.,WASHINGTON.EDU"
1671
A realm name beginning with a "/" is interpreted as being appended to
1672
the previous realm (For the purpose of appending, the realm preceding
1673
the first listed realm is considered to be the null realm ("")). If
1674
it is to stand by itself, then it should be preceded by a space ("
1675
"). For example, we can encode traversal of /COM/HP/APOLLO, /COM/HP,
1676
/COM, and /COM/DEC as:
1678
"/COM,/HP,/APOLLO, /COM/DEC".
1682
Kohl & Neuman [Page 30]
1684
RFC 1510 Kerberos September 1993
1687
Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints,
1688
they they would not be included in this field, and we would have:
1692
A null subfield preceding or following a "," indicates that all
1693
realms between the previous realm and the next realm have been
1694
traversed (For the purpose of interpreting null subfields, the
1695
client's realm is considered to precede those in the transited field,
1696
and the server's realm is considered to follow them.). Thus, ","
1697
means that all realms along the path between the client and the
1698
server have been traversed. ",EDU, /COM," means that that all realms
1699
from the client's realm up to EDU (in a domain style hierarchy) have
1700
been traversed, and that everything from /COM down to the server's
1701
realm in an X.500 style has also been traversed. This could occur if
1702
the EDU realm in one hierarchy shares an inter-realm key directly
1703
with the /COM realm in another hierarchy.
1705
3.3.4. Receipt of KRB_TGS_REP message
1707
When the KRB_TGS_REP is received by the client, it is processed in
1708
the same manner as the KRB_AS_REP processing described above. The
1709
primary difference is that the ciphertext part of the response must
1710
be decrypted using the session key from the ticket-granting ticket
1711
rather than the client's secret key. See section A.7 for pseudocode.
1713
3.4. The KRB_SAFE Exchange
1715
The KRB_SAFE message may be used by clients requiring the ability to
1716
detect modifications of messages they exchange. It achieves this by
1717
including a keyed collisionproof checksum of the user data and some
1718
control information. The checksum is keyed with an encryption key
1719
(usually the last key negotiated via subkeys, or the session key if
1720
no negotiation has occured).
1722
3.4.1. Generation of a KRB_SAFE message
1724
When an application wishes to send a KRB_SAFE message, it collects
1725
its data and the appropriate control information and computes a
1726
checksum over them. The checksum algorithm should be some sort of
1727
keyed one-way hash function (such as the RSA-MD5-DES checksum
1728
algorithm specified in section 6.4.5, or the DES MAC), generated
1729
using the sub-session key if present, or the session key. Different
1730
algorithms may be selected by changing the checksum type in the
1731
message. Unkeyed or non-collision-proof checksums are not suitable
1734
The control information for the KRB_SAFE message includes both a
1738
Kohl & Neuman [Page 31]
1740
RFC 1510 Kerberos September 1993
1743
timestamp and a sequence number. The designer of an application
1744
using the KRB_SAFE message must choose at least one of the two
1745
mechanisms. This choice should be based on the needs of the
1746
application protocol.
1748
Sequence numbers are useful when all messages sent will be received
1749
by one's peer. Connection state is presently required to maintain
1750
the session key, so maintaining the next sequence number should not
1751
present an additional problem.
1753
If the application protocol is expected to tolerate lost messages
1754
without them being resent, the use of the timestamp is the
1755
appropriate replay detection mechanism. Using timestamps is also the
1756
appropriate mechanism for multi-cast protocols where all of one's
1757
peers share a common sub-session key, but some messages will be sent
1758
to a subset of one's peers.
1760
After computing the checksum, the client then transmits the
1761
information and checksum to the recipient in the message format
1762
specified in section 5.6.1.
1764
3.4.2. Receipt of KRB_SAFE message
1766
When an application receives a KRB_SAFE message, it verifies it as
1767
follows. If any error occurs, an error code is reported for use by
1770
The message is first checked by verifying that the protocol version
1771
and type fields match the current version and KRB_SAFE, respectively.
1772
A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE
1773
error. The application verifies that the checksum used is a
1774
collisionproof keyed checksum, and if it is not, a
1775
KRB_AP_ERR_INAPP_CKSUM error is generated. The recipient verifies
1776
that the operating system's report of the sender's address matches
1777
the sender's address in the message, and (if a recipient address is
1778
specified or the recipient requires an address) that one of the
1779
recipient's addresses appears as the recipient's address in the
1780
message. A failed match for either case generates a
1781
KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the
1782
sequence number fields are checked. If timestamp and usec are
1783
expected and not present, or they are present but not current, the
1784
KRB_AP_ERR_SKEW error is generated. If the server name, along with
1785
the client name, time and microsecond fields from the Authenticator
1786
match any recently-seen such tuples, the KRB_AP_ERR_REPEAT error is
1787
generated. If an incorrect sequence number is included, or a
1788
sequence number is expected but not present, the KRB_AP_ERR_BADORDER
1789
error is generated. If neither a timestamp and usec or a sequence
1790
number is present, a KRB_AP_ERR_MODIFIED error is generated.
1794
Kohl & Neuman [Page 32]
1796
RFC 1510 Kerberos September 1993
1799
Finally, the checksum is computed over the data and control
1800
information, and if it doesn't match the received checksum, a
1801
KRB_AP_ERR_MODIFIED error is generated.
1803
If all the checks succeed, the application is assured that the
1804
message was generated by its peer and was not modified in transit.
1806
3.5. The KRB_PRIV Exchange
1808
The KRB_PRIV message may be used by clients requiring confidentiality
1809
and the ability to detect modifications of exchanged messages. It
1810
achieves this by encrypting the messages and adding control
1813
3.5.1. Generation of a KRB_PRIV message
1815
When an application wishes to send a KRB_PRIV message, it collects
1816
its data and the appropriate control information (specified in
1817
section 5.7.1) and encrypts them under an encryption key (usually the
1818
last key negotiated via subkeys, or the session key if no negotiation
1819
has occured). As part of the control information, the client must
1820
choose to use either a timestamp or a sequence number (or both); see
1821
the discussion in section 3.4.1 for guidelines on which to use.
1822
After the user data and control information are encrypted, the client
1823
transmits the ciphertext and some "envelope" information to the
1826
3.5.2. Receipt of KRB_PRIV message
1828
When an application receives a KRB_PRIV message, it verifies it as
1829
follows. If any error occurs, an error code is reported for use by
1832
The message is first checked by verifying that the protocol version
1833
and type fields match the current version and KRB_PRIV, respectively.
1834
A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE
1835
error. The application then decrypts the ciphertext and processes
1836
the resultant plaintext. If decryption shows the data to have been
1837
modified, a KRB_AP_ERR_BAD_INTEGRITY error is generated. The
1838
recipient verifies that the operating system's report of the sender's
1839
address matches the sender's address in the message, and (if a
1840
recipient address is specified or the recipient requires an address)
1841
that one of the recipient's addresses appears as the recipient's
1842
address in the message. A failed match for either case generates a
1843
KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the
1844
sequence number fields are checked. If timestamp and usec are
1845
expected and not present, or they are present but not current, the
1846
KRB_AP_ERR_SKEW error is generated. If the server name, along with
1850
Kohl & Neuman [Page 33]
1852
RFC 1510 Kerberos September 1993
1855
the client name, time and microsecond fields from the Authenticator
1856
match any recently-seen such tuples, the KRB_AP_ERR_REPEAT error is
1857
generated. If an incorrect sequence number is included, or a
1858
sequence number is expected but not present, the KRB_AP_ERR_BADORDER
1859
error is generated. If neither a timestamp and usec or a sequence
1860
number is present, a KRB_AP_ERR_MODIFIED error is generated.
1862
If all the checks succeed, the application can assume the message was
1863
generated by its peer, and was securely transmitted (without
1864
intruders able to see the unencrypted contents).
1866
3.6. The KRB_CRED Exchange
1868
The KRB_CRED message may be used by clients requiring the ability to
1869
send Kerberos credentials from one host to another. It achieves this
1870
by sending the tickets together with encrypted data containing the
1871
session keys and other information associated with the tickets.
1873
3.6.1. Generation of a KRB_CRED message
1875
When an application wishes to send a KRB_CRED message it first (using
1876
the KRB_TGS exchange) obtains credentials to be sent to the remote
1877
host. It then constructs a KRB_CRED message using the ticket or
1878
tickets so obtained, placing the session key needed to use each
1879
ticket in the key field of the corresponding KrbCredInfo sequence of
1880
the encrypted part of the the KRB_CRED message.
1882
Other information associated with each ticket and obtained during the
1883
KRB_TGS exchange is also placed in the corresponding KrbCredInfo
1884
sequence in the encrypted part of the KRB_CRED message. The current
1885
time and, if specifically required by the application the nonce, s-
1886
address, and raddress fields, are placed in the encrypted part of the
1887
KRB_CRED message which is then encrypted under an encryption key
1888
previosuly exchanged in the KRB_AP exchange (usually the last key
1889
negotiated via subkeys, or the session key if no negotiation has
1892
3.6.2. Receipt of KRB_CRED message
1894
When an application receives a KRB_CRED message, it verifies it. If
1895
any error occurs, an error code is reported for use by the
1896
application. The message is verified by checking that the protocol
1897
version and type fields match the current version and KRB_CRED,
1898
respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or
1899
KRB_AP_ERR_MSG_TYPE error. The application then decrypts the
1900
ciphertext and processes the resultant plaintext. If decryption shows
1901
the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is
1906
Kohl & Neuman [Page 34]
1908
RFC 1510 Kerberos September 1993
1911
If present or required, the recipient verifies that the operating
1912
system's report of the sender's address matches the sender's address
1913
in the message, and that one of the recipient's addresses appears as
1914
the recipient's address in the message. A failed match for either
1915
case generates a KRB_AP_ERR_BADADDR error. The timestamp and usec
1916
fields (and the nonce field if required) are checked next. If the
1917
timestamp and usec are not present, or they are present but not
1918
current, the KRB_AP_ERR_SKEW error is generated.
1920
If all the checks succeed, the application stores each of the new
1921
tickets in its ticket cache together with the session key and other
1922
information in the corresponding KrbCredInfo sequence from the
1923
encrypted part of the KRB_CRED message.
1925
4. The Kerberos Database
1927
The Kerberos server must have access to a database containing the
1928
principal identifiers and secret keys of principals to be
1929
authenticated (The implementation of the Kerberos server need not
1930
combine the database and the server on the same machine; it is
1931
feasible to store the principal database in, say, a network name
1932
service, as long as the entries stored therein are protected from
1933
disclosure to and modification by unauthorized parties. However, we
1934
recommend against such strategies, as they can make system management
1935
and threat analysis quite complex.).
1937
4.1. Database contents
1939
A database entry should contain at least the following fields:
1943
name Principal's identifier
1944
key Principal's secret key
1945
p_kvno Principal's key version
1946
max_life Maximum lifetime for Tickets
1947
max_renewable_life Maximum total lifetime for renewable
1950
The name field is an encoding of the principal's identifier. The key
1951
field contains an encryption key. This key is the principal's secret
1952
key. (The key can be encrypted before storage under a Kerberos
1953
"master key" to protect it in case the database is compromised but
1954
the master key is not. In that case, an extra field must be added to
1955
indicate the master key version used, see below.) The p_kvno field is
1956
the key version number of the principal's secret key. The max_life
1957
field contains the maximum allowable lifetime (endtime - starttime)
1958
for any Ticket issued for this principal. The max_renewable_life
1962
Kohl & Neuman [Page 35]
1964
RFC 1510 Kerberos September 1993
1967
field contains the maximum allowable total lifetime for any renewable
1968
Ticket issued for this principal. (See section 3.1 for a description
1969
of how these lifetimes are used in determining the lifetime of a
1972
A server may provide KDC service to several realms, as long as the
1973
database representation provides a mechanism to distinguish between
1974
principal records with identifiers which differ only in the realm
1977
When an application server's key changes, if the change is routine
1978
(i.e., not the result of disclosure of the old key), the old key
1979
should be retained by the server until all tickets that had been
1980
issued using that key have expired. Because of this, it is possible
1981
for several keys to be active for a single principal. Ciphertext
1982
encrypted in a principal's key is always tagged with the version of
1983
the key that was used for encryption, to help the recipient find the
1984
proper key for decryption.
1986
When more than one key is active for a particular principal, the
1987
principal will have more than one record in the Kerberos database.
1988
The keys and key version numbers will differ between the records (the
1989
rest of the fields may or may not be the same). Whenever Kerberos
1990
issues a ticket, or responds to a request for initial authentication,
1991
the most recent key (known by the Kerberos server) will be used for
1992
encryption. This is the key with the highest key version number.
1994
4.2. Additional fields
1996
Project Athena's KDC implementation uses additional fields in its
2001
K_kvno Kerberos' key version
2002
expiration Expiration date for entry
2003
attributes Bit field of attributes
2004
mod_date Timestamp of last modification
2005
mod_name Modifying principal's identifier
2007
The K_kvno field indicates the key version of the Kerberos master key
2008
under which the principal's secret key is encrypted.
2010
After an entry's expiration date has passed, the KDC will return an
2011
error to any client attempting to gain tickets as or for the
2012
principal. (A database may want to maintain two expiration dates:
2013
one for the principal, and one for the principal's current key. This
2014
allows password aging to work independently of the principal's
2018
Kohl & Neuman [Page 36]
2020
RFC 1510 Kerberos September 1993
2023
expiration date. However, due to the limited space in the responses,
2024
the KDC must combine the key expiration and principal expiration date
2025
into a single value called "key_exp", which is used as a hint to the
2026
user to take administrative action.)
2028
The attributes field is a bitfield used to govern the operations
2029
involving the principal. This field might be useful in conjunction
2030
with user registration procedures, for site-specific policy
2031
implementations (Project Athena currently uses it for their user
2032
registration process controlled by the system-wide database service,
2033
Moira [7]), or to identify the "string to key" conversion algorithm
2034
used for a principal's key. (See the discussion of the padata field
2035
in section 5.4.2 for details on why this can be useful.) Other bits
2036
are used to indicate that certain ticket options should not be
2037
allowed in tickets encrypted under a principal's key (one bit each):
2038
Disallow issuing postdated tickets, disallow issuing forwardable
2039
tickets, disallow issuing tickets based on TGT authentication,
2040
disallow issuing renewable tickets, disallow issuing proxiable
2041
tickets, and disallow issuing tickets for which the principal is the
2044
The mod_date field contains the time of last modification of the
2045
entry, and the mod_name field contains the name of the principal
2046
which last modified the entry.
2048
4.3. Frequently Changing Fields
2050
Some KDC implementations may wish to maintain the last time that a
2051
request was made by a particular principal. Information that might
2052
be maintained includes the time of the last request, the time of the
2053
last request for a ticket-granting ticket, the time of the last use
2054
of a ticket-granting ticket, or other times. This information can
2055
then be returned to the user in the last-req field (see section 5.2).
2057
Other frequently changing information that can be maintained is the
2058
latest expiration time for any tickets that have been issued using
2059
each key. This field would be used to indicate how long old keys
2060
must remain valid to allow the continued use of outstanding tickets.
2064
The KDC implementation should have the following configurable
2065
constants or options, to allow an administrator to make and enforce
2068
+ The minimum supported lifetime (used to determine whether the
2069
KDC_ERR_NEVER_VALID error should be returned). This constant
2070
should reflect reasonable expectations of round-trip time to the
2074
Kohl & Neuman [Page 37]
2076
RFC 1510 Kerberos September 1993
2079
KDC, encryption/decryption time, and processing time by the client
2080
and target server, and it should allow for a minimum "useful"
2083
+ The maximum allowable total (renewable) lifetime of a ticket
2084
(renew_till - starttime).
2086
+ The maximum allowable lifetime of a ticket (endtime - starttime).
2088
+ Whether to allow the issue of tickets with empty address fields
2089
(including the ability to specify that such tickets may only be
2090
issued if the request specifies some authorization_data).
2092
+ Whether proxiable, forwardable, renewable or post-datable tickets
2095
5. Message Specifications
2097
The following sections describe the exact contents and encoding of
2098
protocol messages and objects. The ASN.1 base definitions are
2099
presented in the first subsection. The remaining subsections specify
2100
the protocol objects (tickets and authenticators) and messages.
2101
Specification of encryption and checksum techniques, and the fields
2102
related to them, appear in section 6.
2104
5.1. ASN.1 Distinguished Encoding Representation
2106
All uses of ASN.1 in Kerberos shall use the Distinguished Encoding
2107
Representation of the data elements as described in the X.509
2108
specification, section 8.7 [8].
2110
5.2. ASN.1 Base Definitions
2112
The following ASN.1 base definitions are used in the rest of this
2113
section. Note that since the underscore character (_) is not
2114
permitted in ASN.1 names, the hyphen (-) is used in its place for the
2115
purposes of ASN.1 names.
2117
Realm ::= GeneralString
2118
PrincipalName ::= SEQUENCE {
2119
name-type[0] INTEGER,
2120
name-string[1] SEQUENCE OF GeneralString
2123
Kerberos realms are encoded as GeneralStrings. Realms shall not
2124
contain a character with the code 0 (the ASCII NUL). Most realms
2125
will usually consist of several components separated by periods (.),
2126
in the style of Internet Domain Names, or separated by slashes (/) in
2130
Kohl & Neuman [Page 38]
2132
RFC 1510 Kerberos September 1993
2135
the style of X.500 names. Acceptable forms for realm names are
2136
specified in section 7. A PrincipalName is a typed sequence of
2137
components consisting of the following sub-fields:
2139
name-type This field specifies the type of name that follows.
2140
Pre-defined values for this field are
2141
specified in section 7.2. The name-type should be
2142
treated as a hint. Ignoring the name type, no two
2143
names can be the same (i.e., at least one of the
2144
components, or the realm, must be different).
2145
This constraint may be eliminated in the future.
2147
name-string This field encodes a sequence of components that
2148
form a name, each component encoded as a General
2149
String. Taken together, a PrincipalName and a Realm
2150
form a principal identifier. Most PrincipalNames
2151
will have only a few components (typically one or two).
2153
KerberosTime ::= GeneralizedTime
2154
-- Specifying UTC time zone (Z)
2156
The timestamps used in Kerberos are encoded as GeneralizedTimes. An
2157
encoding shall specify the UTC time zone (Z) and shall not include
2158
any fractional portions of the seconds. It further shall not include
2159
any separators. Example: The only valid format for UTC time 6
2160
minutes, 27 seconds after 9 pm on 6 November 1985 is 19851106210627Z.
2162
HostAddress ::= SEQUENCE {
2163
addr-type[0] INTEGER,
2164
address[1] OCTET STRING
2167
HostAddresses ::= SEQUENCE OF SEQUENCE {
2168
addr-type[0] INTEGER,
2169
address[1] OCTET STRING
2173
The host adddress encodings consists of two fields:
2175
addr-type This field specifies the type of address that
2176
follows. Pre-defined values for this field are
2177
specified in section 8.1.
2180
address This field encodes a single address of type addr-type.
2182
The two forms differ slightly. HostAddress contains exactly one
2186
Kohl & Neuman [Page 39]
2188
RFC 1510 Kerberos September 1993
2191
address; HostAddresses contains a sequence of possibly many
2194
AuthorizationData ::= SEQUENCE OF SEQUENCE {
2196
ad-data[1] OCTET STRING
2200
ad-data This field contains authorization data to be
2201
interpreted according to the value of the
2202
corresponding ad-type field.
2204
ad-type This field specifies the format for the ad-data
2205
subfield. All negative values are reserved for
2206
local use. Non-negative values are reserved for
2209
APOptions ::= BIT STRING {
2216
TicketFlags ::= BIT STRING {
2231
KDCOptions ::= BIT STRING {
2242
Kohl & Neuman [Page 40]
2244
RFC 1510 Kerberos September 1993
2253
enc-tkt-in-skey(28),
2259
LastReq ::= SEQUENCE OF SEQUENCE {
2261
lr-value[1] KerberosTime
2264
lr-type This field indicates how the following lr-value
2265
field is to be interpreted. Negative values indicate
2266
that the information pertains only to the
2267
responding server. Non-negative values pertain to
2268
all servers for the realm.
2270
If the lr-type field is zero (0), then no information
2271
is conveyed by the lr-value subfield. If the
2272
absolute value of the lr-type field is one (1),
2273
then the lr-value subfield is the time of last
2274
initial request for a TGT. If it is two (2), then
2275
the lr-value subfield is the time of last initial
2276
request. If it is three (3), then the lr-value
2277
subfield is the time of issue for the newest
2278
ticket-granting ticket used. If it is four (4),
2279
then the lr-value subfield is the time of the last
2280
renewal. If it is five (5), then the lr-value
2281
subfield is the time of last request (of any
2284
lr-value This field contains the time of the last request.
2285
The time must be interpreted according to the contents
2286
of the accompanying lr-type subfield.
2288
See section 6 for the definitions of Checksum, ChecksumType,
2289
EncryptedData, EncryptionKey, EncryptionType, and KeyType.
2298
Kohl & Neuman [Page 41]
2300
RFC 1510 Kerberos September 1993
2303
5.3. Tickets and Authenticators
2305
This section describes the format and encryption parameters for
2306
tickets and authenticators. When a ticket or authenticator is
2307
included in a protocol message it is treated as an opaque object.
2311
A ticket is a record that helps a client authenticate to a service.
2312
A Ticket contains the following information:
2314
Ticket ::= [APPLICATION 1] SEQUENCE {
2317
sname[2] PrincipalName,
2318
enc-part[3] EncryptedData
2320
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
2321
flags[0] TicketFlags,
2322
key[1] EncryptionKey,
2324
cname[3] PrincipalName,
2325
transited[4] TransitedEncoding,
2326
authtime[5] KerberosTime,
2327
starttime[6] KerberosTime OPTIONAL,
2328
endtime[7] KerberosTime,
2329
renew-till[8] KerberosTime OPTIONAL,
2330
caddr[9] HostAddresses OPTIONAL,
2331
authorization-data[10] AuthorizationData OPTIONAL
2333
TransitedEncoding ::= SEQUENCE {
2334
tr-type[0] INTEGER, -- must be registered
2335
contents[1] OCTET STRING
2338
The encoding of EncTicketPart is encrypted in the key shared by
2339
Kerberos and the end server (the server's secret key). See section 6
2340
for the format of the ciphertext.
2342
tkt-vno This field specifies the version number for the ticket
2343
format. This document describes version number 5.
2345
realm This field specifies the realm that issued a ticket. It
2346
also serves to identify the realm part of the server's
2347
principal identifier. Since a Kerberos server can only
2348
issue tickets for servers within its realm, the two will
2352
Kohl & Neuman [Page 42]
2354
RFC 1510 Kerberos September 1993
2357
always be identical.
2359
sname This field specifies the name part of the server's
2362
enc-part This field holds the encrypted encoding of the
2363
EncTicketPart sequence.
2365
flags This field indicates which of various options were used or
2366
requested when the ticket was issued. It is a bit-field,
2367
where the selected options are indicated by the bit being
2368
set (1), and the unselected options and reserved fields
2369
being reset (0). Bit 0 is the most significant bit. The
2370
encoding of the bits is specified in section 5.2. The
2371
flags are described in more detail above in section 2. The
2372
meanings of the flags are:
2374
Bit(s) Name Description
2376
0 RESERVED Reserved for future expansion of this
2379
1 FORWARDABLE The FORWARDABLE flag is normally only
2380
interpreted by the TGS, and can be
2381
ignored by end servers. When set,
2382
this flag tells the ticket-granting
2383
server that it is OK to issue a new
2384
ticket- granting ticket with a
2385
different network address based on
2386
the presented ticket.
2388
2 FORWARDED When set, this flag indicates that
2389
the ticket has either been forwarded
2390
or was issued based on authentication
2391
involving a forwarded ticket-granting
2394
3 PROXIABLE The PROXIABLE flag is normally only
2395
interpreted by the TGS, and can be
2396
ignored by end servers. The PROXIABLE
2397
flag has an interpretation identical
2398
to that of the FORWARDABLE flag,
2399
except that the PROXIABLE flag tells
2400
the ticket-granting server that only
2401
non- ticket-granting tickets may be
2402
issued with different network
2408
Kohl & Neuman [Page 43]
2410
RFC 1510 Kerberos September 1993
2413
4 PROXY When set, this flag indicates that a
2416
5 MAY-POSTDATE The MAY-POSTDATE flag is normally
2417
only interpreted by the TGS, and can
2418
be ignored by end servers. This flag
2419
tells the ticket-granting server that
2420
a post- dated ticket may be issued
2421
based on this ticket-granting ticket.
2423
6 POSTDATED This flag indicates that this ticket
2424
has been postdated. The end-service
2425
can check the authtime field to see
2426
when the original authentication
2429
7 INVALID This flag indicates that a ticket is
2430
invalid, and it must be validated by
2431
the KDC before use. Application
2432
servers must reject tickets which
2435
8 RENEWABLE The RENEWABLE flag is normally only
2436
interpreted by the TGS, and can
2437
usually be ignored by end servers
2438
(some particularly careful servers
2439
may wish to disallow renewable
2440
tickets). A renewable ticket can be
2441
used to obtain a replacement ticket
2442
that expires at a later date.
2444
9 INITIAL This flag indicates that this ticket
2445
was issued using the AS protocol, and
2446
not issued based on a ticket-granting
2449
10 PRE-AUTHENT This flag indicates that during
2450
initial authentication, the client
2451
was authenticated by the KDC before a
2452
ticket was issued. The strength of
2453
the preauthentication method is not
2454
indicated, but is acceptable to the
2457
11 HW-AUTHENT This flag indicates that the protocol
2458
employed for initial authentication
2459
required the use of hardware expected
2460
to be possessed solely by the named
2464
Kohl & Neuman [Page 44]
2466
RFC 1510 Kerberos September 1993
2469
client. The hardware authentication
2470
method is selected by the KDC and the
2471
strength of the method is not
2474
12-31 RESERVED Reserved for future use.
2476
key This field exists in the ticket and the KDC response and is
2477
used to pass the session key from Kerberos to the
2478
application server and the client. The field's encoding is
2479
described in section 6.2.
2481
crealm This field contains the name of the realm in which the
2482
client is registered and in which initial authentication
2485
cname This field contains the name part of the client's principal
2488
transited This field lists the names of the Kerberos realms that took
2489
part in authenticating the user to whom this ticket was
2490
issued. It does not specify the order in which the realms
2491
were transited. See section 3.3.3.1 for details on how
2492
this field encodes the traversed realms.
2494
authtime This field indicates the time of initial authentication for
2495
the named principal. It is the time of issue for the
2496
original ticket on which this ticket is based. It is
2497
included in the ticket to provide additional information to
2498
the end service, and to provide the necessary information
2499
for implementation of a `hot list' service at the KDC. An
2500
end service that is particularly paranoid could refuse to
2501
accept tickets for which the initial authentication
2502
occurred "too far" in the past.
2504
This field is also returned as part of the response from
2505
the KDC. When returned as part of the response to initial
2506
authentication (KRB_AS_REP), this is the current time on
2507
the Kerberos server (It is NOT recommended that this time
2508
value be used to adjust the workstation's clock since the
2509
workstation cannot reliably determine that such a
2510
KRB_AS_REP actually came from the proper KDC in a timely
2513
starttime This field in the ticket specifies the time after which the
2514
ticket is valid. Together with endtime, this field
2515
specifies the life of the ticket. If it is absent from
2516
the ticket, its value should be treated as that of the
2520
Kohl & Neuman [Page 45]
2522
RFC 1510 Kerberos September 1993
2527
endtime This field contains the time after which the ticket will
2528
not be honored (its expiration time). Note that individual
2529
services may place their own limits on the life of a ticket
2530
and may reject tickets which have not yet expired. As
2531
such, this is really an upper bound on the expiration time
2534
renew-till This field is only present in tickets that have the
2535
RENEWABLE flag set in the flags field. It indicates the
2536
maximum endtime that may be included in a renewal. It can
2537
be thought of as the absolute expiration time for the
2538
ticket, including all renewals.
2540
caddr This field in a ticket contains zero (if omitted) or more
2541
(if present) host addresses. These are the addresses from
2542
which the ticket can be used. If there are no addresses,
2543
the ticket can be used from any location. The decision
2544
by the KDC to issue or by the end server to accept zero-
2545
address tickets is a policy decision and is left to the
2546
Kerberos and end-service administrators; they may refuse to
2547
issue or accept such tickets. The suggested and default
2548
policy, however, is that such tickets will only be issued
2549
or accepted when additional information that can be used to
2550
restrict the use of the ticket is included in the
2551
authorization_data field. Such a ticket is a capability.
2553
Network addresses are included in the ticket to make it
2554
harder for an attacker to use stolen credentials. Because
2555
the session key is not sent over the network in cleartext,
2556
credentials can't be stolen simply by listening to the
2557
network; an attacker has to gain access to the session key
2558
(perhaps through operating system security breaches or a
2559
careless user's unattended session) to make use of stolen
2562
It is important to note that the network address from which
2563
a connection is received cannot be reliably determined.
2564
Even if it could be, an attacker who has compromised the
2565
client's workstation could use the credentials from there.
2566
Including the network addresses only makes it more
2567
difficult, not impossible, for an attacker to walk off with
2568
stolen credentials and then use them from a "safe"
2576
Kohl & Neuman [Page 46]
2578
RFC 1510 Kerberos September 1993
2581
authorization-data The authorization-data field is used to pass
2582
authorization data from the principal on whose behalf a
2583
ticket was issued to the application service. If no
2584
authorization data is included, this field will be left
2585
out. The data in this field are specific to the end
2586
service. It is expected that the field will contain the
2587
names of service specific objects, and the rights to those
2588
objects. The format for this field is described in section
2589
5.2. Although Kerberos is not concerned with the format of
2590
the contents of the subfields, it does carry type
2591
information (ad-type).
2593
By using the authorization_data field, a principal is able
2594
to issue a proxy that is valid for a specific purpose. For
2595
example, a client wishing to print a file can obtain a file
2596
server proxy to be passed to the print server. By
2597
specifying the name of the file in the authorization_data
2598
field, the file server knows that the print server can only
2599
use the client's rights when accessing the particular file
2602
It is interesting to note that if one specifies the
2603
authorization-data field of a proxy and leaves the host
2604
addresses blank, the resulting ticket and session key can
2605
be treated as a capability. See [9] for some suggested
2608
The authorization-data field is optional and does not have
2609
to be included in a ticket.
2611
5.3.2. Authenticators
2613
An authenticator is a record sent with a ticket to a server to
2614
certify the client's knowledge of the encryption key in the ticket,
2615
to help the server detect replays, and to help choose a "true session
2616
key" to use with the particular session. The encoding is encrypted
2617
in the ticket's session key shared by the client and the server:
2619
Authenticator ::= [APPLICATION 2] SEQUENCE {
2620
authenticator-vno[0] INTEGER,
2622
cname[2] PrincipalName,
2623
cksum[3] Checksum OPTIONAL,
2625
ctime[5] KerberosTime,
2626
subkey[6] EncryptionKey OPTIONAL,
2627
seq-number[7] INTEGER OPTIONAL,
2631
Kohl & Neuman [Page 47]
2633
RFC 1510 Kerberos September 1993
2636
authorization-data[8] AuthorizationData OPTIONAL
2639
authenticator-vno This field specifies the version number for the
2640
format of the authenticator. This document specifies
2643
crealm and cname These fields are the same as those described for the
2644
ticket in section 5.3.1.
2646
cksum This field contains a checksum of the the application data
2647
that accompanies the KRB_AP_REQ.
2649
cusec This field contains the microsecond part of the client's
2650
timestamp. Its value (before encryption) ranges from 0 to
2651
999999. It often appears along with ctime. The two fields
2652
are used together to specify a reasonably accurate
2655
ctime This field contains the current time on the client's host.
2657
subkey This field contains the client's choice for an encryption
2658
key which is to be used to protect this specific
2659
application session. Unless an application specifies
2660
otherwise, if this field is left out the session key from
2661
the ticket will be used.
2663
seq-number This optional field includes the initial sequence number
2664
to be used by the KRB_PRIV or KRB_SAFE messages when
2665
sequence numbers are used to detect replays (It may also be
2666
used by application specific messages). When included in
2667
the authenticator this field specifies the initial sequence
2668
number for messages from the client to the server. When
2669
included in the AP-REP message, the initial sequence number
2670
is that for messages from the server to the client. When
2671
used in KRB_PRIV or KRB_SAFE messages, it is incremented by
2672
one after each message is sent.
2674
For sequence numbers to adequately support the detection of
2675
replays they should be non-repeating, even across
2676
connection boundaries. The initial sequence number should
2677
be random and uniformly distributed across the full space
2678
of possible sequence numbers, so that it cannot be guessed
2679
by an attacker and so that it and the successive sequence
2680
numbers do not repeat other sequences.
2687
Kohl & Neuman [Page 48]
2689
RFC 1510 Kerberos September 1993
2692
authorization-data This field is the same as described for the ticket
2693
in section 5.3.1. It is optional and will only appear when
2694
additional restrictions are to be placed on the use of a
2695
ticket, beyond those carried in the ticket itself.
2697
5.4. Specifications for the AS and TGS exchanges
2699
This section specifies the format of the messages used in exchange
2700
between the client and the Kerberos server. The format of possible
2701
error messages appears in section 5.9.1.
2703
5.4.1. KRB_KDC_REQ definition
2705
The KRB_KDC_REQ message has no type of its own. Instead, its type is
2706
one of KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is
2707
for an initial ticket or an additional ticket. In either case, the
2708
message is sent from the client to the Authentication Server to
2709
request credentials for a service.
2711
The message fields are:
2713
AS-REQ ::= [APPLICATION 10] KDC-REQ
2714
TGS-REQ ::= [APPLICATION 12] KDC-REQ
2716
KDC-REQ ::= SEQUENCE {
2718
msg-type[2] INTEGER,
2719
padata[3] SEQUENCE OF PA-DATA OPTIONAL,
2720
req-body[4] KDC-REQ-BODY
2723
PA-DATA ::= SEQUENCE {
2724
padata-type[1] INTEGER,
2725
padata-value[2] OCTET STRING,
2726
-- might be encoded AP-REQ
2729
KDC-REQ-BODY ::= SEQUENCE {
2730
kdc-options[0] KDCOptions,
2731
cname[1] PrincipalName OPTIONAL,
2732
-- Used only in AS-REQ
2733
realm[2] Realm, -- Server's realm
2734
-- Also client's in AS-REQ
2735
sname[3] PrincipalName OPTIONAL,
2736
from[4] KerberosTime OPTIONAL,
2737
till[5] KerberosTime,
2738
rtime[6] KerberosTime OPTIONAL,
2743
Kohl & Neuman [Page 49]
2745
RFC 1510 Kerberos September 1993
2748
etype[8] SEQUENCE OF INTEGER, -- EncryptionType,
2749
-- in preference order
2750
addresses[9] HostAddresses OPTIONAL,
2751
enc-authorization-data[10] EncryptedData OPTIONAL,
2752
-- Encrypted AuthorizationData encoding
2753
additional-tickets[11] SEQUENCE OF Ticket OPTIONAL
2756
The fields in this message are:
2758
pvno This field is included in each message, and specifies the
2759
protocol version number. This document specifies protocol
2762
msg-type This field indicates the type of a protocol message. It
2763
will almost always be the same as the application
2764
identifier associated with a message. It is included to
2765
make the identifier more readily accessible to the
2766
application. For the KDC-REQ message, this type will be
2767
KRB_AS_REQ or KRB_TGS_REQ.
2769
padata The padata (pre-authentication data) field contains a of
2770
authentication information which may be needed before
2771
credentials can be issued or decrypted. In the case of
2772
requests for additional tickets (KRB_TGS_REQ), this field
2773
will include an element with padata-type of PA-TGS-REQ and
2774
data of an authentication header (ticket-granting ticket
2775
and authenticator). The checksum in the authenticator
2776
(which must be collisionproof) is to be computed over the
2777
KDC-REQ-BODY encoding. In most requests for initial
2778
authentication (KRB_AS_REQ) and most replies (KDC-REP), the
2779
padata field will be left out.
2781
This field may also contain information needed by certain
2782
extensions to the Kerberos protocol. For example, it might
2783
be used to initially verify the identity of a client before
2784
any response is returned. This is accomplished with a
2785
padata field with padata-type equal to PA-ENC-TIMESTAMP and
2786
padata-value defined as follows:
2788
padata-type ::= PA-ENC-TIMESTAMP
2789
padata-value ::= EncryptedData -- PA-ENC-TS-ENC
2791
PA-ENC-TS-ENC ::= SEQUENCE {
2792
patimestamp[0] KerberosTime, -- client's time
2793
pausec[1] INTEGER OPTIONAL
2799
Kohl & Neuman [Page 50]
2801
RFC 1510 Kerberos September 1993
2804
with patimestamp containing the client's time and pausec
2805
containing the microseconds which may be omitted if a
2806
client will not generate more than one request per second.
2807
The ciphertext (padata-value) consists of the PA-ENC-TS-ENC
2808
sequence, encrypted using the client's secret key.
2810
The padata field can also contain information needed to
2811
help the KDC or the client select the key needed for
2812
generating or decrypting the response. This form of the
2813
padata is useful for supporting the use of certain
2814
"smartcards" with Kerberos. The details of such extensions
2815
are beyond the scope of this specification. See [10] for
2816
additional uses of this field.
2818
padata-type The padata-type element of the padata field indicates the
2819
way that the padata-value element is to be interpreted.
2820
Negative values of padata-type are reserved for
2821
unregistered use; non-negative values are used for a
2822
registered interpretation of the element type.
2824
req-body This field is a placeholder delimiting the extent of the
2825
remaining fields. If a checksum is to be calculated over
2826
the request, it is calculated over an encoding of the KDC-
2827
REQ-BODY sequence which is enclosed within the req-body
2830
kdc-options This field appears in the KRB_AS_REQ and KRB_TGS_REQ
2831
requests to the KDC and indicates the flags that the client
2832
wants set on the tickets as well as other information that
2833
is to modify the behavior of the KDC. Where appropriate,
2834
the name of an option may be the same as the flag that is
2835
set by that option. Although in most case, the bit in the
2836
options field will be the same as that in the flags field,
2837
this is not guaranteed, so it is not acceptable to simply
2838
copy the options field to the flags field. There are
2839
various checks that must be made before honoring an option
2842
The kdc_options field is a bit-field, where the selected
2843
options are indicated by the bit being set (1), and the
2844
unselected options and reserved fields being reset (0).
2845
The encoding of the bits is specified in section 5.2. The
2846
options are described in more detail above in section 2.
2847
The meanings of the options are:
2855
Kohl & Neuman [Page 51]
2857
RFC 1510 Kerberos September 1993
2860
Bit(s) Name Description
2862
0 RESERVED Reserved for future expansion of this
2865
1 FORWARDABLE The FORWARDABLE option indicates that
2866
the ticket to be issued is to have its
2867
forwardable flag set. It may only be
2868
set on the initial request, or in a
2869
subsequent request if the ticket-
2870
granting ticket on which it is based
2871
is also forwardable.
2873
2 FORWARDED The FORWARDED option is only specified
2874
in a request to the ticket-granting
2875
server and will only be honored if the
2876
ticket-granting ticket in the request
2877
has its FORWARDABLE bit set. This
2878
option indicates that this is a
2879
request for forwarding. The
2880
address(es) of the host from which the
2881
resulting ticket is to be valid are
2882
included in the addresses field of the
2886
3 PROXIABLE The PROXIABLE option indicates that
2887
the ticket to be issued is to have its
2888
proxiable flag set. It may only be set
2889
on the initial request, or in a
2890
subsequent request if the ticket-
2891
granting ticket on which it is based
2894
4 PROXY The PROXY option indicates that this
2895
is a request for a proxy. This option
2896
will only be honored if the ticket-
2897
granting ticket in the request has its
2898
PROXIABLE bit set. The address(es) of
2899
the host from which the resulting
2900
ticket is to be valid are included in
2901
the addresses field of the request.
2903
5 ALLOW-POSTDATE The ALLOW-POSTDATE option indicates
2904
that the ticket to be issued is to
2905
have its MAY-POSTDATE flag set. It
2906
may only be set on the initial
2907
request, or in a subsequent request if
2911
Kohl & Neuman [Page 52]
2913
RFC 1510 Kerberos September 1993
2916
the ticket-granting ticket on which it
2917
is based also has its MAY-POSTDATE
2920
6 POSTDATED The POSTDATED option indicates that
2921
this is a request for a postdated
2922
ticket. This option will only be
2923
honored if the ticket-granting ticket
2924
on which it is based has its MAY-
2925
POSTDATE flag set. The resulting
2926
ticket will also have its INVALID flag
2927
set, and that flag may be reset by a
2928
subsequent request to the KDC after
2929
the starttime in the ticket has been
2932
7 UNUSED This option is presently unused.
2934
8 RENEWABLE The RENEWABLE option indicates that
2935
the ticket to be issued is to have its
2936
RENEWABLE flag set. It may only be
2937
set on the initial request, or when
2938
the ticket-granting ticket on which
2939
the request is based is also
2940
renewable. If this option is
2941
requested, then the rtime field in the
2942
request contains the desired absolute
2943
expiration time for the ticket.
2945
9-26 RESERVED Reserved for future use.
2947
27 RENEWABLE-OK The RENEWABLE-OK option indicates that
2948
a renewable ticket will be acceptable
2949
if a ticket with the requested life
2950
cannot otherwise be provided. If a
2951
ticket with the requested life cannot
2952
be provided, then a renewable ticket
2953
may be issued with a renew-till equal
2954
to the the requested endtime. The
2955
value of the renew-till field may
2956
still be limited by local limits, or
2957
limits selected by the individual
2958
principal or server.
2960
28 ENC-TKT-IN-SKEY This option is used only by the
2961
ticket-granting service. The ENC-
2962
TKT-IN-SKEY option indicates that the
2963
ticket for the end server is to be
2967
Kohl & Neuman [Page 53]
2969
RFC 1510 Kerberos September 1993
2972
encrypted in the session key from the
2973
additional ticket-granting ticket
2976
29 RESERVED Reserved for future use.
2978
30 RENEW This option is used only by the
2979
ticket-granting service. The RENEW
2980
option indicates that the present
2981
request is for a renewal. The ticket
2982
provided is encrypted in the secret
2983
key for the server on which it is
2984
valid. This option will only be
2985
honored if the ticket to be renewed
2986
has its RENEWABLE flag set and if the
2987
time in its renew till field has not
2988
passed. The ticket to be renewed is
2989
passed in the padata field as part of
2990
the authentication header.
2992
31 VALIDATE This option is used only by the
2993
ticket-granting service. The VALIDATE
2994
option indicates that the request is
2995
to validate a postdated ticket. It
2996
will only be honored if the ticket
2997
presented is postdated, presently has
2998
its INVALID flag set, and would be
2999
otherwise usable at this time. A
3000
ticket cannot be validated before its
3001
starttime. The ticket presented for
3002
validation is encrypted in the key of
3003
the server for which it is valid and
3004
is passed in the padata field as part
3005
of the authentication header.
3007
cname and sname These fields are the same as those described for the
3008
ticket in section 5.3.1. sname may only be absent when the
3009
ENC-TKT-IN-SKEY option is specified. If absent, the name
3010
of the server is taken from the name of the client in the
3011
ticket passed as additional-tickets.
3013
enc-authorization-data The enc-authorization-data, if present (and it
3014
can only be present in the TGS_REQ form), is an encoding of
3015
the desired authorization-data encrypted under the sub-
3016
session key if present in the Authenticator, or
3017
alternatively from the session key in the ticket-granting
3018
ticket, both from the padata field in the KRB_AP_REQ.
3023
Kohl & Neuman [Page 54]
3025
RFC 1510 Kerberos September 1993
3028
realm This field specifies the realm part of the server's
3029
principal identifier. In the AS exchange, this is also the
3030
realm part of the client's principal identifier.
3032
from This field is included in the KRB_AS_REQ and KRB_TGS_REQ
3033
ticket requests when the requested ticket is to be
3034
postdated. It specifies the desired start time for the
3037
till This field contains the expiration date requested by the
3038
client in a ticket request.
3040
rtime This field is the requested renew-till time sent from a
3041
client to the KDC in a ticket request. It is optional.
3043
nonce This field is part of the KDC request and response. It it
3044
intended to hold a random number generated by the client.
3045
If the same number is included in the encrypted response
3046
from the KDC, it provides evidence that the response is
3047
fresh and has not been replayed by an attacker. Nonces
3048
must never be re-used. Ideally, it should be gen erated
3049
randomly, but if the correct time is known, it may suffice
3050
(Note, however, that if the time is used as the nonce, one
3051
must make sure that the workstation time is monotonically
3052
increasing. If the time is ever reset backwards, there is
3053
a small, but finite, probability that a nonce will be
3056
etype This field specifies the desired encryption algorithm to be
3057
used in the response.
3059
addresses This field is included in the initial request for tickets,
3060
and optionally included in requests for additional tickets
3061
from the ticket-granting server. It specifies the
3062
addresses from which the requested ticket is to be valid.
3063
Normally it includes the addresses for the client's host.
3064
If a proxy is requested, this field will contain other
3065
addresses. The contents of this field are usually copied
3066
by the KDC into the caddr field of the resulting ticket.
3068
additional-tickets Additional tickets may be optionally included in a
3069
request to the ticket-granting server. If the ENC-TKT-IN-
3070
SKEY option has been specified, then the session key from
3071
the additional ticket will be used in place of the server's
3072
key to encrypt the new ticket. If more than one option
3073
which requires additional tickets has been specified, then
3074
the additional tickets are used in the order specified by
3075
the ordering of the options bits (see kdc-options, above).
3079
Kohl & Neuman [Page 55]
3081
RFC 1510 Kerberos September 1993
3084
The application code will be either ten (10) or twelve (12) depending
3085
on whether the request is for an initial ticket (AS-REQ) or for an
3086
additional ticket (TGS-REQ).
3088
The optional fields (addresses, authorization-data and additional-
3089
tickets) are only included if necessary to perform the operation
3090
specified in the kdc-options field.
3092
It should be noted that in KRB_TGS_REQ, the protocol version number
3093
appears twice and two different message types appear: the KRB_TGS_REQ
3094
message contains these fields as does the authentication header
3095
(KRB_AP_REQ) that is passed in the padata field.
3097
5.4.2. KRB_KDC_REP definition
3099
The KRB_KDC_REP message format is used for the reply from the KDC for
3100
either an initial (AS) request or a subsequent (TGS) request. There
3101
is no message type for KRB_KDC_REP. Instead, the type will be either
3102
KRB_AS_REP or KRB_TGS_REP. The key used to encrypt the ciphertext
3103
part of the reply depends on the message type. For KRB_AS_REP, the
3104
ciphertext is encrypted in the client's secret key, and the client's
3105
key version number is included in the key version number for the
3106
encrypted data. For KRB_TGS_REP, the ciphertext is encrypted in the
3107
sub-session key from the Authenticator, or if absent, the session key
3108
from the ticket-granting ticket used in the request. In that case,
3109
no version number will be present in the EncryptedData sequence.
3111
The KRB_KDC_REP message contains the following fields:
3113
AS-REP ::= [APPLICATION 11] KDC-REP
3114
TGS-REP ::= [APPLICATION 13] KDC-REP
3116
KDC-REP ::= SEQUENCE {
3118
msg-type[1] INTEGER,
3119
padata[2] SEQUENCE OF PA-DATA OPTIONAL,
3121
cname[4] PrincipalName,
3123
enc-part[6] EncryptedData
3126
EncASRepPart ::= [APPLICATION 25[25]] EncKDCRepPart
3127
EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart
3129
EncKDCRepPart ::= SEQUENCE {
3130
key[0] EncryptionKey,
3131
last-req[1] LastReq,
3135
Kohl & Neuman [Page 56]
3137
RFC 1510 Kerberos September 1993
3141
key-expiration[3] KerberosTime OPTIONAL,
3142
flags[4] TicketFlags,
3143
authtime[5] KerberosTime,
3144
starttime[6] KerberosTime OPTIONAL,
3145
endtime[7] KerberosTime,
3146
renew-till[8] KerberosTime OPTIONAL,
3148
sname[10] PrincipalName,
3149
caddr[11] HostAddresses OPTIONAL
3152
NOTE: In EncASRepPart, the application code in the encrypted
3153
part of a message provides an additional check that
3154
the message was decrypted properly.
3156
pvno and msg-type These fields are described above in section 5.4.1.
3157
msg-type is either KRB_AS_REP or KRB_TGS_REP.
3159
padata This field is described in detail in section 5.4.1. One
3160
possible use for this field is to encode an alternate
3161
"mix-in" string to be used with a string-to-key algorithm
3162
(such as is described in section 6.3.2). This ability is
3163
useful to ease transitions if a realm name needs to change
3164
(e.g., when a company is acquired); in such a case all
3165
existing password-derived entries in the KDC database would
3166
be flagged as needing a special mix-in string until the
3167
next password change.
3169
crealm, cname, srealm and sname These fields are the same as those
3170
described for the ticket in section 5.3.1.
3172
ticket The newly-issued ticket, from section 5.3.1.
3174
enc-part This field is a place holder for the ciphertext and related
3175
information that forms the encrypted part of a message.
3176
The description of the encrypted part of the message
3177
follows each appearance of this field. The encrypted part
3178
is encoded as described in section 6.1.
3180
key This field is the same as described for the ticket in
3183
last-req This field is returned by the KDC and specifies the time(s)
3184
of the last request by a principal. Depending on what
3185
information is available, this might be the last time that
3186
a request for a ticket-granting ticket was made, or the
3187
last time that a request based on a ticket-granting ticket
3191
Kohl & Neuman [Page 57]
3193
RFC 1510 Kerberos September 1993
3196
was successful. It also might cover all servers for a
3197
realm, or just the particular server. Some implementations
3198
may display this information to the user to aid in
3199
discovering unauthorized use of one's identity. It is
3200
similar in spirit to the last login time displayed when
3201
logging into timesharing systems.
3203
nonce This field is described above in section 5.4.1.
3205
key-expiration The key-expiration field is part of the response from
3206
the KDC and specifies the time that the client's secret key
3207
is due to expire. The expiration might be the result of
3208
password aging or an account expiration. This field will
3209
usually be left out of the TGS reply since the response to
3210
the TGS request is encrypted in a session key and no client
3211
information need be retrieved from the KDC database. It is
3212
up to the application client (usually the login program) to
3213
take appropriate action (such as notifying the user) if the
3214
expira tion time is imminent.
3216
flags, authtime, starttime, endtime, renew-till and caddr These
3217
fields are duplicates of those found in the encrypted
3218
portion of the attached ticket (see section 5.3.1),
3219
provided so the client may verify they match the intended
3220
request and to assist in proper ticket caching. If the
3221
message is of type KRB_TGS_REP, the caddr field will only
3222
be filled in if the request was for a proxy or forwarded
3223
ticket, or if the user is substituting a subset of the
3224
addresses from the ticket granting ticket. If the client-
3225
requested addresses are not present or not used, then the
3226
addresses contained in the ticket will be the same as those
3227
included in the ticket-granting ticket.
3229
5.5. Client/Server (CS) message specifications
3231
This section specifies the format of the messages used for the
3232
authentication of the client to the application server.
3234
5.5.1. KRB_AP_REQ definition
3236
The KRB_AP_REQ message contains the Kerberos protocol version number,
3237
the message type KRB_AP_REQ, an options field to indicate any options
3238
in use, and the ticket and authenticator themselves. The KRB_AP_REQ
3239
message is often referred to as the "authentication header".
3241
AP-REQ ::= [APPLICATION 14] SEQUENCE {
3243
msg-type[1] INTEGER,
3247
Kohl & Neuman [Page 58]
3249
RFC 1510 Kerberos September 1993
3252
ap-options[2] APOptions,
3254
authenticator[4] EncryptedData
3257
APOptions ::= BIT STRING {
3263
pvno and msg-type These fields are described above in section 5.4.1.
3264
msg-type is KRB_AP_REQ.
3266
ap-options This field appears in the application request (KRB_AP_REQ)
3267
and affects the way the request is processed. It is a
3268
bit-field, where the selected options are indicated by the
3269
bit being set (1), and the unselected options and reserved
3270
fields being reset (0). The encoding of the bits is
3271
specified in section 5.2. The meanings of the options are:
3273
Bit(s) Name Description
3275
0 RESERVED Reserved for future expansion of
3278
1 USE-SESSION-KEYThe USE-SESSION-KEY option indicates
3279
that the ticket the client is
3280
presenting to a server is encrypted in
3281
the session key from the server's
3282
ticket-granting ticket. When this
3283
option is not specified, the ticket is
3284
encrypted in the server's secret key.
3286
2 MUTUAL-REQUIREDThe MUTUAL-REQUIRED option tells the
3287
server that the client requires mutual
3288
authentication, and that it must
3289
respond with a KRB_AP_REP message.
3291
3-31 RESERVED Reserved for future use.
3293
ticket This field is a ticket authenticating the client to the
3296
authenticator This contains the authenticator, which includes the
3297
client's choice of a subkey. Its encoding is described in
3303
Kohl & Neuman [Page 59]
3305
RFC 1510 Kerberos September 1993
3308
5.5.2. KRB_AP_REP definition
3310
The KRB_AP_REP message contains the Kerberos protocol version number,
3311
the message type, and an encrypted timestamp. The message is sent in
3312
in response to an application request (KRB_AP_REQ) where the mutual
3313
authentication option has been selected in the ap-options field.
3315
AP-REP ::= [APPLICATION 15] SEQUENCE {
3317
msg-type[1] INTEGER,
3318
enc-part[2] EncryptedData
3321
EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
3322
ctime[0] KerberosTime,
3324
subkey[2] EncryptionKey OPTIONAL,
3325
seq-number[3] INTEGER OPTIONAL
3328
NOTE: in EncAPRepPart, the application code in the encrypted part of
3329
a message provides an additional check that the message was decrypted
3332
The encoded EncAPRepPart is encrypted in the shared session key of
3333
the ticket. The optional subkey field can be used in an
3334
application-arranged negotiation to choose a per association session
3337
pvno and msg-type These fields are described above in section 5.4.1.
3338
msg-type is KRB_AP_REP.
3340
enc-part This field is described above in section 5.4.2.
3342
ctime This field contains the current time on the client's host.
3344
cusec This field contains the microsecond part of the client's
3347
subkey This field contains an encryption key which is to be used
3348
to protect this specific application session. See section
3349
3.2.6 for specifics on how this field is used to negotiate
3350
a key. Unless an application specifies otherwise, if this
3351
field is left out, the sub-session key from the
3352
authenticator, or if also left out, the session key from
3353
the ticket will be used.
3359
Kohl & Neuman [Page 60]
3361
RFC 1510 Kerberos September 1993
3364
5.5.3. Error message reply
3366
If an error occurs while processing the application request, the
3367
KRB_ERROR message will be sent in response. See section 5.9.1 for
3368
the format of the error message. The cname and crealm fields may be
3369
left out if the server cannot determine their appropriate values from
3370
the corresponding KRB_AP_REQ message. If the authenticator was
3371
decipherable, the ctime and cusec fields will contain the values from
3374
5.6. KRB_SAFE message specification
3376
This section specifies the format of a message that can be used by
3377
either side (client or server) of an application to send a tamper-
3378
proof message to its peer. It presumes that a session key has
3379
previously been exchanged (for example, by using the
3380
KRB_AP_REQ/KRB_AP_REP messages).
3382
5.6.1. KRB_SAFE definition
3384
The KRB_SAFE message contains user data along with a collision-proof
3385
checksum keyed with the session key. The message fields are:
3387
KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
3389
msg-type[1] INTEGER,
3390
safe-body[2] KRB-SAFE-BODY,
3394
KRB-SAFE-BODY ::= SEQUENCE {
3395
user-data[0] OCTET STRING,
3396
timestamp[1] KerberosTime OPTIONAL,
3397
usec[2] INTEGER OPTIONAL,
3398
seq-number[3] INTEGER OPTIONAL,
3399
s-address[4] HostAddress,
3400
r-address[5] HostAddress OPTIONAL
3403
pvno and msg-type These fields are described above in section 5.4.1.
3404
msg-type is KRB_SAFE.
3406
safe-body This field is a placeholder for the body of the KRB-SAFE
3407
message. It is to be encoded separately and then have the
3408
checksum computed over it, for use in the cksum field.
3410
cksum This field contains the checksum of the application data.
3411
Checksum details are described in section 6.4. The
3415
Kohl & Neuman [Page 61]
3417
RFC 1510 Kerberos September 1993
3420
checksum is computed over the encoding of the KRB-SAFE-BODY
3423
user-data This field is part of the KRB_SAFE and KRB_PRIV messages
3424
and contain the application specific data that is being
3425
passed from the sender to the recipient.
3427
timestamp This field is part of the KRB_SAFE and KRB_PRIV messages.
3428
Its contents are the current time as known by the sender of
3429
the message. By checking the timestamp, the recipient of
3430
the message is able to make sure that it was recently
3431
generated, and is not a replay.
3433
usec This field is part of the KRB_SAFE and KRB_PRIV headers.
3434
It contains the microsecond part of the timestamp.
3436
seq-number This field is described above in section 5.3.2.
3438
s-address This field specifies the address in use by the sender of
3441
r-address This field specifies the address in use by the recipient of
3442
the message. It may be omitted for some uses (such as
3443
broadcast protocols), but the recipient may arbitrarily
3444
reject such messages. This field along with s-address can
3445
be used to help detect messages which have been incorrectly
3446
or maliciously delivered to the wrong recipient.
3448
5.7. KRB_PRIV message specification
3450
This section specifies the format of a message that can be used by
3451
either side (client or server) of an application to securely and
3452
privately send a message to its peer. It presumes that a session key
3453
has previously been exchanged (for example, by using the
3454
KRB_AP_REQ/KRB_AP_REP messages).
3456
5.7.1. KRB_PRIV definition
3458
The KRB_PRIV message contains user data encrypted in the Session Key.
3459
The message fields are:
3461
KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
3463
msg-type[1] INTEGER,
3464
enc-part[3] EncryptedData
3471
Kohl & Neuman [Page 62]
3473
RFC 1510 Kerberos September 1993
3476
EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
3477
user-data[0] OCTET STRING,
3478
timestamp[1] KerberosTime OPTIONAL,
3479
usec[2] INTEGER OPTIONAL,
3480
seq-number[3] INTEGER OPTIONAL,
3481
s-address[4] HostAddress, -- sender's addr
3482
r-address[5] HostAddress OPTIONAL
3486
NOTE: In EncKrbPrivPart, the application code in the encrypted part
3487
of a message provides an additional check that the message was
3490
pvno and msg-type These fields are described above in section 5.4.1.
3491
msg-type is KRB_PRIV.
3493
enc-part This field holds an encoding of the EncKrbPrivPart sequence
3494
encrypted under the session key (If supported by the
3495
encryption method in use, an initialization vector may be
3496
passed to the encryption procedure, in order to achieve
3497
proper cipher chaining. The initialization vector might
3498
come from the last block of the ciphertext from the
3499
previous KRB_PRIV message, but it is the application's
3500
choice whether or not to use such an initialization vector.
3501
If left out, the default initialization vector for the
3502
encryption algorithm will be used.). This encrypted
3503
encoding is used for the enc-part field of the KRB-PRIV
3504
message. See section 6 for the format of the ciphertext.
3506
user-data, timestamp, usec, s-address and r-address These fields are
3507
described above in section 5.6.1.
3509
seq-number This field is described above in section 5.3.2.
3511
5.8. KRB_CRED message specification
3513
This section specifies the format of a message that can be used to
3514
send Kerberos credentials from one principal to another. It is
3515
presented here to encourage a common mechanism to be used by
3516
applications when forwarding tickets or providing proxies to
3517
subordinate servers. It presumes that a session key has already been
3518
exchanged perhaps by using the KRB_AP_REQ/KRB_AP_REP messages.
3520
5.8.1. KRB_CRED definition
3522
The KRB_CRED message contains a sequence of tickets to be sent and
3523
information needed to use the tickets, including the session key from
3527
Kohl & Neuman [Page 63]
3529
RFC 1510 Kerberos September 1993
3532
each. The information needed to use the tickets is encryped under an
3533
encryption key previously exchanged. The message fields are:
3535
KRB-CRED ::= [APPLICATION 22] SEQUENCE {
3537
msg-type[1] INTEGER, -- KRB_CRED
3538
tickets[2] SEQUENCE OF Ticket,
3539
enc-part[3] EncryptedData
3542
EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
3543
ticket-info[0] SEQUENCE OF KrbCredInfo,
3544
nonce[1] INTEGER OPTIONAL,
3545
timestamp[2] KerberosTime OPTIONAL,
3546
usec[3] INTEGER OPTIONAL,
3547
s-address[4] HostAddress OPTIONAL,
3548
r-address[5] HostAddress OPTIONAL
3551
KrbCredInfo ::= SEQUENCE {
3552
key[0] EncryptionKey,
3553
prealm[1] Realm OPTIONAL,
3554
pname[2] PrincipalName OPTIONAL,
3555
flags[3] TicketFlags OPTIONAL,
3556
authtime[4] KerberosTime OPTIONAL,
3557
starttime[5] KerberosTime OPTIONAL,
3558
endtime[6] KerberosTime OPTIONAL
3559
renew-till[7] KerberosTime OPTIONAL,
3560
srealm[8] Realm OPTIONAL,
3561
sname[9] PrincipalName OPTIONAL,
3562
caddr[10] HostAddresses OPTIONAL
3566
pvno and msg-type These fields are described above in section 5.4.1.
3567
msg-type is KRB_CRED.
3570
These are the tickets obtained from the KDC specifically
3571
for use by the intended recipient. Successive tickets are
3572
paired with the corresponding KrbCredInfo sequence from the
3573
enc-part of the KRB-CRED message.
3575
enc-part This field holds an encoding of the EncKrbCredPart sequence
3576
encrypted under the session key shared between the sender
3577
and the intended recipient. This encrypted encoding is
3578
used for the enc-part field of the KRB-CRED message. See
3579
section 6 for the format of the ciphertext.
3583
Kohl & Neuman [Page 64]
3585
RFC 1510 Kerberos September 1993
3588
nonce If practical, an application may require the inclusion of a
3589
nonce generated by the recipient of the message. If the
3590
same value is included as the nonce in the message, it
3591
provides evidence that the message is fresh and has not
3592
been replayed by an attacker. A nonce must never be re-
3593
used; it should be generated randomly by the recipient of
3594
the message and provided to the sender of the mes sage in
3595
an application specific manner.
3597
timestamp and usec These fields specify the time that the KRB-CRED
3598
message was generated. The time is used to provide
3599
assurance that the message is fresh.
3601
s-address and r-address These fields are described above in section
3602
5.6.1. They are used optionally to provide additional
3603
assurance of the integrity of the KRB-CRED message.
3605
key This field exists in the corresponding ticket passed by the
3606
KRB-CRED message and is used to pass the session key from
3607
the sender to the intended recipient. The field's encoding
3608
is described in section 6.2.
3610
The following fields are optional. If present, they can be
3611
associated with the credentials in the remote ticket file. If left
3612
out, then it is assumed that the recipient of the credentials already
3615
prealm and pname The name and realm of the delegated principal
3618
flags, authtime, starttime, endtime, renew-till, srealm, sname,
3619
and caddr These fields contain the values of the
3620
corresponding fields from the ticket found in the ticket
3621
field. Descriptions of the fields are identical to the
3622
descriptions in the KDC-REP message.
3624
5.9. Error message specification
3626
This section specifies the format for the KRB_ERROR message. The
3627
fields included in the message are intended to return as much
3628
information as possible about an error. It is not expected that all
3629
the information required by the fields will be available for all
3630
types of errors. If the appropriate information is not available
3631
when the message is composed, the corresponding field will be left
3634
Note that since the KRB_ERROR message is not protected by any
3635
encryption, it is quite possible for an intruder to synthesize or
3639
Kohl & Neuman [Page 65]
3641
RFC 1510 Kerberos September 1993
3644
modify such a message. In particular, this means that the client
3645
should not use any fields in this message for security-critical
3646
purposes, such as setting a system clock or generating a fresh
3647
authenticator. The message can be useful, however, for advising a
3648
user on the reason for some failure.
3650
5.9.1. KRB_ERROR definition
3652
The KRB_ERROR message consists of the following fields:
3654
KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
3656
msg-type[1] INTEGER,
3657
ctime[2] KerberosTime OPTIONAL,
3658
cusec[3] INTEGER OPTIONAL,
3659
stime[4] KerberosTime,
3661
error-code[6] INTEGER,
3662
crealm[7] Realm OPTIONAL,
3663
cname[8] PrincipalName OPTIONAL,
3664
realm[9] Realm, -- Correct realm
3665
sname[10] PrincipalName, -- Correct name
3666
e-text[11] GeneralString OPTIONAL,
3667
e-data[12] OCTET STRING OPTIONAL
3670
pvno and msg-type These fields are described above in section 5.4.1.
3671
msg-type is KRB_ERROR.
3673
ctime This field is described above in section 5.4.1.
3675
cusec This field is described above in section 5.5.2.
3677
stime This field contains the current time on the server. It is
3678
of type KerberosTime.
3680
susec This field contains the microsecond part of the server's
3681
timestamp. Its value ranges from 0 to 999. It appears
3682
along with stime. The two fields are used in conjunction to
3683
specify a reasonably accurate timestamp.
3685
error-code This field contains the error code returned by Kerberos or
3686
the server when a request fails. To interpret the value of
3687
this field see the list of error codes in section 8.
3688
Implementations are encouraged to provide for national
3689
language support in the display of error messages.
3691
crealm, cname, srealm and sname These fields are described above in
3695
Kohl & Neuman [Page 66]
3697
RFC 1510 Kerberos September 1993
3702
e-text This field contains additional text to help explain the
3703
error code associated with the failed request (for example,
3704
it might include a principal name which was unknown).
3706
e-data This field contains additional data about the error for use
3707
by the application to help it recover from or handle the
3708
error. If the errorcode is KDC_ERR_PREAUTH_REQUIRED, then
3709
the e-data field will contain an encoding of a sequence of
3710
padata fields, each corresponding to an acceptable pre-
3711
authentication method and optionally containing data for
3714
METHOD-DATA ::= SEQUENCE of PA-DATA
3716
If the error-code is KRB_AP_ERR_METHOD, then the e-data field will
3717
contain an encoding of the following sequence:
3719
METHOD-DATA ::= SEQUENCE {
3720
method-type[0] INTEGER,
3721
method-data[1] OCTET STRING OPTIONAL
3724
method-type will indicate the required alternate method; method-data
3725
will contain any required additional information.
3727
6. Encryption and Checksum Specifications
3729
The Kerberos protocols described in this document are designed to use
3730
stream encryption ciphers, which can be simulated using commonly
3731
available block encryption ciphers, such as the Data Encryption
3732
Standard [11], in conjunction with block chaining and checksum
3733
methods [12]. Encryption is used to prove the identities of the
3734
network entities participating in message exchanges. The Key
3735
Distribution Center for each realm is trusted by all principals
3736
registered in that realm to store a secret key in confidence. Proof
3737
of knowledge of this secret key is used to verify the authenticity of
3740
The KDC uses the principal's secret key (in the AS exchange) or a
3741
shared session key (in the TGS exchange) to encrypt responses to
3742
ticket requests; the ability to obtain the secret key or session key
3743
implies the knowledge of the appropriate keys and the identity of the
3744
KDC. The ability of a principal to decrypt the KDC response and
3745
present a Ticket and a properly formed Authenticator (generated with
3746
the session key from the KDC response) to a service verifies the
3747
identity of the principal; likewise the ability of the service to
3751
Kohl & Neuman [Page 67]
3753
RFC 1510 Kerberos September 1993
3756
extract the session key from the Ticket and prove its knowledge
3757
thereof in a response verifies the identity of the service.
3759
The Kerberos protocols generally assume that the encryption used is
3760
secure from cryptanalysis; however, in some cases, the order of
3761
fields in the encrypted portions of messages are arranged to minimize
3762
the effects of poorly chosen keys. It is still important to choose
3763
good keys. If keys are derived from user-typed passwords, those
3764
passwords need to be well chosen to make brute force attacks more
3765
difficult. Poorly chosen keys still make easy targets for intruders.
3767
The following sections specify the encryption and checksum mechanisms
3768
currently defined for Kerberos. The encodings, chaining, and padding
3769
requirements for each are described. For encryption methods, it is
3770
often desirable to place random information (often referred to as a
3771
confounder) at the start of the message. The requirements for a
3772
confounder are specified with each encryption mechanism.
3774
Some encryption systems use a block-chaining method to improve the
3775
the security characteristics of the ciphertext. However, these
3776
chaining methods often don't provide an integrity check upon
3777
decryption. Such systems (such as DES in CBC mode) must be augmented
3778
with a checksum of the plaintext which can be verified at decryption
3779
and used to detect any tampering or damage. Such checksums should be
3780
good at detecting burst errors in the input. If any damage is
3781
detected, the decryption routine is expected to return an error
3782
indicating the failure of an integrity check. Each encryption type is
3783
expected to provide and verify an appropriate checksum. The
3784
specification of each encryption method sets out its checksum
3787
Finally, where a key is to be derived from a user's password, an
3788
algorithm for converting the password to a key of the appropriate
3789
type is included. It is desirable for the string to key function to
3790
be one-way, and for the mapping to be different in different realms.
3791
This is important because users who are registered in more than one
3792
realm will often use the same password in each, and it is desirable
3793
that an attacker compromising the Kerberos server in one realm not
3794
obtain or derive the user's key in another.
3796
For a discussion of the integrity characteristics of the candidate
3797
encryption and checksum methods considered for Kerberos, the the
3798
reader is referred to [13].
3800
6.1. Encryption Specifications
3802
The following ASN.1 definition describes all encrypted messages. The
3803
enc-part field which appears in the unencrypted part of messages in
3807
Kohl & Neuman [Page 68]
3809
RFC 1510 Kerberos September 1993
3812
section 5 is a sequence consisting of an encryption type, an optional
3813
key version number, and the ciphertext.
3815
EncryptedData ::= SEQUENCE {
3816
etype[0] INTEGER, -- EncryptionType
3817
kvno[1] INTEGER OPTIONAL,
3818
cipher[2] OCTET STRING -- ciphertext
3821
etype This field identifies which encryption algorithm was used
3822
to encipher the cipher. Detailed specifications for
3823
selected encryption types appear later in this section.
3825
kvno This field contains the version number of the key under
3826
which data is encrypted. It is only present in messages
3827
encrypted under long lasting keys, such as principals'
3830
cipher This field contains the enciphered text, encoded as an
3833
The cipher field is generated by applying the specified encryption
3834
algorithm to data composed of the message and algorithm-specific
3835
inputs. Encryption mechanisms defined for use with Kerberos must
3836
take sufficient measures to guarantee the integrity of the plaintext,
3837
and we recommend they also take measures to protect against
3838
precomputed dictionary attacks. If the encryption algorithm is not
3839
itself capable of doing so, the protections can often be enhanced by
3840
adding a checksum and a confounder.
3842
The suggested format for the data to be encrypted includes a
3843
confounder, a checksum, the encoded plaintext, and any necessary
3844
padding. The msg-seq field contains the part of the protocol message
3845
described in section 5 which is to be encrypted. The confounder,
3846
checksum, and padding are all untagged and untyped, and their length
3847
is exactly sufficient to hold the appropriate item. The type and
3848
length is implicit and specified by the particular encryption type
3849
being used (etype). The format for the data to be encrypted is
3850
described in the following diagram:
3852
+-----------+----------+-------------+-----+
3853
|confounder | check | msg-seq | pad |
3854
+-----------+----------+-------------+-----+
3856
The format cannot be described in ASN.1, but for those who prefer an
3857
ASN.1-like notation:
3863
Kohl & Neuman [Page 69]
3865
RFC 1510 Kerberos September 1993
3868
CipherText ::= ENCRYPTED SEQUENCE {
3869
confounder[0] UNTAGGED OCTET STRING(conf_length) OPTIONAL,
3870
check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL,
3871
msg-seq[2] MsgSequence,
3872
pad UNTAGGED OCTET STRING(pad_length) OPTIONAL
3875
In the above specification, UNTAGGED OCTET STRING(length) is the
3876
notation for an octet string with its tag and length removed. It is
3877
not a valid ASN.1 type. The tag bits and length must be removed from
3878
the confounder since the purpose of the confounder is so that the
3879
message starts with random data, but the tag and its length are
3880
fixed. For other fields, the length and tag would be redundant if
3881
they were included because they are specified by the encryption type.
3883
One generates a random confounder of the appropriate length, placing
3884
it in confounder; zeroes out check; calculates the appropriate
3885
checksum over confounder, check, and msg-seq, placing the result in
3886
check; adds the necessary padding; then encrypts using the specified
3887
encryption type and the appropriate key.
3889
Unless otherwise specified, a definition of an encryption algorithm
3890
that specifies a checksum, a length for the confounder field, or an
3891
octet boundary for padding uses this ciphertext format (The ordering
3892
of the fields in the CipherText is important. Additionally, messages
3893
encoded in this format must include a length as part of the msg-seq
3894
field. This allows the recipient to verify that the message has not
3895
been truncated. Without a length, an attacker could use a chosen
3896
plaintext attack to generate a message which could be truncated,
3897
while leaving the checksum intact. Note that if the msg-seq is an
3898
encoding of an ASN.1 SEQUENCE or OCTET STRING, then the length is
3899
part of that encoding.). Those fields which are not specified will be
3902
In the interest of allowing all implementations using a particular
3903
encryption type to communicate with all others using that type, the
3904
specification of an encryption type defines any checksum that is
3905
needed as part of the encryption process. If an alternative checksum
3906
is to be used, a new encryption type must be defined.
3908
Some cryptosystems require additional information beyond the key and
3909
the data to be encrypted. For example, DES, when used in cipher-
3910
block-chaining mode, requires an initialization vector. If required,
3911
the description for each encryption type must specify the source of
3912
such additional information.
3919
Kohl & Neuman [Page 70]
3921
RFC 1510 Kerberos September 1993
3924
6.2. Encryption Keys
3926
The sequence below shows the encoding of an encryption key:
3928
EncryptionKey ::= SEQUENCE {
3930
keyvalue[1] OCTET STRING
3933
keytype This field specifies the type of encryption key that
3934
follows in the keyvalue field. It will almost always
3935
correspond to the encryption algorithm used to generate the
3936
EncryptedData, though more than one algorithm may use the
3937
same type of key (the mapping is many to one). This might
3938
happen, for example, if the encryption algorithm uses an
3939
alternate checksum algorithm for an integrity check, or a
3940
different chaining mechanism.
3942
keyvalue This field contains the key itself, encoded as an octet
3945
All negative values for the encryption key type are reserved for
3946
local use. All non-negative values are reserved for officially
3947
assigned type fields and interpretations.
3949
6.3. Encryption Systems
3951
6.3.1. The NULL Encryption System (null)
3953
If no encryption is in use, the encryption system is said to be the
3954
NULL encryption system. In the NULL encryption system there is no
3955
checksum, confounder or padding. The ciphertext is simply the
3956
plaintext. The NULL Key is used by the null encryption system and is
3957
zero octets in length, with keytype zero (0).
3959
6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc)
3961
The des-cbc-crc encryption mode encrypts information under the Data
3962
Encryption Standard [11] using the cipher block chaining mode [12].
3963
A CRC-32 checksum (described in ISO 3309 [14]) is applied to the
3964
confounder and message sequence (msg-seq) and placed in the cksum
3965
field. DES blocks are 8 bytes. As a result, the data to be
3966
encrypted (the concatenation of confounder, checksum, and message)
3967
must be padded to an 8 byte boundary before encryption. The details
3968
of the encryption of this data are identical to those for the des-
3969
cbc-md5 encryption mode.
3971
Note that, since the CRC-32 checksum is not collisionproof, an
3975
Kohl & Neuman [Page 71]
3977
RFC 1510 Kerberos September 1993
3980
attacker could use a probabilistic chosenplaintext attack to generate
3981
a valid message even if a confounder is used [13]. The use of
3982
collision-proof checksums is recommended for environments where such
3983
attacks represent a significant threat. The use of the CRC-32 as the
3984
checksum for ticket or authenticator is no longer mandated as an
3985
interoperability requirement for Kerberos Version 5 Specification 1
3986
(See section 9.1 for specific details).
3988
6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4)
3990
The des-cbc-md4 encryption mode encrypts information under the Data
3991
Encryption Standard [11] using the cipher block chaining mode [12].
3992
An MD4 checksum (described in [15]) is applied to the confounder and
3993
message sequence (msg-seq) and placed in the cksum field. DES blocks
3994
are 8 bytes. As a result, the data to be encrypted (the
3995
concatenation of confounder, checksum, and message) must be padded to
3996
an 8 byte boundary before encryption. The details of the encryption
3997
of this data are identical to those for the descbc-md5 encryption
4000
6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5)
4002
The des-cbc-md5 encryption mode encrypts information under the Data
4003
Encryption Standard [11] using the cipher block chaining mode [12].
4004
An MD5 checksum (described in [16]) is applied to the confounder and
4005
message sequence (msg-seq) and placed in the cksum field. DES blocks
4006
are 8 bytes. As a result, the data to be encrypted (the
4007
concatenation of confounder, checksum, and message) must be padded to
4008
an 8 byte boundary before encryption.
4010
Plaintext and DES ciphtertext are encoded as 8-octet blocks which are
4011
concatenated to make the 64-bit inputs for the DES algorithms. The
4012
first octet supplies the 8 most significant bits (with the octet's
4013
MSbit used as the DES input block's MSbit, etc.), the second octet
4014
the next 8 bits, ..., and the eighth octet supplies the 8 least
4017
Encryption under DES using cipher block chaining requires an
4018
additional input in the form of an initialization vector. Unless
4019
otherwise specified, zero should be used as the initialization
4020
vector. Kerberos' use of DES requires an 8-octet confounder.
4022
The DES specifications identify some "weak" and "semiweak" keys;
4023
those keys shall not be used for encrypting messages for use in
4024
Kerberos. Additionally, because of the way that keys are derived for
4025
the encryption of checksums, keys shall not be used that yield "weak"
4026
or "semi-weak" keys when eXclusive-ORed with the constant
4031
Kohl & Neuman [Page 72]
4033
RFC 1510 Kerberos September 1993
4036
A DES key is 8 octets of data, with keytype one (1). This consists
4037
of 56 bits of key, and 8 parity bits (one per octet). The key is
4038
encoded as a series of 8 octets written in MSB-first order. The bits
4039
within the key are also encoded in MSB order. For example, if the
4041
(B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where
4042
B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the
4043
parity bits, the first octet of the key would be B1,B2,...,B7,P1
4044
(with B1 as the MSbit). [See the FIPS 81 introduction for
4047
To generate a DES key from a text string (password), the text string
4048
normally must have the realm and each component of the principal's
4049
name appended(In some cases, it may be necessary to use a different
4050
"mix-in" string for compatibility reasons; see the discussion of
4051
padata in section 5.4.2.), then padded with ASCII nulls to an 8 byte
4052
boundary. This string is then fan-folded and eXclusive-ORed with
4053
itself to form an 8 byte DES key. The parity is corrected on the
4054
key, and it is used to generate a DES CBC checksum on the initial
4055
string (with the realm and name appended). Next, parity is corrected
4056
on the CBC checksum. If the result matches a "weak" or "semiweak"
4057
key as described in the DES specification, it is eXclusive-ORed with
4058
the constant 00000000000000F0. Finally, the result is returned as
4059
the key. Pseudocode follows:
4061
string_to_key(string,realm,name) {
4064
for(each component in name) {
4068
pad(s); /* with nulls to 8 byte boundary */
4069
for(8byteblock in s) {
4075
tempkey = tempkey XOR 8byteblock;
4078
key = DES-CBC-check(s,tempkey);
4080
if(is_weak_key_key(key))
4087
Kohl & Neuman [Page 73]
4089
RFC 1510 Kerberos September 1993
4094
The following is the ASN.1 definition used for a checksum:
4096
Checksum ::= SEQUENCE {
4097
cksumtype[0] INTEGER,
4098
checksum[1] OCTET STRING
4101
cksumtype This field indicates the algorithm used to generate the
4102
accompanying checksum.
4104
checksum This field contains the checksum itself, encoded
4107
Detailed specification of selected checksum types appear later in
4108
this section. Negative values for the checksum type are reserved for
4109
local use. All non-negative values are reserved for officially
4110
assigned type fields and interpretations.
4112
Checksums used by Kerberos can be classified by two properties:
4113
whether they are collision-proof, and whether they are keyed. It is
4114
infeasible to find two plaintexts which generate the same checksum
4115
value for a collision-proof checksum. A key is required to perturb
4116
or initialize the algorithm in a keyed checksum. To prevent
4117
message-stream modification by an active attacker, unkeyed checksums
4118
should only be used when the checksum and message will be
4119
subsequently encrypted (e.g., the checksums defined as part of the
4120
encryption algorithms covered earlier in this section). Collision-
4121
proof checksums can be made tamper-proof as well if the checksum
4122
value is encrypted before inclusion in a message. In such cases, the
4123
composition of the checksum and the encryption algorithm must be
4124
considered a separate checksum algorithm (e.g., RSA-MD5 encrypted
4125
using DES is a new checksum algorithm of type RSA-MD5-DES). For most
4126
keyed checksums, as well as for the encrypted forms of collisionproof
4127
checksums, Kerberos prepends a confounder before the checksum is
4130
6.4.1. The CRC-32 Checksum (crc32)
4132
The CRC-32 checksum calculates a checksum based on a cyclic
4133
redundancy check as described in ISO 3309 [14]. The resulting
4134
checksum is four (4) octets in length. The CRC-32 is neither keyed
4135
nor collision-proof. The use of this checksum is not recommended.
4136
An attacker using a probabilistic chosen-plaintext attack as
4137
described in [13] might be able to generate an alternative message
4138
that satisfies the checksum. The use of collision-proof checksums is
4139
recommended for environments where such attacks represent a
4143
Kohl & Neuman [Page 74]
4145
RFC 1510 Kerberos September 1993
4150
6.4.2. The RSA MD4 Checksum (rsa-md4)
4152
The RSA-MD4 checksum calculates a checksum using the RSA MD4
4153
algorithm [15]. The algorithm takes as input an input message of
4154
arbitrary length and produces as output a 128-bit (16 octet)
4155
checksum. RSA-MD4 is believed to be collision-proof.
4157
6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4des)
4159
The RSA-MD4-DES checksum calculates a keyed collisionproof checksum
4160
by prepending an 8 octet confounder before the text, applying the RSA
4161
MD4 checksum algorithm, and encrypting the confounder and the
4162
checksum using DES in cipher-block-chaining (CBC) mode using a
4163
variant of the key, where the variant is computed by eXclusive-ORing
4164
the key with the constant F0F0F0F0F0F0F0F0 (A variant of the key is
4165
used to limit the use of a key to a particular function, separating
4166
the functions of generating a checksum from other encryption
4167
performed using the session key. The constant F0F0F0F0F0F0F0F0 was
4168
chosen because it maintains key parity. The properties of DES
4169
precluded the use of the complement. The same constant is used for
4170
similar purpose in the Message Integrity Check in the Privacy
4171
Enhanced Mail standard.). The initialization vector should be zero.
4172
The resulting checksum is 24 octets long (8 octets of which are
4173
redundant). This checksum is tamper-proof and believed to be
4176
The DES specifications identify some "weak keys"; those keys shall
4177
not be used for generating RSA-MD4 checksums for use in Kerberos.
4179
The format for the checksum is described in the following diagram:
4181
+--+--+--+--+--+--+--+--
4182
| des-cbc(confounder
4183
+--+--+--+--+--+--+--+--
4185
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4186
rsa-md4(confounder+msg),key=var(key),iv=0) |
4187
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4189
The format cannot be described in ASN.1, but for those who prefer an
4190
ASN.1-like notation:
4192
rsa-md4-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE {
4193
confounder[0] UNTAGGED OCTET STRING(8),
4194
check[1] UNTAGGED OCTET STRING(16)
4199
Kohl & Neuman [Page 75]
4201
RFC 1510 Kerberos September 1993
4204
6.4.4. The RSA MD5 Checksum (rsa-md5)
4206
The RSA-MD5 checksum calculates a checksum using the RSA MD5
4207
algorithm [16]. The algorithm takes as input an input message of
4208
arbitrary length and produces as output a 128-bit (16 octet)
4209
checksum. RSA-MD5 is believed to be collision-proof.
4211
6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5des)
4213
The RSA-MD5-DES checksum calculates a keyed collisionproof checksum
4214
by prepending an 8 octet confounder before the text, applying the RSA
4215
MD5 checksum algorithm, and encrypting the confounder and the
4216
checksum using DES in cipher-block-chaining (CBC) mode using a
4217
variant of the key, where the variant is computed by eXclusive-ORing
4218
the key with the constant F0F0F0F0F0F0F0F0. The initialization
4219
vector should be zero. The resulting checksum is 24 octets long (8
4220
octets of which are redundant). This checksum is tamper-proof and
4221
believed to be collision-proof.
4223
The DES specifications identify some "weak keys"; those keys shall
4224
not be used for encrypting RSA-MD5 checksums for use in Kerberos.
4226
The format for the checksum is described in the following diagram:
4228
+--+--+--+--+--+--+--+--
4229
| des-cbc(confounder
4230
+--+--+--+--+--+--+--+--
4232
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4233
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
4247
to the plaintext, performing a DES CBC-mode encryption on the result
4248
using the key and an initialization vector of zero, taking the last
4249
block of the ciphertext, prepending the same confounder and
4250
encrypting the pair using DES in cipher-block-chaining (CBC) mode
4251
using a a variant of the key, where the variant is computed by
4255
Kohl & Neuman [Page 76]
4257
RFC 1510 Kerberos September 1993
4260
eXclusive-ORing the key with the constant F0F0F0F0F0F0F0F0. The
4261
initialization vector should be zero. The resulting checksum is 128
4262
bits (16 octets) long, 64 bits of which are redundant. This checksum
4263
is tamper-proof and collision-proof.
4265
The format for the checksum is described in the following diagram:
4267
+--+--+--+--+--+--+--+--
4268
| des-cbc(confounder
4269
+--+--+--+--+--+--+--+--
4271
+-----+-----+-----+-----+-----+-----+-----+-----+
4272
des-mac(conf+msg,iv=0,key),key=var(key),iv=0) |
4273
+-----+-----+-----+-----+-----+-----+-----+-----+
4275
The format cannot be described in ASN.1, but for those who prefer an
4276
ASN.1-like notation:
4278
des-mac-checksum ::= ENCRYPTED UNTAGGED SEQUENCE {
4279
confounder[0] UNTAGGED OCTET STRING(8),
4280
check[1] UNTAGGED OCTET STRING(8)
4283
The DES specifications identify some "weak" and "semiweak" keys;
4284
those keys shall not be used for generating DES-MAC checksums for use
4285
in Kerberos, nor shall a key be used whose veriant is "weak" or
4288
6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative
4291
The RSA-MD4-DES-K checksum calculates a keyed collision-proof
4292
checksum by applying the RSA MD4 checksum algorithm and encrypting
4293
the results using DES in cipherblock-chaining (CBC) mode using a DES
4294
key as both key and initialization vector. The resulting checksum is
4295
16 octets long. This checksum is tamper-proof and believed to be
4296
collision-proof. Note that this checksum type is the old method for
4297
encoding the RSA-MD4-DES checksum and it is no longer recommended.
4299
6.4.8. DES cipher-block chained checksum alternative (desmac-k)
4301
The DES-MAC-K checksum is computed by performing a DES CBC-mode
4302
encryption of the plaintext, and using the last block of the
4303
ciphertext as the checksum value. It is keyed with an encryption key
4304
and an initialization vector; any uses which do not specify an
4305
additional initialization vector will use the key as both key and
4306
initialization vector. The resulting checksum is 64 bits (8 octets)
4307
long. This checksum is tamper-proof and collision-proof. Note that
4311
Kohl & Neuman [Page 77]
4313
RFC 1510 Kerberos September 1993
4316
this checksum type is the old method for encoding the DESMAC checksum
4317
and it is no longer recommended.
4319
The DES specifications identify some "weak keys"; those keys shall
4320
not be used for generating DES-MAC checksums for use in Kerberos.
4322
7. Naming Constraints
4326
Although realm names are encoded as GeneralStrings and although a
4327
realm can technically select any name it chooses, interoperability
4328
across realm boundaries requires agreement on how realm names are to
4329
be assigned, and what information they imply.
4331
To enforce these conventions, each realm must conform to the
4332
conventions itself, and it must require that any realms with which
4333
inter-realm keys are shared also conform to the conventions and
4334
require the same from its neighbors.
4336
There are presently four styles of realm names: domain, X500, other,
4337
and reserved. Examples of each style follow:
4339
domain: host.subdomain.domain (example)
4340
X500: C=US/O=OSF (example)
4341
other: NAMETYPE:rest/of.name=without-restrictions (example)
4342
reserved: reserved, but will not conflict with above
4344
Domain names must look like domain names: they consist of components
4345
separated by periods (.) and they contain neither colons (:) nor
4348
X.500 names contain an equal (=) and cannot contain a colon (:)
4349
before the equal. The realm names for X.500 names will be string
4350
representations of the names with components separated by slashes.
4351
Leading and trailing slashes will not be included.
4353
Names that fall into the other category must begin with a prefix that
4354
contains no equal (=) or period (.) and the prefix must be followed
4355
by a colon (:) and the rest of the name. All prefixes must be
4356
assigned before they may be used. Presently none are assigned.
4358
The reserved category includes strings which do not fall into the
4359
first three categories. All names in this category are reserved. It
4360
is unlikely that names will be assigned to this category unless there
4361
is a very strong argument for not using the "other" category.
4363
These rules guarantee that there will be no conflicts between the
4367
Kohl & Neuman [Page 78]
4369
RFC 1510 Kerberos September 1993
4372
various name styles. The following additional constraints apply to
4373
the assignment of realm names in the domain and X.500 categories: the
4374
name of a realm for the domain or X.500 formats must either be used
4375
by the organization owning (to whom it was assigned) an Internet
4376
domain name or X.500 name, or in the case that no such names are
4377
registered, authority to use a realm name may be derived from the
4378
authority of the parent realm. For example, if there is no domain
4379
name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can
4380
authorize the creation of a realm with that name.
4382
This is acceptable because the organization to which the parent is
4383
assigned is presumably the organization authorized to assign names to
4384
its children in the X.500 and domain name systems as well. If the
4385
parent assigns a realm name without also registering it in the domain
4386
name or X.500 hierarchy, it is the parent's responsibility to make
4387
sure that there will not in the future exists a name identical to the
4388
realm name of the child unless it is assigned to the same entity as
4391
7.2. Principal Names
4393
As was the case for realm names, conventions are needed to ensure
4394
that all agree on what information is implied by a principal name.
4395
The name-type field that is part of the principal name indicates the
4396
kind of information implied by the name. The name-type should be
4397
treated as a hint. Ignoring the name type, no two names can be the
4398
same (i.e., at least one of the components, or the realm, must be
4399
different). This constraint may be eliminated in the future. The
4400
following name types are defined:
4402
name-type value meaning
4403
NT-UNKNOWN 0 Name type not known
4404
NT-PRINCIPAL 1 Just the name of the principal as in
4406
NT-SRV-INST 2 Service and other unique instance (krbtgt)
4407
NT-SRV-HST 3 Service with host name as instance
4409
NT-SRV-XHST 4 Service with host as remaining components
4412
When a name implies no information other than its uniqueness at a
4413
particular time the name type PRINCIPAL should be used. The
4414
principal name type should be used for users, and it might also be
4415
used for a unique server. If the name is a unique machine generated
4416
ID that is guaranteed never to be reassigned then the name type of
4417
UID should be used (note that it is generally a bad idea to reassign
4418
names of any type since stale entries might remain in access control
4423
Kohl & Neuman [Page 79]
4425
RFC 1510 Kerberos September 1993
4428
If the first component of a name identifies a service and the
4429
remaining components identify an instance of the service in a server
4430
specified manner, then the name type of SRV-INST should be used. An
4431
example of this name type is the Kerberos ticket-granting ticket
4432
which has a first component of krbtgt and a second component
4433
identifying the realm for which the ticket is valid.
4435
If instance is a single component following the service name and the
4436
instance identifies the host on which the server is running, then the
4437
name type SRV-HST should be used. This type is typically used for
4438
Internet services such as telnet and the Berkeley R commands. If the
4439
separate components of the host name appear as successive components
4440
following the name of the service, then the name type SRVXHST should
4441
be used. This type might be used to identify servers on hosts with
4442
X.500 names where the slash (/) might otherwise be ambiguous.
4444
A name type of UNKNOWN should be used when the form of the name is
4445
not known. When comparing names, a name of type UNKNOWN will match
4446
principals authenticated with names of any type. A principal
4447
authenticated with a name of type UNKNOWN, however, will only match
4448
other names of type UNKNOWN.
4450
Names of any type with an initial component of "krbtgt" are reserved
4451
for the Kerberos ticket granting service. See section 8.2.3 for the
4454
7.2.1. Name of server principals
4456
The principal identifier for a server on a host will generally be
4457
composed of two parts: (1) the realm of the KDC with which the server
4458
is registered, and (2) a two-component name of type NT-SRV-HST if the
4459
host name is an Internet domain name or a multi-component name of
4460
type NT-SRV-XHST if the name of the host is of a form such as X.500
4461
that allows slash (/) separators. The first component of the two- or
4462
multi-component name will identify the service and the latter
4463
components will identify the host. Where the name of the host is not
4464
case sensitive (for example, with Internet domain names) the name of
4465
the host must be lower case. For services such as telnet and the
4466
Berkeley R commands which run with system privileges, the first
4467
component will be the string "host" instead of a service specific
4470
8. Constants and other defined values
4472
8.1. Host address types
4474
All negative values for the host address type are reserved for local
4475
use. All non-negative values are reserved for officially assigned
4479
Kohl & Neuman [Page 80]
4481
RFC 1510 Kerberos September 1993
4484
type fields and interpretations.
4486
The values of the types for the following addresses are chosen to
4487
match the defined address family constants in the Berkeley Standard
4488
Distributions of Unix. They can be found in <sys/socket.h> with
4489
symbolic names AF_xxx (where xxx is an abbreviation of the address
4495
Internet addresses are 32-bit (4-octet) quantities, encoded in MSB
4496
order. The type of internet addresses is two (2).
4500
CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB
4501
order. The type of CHAOSnet addresses is five (5).
4505
ISO addresses are variable-length. The type of ISO addresses is
4508
Xerox Network Services (XNS) addresses
4510
XNS addresses are 48-bit (6-octet) quantities, encoded in MSB
4511
order. The type of XNS addresses is six (6).
4513
AppleTalk Datagram Delivery Protocol (DDP) addresses
4515
AppleTalk DDP addresses consist of an 8-bit node number and a 16-
4516
bit network number. The first octet of the address is the node
4517
number; the remaining two octets encode the network number in MSB
4518
order. The type of AppleTalk DDP addresses is sixteen (16).
4520
DECnet Phase IV addresses
4522
DECnet Phase IV addresses are 16-bit addresses, encoded in LSB
4523
order. The type of DECnet Phase IV addresses is twelve (12).
4529
When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request
4530
using IP transport, the client shall send a UDP datagram containing
4531
only an encoding of the request to port 88 (decimal) at the KDC's IP
4535
Kohl & Neuman [Page 81]
4537
RFC 1510 Kerberos September 1993
4540
address; the KDC will respond with a reply datagram containing only
4541
an encoding of the reply message (either a KRB_ERROR or a
4542
KRB_KDC_REP) to the sending port at the sender's IP address.
4544
8.2.2. OSI transport
4546
During authentication of an OSI client to and OSI server, the mutual
4547
authentication of an OSI server to an OSI client, the transfer of
4548
credentials from an OSI client to an OSI server, or during exchange
4549
of private or integrity checked messages, Kerberos protocol messages
4550
may be treated as opaque objects and the type of the authentication
4553
OBJECT IDENTIFIER ::= {iso (1), org(3), dod(5),internet(1),
4554
security(5), kerberosv5(2)}
4556
Depending on the situation, the opaque object will be an
4557
authentication header (KRB_AP_REQ), an authentication reply
4558
(KRB_AP_REP), a safe message (KRB_SAFE), a private message
4559
(KRB_PRIV), or a credentials message (KRB_CRED). The opaque data
4560
contains an application code as specified in the ASN.1 description
4561
for each message. The application code may be used by Kerberos to
4562
determine the message type.
4564
8.2.3. Name of the TGS
4566
The principal identifier of the ticket-granting service shall be
4567
composed of three parts: (1) the realm of the KDC issuing the TGS
4568
ticket (2) a two-part name of type NT-SRVINST, with the first part
4569
"krbtgt" and the second part the name of the realm which will accept
4570
the ticket-granting ticket. For example, a ticket-granting ticket
4571
issued by the ATHENA.MIT.EDU realm to be used to get tickets from the
4572
ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU"
4573
(realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting
4574
ticket issued by the ATHENA.MIT.EDU realm to be used to get tickets
4575
from the MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU"
4576
(realm), ("krbtgt", "MIT.EDU") (name).
4578
8.3. Protocol constants and associated values
4580
The following tables list constants used in the protocol and defines
4591
Kohl & Neuman [Page 82]
4593
RFC 1510 Kerberos September 1993
4596
---------------+-----------+----------+----------------+---------------
4597
Encryption type|etype value|block size|minimum pad size|confounder size
4598
---------------+-----------+----------+----------------+---------------
4604
-------------------------------+-------------------+-------------
4605
Checksum type |sumtype value |checksum size
4606
-------------------------------+-------------------+-------------
4616
-------------------------------+-----------------
4617
padata type |padata-type value
4618
-------------------------------+-----------------
4623
-------------------------------+-------------
4624
authorization data type |ad-type value
4625
-------------------------------+-------------
4626
reserved values 0-63
4630
-------------------------------+-----------------
4631
alternate authentication type |method-type value
4632
-------------------------------+-----------------
4633
reserved values 0-63
4634
ATT-CHALLENGE-RESPONSE 64
4636
-------------------------------+-------------
4637
transited encoding type |tr-type value
4638
-------------------------------+-------------
4639
DOMAIN-X500-COMPRESS 1
4640
reserved values all others
4647
Kohl & Neuman [Page 83]
4649
RFC 1510 Kerberos September 1993
4652
--------------+-------+-----------------------------------------
4653
Label |Value |Meaning or MIT code
4654
--------------+-------+-----------------------------------------
4656
pvno 5 current Kerberos protocol version number
4660
KRB_AS_REQ 10 Request for initial authentication
4661
KRB_AS_REP 11 Response to KRB_AS_REQ request
4662
KRB_TGS_REQ 12 Request for authentication based on TGT
4663
KRB_TGS_REP 13 Response to KRB_TGS_REQ request
4664
KRB_AP_REQ 14 application request to server
4665
KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL
4666
KRB_SAFE 20 Safe (checksummed) application message
4667
KRB_PRIV 21 Private (encrypted) application message
4668
KRB_CRED 22 Private (encrypted) message to forward
4670
KRB_ERROR 30 Error response
4674
KRB_NT_UNKNOWN 0 Name type not known
4675
KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or
4677
KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt)
4678
KRB_NT_SRV_HST 3 Service with host name as instance (telnet,
4680
KRB_NT_SRV_XHST 4 Service with host as remaining components
4681
KRB_NT_UID 5 Unique ID
4685
KDC_ERR_NONE 0 No error
4686
KDC_ERR_NAME_EXP 1 Client's entry in database has
4688
KDC_ERR_SERVICE_EXP 2 Server's entry in database has
4690
KDC_ERR_BAD_PVNO 3 Requested protocol version number
4692
KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old
4694
KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old
4696
KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database
4697
KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database
4698
KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in
4703
Kohl & Neuman [Page 84]
4705
RFC 1510 Kerberos September 1993
4708
KDC_ERR_NULL_KEY 9 The client or server has a null key
4709
KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating
4710
KDC_ERR_NEVER_VALID 11 Requested start time is later than
4712
KDC_ERR_POLICY 12 KDC policy rejects request
4713
KDC_ERR_BADOPTION 13 KDC cannot accommodate requested
4715
KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption
4717
KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type
4718
KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type
4719
KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type
4720
KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked
4721
KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been
4723
KDC_ERR_TGT_REVOKED 20 TGT has been revoked
4724
KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again
4726
KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again
4728
KDC_ERR_KEY_EXPIRED 23 Password has expired - change
4730
KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information
4732
KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authentication
4734
KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field
4736
KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired
4737
KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid
4738
KRB_AP_ERR_REPEAT 34 Request is a replay
4739
KRB_AP_ERR_NOT_US 35 The ticket isn't for us
4740
KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match
4741
KRB_AP_ERR_SKEW 37 Clock skew too great
4742
KRB_AP_ERR_BADADDR 38 Incorrect net address
4743
KRB_AP_ERR_BADVERSION 39 Protocol version mismatch
4744
KRB_AP_ERR_MSG_TYPE 40 Invalid msg type
4745
KRB_AP_ERR_MODIFIED 41 Message stream modified
4746
KRB_AP_ERR_BADORDER 42 Message out of order
4747
KRB_AP_ERR_BADKEYVER 44 Specified version of key is not
4749
KRB_AP_ERR_NOKEY 45 Service key not available
4750
KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed
4751
KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction
4752
KRB_AP_ERR_METHOD 48 Alternative authentication method
4754
KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message
4755
KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in
4759
Kohl & Neuman [Page 85]
4761
RFC 1510 Kerberos September 1993
4765
KRB_ERR_GENERIC 60 Generic error (description in e-text)
4766
KRB_ERR_FIELD_TOOLONG 61 Field is too long for this
4769
*This error carries additional information in the e-data field. The
4770
contents of the e-data field for this message is described in section
4773
9. Interoperability requirements
4775
Version 5 of the Kerberos protocol supports a myriad of options.
4776
Among these are multiple encryption and checksum types, alternative
4777
encoding schemes for the transited field, optional mechanisms for
4778
pre-authentication, the handling of tickets with no addresses,
4779
options for mutual authentication, user to user authentication,
4780
support for proxies, forwarding, postdating, and renewing tickets,
4781
the format of realm names, and the handling of authorization data.
4783
In order to ensure the interoperability of realms, it is necessary to
4784
define a minimal configuration which must be supported by all
4785
implementations. This minimal configuration is subject to change as
4786
technology does. For example, if at some later date it is discovered
4787
that one of the required encryption or checksum algorithms is not
4788
secure, it will be replaced.
4790
9.1. Specification 1
4792
This section defines the first specification of these options.
4793
Implementations which are configured in this way can be said to
4794
support Kerberos Version 5 Specification 1 (5.1).
4796
Encryption and checksum methods
4798
The following encryption and checksum mechanisms must be supported.
4799
Implementations may support other mechanisms as well, but the
4800
additional mechanisms may only be used when communicating with
4801
principals known to also support them: Encryption: DES-CBC-MD5
4802
Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5
4806
All implementations must understand hierarchical realms in both the
4807
Internet Domain and the X.500 style. When a ticket granting ticket
4808
for an unknown realm is requested, the KDC must be able to determine
4809
the names of the intermediate realms between the KDCs realm and the
4815
Kohl & Neuman [Page 86]
4817
RFC 1510 Kerberos September 1993
4820
Transited field encoding
4822
DOMAIN-X500-COMPRESS (described in section 3.3.3.1) must be
4823
supported. Alternative encodings may be supported, but they may be
4824
used only when that encoding is supported by ALL intermediate realms.
4826
Pre-authentication methods
4828
The TGS-REQ method must be supported. The TGS-REQ method is not used
4829
on the initial request. The PA-ENC-TIMESTAMP method must be supported
4830
by clients but whether it is enabled by default may be determined on
4831
a realm by realm basis. If not used in the initial request and the
4832
error KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENCTIMESTAMP
4833
as an acceptable method, the client should retry the initial request
4834
using the PA-ENC-TIMESTAMP preauthentication method. Servers need not
4835
support the PAENC-TIMESTAMP method, but if not supported the server
4836
should ignore the presence of PA-ENC-TIMESTAMP pre-authentication in
4839
Mutual authentication
4841
Mutual authentication (via the KRB_AP_REP message) must be supported.
4843
Ticket addresses and flags
4845
All KDC's must pass on tickets that carry no addresses (i.e., if a
4846
TGT contains no addresses, the KDC will return derivative tickets),
4847
but each realm may set its own policy for issuing such tickets, and
4848
each application server will set its own policy with respect to
4849
accepting them. By default, servers should not accept them.
4851
Proxies and forwarded tickets must be supported. Individual realms
4852
and application servers can set their own policy on when such tickets
4855
All implementations must recognize renewable and postdated tickets,
4856
but need not actually implement them. If these options are not
4857
supported, the starttime and endtime in the ticket shall specify a
4858
ticket's entire useful life. When a postdated ticket is decoded by a
4859
server, all implementations shall make the presence of the postdated
4860
flag visible to the calling server.
4862
User-to-user authentication
4864
Support for user to user authentication (via the ENC-TKTIN-SKEY KDC
4865
option) must be provided by implementations, but individual realms
4866
may decide as a matter of policy to reject such requests on a per-
4867
principal or realm-wide basis.
4871
Kohl & Neuman [Page 87]
4873
RFC 1510 Kerberos September 1993
4878
Implementations must pass all authorization data subfields from
4879
ticket-granting tickets to any derivative tickets unless directed to
4880
suppress a subfield as part of the definition of that registered
4881
subfield type (it is never incorrect to pass on a subfield, and no
4882
registered subfield types presently specify suppression at the KDC).
4884
Implementations must make the contents of any authorization data
4885
subfields available to the server when a ticket is used.
4886
Implementations are not required to allow clients to specify the
4887
contents of the authorization data fields.
4889
9.2. Recommended KDC values
4891
Following is a list of recommended values for a KDC implementation,
4892
based on the list of suggested configuration constants (see section
4895
minimum lifetime 5 minutes
4897
maximum renewable lifetime 1 week
4899
maximum ticket lifetime 1 day
4901
empty addresses only when suitable restrictions appear
4902
in authorization data
4904
proxiable, etc. Allowed.
4908
Early versions of this document, describing version 4 of the
4909
protocol, were written by Jennifer Steiner (formerly at Project
4910
Athena); these drafts provided an excellent starting point for this
4911
current version 5 specification. Many people in the Internet
4912
community have contributed ideas and suggested protocol changes for
4913
version 5. Notable contributions came from Ted Anderson, Steve
4914
Bellovin and Michael Merritt [17], Daniel Bernstein, Mike Burrows,
4915
Donald Davis, Ravi Ganesan, Morrie Gasser, Virgil Gligor, Bill
4916
Griffeth, Mark Lillibridge, Mark Lomas, Steve Lunt, Piers McMahon,
4917
Joe Pato, William Sommerfeld, Stuart Stubblebine, Ralph Swick, Ted
4918
T'so, and Stanley Zanarotti. Many others commented and helped shape
4919
this specification into its current form.
4927
Kohl & Neuman [Page 88]
4929
RFC 1510 Kerberos September 1993
4934
[1] Miller, S., Neuman, C., Schiller, J., and J. Saltzer, "Section
4935
E.2.1: Kerberos Authentication and Authorization System",
4936
M.I.T. Project Athena, Cambridge, Massachusetts, December 21,
4939
[2] Steiner, J., Neuman, C., and J. Schiller, "Kerberos: An
4940
Authentication Service for Open Network Systems", pp. 191-202 in
4941
Usenix Conference Proceedings, Dallas, Texas, February, 1988.
4943
[3] Needham, R., and M. Schroeder, "Using Encryption for
4944
Authentication in Large Networks of Computers", Communications
4945
of the ACM, Vol. 21 (12), pp. 993-999, December 1978.
4947
[4] Denning, D., and G. Sacco, "Time stamps in Key Distribution
4948
Protocols", Communications of the ACM, Vol. 24 (8), pp. 533-536,
4951
[5] Kohl, J., Neuman, C., and T. Ts'o, "The Evolution of the
4952
Kerberos Authentication Service", in an IEEE Computer Society
4953
Text soon to be published, June 1992.
4955
[6] Davis, D., and R. Swick, "Workstation Services and Kerberos
4956
Authentication at Project Athena", Technical Memorandum TM-424,
4957
MIT Laboratory for Computer Science, February 1990.
4959
[7] Levine, P., Gretzinger, M, Diaz, J., Sommerfeld, W., and K.
4960
Raeburn, "Section E.1: Service Management System, M.I.T.
4961
Project Athena, Cambridge, Mas sachusetts (1987).
4963
[8] CCITT, Recommendation X.509: The Directory Authentication
4964
Framework, December 1988.
4966
[9] Neuman, C., "Proxy-Based Authorization and Accounting for
4967
Distributed Systems," in Proceedings of the 13th International
4968
Conference on Distributed Computing Systems", Pittsburgh, PA,
4971
[10] Pato, J., "Using Pre-Authentication to Avoid Password Guessing
4972
Attacks", Open Software Foundation DCE Request for Comments 26,
4975
[11] National Bureau of Standards, U.S. Department of Commerce, "Data
4976
Encryption Standard", Federal Information Processing Standards
4977
Publication 46, Washington, DC (1977).
4983
Kohl & Neuman [Page 89]
4985
RFC 1510 Kerberos September 1993
4988
[12] National Bureau of Standards, U.S. Department of Commerce, "DES
4989
Modes of Operation", Federal Information Processing Standards
4990
Publication 81, Springfield, VA, December 1980.
4992
[13] Stubblebine S., and V. Gligor, "On Message Integrity in
4993
Cryptographic Protocols", in Proceedings of the IEEE Symposium
4994
on Research in Security and Privacy, Oakland, California, May
4997
[14] International Organization for Standardization, "ISO Information
4998
Processing Systems - Data Communication High-Level Data Link
4999
Control Procedure - Frame Structure", IS 3309, October 1984, 3rd
5002
[15] Rivest, R., "The MD4 Message Digest Algorithm", RFC 1320, MIT
5003
Laboratory for Computer Science, April 1992.
5005
[16] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, MIT
5006
Laboratory for Computer Science, April 1992.
5008
[17] Bellovin S., and M. Merritt, "Limitations of the Kerberos
5009
Authentication System", Computer Communications Review, Vol.
5010
20(5), pp. 119-132, October 1990.
5012
12. Security Considerations
5014
Security issues are discussed throughout this memo.
5016
13. Authors' Addresses
5019
Digital Equipment Corporation
5020
110 Spit Brook Road, M/S ZKO3-3/U14
5024
EMail: jtkohl@zk3.dec.com
5028
USC/Information Sciences Institute
5029
4676 Admiralty Way #1001
5030
Marina del Rey, CA 90292-6695
5039
Kohl & Neuman [Page 90]
5041
RFC 1510 Kerberos September 1993
5044
A. Pseudo-code for protocol processing
5046
This appendix provides pseudo-code describing how the messages are to
5047
be constructed and interpreted by clients and servers.
5049
A.1. KRB_AS_REQ generation
5050
request.pvno := protocol version; /* pvno = 5 */
5051
request.msg-type := message type; /* type = KRB_AS_REQ */
5053
if(pa_enc_timestamp_required) then
5054
request.padata.padata-type = PA-ENC-TIMESTAMP;
5056
padata-body.patimestamp,pausec = system_time;
5057
encrypt padata-body into request.padata.padata-value
5058
using client.key; /* derived from password */
5061
body.kdc-options := users's preferences;
5062
body.cname := user's name;
5063
body.realm := user's realm;
5064
body.sname := service's name; /* usually "krbtgt",
5066
if (body.kdc-options.POSTDATED is set) then
5067
body.from := requested starting time;
5071
body.till := requested end time;
5072
if (body.kdc-options.RENEWABLE is set) then
5073
body.rtime := requested final renewal time;
5075
body.nonce := random_nonce();
5076
body.etype := requested etypes;
5077
if (user supplied addresses) then
5078
body.addresses := user's addresses;
5080
omit body.addresses;
5082
omit body.enc-authorization-data;
5083
request.req-body := body;
5085
kerberos := lookup(name of local kerberos server (or servers));
5086
send(packet,kerberos);
5090
retry or use alternate server;
5095
Kohl & Neuman [Page 91]
5097
RFC 1510 Kerberos September 1993
5100
A.2. KRB_AS_REQ verification and KRB_AS_REP generation
5101
decode message into req;
5103
client := lookup(req.cname,req.realm);
5104
server := lookup(req.sname,req.realm);
5106
kdc_time := system_time.seconds;
5109
/* no client in Database */
5110
error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN);
5113
/* no server in Database */
5114
error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
5117
if(client.pa_enc_timestamp_required and
5118
pa_enc_timestamp not present) then
5119
error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP));
5122
if(pa_enc_timestamp present) then
5123
decrypt req.padata-value into decrypted_enc_timestamp
5125
using auth_hdr.authenticator.subkey;
5126
if (decrypt_error()) then
5127
error_out(KRB_AP_ERR_BAD_INTEGRITY);
5128
if(decrypted_enc_timestamp is not within allowable
5129
skew) then error_out(KDC_ERR_PREAUTH_FAILED);
5131
if(decrypted_enc_timestamp and usec is replay)
5132
error_out(KDC_ERR_PREAUTH_FAILED);
5134
add decrypted_enc_timestamp and usec to replay cache;
5137
use_etype := first supported etype in req.etypes;
5139
if (no support for req.etypes) then
5140
error_out(KDC_ERR_ETYPE_NOSUPP);
5143
new_tkt.vno := ticket version; /* = 5 */
5144
new_tkt.sname := req.sname;
5145
new_tkt.srealm := req.srealm;
5146
reset all flags in new_tkt.flags;
5151
Kohl & Neuman [Page 92]
5153
RFC 1510 Kerberos September 1993
5156
/* It should be noted that local policy may affect the */
5157
/* processing of any of these flags. For example, some */
5158
/* realms may refuse to issue renewable tickets */
5160
if (req.kdc-options.FORWARDABLE is set) then
5161
set new_tkt.flags.FORWARDABLE;
5163
if (req.kdc-options.PROXIABLE is set) then
5164
set new_tkt.flags.PROXIABLE;
5166
if (req.kdc-options.ALLOW-POSTDATE is set) then
5167
set new_tkt.flags.ALLOW-POSTDATE;
5169
if ((req.kdc-options.RENEW is set) or
5170
(req.kdc-options.VALIDATE is set) or
5171
(req.kdc-options.PROXY is set) or
5172
(req.kdc-options.FORWARDED is set) or
5173
(req.kdc-options.ENC-TKT-IN-SKEY is set)) then
5174
error_out(KDC_ERR_BADOPTION);
5177
new_tkt.session := random_session_key();
5178
new_tkt.cname := req.cname;
5179
new_tkt.crealm := req.crealm;
5180
new_tkt.transited := empty_transited_field();
5182
new_tkt.authtime := kdc_time;
5184
if (req.kdc-options.POSTDATED is set) then
5185
if (against_postdate_policy(req.from)) then
5186
error_out(KDC_ERR_POLICY);
5188
set new_tkt.flags.INVALID;
5189
new_tkt.starttime := req.from;
5191
omit new_tkt.starttime; /* treated as authtime when
5194
if (req.till = 0) then
5200
new_tkt.endtime := min(till,
5201
new_tkt.starttime+client.max_life,
5202
new_tkt.starttime+server.max_life,
5203
new_tkt.starttime+max_life_for_realm);
5207
Kohl & Neuman [Page 93]
5209
RFC 1510 Kerberos September 1993
5212
if ((req.kdc-options.RENEWABLE-OK is set) and
5213
(new_tkt.endtime < req.till)) then
5214
/* we set the RENEWABLE option for later processing */
5215
set req.kdc-options.RENEWABLE;
5216
req.rtime := req.till;
5219
if (req.rtime = 0) then
5225
if (req.kdc-options.RENEWABLE is set) then
5226
set new_tkt.flags.RENEWABLE;
5227
new_tkt.renew-till := min(rtime,
5228
new_tkt.starttime+client.max_rlife,
5229
new_tkt.starttime+server.max_rlife,
5230
new_tkt.starttime+max_rlife_for_realm);
5232
omit new_tkt.renew-till; /* only present if RENEWABLE */
5235
if (req.addresses) then
5236
new_tkt.caddr := req.addresses;
5241
new_tkt.authorization_data := empty_authorization_data();
5243
encode to-be-encrypted part of ticket into OCTET STRING;
5244
new_tkt.enc-part := encrypt OCTET STRING
5245
using etype_for_key(server.key), server.key, server.p_kvno;
5248
/* Start processing the response */
5251
resp.msg-type := KRB_AS_REP;
5252
resp.cname := req.cname;
5253
resp.crealm := req.realm;
5254
resp.ticket := new_tkt;
5256
resp.key := new_tkt.session;
5257
resp.last-req := fetch_last_request_info(client);
5258
resp.nonce := req.nonce;
5259
resp.key-expiration := client.expiration;
5263
Kohl & Neuman [Page 94]
5265
RFC 1510 Kerberos September 1993
5268
resp.flags := new_tkt.flags;
5270
resp.authtime := new_tkt.authtime;
5271
resp.starttime := new_tkt.starttime;
5272
resp.endtime := new_tkt.endtime;
5274
if (new_tkt.flags.RENEWABLE) then
5275
resp.renew-till := new_tkt.renew-till;
5278
resp.realm := new_tkt.realm;
5279
resp.sname := new_tkt.sname;
5281
resp.caddr := new_tkt.caddr;
5283
encode body of reply into OCTET STRING;
5285
resp.enc-part := encrypt OCTET STRING
5286
using use_etype, client.key, client.p_kvno;
5289
A.3. KRB_AS_REP verification
5290
decode response into resp;
5292
if (resp.msg-type = KRB_ERROR) then
5293
if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP))
5294
then set pa_enc_timestamp_required;
5297
process_error(resp);
5301
/* On error, discard the response, and zero the session key */
5302
/* from the response immediately */
5304
key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype,
5306
unencrypted part of resp := decode of decrypt of resp.enc-part
5307
using resp.enc-part.etype and key;
5310
if (common_as_rep_tgs_rep_checks fail) then
5315
if near(resp.princ_exp) then
5319
Kohl & Neuman [Page 95]
5321
RFC 1510 Kerberos September 1993
5324
print(warning message);
5326
save_for_later(ticket,session,client,server,times,flags);
5328
A.4. KRB_AS_REP and KRB_TGS_REP common checks
5329
if (decryption_error() or
5330
(req.cname != resp.cname) or
5331
(req.realm != resp.crealm) or
5332
(req.sname != resp.sname) or
5333
(req.realm != resp.realm) or
5334
(req.nonce != resp.nonce) or
5335
(req.addresses != resp.caddr)) then
5337
return KRB_AP_ERR_MODIFIED;
5340
/* make sure no flags are set that shouldn't be, and that */
5341
/* all that should be are set */
5342
if (!check_flags_for_compatability(req.kdc-options,resp.flags))
5343
then destroy resp.key;
5344
return KRB_AP_ERR_MODIFIED;
5347
if ((req.from = 0) and
5348
(resp.starttime is not within allowable skew)) then
5350
return KRB_AP_ERR_SKEW;
5352
if ((req.from != 0) and (req.from != resp.starttime)) then
5354
return KRB_AP_ERR_MODIFIED;
5356
if ((req.till != 0) and (resp.endtime > req.till)) then
5358
return KRB_AP_ERR_MODIFIED;
5361
if ((req.kdc-options.RENEWABLE is set) and
5362
(req.rtime != 0) and (resp.renew-till > req.rtime)) then
5364
return KRB_AP_ERR_MODIFIED;
5366
if ((req.kdc-options.RENEWABLE-OK is set) and
5367
(resp.flags.RENEWABLE) and
5369
(resp.renew-till > req.till)) then
5371
return KRB_AP_ERR_MODIFIED;
5375
Kohl & Neuman [Page 96]
5377
RFC 1510 Kerberos September 1993
5382
A.5. KRB_TGS_REQ generation
5383
/* Note that make_application_request might have to */
5384
/* recursivly call this routine to get the appropriate */
5385
/* ticket-granting ticket */
5387
request.pvno := protocol version; /* pvno = 5 */
5388
request.msg-type := message type; /* type = KRB_TGS_REQ */
5390
body.kdc-options := users's preferences;
5391
/* If the TGT is not for the realm of the end-server */
5392
/* then the sname will be for a TGT for the end-realm */
5393
/* and the realm of the requested ticket (body.realm) */
5394
/* will be that of the TGS to which the TGT we are */
5395
/* sending applies */
5396
body.sname := service's name;
5397
body.realm := service's realm;
5399
if (body.kdc-options.POSTDATED is set) then
5400
body.from := requested starting time;
5404
body.till := requested end time;
5405
if (body.kdc-options.RENEWABLE is set) then
5406
body.rtime := requested final renewal time;
5408
body.nonce := random_nonce();
5409
body.etype := requested etypes;
5410
if (user supplied addresses) then
5411
body.addresses := user's addresses;
5413
omit body.addresses;
5416
body.enc-authorization-data := user-supplied data;
5417
if (body.kdc-options.ENC-TKT-IN-SKEY) then
5418
body.additional-tickets_ticket := second TGT;
5421
request.req-body := body;
5422
check := generate_checksum (req.body,checksumtype);
5424
request.padata[0].padata-type := PA-TGS-REQ;
5425
request.padata[0].padata-value := create a KRB_AP_REQ using
5426
the TGT and checksum
5431
Kohl & Neuman [Page 97]
5433
RFC 1510 Kerberos September 1993
5436
/* add in any other padata as required/supplied */
5438
kerberos := lookup(name of local kerberose server (or servers));
5439
send(packet,kerberos);
5443
retry or use alternate server;
5446
A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation
5447
/* note that reading the application request requires first
5448
determining the server for which a ticket was issued, and
5449
choosing the correct key for decryption. The name of the
5450
server appears in the plaintext part of the ticket. */
5452
if (no KRB_AP_REQ in req.padata) then
5453
error_out(KDC_ERR_PADATA_TYPE_NOSUPP);
5455
verify KRB_AP_REQ in req.padata;
5457
/* Note that the realm in which the Kerberos server is
5458
operating is determined by the instance from the
5459
ticket-granting ticket. The realm in the ticket-granting
5460
ticket is the realm under which the ticket granting ticket was
5461
issued. It is possible for a single Kerberos server to
5462
support more than one realm. */
5464
auth_hdr := KRB_AP_REQ;
5465
tgt := auth_hdr.ticket;
5467
if (tgt.sname is not a TGT for local realm and is not
5468
req.sname) then error_out(KRB_AP_ERR_NOT_US);
5470
realm := realm_tgt_is_for(tgt);
5472
decode remainder of request;
5474
if (auth_hdr.authenticator.cksum is missing) then
5475
error_out(KRB_AP_ERR_INAPP_CKSUM);
5477
if (auth_hdr.authenticator.cksum type is not supported) then
5478
error_out(KDC_ERR_SUMTYPE_NOSUPP);
5480
if (auth_hdr.authenticator.cksum is not both collision-proof
5482
error_out(KRB_AP_ERR_INAPP_CKSUM);
5487
Kohl & Neuman [Page 98]
5489
RFC 1510 Kerberos September 1993
5492
set computed_checksum := checksum(req);
5493
if (computed_checksum != auth_hdr.authenticatory.cksum) then
5494
error_out(KRB_AP_ERR_MODIFIED);
5497
server := lookup(req.sname,realm);
5500
if (is_foreign_tgt_name(server)) then
5501
server := best_intermediate_tgs(server);
5503
/* no server in Database */
5504
error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
5508
session := generate_random_session_key();
5511
use_etype := first supported etype in req.etypes;
5513
if (no support for req.etypes) then
5514
error_out(KDC_ERR_ETYPE_NOSUPP);
5517
new_tkt.vno := ticket version; /* = 5 */
5518
new_tkt.sname := req.sname;
5519
new_tkt.srealm := realm;
5520
reset all flags in new_tkt.flags;
5522
/* It should be noted that local policy may affect the */
5523
/* processing of any of these flags. For example, some */
5524
/* realms may refuse to issue renewable tickets */
5526
new_tkt.caddr := tgt.caddr;
5527
resp.caddr := NULL; /* We only include this if they change */
5528
if (req.kdc-options.FORWARDABLE is set) then
5529
if (tgt.flags.FORWARDABLE is reset) then
5530
error_out(KDC_ERR_BADOPTION);
5532
set new_tkt.flags.FORWARDABLE;
5534
if (req.kdc-options.FORWARDED is set) then
5535
if (tgt.flags.FORWARDABLE is reset) then
5536
error_out(KDC_ERR_BADOPTION);
5538
set new_tkt.flags.FORWARDED;
5539
new_tkt.caddr := req.addresses;
5543
Kohl & Neuman [Page 99]
5545
RFC 1510 Kerberos September 1993
5548
resp.caddr := req.addresses;
5550
if (tgt.flags.FORWARDED is set) then
5551
set new_tkt.flags.FORWARDED;
5554
if (req.kdc-options.PROXIABLE is set) then
5555
if (tgt.flags.PROXIABLE is reset)
5556
error_out(KDC_ERR_BADOPTION);
5558
set new_tkt.flags.PROXIABLE;
5560
if (req.kdc-options.PROXY is set) then
5561
if (tgt.flags.PROXIABLE is reset) then
5562
error_out(KDC_ERR_BADOPTION);
5564
set new_tkt.flags.PROXY;
5565
new_tkt.caddr := req.addresses;
5566
resp.caddr := req.addresses;
5569
if (req.kdc-options.POSTDATE is set) then
5570
if (tgt.flags.POSTDATE is reset)
5571
error_out(KDC_ERR_BADOPTION);
5573
set new_tkt.flags.POSTDATE;
5575
if (req.kdc-options.POSTDATED is set) then
5576
if (tgt.flags.POSTDATE is reset) then
5577
error_out(KDC_ERR_BADOPTION);
5579
set new_tkt.flags.POSTDATED;
5580
set new_tkt.flags.INVALID;
5581
if (against_postdate_policy(req.from)) then
5582
error_out(KDC_ERR_POLICY);
5584
new_tkt.starttime := req.from;
5588
if (req.kdc-options.VALIDATE is set) then
5589
if (tgt.flags.INVALID is reset) then
5590
error_out(KDC_ERR_POLICY);
5592
if (tgt.starttime > kdc_time) then
5593
error_out(KRB_AP_ERR_NYV);
5595
if (check_hot_list(tgt)) then
5599
Kohl & Neuman [Page 100]
5601
RFC 1510 Kerberos September 1993
5604
error_out(KRB_AP_ERR_REPEAT);
5607
reset new_tkt.flags.INVALID;
5610
if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW,
5611
and those already processed) is set) then
5612
error_out(KDC_ERR_BADOPTION);
5615
new_tkt.authtime := tgt.authtime;
5617
if (req.kdc-options.RENEW is set) then
5618
/* Note that if the endtime has already passed, the ticket */
5619
/* would have been rejected in the initial authentication */
5620
/* stage, so there is no need to check again here */
5621
if (tgt.flags.RENEWABLE is reset) then
5622
error_out(KDC_ERR_BADOPTION);
5624
if (tgt.renew-till >= kdc_time) then
5625
error_out(KRB_AP_ERR_TKT_EXPIRED);
5628
new_tkt.starttime := kdc_time;
5629
old_life := tgt.endttime - tgt.starttime;
5630
new_tkt.endtime := min(tgt.renew-till,
5631
new_tkt.starttime + old_life);
5633
new_tkt.starttime := kdc_time;
5634
if (req.till = 0) then
5639
new_tkt.endtime := min(till,
5640
new_tkt.starttime+client.max_life,
5641
new_tkt.starttime+server.max_life,
5642
new_tkt.starttime+max_life_for_realm,
5645
if ((req.kdc-options.RENEWABLE-OK is set) and
5646
(new_tkt.endtime < req.till) and
5647
(tgt.flags.RENEWABLE is set) then
5648
/* we set the RENEWABLE option for later */
5650
set req.kdc-options.RENEWABLE;
5651
req.rtime := min(req.till, tgt.renew-till);
5655
Kohl & Neuman [Page 101]
5657
RFC 1510 Kerberos September 1993
5663
if (req.rtime = 0) then
5669
if ((req.kdc-options.RENEWABLE is set) and
5670
(tgt.flags.RENEWABLE is set)) then
5671
set new_tkt.flags.RENEWABLE;
5672
new_tkt.renew-till := min(rtime,
5673
new_tkt.starttime+client.max_rlife,
5674
new_tkt.starttime+server.max_rlife,
5675
new_tkt.starttime+max_rlife_for_realm,
5678
new_tkt.renew-till := OMIT;
5679
/* leave the renew-till field out */
5681
if (req.enc-authorization-data is present) then
5682
decrypt req.enc-authorization-data
5683
into decrypted_authorization_data
5684
using auth_hdr.authenticator.subkey;
5685
if (decrypt_error()) then
5686
error_out(KRB_AP_ERR_BAD_INTEGRITY);
5689
new_tkt.authorization_data :=
5690
req.auth_hdr.ticket.authorization_data +
5691
decrypted_authorization_data;
5693
new_tkt.key := session;
5694
new_tkt.crealm := tgt.crealm;
5695
new_tkt.cname := req.auth_hdr.ticket.cname;
5697
if (realm_tgt_is_for(tgt) := tgt.realm) then
5698
/* tgt issued by local realm */
5699
new_tkt.transited := tgt.transited;
5701
/* was issued for this realm by some other realm */
5702
if (tgt.transited.tr-type not supported) then
5703
error_out(KDC_ERR_TRTYPE_NOSUPP);
5706
:= compress_transited(tgt.transited + tgt.realm)
5711
Kohl & Neuman [Page 102]
5713
RFC 1510 Kerberos September 1993
5716
encode encrypted part of new_tkt into OCTET STRING;
5717
if (req.kdc-options.ENC-TKT-IN-SKEY is set) then
5718
if (server not specified) then
5719
server = req.second_ticket.client;
5721
if ((req.second_ticket is not a TGT) or
5722
(req.second_ticket.client != server)) then
5723
error_out(KDC_ERR_POLICY);
5726
new_tkt.enc-part := encrypt OCTET STRING using
5727
using etype_for_key(second-ticket.key),
5730
new_tkt.enc-part := encrypt OCTET STRING
5731
using etype_for_key(server.key), server.key,
5736
resp.msg-type := KRB_TGS_REP;
5737
resp.crealm := tgt.crealm;
5738
resp.cname := tgt.cname;
5739
resp.ticket := new_tkt;
5741
resp.key := session;
5742
resp.nonce := req.nonce;
5743
resp.last-req := fetch_last_request_info(client);
5744
resp.flags := new_tkt.flags;
5746
resp.authtime := new_tkt.authtime;
5747
resp.starttime := new_tkt.starttime;
5748
resp.endtime := new_tkt.endtime;
5750
omit resp.key-expiration;
5752
resp.sname := new_tkt.sname;
5753
resp.realm := new_tkt.realm;
5755
if (new_tkt.flags.RENEWABLE) then
5756
resp.renew-till := new_tkt.renew-till;
5760
encode body of reply into OCTET STRING;
5762
if (req.padata.authenticator.subkey)
5763
resp.enc-part := encrypt OCTET STRING using use_etype,
5767
Kohl & Neuman [Page 103]
5769
RFC 1510 Kerberos September 1993
5772
req.padata.authenticator.subkey;
5773
else resp.enc-part := encrypt OCTET STRING
5774
using use_etype, tgt.key;
5778
A.7. KRB_TGS_REP verification
5779
decode response into resp;
5781
if (resp.msg-type = KRB_ERROR) then
5782
process_error(resp);
5786
/* On error, discard the response, and zero the session key from
5787
the response immediately */
5789
if (req.padata.authenticator.subkey)
5790
unencrypted part of resp :=
5791
decode of decrypt of resp.enc-part
5792
using resp.enc-part.etype and subkey;
5793
else unencrypted part of resp :=
5794
decode of decrypt of resp.enc-part
5795
using resp.enc-part.etype and tgt's session key;
5796
if (common_as_rep_tgs_rep_checks fail) then
5801
check authorization_data as necessary;
5802
save_for_later(ticket,session,client,server,times,flags);
5804
A.8. Authenticator generation
5805
body.authenticator-vno := authenticator vno; /* = 5 */
5806
body.cname, body.crealm := client name;
5807
if (supplying checksum) then
5808
body.cksum := checksum;
5811
body.ctime, body.cusec := system_time;
5812
if (selecting sub-session key) then
5813
select sub-session key;
5814
body.subkey := sub-session key;
5816
if (using sequence numbers) then
5817
select initial sequence number;
5818
body.seq-number := initial sequence;
5823
Kohl & Neuman [Page 104]
5825
RFC 1510 Kerberos September 1993
5828
A.9. KRB_AP_REQ generation
5829
obtain ticket and session_key from cache;
5831
packet.pvno := protocol version; /* 5 */
5832
packet.msg-type := message type; /* KRB_AP_REQ */
5834
if (desired(MUTUAL_AUTHENTICATION)) then
5835
set packet.ap-options.MUTUAL-REQUIRED;
5837
reset packet.ap-options.MUTUAL-REQUIRED;
5839
if (using session key for ticket) then
5840
set packet.ap-options.USE-SESSION-KEY;
5842
reset packet.ap-options.USE-SESSION-KEY;
5844
packet.ticket := ticket; /* ticket */
5845
generate authenticator;
5846
encode authenticator into OCTET STRING;
5847
encrypt OCTET STRING into packet.authenticator
5850
A.10. KRB_AP_REQ verification
5852
if (packet.pvno != 5) then
5853
either process using other protocol spec
5854
or error_out(KRB_AP_ERR_BADVERSION);
5856
if (packet.msg-type != KRB_AP_REQ) then
5857
error_out(KRB_AP_ERR_MSG_TYPE);
5859
if (packet.ticket.tkt_vno != 5) then
5860
either process using other protocol spec
5861
or error_out(KRB_AP_ERR_BADVERSION);
5863
if (packet.ap_options.USE-SESSION-KEY is set) then
5864
retrieve session key from ticket-granting ticket for
5865
packet.ticket.{sname,srealm,enc-part.etype};
5867
retrieve service key for
5868
packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno};
5870
if (no_key_available) then
5871
if (cannot_find_specified_skvno) then
5872
error_out(KRB_AP_ERR_BADKEYVER);
5874
error_out(KRB_AP_ERR_NOKEY);
5879
Kohl & Neuman [Page 105]
5881
RFC 1510 Kerberos September 1993
5885
decrypt packet.ticket.enc-part into decr_ticket
5886
using retrieved key;
5887
if (decryption_error()) then
5888
error_out(KRB_AP_ERR_BAD_INTEGRITY);
5890
decrypt packet.authenticator into decr_authenticator
5891
using decr_ticket.key;
5892
if (decryption_error()) then
5893
error_out(KRB_AP_ERR_BAD_INTEGRITY);
5895
if (decr_authenticator.{cname,crealm} !=
5896
decr_ticket.{cname,crealm}) then
5897
error_out(KRB_AP_ERR_BADMATCH);
5899
if (decr_ticket.caddr is present) then
5900
if (sender_address(packet) is not in decr_ticket.caddr)
5901
then error_out(KRB_AP_ERR_BADADDR);
5903
elseif (application requires addresses) then
5904
error_out(KRB_AP_ERR_BADADDR);
5906
if (not in_clock_skew(decr_authenticator.ctime,
5907
decr_authenticator.cusec)) then
5908
error_out(KRB_AP_ERR_SKEW);
5910
if (repeated(decr_authenticator.{ctime,cusec,cname,crealm}))
5911
then error_out(KRB_AP_ERR_REPEAT);
5913
save_identifier(decr_authenticator.{ctime,cusec,cname,crealm});
5915
if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or
5916
(decr_ticket.flags.INVALID is set)) then
5917
/* it hasn't yet become valid */
5918
error_out(KRB_AP_ERR_TKT_NYV);
5920
if (system_time-decr_ticket.endtime > CLOCK_SKEW) then
5921
error_out(KRB_AP_ERR_TKT_EXPIRED);
5923
/* caller must check decr_ticket.flags for any pertinent */
5925
return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED);
5927
A.11. KRB_AP_REP generation
5928
packet.pvno := protocol version; /* 5 */
5929
packet.msg-type := message type; /* KRB_AP_REP */
5930
body.ctime := packet.ctime;
5931
body.cusec := packet.cusec;
5935
Kohl & Neuman [Page 106]
5937
RFC 1510 Kerberos September 1993
5940
if (selecting sub-session key) then
5941
select sub-session key;
5942
body.subkey := sub-session key;
5944
if (using sequence numbers) then
5945
select initial sequence number;
5946
body.seq-number := initial sequence;
5949
encode body into OCTET STRING;
5951
select encryption type;
5952
encrypt OCTET STRING into packet.enc-part;
5954
A.12. KRB_AP_REP verification
5956
if (packet.pvno != 5) then
5957
either process using other protocol spec
5958
or error_out(KRB_AP_ERR_BADVERSION);
5960
if (packet.msg-type != KRB_AP_REP) then
5961
error_out(KRB_AP_ERR_MSG_TYPE);
5963
cleartext := decrypt(packet.enc-part)
5964
using ticket's session key;
5965
if (decryption_error()) then
5966
error_out(KRB_AP_ERR_BAD_INTEGRITY);
5968
if (cleartext.ctime != authenticator.ctime) then
5969
error_out(KRB_AP_ERR_MUT_FAIL);
5971
if (cleartext.cusec != authenticator.cusec) then
5972
error_out(KRB_AP_ERR_MUT_FAIL);
5974
if (cleartext.subkey is present) then
5975
save cleartext.subkey for future use;
5977
if (cleartext.seq-number is present) then
5978
save cleartext.seq-number for future verifications;
5980
return(AUTHENTICATION_SUCCEEDED);
5982
A.13. KRB_SAFE generation
5983
collect user data in buffer;
5985
/* assemble packet: */
5986
packet.pvno := protocol version; /* 5 */
5987
packet.msg-type := message type; /* KRB_SAFE */
5991
Kohl & Neuman [Page 107]
5993
RFC 1510 Kerberos September 1993
5996
body.user-data := buffer; /* DATA */
5997
if (using timestamp) then
5999
body.timestamp, body.usec := system_time;
6001
if (using sequence numbers) then
6002
body.seq-number := sequence number;
6004
body.s-address := sender host addresses;
6005
if (only one recipient) then
6006
body.r-address := recipient host address;
6008
checksum.cksumtype := checksum type;
6009
compute checksum over body;
6010
checksum.checksum := checksum value; /* checksum.checksum */
6011
packet.cksum := checksum;
6012
packet.safe-body := body;
6014
A.14. KRB_SAFE verification
6016
if (packet.pvno != 5) then
6017
either process using other protocol spec
6018
or error_out(KRB_AP_ERR_BADVERSION);
6020
if (packet.msg-type != KRB_SAFE) then
6021
error_out(KRB_AP_ERR_MSG_TYPE);
6023
if (packet.checksum.cksumtype is not both collision-proof
6025
error_out(KRB_AP_ERR_INAPP_CKSUM);
6027
if (safe_priv_common_checks_ok(packet)) then
6028
set computed_checksum := checksum(packet.body);
6029
if (computed_checksum != packet.checksum) then
6030
error_out(KRB_AP_ERR_MODIFIED);
6032
return (packet, PACKET_IS_GENUINE);
6034
return common_checks_error;
6037
A.15. KRB_SAFE and KRB_PRIV common checks
6038
if (packet.s-address != O/S_sender(packet)) then
6039
/* O/S report of sender not who claims to have sent it */
6040
error_out(KRB_AP_ERR_BADADDR);
6042
if ((packet.r-address is present) and
6043
(packet.r-address != local_host_address)) then
6047
Kohl & Neuman [Page 108]
6049
RFC 1510 Kerberos September 1993
6052
/* was not sent to proper place */
6053
error_out(KRB_AP_ERR_BADADDR);
6055
if (((packet.timestamp is present) and
6056
(not in_clock_skew(packet.timestamp,packet.usec))) or
6057
(packet.timestamp is not present and timestamp expected))
6058
then error_out(KRB_AP_ERR_SKEW);
6060
if (repeated(packet.timestamp,packet.usec,packet.s-address))
6061
then error_out(KRB_AP_ERR_REPEAT);
6063
if (((packet.seq-number is present) and
6064
((not in_sequence(packet.seq-number)))) or
6065
(packet.seq-number is not present and sequence expected))
6066
then error_out(KRB_AP_ERR_BADORDER);
6068
if (packet.timestamp not present and
6069
packet.seq-number not present) then
6070
error_out(KRB_AP_ERR_MODIFIED);
6073
save_identifier(packet.{timestamp,usec,s-address},
6074
sender_principal(packet));
6076
return PACKET_IS_OK;
6078
A.16. KRB_PRIV generation
6079
collect user data in buffer;
6081
/* assemble packet: */
6082
packet.pvno := protocol version; /* 5 */
6083
packet.msg-type := message type; /* KRB_PRIV */
6085
packet.enc-part.etype := encryption type;
6087
body.user-data := buffer;
6088
if (using timestamp) then
6090
body.timestamp, body.usec := system_time;
6092
if (using sequence numbers) then
6093
body.seq-number := sequence number;
6095
body.s-address := sender host addresses;
6096
if (only one recipient) then
6097
body.r-address := recipient host address;
6103
Kohl & Neuman [Page 109]
6105
RFC 1510 Kerberos September 1993
6108
encode body into OCTET STRING;
6110
select encryption type;
6111
encrypt OCTET STRING into packet.enc-part.cipher;
6113
A.17. KRB_PRIV verification
6115
if (packet.pvno != 5) then
6116
either process using other protocol spec
6117
or error_out(KRB_AP_ERR_BADVERSION);
6119
if (packet.msg-type != KRB_PRIV) then
6120
error_out(KRB_AP_ERR_MSG_TYPE);
6123
cleartext := decrypt(packet.enc-part) using negotiated key;
6124
if (decryption_error()) then
6125
error_out(KRB_AP_ERR_BAD_INTEGRITY);
6128
if (safe_priv_common_checks_ok(cleartext)) then
6129
return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED);
6131
return common_checks_error;
6134
A.18. KRB_CRED generation
6135
invoke KRB_TGS; /* obtain tickets to be provided to peer */
6137
/* assemble packet: */
6138
packet.pvno := protocol version; /* 5 */
6139
packet.msg-type := message type; /* KRB_CRED */
6141
for (tickets[n] in tickets to be forwarded) do
6142
packet.tickets[n] = tickets[n].ticket;
6145
packet.enc-part.etype := encryption type;
6147
for (ticket[n] in tickets to be forwarded) do
6148
body.ticket-info[n].key = tickets[n].session;
6149
body.ticket-info[n].prealm = tickets[n].crealm;
6150
body.ticket-info[n].pname = tickets[n].cname;
6151
body.ticket-info[n].flags = tickets[n].flags;
6152
body.ticket-info[n].authtime = tickets[n].authtime;
6153
body.ticket-info[n].starttime = tickets[n].starttime;
6154
body.ticket-info[n].endtime = tickets[n].endtime;
6155
body.ticket-info[n].renew-till = tickets[n].renew-till;
6159
Kohl & Neuman [Page 110]
6161
RFC 1510 Kerberos September 1993
6164
body.ticket-info[n].srealm = tickets[n].srealm;
6165
body.ticket-info[n].sname = tickets[n].sname;
6166
body.ticket-info[n].caddr = tickets[n].caddr;
6170
body.timestamp, body.usec := system_time;
6172
if (using nonce) then
6173
body.nonce := nonce;
6176
if (using s-address) then
6177
body.s-address := sender host addresses;
6179
if (limited recipients) then
6180
body.r-address := recipient host address;
6183
encode body into OCTET STRING;
6185
select encryption type;
6186
encrypt OCTET STRING into packet.enc-part.cipher
6187
using negotiated encryption key;
6189
A.19. KRB_CRED verification
6191
if (packet.pvno != 5) then
6192
either process using other protocol spec
6193
or error_out(KRB_AP_ERR_BADVERSION);
6195
if (packet.msg-type != KRB_CRED) then
6196
error_out(KRB_AP_ERR_MSG_TYPE);
6199
cleartext := decrypt(packet.enc-part) using negotiated key;
6200
if (decryption_error()) then
6201
error_out(KRB_AP_ERR_BAD_INTEGRITY);
6203
if ((packet.r-address is present or required) and
6204
(packet.s-address != O/S_sender(packet)) then
6205
/* O/S report of sender not who claims to have sent it */
6206
error_out(KRB_AP_ERR_BADADDR);
6208
if ((packet.r-address is present) and
6209
(packet.r-address != local_host_address)) then
6210
/* was not sent to proper place */
6211
error_out(KRB_AP_ERR_BADADDR);
6215
Kohl & Neuman [Page 111]
6217
RFC 1510 Kerberos September 1993
6221
if (not in_clock_skew(packet.timestamp,packet.usec)) then
6222
error_out(KRB_AP_ERR_SKEW);
6224
if (repeated(packet.timestamp,packet.usec,packet.s-address))
6225
then error_out(KRB_AP_ERR_REPEAT);
6227
if (packet.nonce is required or present) and
6228
(packet.nonce != expected-nonce) then
6229
error_out(KRB_AP_ERR_MODIFIED);
6232
for (ticket[n] in tickets that were forwarded) do
6233
save_for_later(ticket[n],key[n],principal[n],
6234
server[n],times[n],flags[n]);
6237
A.20. KRB_ERROR generation
6239
/* assemble packet: */
6240
packet.pvno := protocol version; /* 5 */
6241
packet.msg-type := message type; /* KRB_ERROR */
6244
packet.stime, packet.susec := system_time;
6245
packet.realm, packet.sname := server name;
6247
if (client time available) then
6248
packet.ctime, packet.cusec := client_time;
6250
packet.error-code := error code;
6251
if (client name available) then
6252
packet.cname, packet.crealm := client name;
6254
if (error text available) then
6255
packet.e-text := error text;
6257
if (error data available) then
6258
packet.e-data := error data;
6271
Kohl & Neuman [Page 112]
b'\\ No newline at end of file'
added
removed
doc/standardisation/rfc1510.txt
