| blob | 5e87195e24447458c08f485393f48d97a9a88c4b |
3 INTERNET-DRAFT Tom Yu
4 draft-ietf-krb-wg-rfc1510ter-04.txt MIT
5 Expires: 06 September 2007 05 March 2007
7 The Kerberos Network Authentication Service (Version 5)
9 Status of This Memo
11 By submitting this Internet-Draft, each author represents that any
12 applicable patent or other IPR claims of which he or she is aware
13 have been or will be disclosed, and any of which he or she becomes
14 aware will be disclosed, in accordance with Section 6 of BCP 79.
16 Internet-Drafts are working documents of the Internet Engineering
17 Task Force (IETF), its areas, and its working groups. Note that
18 other groups may also distribute working documents as Internet-
19 Drafts.
21 Internet-Drafts are draft documents valid for a maximum of six months
22 and may be updated, replaced, or obsoleted by other documents at any
23 time. It is inappropriate to use Internet-Drafts as reference
24 material or to cite them other than as "work in progress."
26 The list of current Internet-Drafts can be accessed at
27 http://www.ietf.org/ietf/1id-abstracts.txt
29 The list of Internet-Draft Shadow Directories can be accessed at
30 http://www.ietf.org/shadow.html
32 Copyright Notice
34 Copyright (C) The IETF Trust (2007).
36 Abstract
38 This document specifies version 5 of the Kerberos network
39 authentication protocol. It obsoletes RFC 4120, and in addition to
40 providing a detailed description of the protocol, it describes a
41 framework to allow for extensions to be made to the protocol without
42 creating interoperability problems.
55 Yu Expires: Sep 2007 [Page 1]
56 \f
57 Internet-Draft rfc1510ter-04 05 Mar 2007
59 Table of Contents
61 Status of This Memo .............................................. 1
62 Copyright Notice ................................................. 1
63 Abstract ......................................................... 1
64 Table of Contents ................................................ 2
65 1. Introduction ................................................. 4
66 1.1. Kerberos Protocol Overview ................................. 4
67 1.2. Document Organization ...................................... 5
68 2. Compatibility Considerations ................................. 6
69 2.1. Extensibility .............................................. 6
70 2.2. Compatibility with RFC 1510 ................................ 6
71 2.3. Backwards Compatibility .................................... 6
72 2.4. Sending Extensible Messages ................................ 7
73 2.5. Criticality ................................................ 7
74 2.6. Authenticating Cleartext Portions of Messages .............. 8
75 2.7. Capability Negotiation ..................................... 9
76 2.8. Strings .................................................... 10
77 3. Use of ASN.1 in Kerberos ..................................... 10
78 3.1. Module Header .............................................. 11
79 3.2. Top-Level Type ............................................. 11
80 3.3. Previously Unused ASN.1 Notation (informative) ............. 12
81 3.4. New Types .................................................. 12
82 4. Basic Types .................................................. 13
83 4.1. Constrained Integer Types .................................. 13
84 4.2. KerberosTime ............................................... 14
85 4.3. KerberosString ............................................. 14
86 4.4. Language Tags .............................................. 15
87 4.5. KerberosFlags .............................................. 15
88 4.6. Typed Holes ................................................ 16
89 4.7. HostAddress and HostAddresses .............................. 16
90 5. Principals ................................................... 18
91 5.1. Name Types ................................................. 18
92 5.2. Principal Type Definition .................................. 19
93 5.3. Principal Name Reuse ....................................... 20
94 5.4. Best Common Practice Recommendations for the Processing
95 of Principal Names Consisting of Internationalized
96 Domain Names: .......................................... 20
97 5.5. Realm Names ................................................ 21
98 5.6. Best Common Practice Recommendations for the Processing
99 of Internationalized Domain-Style Realm Names: ......... 21
100 5.7. Printable Representations of Principal Names ............... 22
101 5.8. Ticket-Granting Service Principal .......................... 22
102 6. Types Relating to Encryption ................................. 23
103 6.1. Assigned Numbers for Encryption ............................ 23
104 6.2. Which Key to Use ........................................... 26
105 6.3. EncryptionKey .............................................. 27
106 6.4. EncryptedData .............................................. 27
107 6.5. Checksums .................................................. 28
108 7. Tickets ...................................................... 30
109 7.1. Timestamps ................................................. 31
111 Yu Expires: Sep 2007 [Page 2]
112 \f
113 Internet-Draft rfc1510ter-04 05 Mar 2007
115 7.2. Ticket Flags ............................................... 32
116 7.3. Transited Realms ........................................... 37
117 7.4. Authorization Data ......................................... 37
118 7.5. Encrypted Part of Ticket ................................... 41
119 7.6. Cleartext Part of Ticket ................................... 41
120 8. Credential Acquisition ....................................... 43
121 8.1. KDC-REQ .................................................... 43
122 8.2. PA-DATA .................................................... 50
123 8.3. KDC-REQ Processing ......................................... 50
124 8.4. KDC-REP .................................................... 56
125 8.5. Reply Validation ........................................... 60
126 8.6. IP Transports .............................................. 60
127 9. Errors ....................................................... 63
128 10. Session Key Exchange ........................................ 65
129 10.1. AP-REQ .................................................... 66
130 10.2. AP-REP .................................................... 67
131 11. Session Key Use ............................................. 69
132 11.1. KRB-SAFE .................................................. 69
133 11.2. KRB-PRIV .................................................. 69
134 11.3. KRB-CRED .................................................. 70
135 12. Security Considerations ..................................... 71
136 12.1. Time Synchronization ...................................... 71
137 12.2. Replays ................................................... 72
138 12.3. Principal Name Reuse ...................................... 72
139 12.4. Password Guessing ......................................... 72
140 12.5. Forward Secrecy ........................................... 72
141 12.6. Authorization ............................................. 72
142 12.7. Login Authentication ...................................... 72
143 13. IANA Considerations ......................................... 72
144 14. Acknowledgments ............................................. 73
145 Appendices ....................................................... 73
146 A. ASN.1 Module (Normative) ..................................... 73
147 B. Kerberos and Character Encodings (Informative) ...............109
148 C. Kerberos History (Informative) ...............................110
149 D. Notational Differences from [RFC4120] ........................111
150 Normative References .............................................111
151 Informative References ...........................................112
152 Author's Address .................................................113
153 Full Copyright Statement .........................................113
154 Intellectual Property ............................................113
167 Yu Expires: Sep 2007 [Page 3]
168 \f
169 Internet-Draft rfc1510ter-04 05 Mar 2007
171 1. Introduction
173 The Kerberos network authentication protocol is a trusted-third-party
174 protocol utilizing symmetric-key cryptography. It assumes that all
175 communications between parties in the protocol may be arbitrarily
176 tampered with or monitored, and that the security of the overall
177 system depends only on the effectiveness of the cryptographic
178 techniques and the secrecy of the cryptographic keys used. The
179 Kerberos protocol authenticates an application client's identity to
180 an application server, and likewise authenticates the application
181 server's identity to the application client. These assurances are
182 made possible by the client and the server sharing secrets with the
183 trusted third party: the Kerberos server, also known as the Key
184 Distribution Center (KDC). In addition, the protocol establishes an
185 ephemeral shared secret (the session key) between the client and the
186 server, allowing the protection of further communications between
187 them.
189 The Kerberos protocol, as originally specified in [RFC1510] and
190 [RFC4120], provides insufficient means for extending the protocol in
191 a backwards-compatible way. This deficiency has caused problems for
192 interoperability. This document describes a framework which enables
193 backwards-compatible extensions to the Kerberos protocol.
195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
196 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
197 to be interpreted as described in [RFC2119].
199 1.1. Kerberos Protocol Overview
201 Kerberos comprises three main sub-protocols: credentials acquisition,
202 session key exchange, and session key usage. A client acquires
203 credentials by asking the KDC for a credential for a service; the KDC
204 issues the credential, which contains a ticket and a session key.
205 The ticket, containing the client's identity, timestamps, expiration
206 time, and a session key, is a encrypted in a key known to the
207 application server. The KDC encrypts the credential using a key
208 known to the client, and transmits the credential to the client.
210 There are two means of requesting credentials: the Authentication
211 Service (AS) exchange, and the Ticket-Granting Service (TGS)
212 exchange. In the typical AS exchange, a client uses a password-
213 derived key to decrypt the response. In the TGS exchange, the KDC
214 behaves as an application server; the client authenticates to the TGS
215 by using a Ticket-Granting Ticket (TGT). The client usually obtains
216 the TGT by using the AS exchange.
218 Session key exchange consists of the client transmitting the ticket
219 to the application server, accompanied by an authenticator. The
220 authenticator contains a timestamp and additional data encrypted
221 using the ticket's session key. The application server decrypts the
223 Yu Expires: Sep 2007 [Page 4]
224 \f
225 Internet-Draft rfc1510ter-04 05 Mar 2007
227 ticket, extracting the session key. The application server then uses
228 the session key to decrypt the authenticator. Upon successful
229 decryption of the authenticator, the application server knows that
230 the data in the authenticator were sent by the client named in the
231 associated ticket. Additionally, since authenticators expire more
232 quickly than tickets, the application server has some assurance that
233 the transaction is not a replay. The application server may send an
234 encrypted acknowledgment to the client, verifying its identity to the
235 client.
237 Once session key exchange has occurred, the client and server may use
238 the established session key to protect further traffic. This
239 protection may consist of protection of integrity only, or of
240 protection of confidentiality and integrity. Additional measures
241 exist for a client to securely forward credentials to a server.
243 The entire scheme depends on loosely synchronized clocks.
244 Synchronization of the clock on the KDC with the application server
245 clock allows the application server to accurately determine whether a
246 credential is expired. Likewise, synchronization of the clock on the
247 client with the application server clock prevents replay attacks
248 utilizing the same credential. Careful design of the application
249 protocol may allow replay prevention without requiring client-server
250 clock synchronization.
252 After establishing a session key, application client and the
253 application server can exchange Kerberos protocol messages that use
254 the session key to protect the integrity or confidentiality of
255 communications between the client and the server. Additionally, the
256 client may forward credentials to the application server.
258 The credentials acquisition protocol takes place over specific,
259 defined transports (UDP and TCP). Application protocols define which
260 transport to use for the session key establishment protocol and for
261 messages using the session key; the application may choose to perform
262 its own encapsulation of the Kerberos messages, for example.
264 1.2. Document Organization
266 The remainder of this document begins by describing the general
267 frameworks for protocol extensibility, including whether to interpret
268 unknown extensions as critical. It then defines the protocol
269 messages and exchanges.
271 The definition of the Kerberos protocol uses Abstract Syntax Notation
272 One (ASN.1) [X680], which specifies notation for describing the
273 abstract content of protocol messages. This document defines a
274 number of base types using ASN.1; these base types subsequently
275 appear in multiple types which define actual protocol messages.
276 Definitions of principal names and of tickets, which are central to
277 the protocol, also appear preceding the protocol message definitions.
279 Yu Expires: Sep 2007 [Page 5]
280 \f
281 Internet-Draft rfc1510ter-04 05 Mar 2007
283 2. Compatibility Considerations
285 2.1. Extensibility
287 In the past, significant interoperability problems have resulted from
288 conflicting assumptions about how the Kerberos protocol can be
289 extended. As the deployed base of Kerberos grows, the ability to
290 extend the Kerberos protocol becomes more important. In order to
291 ensure that vendors and the IETF can extend the protocol while
292 maintaining backwards compatibility, this document outlines a
293 framework for extending Kerberos.
295 Kerberos provides two general mechanisms for protocol extensibility.
296 Many protocol messages, including some defined in RFC 1510, contain
297 typed holes--sub-messages containing an octet string along with an
298 integer that identifies how to interpret the octet string. The
299 integer identifiers are registered centrally, but can be used both
300 for vendor extensions and for extensions standardized in the IETF.
301 This document adds typed holes to a number of messages which
302 previously lacked typed holes.
304 Many new messages defined in this document also contain ASN.1
305 extension markers. These markers allow future revisions of this
306 document to add additional elements to messages, for cases where
307 typed holes are inadequate for some reason. Because tag numbers and
308 position in a sequence need to be coordinated in order to maintain
309 interoperability, implementations MUST NOT include ASN.1 extensions
310 except when those extensions are specified by IETF standards-track
311 documents.
313 2.2. Compatibility with RFC 1510
315 Implementations of RFC 1510 did not use extensible ASN.1 types.
316 Sending additional fields not in RFC 1510 to these implementations
317 results in undefined behavior. Examples of this behavior are known
318 to include discarding messages with no error indications.
320 Where messages have been changed since RFC 1510, ASN.1 CHOICE types
321 are used; one alternative of the CHOICE provides a message which is
322 wire-encoding compatible with RFC 1510, and the other alternative
323 provides the new, extensible message.
325 Implementations sending new messages MUST ensure that the recipient
326 supports these new messages. Along with each extensible message is a
327 guideline for when that message MAY be used. If that guideline is
328 followed, then the recipient is guaranteed to understand the message.
330 2.3. Backwards Compatibility
332 This document describes two sets (for the most part) of ASN.1 types.
333 The first set of types is wire-encoding compatible with RFC 1510 and
335 Yu Expires: Sep 2007 [Page 6]
336 \f
337 Internet-Draft rfc1510ter-04 05 Mar 2007
339 [RFC4120]. The second set of types is the set of types enabling
340 extensibility. This second set may be referred to as
341 "extensibility-enabled types". [ need to make this consistent
342 throughout? ]
344 A major difference between the new extensibility-enabled types and
345 the types for RFC 1510 compatibility is that the extensibility-
346 enabled types allow for the use of UTF-8 encodings in various
347 character strings in the protocol. Each party in the protocol must
348 have some knowledge of the capabilities of the other parties in the
349 protocol. There are methods for establishing this knowledge without
350 necessarily requiring explicit configuration.
352 An extensibility-enabled client can detect whether a KDC supports the
353 extensibility-enabled types by requesting an extensibility-enabled
354 reply. If the KDC replies with an extensibility-enabled reply, the
355 client knows that the KDC supports extensibility. If the KDC issues
356 an extensibility-enabled ticket, the client knows that the service
357 named in the ticket is extensibility-enabled.
359 2.4. Sending Extensible Messages
361 Care must be taken to make sure that old implementations can
362 understand messages sent to them even if they do not understand an
363 extension that is used. Unless the sender knows the extension is
364 supported, the extension cannot change the semantics of the core
365 message or previously defined extensions.
367 For example, an extension including key information necessary to
368 decrypt the encrypted part of a KDC-REP could only be used in
369 situations where the recipient was known to support the extension.
370 Thus when designing such extensions it is important to provide a way
371 for the recipient to notify the sender of support for the extension.
372 For example in the case of an extension that changes the KDC-REP
373 reply key, the client could indicate support for the extension by
374 including a padata element in the AS-REQ sequence. The KDC should
375 only use the extension if this padata element is present in the AS-
376 REQ. Even if policy requires the use of the extension, it is better
377 to return an error indicating that the extension is required than to
378 use the extension when the recipient may not support it; debugging
379 why implementations do not interoperate is easier when errors are
380 returned.
382 2.5. Criticality
384 Recipients of unknown message extensions (including typed holes, new
385 flags, and ASN.1 extension elements) should preserve the encoding of
386 the extension but otherwise ignore the presence of the extension;
387 i.e., unknown extensions SHOULD be treated as non-critical. If a
388 copy of the message is used later--for example, when a Ticket
389 received in a KDC-REP is later used in an AP-REQ--then the unknown
391 Yu Expires: Sep 2007 [Page 7]
392 \f
393 Internet-Draft rfc1510ter-04 05 Mar 2007
395 extensions MUST be included.
397 An implementation SHOULD NOT reject a request merely because it does
398 not understand some element of the request. As a related
399 consequence, implementations SHOULD handle communicating with other
400 implementations which do not implement some requested options. This
401 may require designers of options to provide means to determine
402 whether an option has been rejected, not understood, or (perhaps
403 maliciously) deleted or modified in transit.
405 There is one exception to non-criticality described above: if an
406 unknown authorization data element is received by a server either in
407 an AP-REQ or in a Ticket contained in an AP-REQ, then the
408 authentication SHOULD fail. Authorization data is intended to
409 restrict the use of a ticket. If the service cannot determine
410 whether the restriction applies to that service then a security
411 weakness may result if authentication succeeds. Authorization
412 elements meant to be truly optional can be enclosed in the AD-IF-
413 RELEVANT element.
415 Many RFC 1510 implementations ignore unknown authorization data
416 elements. Depending on these implementations to honor authorization
417 data restrictions may create a security weakness.
419 2.6. Authenticating Cleartext Portions of Messages
421 Various denial of service attacks and downgrade attacks against
422 Kerberos are possible unless plaintexts are somehow protected against
423 modification. An early design goal of Kerberos Version 5 was to
424 avoid encrypting more of the authentication exchange that was
425 required. (Version 4 doubly-encrypted the encrypted part of a ticket
426 in a KDC reply, for example.) This minimization of encryption
427 reduces the load on the KDC and busy servers. Also, during the
428 initial design of Version 5, the existence of legal restrictions on
429 the export of cryptography made it desirable to minimize of the
430 number of uses of encryption in the protocol. Unfortunately,
431 performing this minimization created numerous instances of
432 unauthenticated security-relevant plaintext fields.
434 The extensible variants of the messages described in this document
435 wrap the actual message in an ASN.1 sequence containing a keyed
436 checksum of the contents of the message. Guidelines in [XXX] section
437 3 specify when the checksum MUST be included and what key MUST be
438 used. Guidelines on when to include a checksum are never ambiguous:
439 a particular PDU is never correct both with and without a checksum.
440 With the exception of the KRB-ERROR message, receiving
441 implementations MUST reject messages where a checksum is included and
442 not expected or where a checksum is expected but not included. The
443 receiving implementation does not always have sufficient information
444 to know whether a KRB-ERROR should contain a checksum. Even so,
445 KRB-ERROR messages with invalid checksums MUST be rejected and
447 Yu Expires: Sep 2007 [Page 8]
448 \f
449 Internet-Draft rfc1510ter-04 05 Mar 2007
451 implementations MAY consider the presence or absence of a checksum
452 when evaluating whether to trust the error.
454 This authenticated cleartext protection is provided only in the
455 extensible variants of the messages; it is never used when
456 communicating with an RFC 1510 implementation.
458 2.7. Capability Negotiation
460 Kerberos is a three-party protocol. Each of the three parties
461 involved needs a means of detecting the capabilities supported by the
462 others. Two of the parties, the KDC and the application server, do
463 not communicate directly in the Kerberos protocol. Communicating
464 capabilities from the KDC to the application server requires using a
465 ticket as an intermediary.
467 The main capability requiring negotiation is the support of the
468 extensibility framework described in this document. Negotiation of
469 this capability while remaining compatible with RFC 1510
470 implementations is possible. The main complication is that the
471 client needs to know whether the application server supports the
472 extensibility framework prior to sending any message to the
473 application server. This can be accomplished if the KDC has
474 knowledge of whether an application server supports the extensibility
475 framework.
477 Client software advertizes its capabilities when requesting
478 credentials from the KDC. If the KDC recognizes the capabilities, it
479 acknowledges this fact to the client in its reply. In addition, if
480 the KDC has knowledge that the application server supports certain
481 capabilities, it also communicates this knowledge to the client in
482 its reply. The KDC can encode its own capabilities in the ticket so
483 that the application server may discover these capabilities. The
484 client advertizes its capabilities to the application server when it
485 initiates authentication to the application server.
487 2.7.1. KDC protocol
489 A client may send an AS-REQ-EXT if it has prior knowledge that the
490 KDC in question will accept it. (possibly via a TCP extension?)
491 Otherwise, the client will send an AS-REQ-1510 with the AS-REQ-EXT
492 inside preauthentication data. The client will always know whether
493 to send TGS-REQ-EXT because (as in the application protocol) it knows
494 the type of the associated Ticket. (Note: could be a problem with
495 non-TGT tickets)
497 The KDC will send AS-REP-EXT or TGS-REP-EXT if the client's message
498 is extensible; otherwise, it will send AS-REP-1510 or TGS-REP-1510.
499 The Ticket contained within the AS-REP-EXT or TGS-REP-EXT will be a
500 TicketExt if the application server supports it; otherwise, it will
501 be a Ticket1510. AS-REP-1510 and TGS-REP-1510 always contain a
503 Yu Expires: Sep 2007 [Page 9]
504 \f
505 Internet-Draft rfc1510ter-04 05 Mar 2007
507 Ticket1510. The EncTicketPart will depend on the server's
508 capability; the client cannot distinguish EncTicketPart1510 from
509 EncTicketPartExt.
511 KDCs within a realm should be uniform in advertized capability for
512 extensible messages. A KDC SHOULD only issue a TicketExt TGT if all
513 KDCs support it. Similarly, a client receiving a TicketExt knows
514 that all instances of the application service will accept extensible
515 messages.
517 2.7.2. Application protocol
519 The client knows whether the application server supports AP-REQ-EXT
520 because it can distinguish Ticket1510 from TicketExt. The server
521 knows the client's capability due to the format of the AP-REQ.
523 2.8. Strings
525 Some implementations of RFC 1510 do not limit princpal names and
526 realm names to ASCII characters. As a result, migration difficulties
527 resulting from legacy non-ASCII principal and realm names can arise.
528 Is it reasonable to assume that any legacy non-ASCII character can be
529 uniquely represented in Unicode?
531 This may result in a situation where various parties of the protocol
532 need to know alternate, possibly multiple, legacy non-ASCII names for
533 principals and also to know how they map into Unicode. An
534 application server needs to know all possible legacy encodings of its
535 name if it receives a "mixed" ticket. (Ticket1510 containing
536 EncTicketPartExt) It also needs to be able to compare a legacy
537 encoding of a client principal against the normalized UTF-8 encoding
538 when checking the client's principal name in the Authenticator
539 against the one contained in the EncTicketPart. This check can be
540 avoided if the application protocol does not require a replay cache.
542 3. Use of ASN.1 in Kerberos
544 Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690].
545 Even though ASN.1 theoretically allows the description of protocol
546 messages to be independent of the encoding rules used to encode the
547 messages, Kerberos messages MUST be encoded with DER. Subtleties in
548 the semantics of the notation, such as whether tags carry any
549 semantic content to the application, may cause the use of other ASN.1
550 encoding rules to be problematic.
552 Implementors not using existing ASN.1 tools (e.g., compilers or
553 support libraries) are cautioned to thoroughly read and understand
554 the actual ASN.1 specification to ensure correct implementation
555 behavior. There is more complexity in the notation than is
556 immediately obvious, and some tutorials and guides to ASN.1 are
557 misleading or erroneous. Recommended tutorials and guides include
559 Yu Expires: Sep 2007 [Page 10]
560 \f
561 Internet-Draft rfc1510ter-04 05 Mar 2007
563 [Dub00], [Lar99], though there is still no substitute for reading the
564 actual ASN.1 specification.
566 3.1. Module Header
568 The type definitions in this document assume an ASN.1 module
569 definition of the following form:
571 KerberosV5Spec3 {
572 iso(1) identified-organization(3) dod(6) internet(1)
573 security(5) kerberosV5(2) modules(4) krb5spec3(4)
574 } DEFINITIONS EXPLICIT TAGS ::= BEGIN
576 -- Rest of definitions here
578 END
580 This specifies that the tagging context for the module will be
581 explicit and that automatic tagging is not done.
583 Some other publications [RFC1510] [RFC1964] erroneously specify an
584 object identifier (OID) having an incorrect value of "5" for the
585 "dod" component of the OID. In the case of RFC 1964, use of the
586 "correct" OID value would result in a change in the wire protocol;
587 therefore, the RFC 1964 OID remains unchanged for now.
589 3.2. Top-Level Type
591 The ASN.1 type "KRB-PDU" is a CHOICE over all the types (Protocol
592 Data Units or PDUs) which an application may directly reference.
593 Applications SHOULD NOT transmit any types other than those which are
594 alternatives of the KRB-PDU CHOICE.
615 Yu Expires: Sep 2007 [Page 11]
616 \f
617 Internet-Draft rfc1510ter-04 05 Mar 2007
619 -- top-level type
620 --
621 -- Applications should not directly reference any types
622 -- other than KRB-PDU and its component types.
623 --
624 KRB-PDU ::= CHOICE {
625 ticket Ticket,
626 as-req AS-REQ,
627 as-rep AS-REP,
628 tgs-req TGS-REQ,
629 tgs-rep TGS-REP,
630 ap-req AP-REQ,
631 ap-rep AP-REP,
632 krb-safe KRB-SAFE,
633 krb-priv KRB-PRIV,
634 krb-cred KRB-CRED,
635 tgt-req TGT-REQ,
636 krb-error KRB-ERROR,
637 ...
638 }
641 3.3. Previously Unused ASN.1 Notation (informative)
643 Some aspects of ASN.1 notation used in this document were not used in
644 [RFC4120], and may be unfamiliar to some readers. This subsection is
645 informative; for normative definitions of the notation, see the
646 actual ASN.1 specifications [X680], [X682], [X683].
648 3.3.1. Parameterized Types
650 This document uses ASN.1 parameterized types [X683] to make
651 definitions of types more readable. For some types, some or all of
652 the parameters are advisory, i.e., they are not encoded in any form
653 for transmission in a protocol message. These advisory parameters
654 can describe implementation behavior associated with the type.
656 3.3.2. Constraints
658 This document uses ASN.1 constraints, including the
659 "UserDefinedConstraint" notation [X682]. Some constraints can be
660 handled automatically by tools that can parse them. Uses of the
661 "UserDefinedConstraint" notation (the "CONSTRAINED BY" notation) will
662 typically need to have behavior manually coded; the notation provides
663 a formalized way of conveying intended implementation behavior.
665 The "WITH COMPONENTS" constraint notation allows constraints to apply
666 to component types of a SEQUENCE type. This constraint notation
667 effectively allows constraints to "reach into" a type to constrain
668 its component types.
671 Yu Expires: Sep 2007 [Page 12]
672 \f
673 Internet-Draft rfc1510ter-04 05 Mar 2007
675 3.4. New Types
677 This document defines a number of ASN.1 types which are new since
678 [RFC4120]. The names of these types will typically have a suffix
679 like "Ext", indicating that the types are intended to support
680 extensibility. Types original to RFC 1510 and [RFC4120] have been
681 renamed to have a suffix like "1510". The "Ext" and "1510" types
682 often contain a number of common elements, but differ primarily in
683 the way strings are encoded.
685 4. Basic Types
687 These "basic" Kerberos ASN.1 types appear in multiple other Kerberos
688 types.
690 4.1. Constrained Integer Types
692 In RFC 1510, many types contained references to the unconstrained
693 INTEGER type. Since an unconstrained INTEGER can contain almost any
694 possible abstract integer value, most of the unconstrained references
695 to INTEGER in RFC 1510 were constrained to 32 bits or smaller in
696 [RFC4120].
698 -- signed values representable in 32 bits
699 --
700 -- These are often used as assigned numbers for various things.
701 Int32 ::= INTEGER (-2147483648..2147483647)
703 The "Int32" type often contains an assigned number identifying the
704 contents of a typed hole. Unless otherwise stated, non-negative
705 values are registered, and negative values are available for local
706 use.
708 -- unsigned 32 bit values
709 UInt32 ::= INTEGER (0..4294967295)
711 The "UInt32" type is used in some places where an unsigned 32-bit
712 integer is needed.
714 -- unsigned 64 bit values
715 UInt64 ::= INTEGER (0..18446744073709551615)
717 The "UInt64" type is used in places where 32 bits of precision may
718 provide inadequate security.
720 -- sequence numbers
721 SeqNum ::= UInt64
723 Sequence numbers were constrained to 32 bits in [RFC4120], but this
724 document allows for 64-bit sequence numbers.
727 Yu Expires: Sep 2007 [Page 13]
728 \f
729 Internet-Draft rfc1510ter-04 05 Mar 2007
731 -- nonces
732 Nonce ::= UInt64
734 Likewise, nonces were constrained to 32 bits in [RFC4120], but
735 expanded to 64 bits here.
737 -- microseconds
738 Microseconds ::= INTEGER (0..999999)
740 The "microseconds" type is intended to carry the microseconds part of
741 a time value.
743 4.2. KerberosTime
745 KerberosTime ::= GeneralizedTime (CONSTRAINED BY {
746 -- MUST NOT include fractional seconds
747 })
749 The timestamps used in Kerberos are encoded as GeneralizedTimes. A
750 KerberosTime value MUST NOT include any fractional portions of the
751 seconds. As required by the DER, it further MUST NOT include any
752 separators, and it specifies the UTC time zone (Z). Example: The
753 only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
754 November 1985 is "19851106210627Z".
756 4.3. KerberosString
758 -- used for names and for error messages
759 KerberosString ::= CHOICE {
760 ia5 GeneralString (IA5String),
761 utf8 UTF8String,
762 ... -- no extension may be sent
763 -- to an rfc1510 implementation --
764 }
766 The KerberosString type is used for character strings in various
767 places in the Kerberos protocol. For compatibility with RFC 1510,
768 GeneralString values constrained to IA5String (US-ASCII) are
769 permitted in messages exchanged with RFC 1510 implementations. The
770 new protocol messages contain strings encoded as UTF-8, and these
771 strings MUST be normalized using [RFC4013]. KerberosString values
772 are present in principal names and in error messages. Control
773 characters SHOULD NOT be used in principal names, and used with
774 caution in error messages.
783 Yu Expires: Sep 2007 [Page 14]
784 \f
785 Internet-Draft rfc1510ter-04 05 Mar 2007
787 -- IA5 choice only; useful for constraints
788 KerberosStringIA5 ::= KerberosString
789 (WITH COMPONENTS { ia5 PRESENT })
791 -- IA5 excluded; useful for constraints
792 KerberosStringExt ::= KerberosString
793 (WITH COMPONENTS { ia5 ABSENT })
795 KerberosStringIA5 requires the use of the "ia5" alternative, while
796 KerberosStringExt forbids it. These types appear in ASN.1
797 constraints on messages.
799 For detailed background regarding the history of character string use
800 in Kerberos, as well as discussion of some compatibility issues, see
801 Appendix B.
803 4.4. Language Tags
805 -- used for language tags
806 LangTag ::= PrintableString
807 (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
809 The "LangTag" type is used to specify language tags for localization
810 purposes, using the [RFC4646] format.
812 4.5. KerberosFlags
814 For several message types, a specific constrained bit string type,
815 KerberosFlags, is used.
817 KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
818 (CONSTRAINED BY {
819 -- MUST be a valid value of -- NamedBits
821 -- but if the value to be sent would be truncated to
822 -- shorter than 32 bits according to DER, the value MUST be
823 -- padded with trailing zero bits to 32 bits. Otherwise,
824 -- no trailing zero bits may be present.
826 })
829 The actual bit string type encoded in Kerberos messages does not use
830 named bits. The advisory parameter of the KerberosFlags type names a
831 bit string type defined using named bits, whose value is encoded as
832 if it were a bit string with unnamed bits. This practice is
833 necessary because the DER require trailing zero bits to be removed
834 when encoding bit strings defined using named bits. Existing
835 implementations of Kerberos send exactly 32 bits rather than
836 truncating, so the size constraint requires the transmission of at
837 least 32 bits. Trailing zero bits beyond the first 32 bits are
839 Yu Expires: Sep 2007 [Page 15]
840 \f
841 Internet-Draft rfc1510ter-04 05 Mar 2007
843 truncated.
845 4.6. Typed Holes
847 -- Typed hole identifiers
848 TH-id ::= CHOICE {
849 int32 Int32,
850 rel-oid RELATIVE-OID
851 }
853 The "TH-id" type is a generalized means to identify the contents of a
854 typed hole. The "int32" alternative may be used for simple integer
855 assignments, in the same manner as "Int32", while the "rel-oid"
856 alternative may be used for hierarchical delegation.
858 4.7. HostAddress and HostAddresses
860 AddrType ::= Int32
862 HostAddress ::= SEQUENCE {
863 addr-type [0] AddrType,
864 address [1] OCTET STRING
865 }
867 -- NOTE: HostAddresses is always used as an OPTIONAL field and
868 -- should not be a zero-length SEQUENCE OF.
869 --
870 -- The extensible messages explicitly constrain this to be
871 -- non-empty.
872 HostAddresses ::= SEQUENCE OF HostAddress
875 addr-type
876 This field specifies the type of address that follows.
878 address
879 This field encodes a single address of the type identified by
880 "addr-type".
882 All negative values for the host address type are reserved for local
883 use. All non-negative values are reserved for officially assigned
884 type fields and interpretations.
895 Yu Expires: Sep 2007 [Page 16]
896 \f
897 Internet-Draft rfc1510ter-04 05 Mar 2007
900 addr-type | meaning
901 __________|______________
902 2 | IPv4
903 3 | directional
904 12 | DECnet
905 20 | NetBIOS
906 24 | IPv6
910 4.7.1. Internet (IPv4) Addresses
912 Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in
913 MSB order (most significant byte first). The IPv4 loopback address
914 SHOULD NOT appear in a Kerberos PDU. The type of IPv4 addresses is
915 two (2).
917 4.7.2. Internet (IPv6) Addresses
919 IPv6 addresses [RFC4291] are 128-bit (16-octet) quantities, encoded
920 in MSB order (most significant byte first). The type of IPv6
921 addresses is twenty-four (24). The following addresses MUST NOT
922 appear in any Kerberos PDU:
924 * the Unspecified Address
926 * the Loopback Address
928 * Link-Local addresses
930 This restriction applies to the inclusion in the address fields of
931 Kerberos PDUs, but not to the address fields of packets that might
932 carry such PDUs. The restriction is necessary because the use of an
933 address with non-global scope could allow the acceptance of a message
934 sent from a node that may have the same address, but which is not the
935 host intended by the entity that added the restriction. If the
936 link-local address type needs to be used for communication, then the
937 address restriction in tickets must not be used (i.e. addressless
938 tickets must be used).
940 IPv4-mapped IPv6 addresses MUST be represented as addresses of type
941 2.
943 4.7.3. DECnet Phase IV addresses
945 DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order.
946 The type of DECnet Phase IV addresses is twelve (12).
951 Yu Expires: Sep 2007 [Page 17]
952 \f
953 Internet-Draft rfc1510ter-04 05 Mar 2007
955 4.7.4. Netbios addresses
957 Netbios addresses are 16-octet addresses typically composed of 1 to
958 15 alphanumeric characters and padded with the US-ASCII SPC character
959 (code 32). The 16th octet MUST be the US-ASCII NUL character (code
960 0). The type of Netbios addresses is twenty (20).
962 4.7.5. Directional Addresses
964 In many environments, including the sender address in KRB-SAFE and
965 KRB-PRIV messages is undesirable because the addresses may be changed
966 in transport by network address translators. However, if these
967 addresses are removed, the messages may be subject to a reflection
968 attack in which a message is reflected back to its originator. The
969 directional address type provides a way to avoid transport addresses
970 and reflection attacks. Directional addresses are encoded as four
971 byte unsigned integers in network byte order. If the message is
972 originated by the party sending the original AP-REQ message, then an
973 address of 0 SHOULD be used. If the message is originated by the
974 party to whom that AP-REQ was sent, then the address 1 SHOULD be
975 used. Applications involving multiple parties can specify the use of
976 other addresses.
978 Directional addresses MUST only be used for the sender address field
979 in the KRB-SAFE or KRB-PRIV messages. They MUST NOT be used as a
980 ticket address or in a AP-REQ message. This address type SHOULD only
981 be used in situations where the sending party knows that the
982 receiving party supports the address type. This generally means that
983 directional addresses may only be used when the application protocol
984 requires their support. Directional addresses are type (3).
986 5. Principals
988 Principals are participants in the Kerberos protocol. A "realm"
989 consists of principals in one administrative domain, served by one
990 KDC (or one replicated set of KDCs). Each principal name has an
991 arbitrary number of components, though typical principal names will
992 only have one or two components. A principal name is meant to be
993 readable by and meaningful to humans, especially in a realm lacking a
994 centrally adminstered authorization infrastructure.
996 5.1. Name Types
998 Each PrincipalName has NameType indicating what sort of name it is.
999 The name-type SHOULD be treated as a hint. Ignoring the name type,
1000 no two names can be the same (i.e., at least one of the components,
1001 or the realm, must be different).
1007 Yu Expires: Sep 2007 [Page 18]
1008 \f
1009 Internet-Draft rfc1510ter-04 05 Mar 2007
1011 -- assigned numbers for name types (used in principal names)
1012 NameType ::= Int32
1014 -- Name type not known
1015 nt-unknown NameType ::= 0
1016 -- Just the name of the principal as in DCE, or for users
1017 nt-principal NameType ::= 1
1018 -- Service and other unique instance (krbtgt)
1019 nt-srv-inst NameType ::= 2
1020 -- Service with host name as instance (telnet, rcommands)
1021 nt-srv-hst NameType ::= 3
1022 -- Service with host as remaining components
1023 nt-srv-xhst NameType ::= 4
1024 -- Unique ID
1025 nt-uid NameType ::= 5
1026 -- Encoded X.509 Distingished name [RFC 2253]
1027 nt-x500-principal NameType ::= 6
1028 -- Name in form of SMTP email name (e.g. user@foo.com)
1029 nt-smtp-name NameType ::= 7
1030 -- Enterprise name - may be mapped to principal name
1031 nt-enterprise NameType ::= 10
1032 -- reserved principal names [krb-wg-naming]
1033 nt-wellknown NameType ::= 11
1036 5.2. Principal Type Definition
1038 The "PrincipalName" type takes a parameter to constrain which string
1039 type it contains.
1041 PrincipalName { StrType } ::= SEQUENCE {
1042 name-type [0] NameType,
1043 -- May have zero elements, or individual elements may be
1044 -- zero-length, but this is NOT RECOMMENDED.
1045 name-string [1] SEQUENCE OF KerberosString (StrType)
1046 }
1049 The constrained types have their own names.
1051 -- IA5 only
1052 PrincipalNameIA5 ::= PrincipalName { KerberosStringIA5 }
1053 -- IA5 excluded
1054 PrincipalNameExt ::= PrincipalName { KerberosStringExt }
1055 -- Either one?
1056 PrincipalNameEither ::= PrincipalName { KerberosString }
1059 name-type
1060 hint of the type of name that follows
1063 Yu Expires: Sep 2007 [Page 19]
1064 \f
1065 Internet-Draft rfc1510ter-04 05 Mar 2007
1067 name-string
1068 The "name-string" encodes a sequence of components that form a
1069 name, each component encoded as a KerberosString. Taken
1070 together, a PrincipalName and a Realm form a principal
1071 identifier. Most PrincipalNames will have only a few components
1072 (typically one or two).
1074 5.3. Principal Name Reuse
1076 Realm administrators SHOULD use extreme caution when considering
1077 reusing a principal name. A service administrator might explicitly
1078 enter principal names into a local access control list (ACL) for the
1079 service. If such local ACLs exist independently of a centrally
1080 administered authorization infrastructure, realm administrators
1081 SHOULD NOT reuse principal names until confirming that all extant ACL
1082 entries referencing that principal name have been updated. Failure
1083 to perform this check can result in a security vulnerability, as a
1084 new principal can inadvertently inherit unauthorized privileges upon
1085 receiving a reused principal name. An organization whose Kerberos-
1086 authenticated services all use a centrally-adminstered authorization
1087 infrastructure may not need to take these precautions regarding
1088 principal name reuse.
1090 5.4. Best Common Practice Recommendations for the Processing of
1091 Principal Names Consisting of Internationalized Domain Names:
1093 Kerberos principals are often created for the purpose of
1094 authenticating a service located on a machine identified by an domain
1095 name. Unfortunately, once a principal name is created it is
1096 impossible to know the source from which the resulting KerberosString
1097 was derived. It is therefore required that principal names
1098 containing internationalized domain names be processed via the
1099 following procedure:
1101 * ensure that the IDN component must be a valid domain name as per
1102 the rules of IDNA [RFC3490]
1104 * separate the IDN component into labels separated by any of the
1105 Full Stop characters
1107 * fold all Full Stop characters to Full Stop (0x002E)
1109 * for each label (perform all steps):
1111 o if the label begins with an ACE prefix as registered with IANA,
1112 the prefix will be removed and the rest of the label will be
1113 converted from the ACE representation to Unicode [need
1114 reference]
1116 o if the label consists of one or more internationalized
1117 characters separately apply the NamePrep and then the SASLprep
1119 Yu Expires: Sep 2007 [Page 20]
1120 \f
1121 Internet-Draft rfc1510ter-04 05 Mar 2007
1123 string preparation methods.
1125 o if the label consists of zero internalizationalized characters,
1126 the label is to be lower-cased
1128 o if the output of the two methods match, continue on to the next
1129 label; otherwise reject the principal name as invalid
1131 * the result of a valid principal name component derived from an IDN
1132 is the joining of the individual string prepared labels separated
1133 by the Full Stop (0x002E)
1135 5.5. Realm Names
1137 Realm { StrType } ::= KerberosString (StrType)
1139 -- IA5 only
1140 RealmIA5 ::= Realm { KerberosStringIA5 }
1142 -- IA5 excluded
1143 RealmExt ::= Realm { KerberosStringExt }
1145 -- Either
1146 RealmEither ::= Realm { KerberosString }
1150 Kerberos realm names are KerberosStrings. Realms MUST NOT contain a
1151 character with the code 0 (the US-ASCII NUL). Most realms will
1152 usually consist of several components separated by periods (.), in
1153 the style of Internet Domain Names, or separated by slashes (/) in
1154 the style of X.500 names.
1156 5.6. Best Common Practice Recommendations for the Processing of
1157 Internationalized Domain-Style Realm Names:
1159 Domain Style Realm names are defined as all realm names whose
1160 components are separated by Full Stop (0x002E) (aka periods, '.') and
1161 contain neither colons, name containing one or more internationalized
1162 characters (not included in US-ASCII), this procedure must be used:
1164 * the realm name must be a valid domain name as per the rules of
1165 IDNA [RFC3490]
1167 * the following string preparation routine must be followed:
1169 - separate the string into components separated by any of the
1170 Full Stop characters
1172 - fold all Full Stop characters to Full Stop (0x002E)
1175 Yu Expires: Sep 2007 [Page 21]
1176 \f
1177 Internet-Draft rfc1510ter-04 05 Mar 2007
1179 - for each component (perform all steps):
1181 o if the component begins with an ACE prefix as registered
1182 with IANA, the prefix will be removed and the rest of the
1183 component will be converted from the ACE representation to
1184 Unicode [need reference]
1186 o if the component consists of one or more internationalized
1187 characters separately apply the NamePrep and SASLprep string
1188 preparation methods.
1190 if the output of the two methods match, continue on to the
1191 next component; otherwise reject the realm name as invalid
1193 - the result of a valid realm name is the joining of the
1194 individual string prepared components separated by the Full
1195 Stop (0x002E)
1197 In [RFC4120], the recommendation is that all domain style realm names
1198 be represented in uppercase. This recommendation is modified in the
1199 following manner. All components of domain style realm names not
1200 including internationalized characters should be upper-cased. All
1201 components of domain style realm names including internationalized
1202 characters must be lower-cased. (The lower case representation of
1203 internationalized components is enforced by the requirement that the
1204 output of NamePrep and StringPrep string preparation must be
1205 equivalent.)
1207 5.7. Printable Representations of Principal Names
1209 [ perhaps non-normative? ]
1211 The printable form of a principal name consists of the concatenation
1212 of components of the PrincipalName value using the slash character
1213 (/), followed by an at-sign (@), followed by the realm name. Any
1214 occurrence of a backslash (\), slash (/) or at-sign (@) in the
1215 PrincipalName value is quoted by a backslash.
1217 5.8. Ticket-Granting Service Principal
1219 The PrincipalName value corresponding to a ticket-granting service
1220 has two components: the first component is the string "krbtgt", and
1221 the second component is the realm name of the TGS which will accept a
1222 ticket-granting ticket having this service principal name. The realm
1223 name of service always indicates which realm issued the ticket. A
1224 ticket-granting ticket issued by "A.EXAMPLE.COM" which is valid for
1225 obtaining tickets in the same realm would have the following ASN.1
1226 values for its "realm" and "sname" components, respectively:
1231 Yu Expires: Sep 2007 [Page 22]
1232 \f
1233 Internet-Draft rfc1510ter-04 05 Mar 2007
1235 -- Example Realm and PrincipalName for a TGS
1237 tgtRealm1 Realm ::= ia5 : "A.EXAMPLE.COM"
1239 tgtPrinc1 PrincipalName ::= {
1240 name-type nt-srv-inst,
1241 name-string { ia5 : "krbtgt", ia5 : "A.EXAMPLE.COM" }
1242 }
1244 Its printable representation would be written as
1245 "krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM".
1247 5.8.1. Cross-Realm TGS Principals
1249 It is possible for a principal in one realm to authenticate to a
1250 service in another realm. A KDC can issue a cross-realm ticket-
1251 granting ticket to allow one of its principals to authenticate to a
1252 service in a foreign realm. For example, the TGS principal
1253 "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" is a principal that permits a
1254 client principal in the realm A.EXAMPLE.COM to authenticate to a
1255 service in the realm B.EXAMPLE.COM. When the KDC for B.EXAMPLE.COM
1256 issues a ticket to a client originating in A.EXAMPLE.COM, the
1257 client's realm name remains "A.EXAMPLE.COM", even though the service
1258 principal will have the realm "B.EXAMPLE.COM".
1260 6. Types Relating to Encryption
1262 Many Kerberos protocol messages contain encrypted encodings of
1263 various data types. Some Kerberos protocol messages also contain
1264 checksums (signatures) of encodings of various types.
1266 6.1. Assigned Numbers for Encryption
1268 Encryption algorithm identifiers and key usages both have assigned
1269 numbers, described in [RFC3961].
1271 6.1.1. EType
1273 EType is the integer type for assigned numbers for encryption
1274 algorithms. Defined in [RFC3961].
1287 Yu Expires: Sep 2007 [Page 23]
1288 \f
1289 Internet-Draft rfc1510ter-04 05 Mar 2007
1291 -- Assigned numbers denoting encryption mechanisms.
1292 EType ::= Int32
1294 -- assigned numbers for encryption schemes
1295 et-des-cbc-crc EType ::= 1
1296 et-des-cbc-md4 EType ::= 2
1297 et-des-cbc-md5 EType ::= 3
1298 -- [reserved] 4
1299 et-des3-cbc-md5 EType ::= 5
1300 -- [reserved] 6
1301 et-des3-cbc-sha1 EType ::= 7
1302 et-dsaWithSHA1-CmsOID EType ::= 9
1303 et-md5WithRSAEncryption-CmsOID EType ::= 10
1304 et-sha1WithRSAEncryption-CmsOID EType ::= 11
1305 et-rc2CBC-EnvOID EType ::= 12
1306 et-rsaEncryption-EnvOID EType ::= 13
1307 et-rsaES-OAEP-ENV-OID EType ::= 14
1308 et-des-ede3-cbc-Env-OID EType ::= 15
1309 et-des3-cbc-sha1-kd EType ::= 16
1310 -- AES
1311 et-aes128-cts-hmac-sha1-96 EType ::= 17
1312 -- AES
1313 et-aes256-cts-hmac-sha1-96 EType ::= 18
1314 -- Microsoft
1315 et-rc4-hmac EType ::= 23
1316 -- Microsoft
1317 et-rc4-hmac-exp EType ::= 24
1318 -- opaque; PacketCable
1319 et-subkey-keymaterial EType ::= 65
1322 6.1.2. Key Usages
1324 KeyUsage is the integer type for assigned numbers for key usages.
1325 Key usage values are inputs to the encryption and decryption
1326 functions described in [RFC3961].
1343 Yu Expires: Sep 2007 [Page 24]
1344 \f
1345 Internet-Draft rfc1510ter-04 05 Mar 2007
1347 -- Assigned numbers denoting key usages.
1348 KeyUsage ::= UInt32
1350 --
1351 -- Actual identifier names are provisional and subject to
1352 -- change.
1353 --
1354 ku-pa-enc-ts KeyUsage ::= 1
1355 ku-Ticket KeyUsage ::= 2
1356 ku-EncASRepPart KeyUsage ::= 3
1357 ku-TGSReqAuthData-sesskey KeyUsage ::= 4
1358 ku-TGSReqAuthData-subkey KeyUsage ::= 5
1359 ku-pa-TGSReq-cksum KeyUsage ::= 6
1360 ku-pa-TGSReq-authenticator KeyUsage ::= 7
1361 ku-EncTGSRepPart-sesskey KeyUsage ::= 8
1362 ku-EncTGSRepPart-subkey KeyUsage ::= 9
1363 ku-Authenticator-cksum KeyUsage ::= 10
1364 ku-APReq-authenticator KeyUsage ::= 11
1365 ku-EncAPRepPart KeyUsage ::= 12
1366 ku-EncKrbPrivPart KeyUsage ::= 13
1367 ku-EncKrbCredPart KeyUsage ::= 14
1368 ku-KrbSafe-cksum KeyUsage ::= 15
1369 ku-ad-KDCIssued-cksum KeyUsage ::= 19
1399 Yu Expires: Sep 2007 [Page 25]
1400 \f
1401 Internet-Draft rfc1510ter-04 05 Mar 2007
1403 -- The following numbers are provisional...
1404 -- conflicts may exist elsewhere.
1405 ku-Ticket-cksum KeyUsage ::= 29
1406 ku-ASReq-cksum KeyUsage ::= 30
1407 ku-TGSReq-cksum KeyUsage ::= 31
1408 ku-ASRep-cksum KeyUsage ::= 32
1409 ku-TGSRep-cksum KeyUsage ::= 33
1410 ku-APReq-cksum KeyUsage ::= 34
1411 ku-APRep-cksum KeyUsage ::= 35
1412 ku-KrbCred-cksum KeyUsage ::= 36
1413 ku-KrbError-cksum KeyUsage ::= 37
1414 ku-KDCRep-cksum KeyUsage ::= 38
1416 ku-kg-acceptor-seal KeyUsage ::= 22
1417 ku-kg-acceptor-sign KeyUsage ::= 23
1418 ku-kg-intiator-seal KeyUsage ::= 24
1419 ku-kg-intiator-sign KeyUsage ::= 25
1421 -- KeyUsage values 25..27 used by hardware preauth?
1423 -- for KINK
1424 ku-kink-encrypt KeyUsage ::= 39
1425 ku-kink-cksum KeyUsage ::= 40
1427 -- IAKERB
1428 ku-iakerb-finished KeyUsage ::= 41
1432 6.2. Which Key to Use
1455 Yu Expires: Sep 2007 [Page 26]
1456 \f
1457 Internet-Draft rfc1510ter-04 05 Mar 2007
1459 -- KeyToUse identifies which key is to be used to encrypt or
1460 -- sign a given value.
1461 --
1462 -- Values of KeyToUse are never actually transmitted over the
1463 -- wire, or even used directly by the implementation in any
1464 -- way, as key usages are; it exists primarily to identify
1465 -- which key gets used for what purpose. Thus, the specific
1466 -- numeric values associated with this type are irrelevant.
1467 KeyToUse ::= ENUMERATED {
1468 -- unspecified
1469 key-unspecified,
1470 -- server long term key
1471 key-server,
1472 -- client long term key
1473 key-client,
1474 -- key selected by KDC for encryption of a KDC-REP
1475 key-kdc-rep,
1476 -- session key from ticket
1477 key-session,
1478 -- subsession key negotiated via AP-REQ/AP-REP
1479 key-subsession,
1480 ...
1481 }
1484 6.3. EncryptionKey
1486 The "EncryptionKey" type holds an encryption key.
1488 EncryptionKey ::= SEQUENCE {
1489 keytype [0] EType,
1490 keyvalue [1] OCTET STRING
1491 }
1494 keytype
1495 This "EType" identifies the encryption algorithm, described in
1496 [RFC3961].
1498 keyvalue
1499 Contains the actual key.
1501 6.4. EncryptedData
1503 The "EncryptedData" type contains the encryption of another data
1504 type. The recipient uses fields within EncryptedData to determine
1505 which key to use for decryption.
1511 Yu Expires: Sep 2007 [Page 27]
1512 \f
1513 Internet-Draft rfc1510ter-04 05 Mar 2007
1516 -- "Type" specifies which ASN.1 type is encrypted to the
1517 -- ciphertext in the EncryptedData. "Keys" specifies a set of
1518 -- keys of which one key may be used to encrypt the data.
1519 -- "KeyUsages" specifies a set of key usages, one of which may
1520 -- be used to encrypt.
1521 --
1522 -- None of the parameters is transmitted over the wire.
1523 EncryptedData {
1524 Type, KeyToUse:Keys, KeyUsage:KeyUsages
1525 } ::= SEQUENCE {
1526 etype [0] EType,
1527 kvno [1] UInt32 OPTIONAL,
1528 cipher [2] OCTET STRING (CONSTRAINED BY {
1529 -- must be encryption of --
1530 OCTET STRING (CONTAINING Type),
1531 -- with one of the keys -- KeyToUse:Keys,
1532 -- with key usage being one of --
1533 KeyUsage:KeyUsages
1534 }),
1535 ...
1536 }
1540 KeyUsages
1541 Advisory parameter indicating which key usage to use when
1542 encrypting the ciphertext. If "KeyUsages" indicate multiple
1543 "KeyUsage" values, the detailed description of the containing
1544 message will indicate which key to use under which conditions.
1546 Type
1547 Advisory parameter indicating the ASN.1 type whose DER encoding
1548 is the plaintext encrypted into the EncryptedData.
1550 Keys
1551 Advisory parameter indicating which key to use to perform the
1552 encryption. If "Keys" indicate multiple "KeyToUse" values, the
1553 detailed description of the containing message will indicate
1554 which key to use under which conditions.
1556 KeyUsages
1557 Advisory parameter indicating which "KeyUsage" value is used to
1558 encrypt. If "KeyUsages" indicates multiple "KeyUsage" values,
1559 the detailed description of the containing message will indicate
1560 which key usage to use under which conditions.
1562 6.5. Checksums
1564 Several types contain checksums (actually signatures) of data.
1567 Yu Expires: Sep 2007 [Page 28]
1568 \f
1569 Internet-Draft rfc1510ter-04 05 Mar 2007
1571 CksumType ::= Int32
1573 -- The parameters specify which key to use to produce the
1574 -- signature, as well as which key usage to use. The
1575 -- parameters are not actually sent over the wire.
1576 Checksum {
1577 KeyToUse:Keys, KeyUsage:KeyUsages
1578 } ::= SEQUENCE {
1579 cksumtype [0] CksumType,
1580 checksum [1] OCTET STRING (CONSTRAINED BY {
1581 -- signed using one of the keys --
1582 KeyToUse:Keys,
1583 -- with key usage being one of --
1584 KeyUsage:KeyUsages
1585 })
1586 }
1589 CksumType
1590 Integer type for assigned numbers for signature algorithms.
1591 Defined in [RFC3961]
1593 Keys
1594 As in EncryptedData
1596 KeyUsages
1597 As in EncryptedData
1599 cksumtype
1600 Signature algorithm used to produce the signature.
1602 checksum
1603 The actual checksum.
1605 6.5.1. ChecksumOf
1607 ChecksumOf is similar to "Checksum", but specifies which type is
1608 signed.
1610 -- a Checksum that must contain the checksum
1611 -- of a particular type
1612 ChecksumOf {
1613 Type, KeyToUse:Keys, KeyUsage:KeyUsages
1614 } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
1615 ...,
1616 checksum (CONSTRAINED BY {
1617 -- must be checksum of --
1618 OCTET STRING (CONTAINING Type)
1619 })
1620 })
1623 Yu Expires: Sep 2007 [Page 29]
1624 \f
1625 Internet-Draft rfc1510ter-04 05 Mar 2007
1627 Type
1628 Indicates the ASN.1 type whose DER encoding is signed.
1630 6.5.2. Signed
1632 Signed is similar to "ChecksumOf", but contains an actual instance of
1633 the type being signed in addition to the signature.
1635 -- parameterized type for wrapping authenticated plaintext
1636 Signed {
1637 InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
1638 } ::= SEQUENCE {
1639 cksum [0] ChecksumOf {
1640 InnerType, Keys, KeyUsages
1641 } OPTIONAL,
1642 inner [1] InnerType,
1643 ...
1644 }
1647 7. Tickets
1649 [ A large number of items described here are duplicated in the
1650 sections describing KDC-REQ processing. Should find a way to avoid
1651 this duplication. ]
1653 A ticket binds a principal name to a session key. The important
1654 fields of a ticket are in the encrypted part.
1656 -- Encrypted part of ticket
1657 EncTicketPart ::= CHOICE {
1658 rfc1510 EncTicketPart1510,
1659 ext EncTicketPartExt
1660 }
1663 EncTicketPart1510 ::= [APPLICATION 3] SEQUENCE {
1664 flags [0] TicketFlags,
1665 key [1] EncryptionKey,
1666 crealm [2] RealmIA5,
1667 cname [3] PrincipalNameIA5,
1668 transited [4] TransitedEncoding,
1669 authtime [5] KerberosTime,
1670 starttime [6] KerberosTime OPTIONAL,
1671 endtime [7] KerberosTime,
1672 renew-till [8] KerberosTime OPTIONAL,
1673 caddr [9] HostAddresses OPTIONAL,
1674 authorization-data [10] AuthorizationData OPTIONAL
1675 }
1679 Yu Expires: Sep 2007 [Page 30]
1680 \f
1681 Internet-Draft rfc1510ter-04 05 Mar 2007
1683 EncTicketPartExt ::= [APPLICATION 5] SEQUENCE {
1684 flags [0] TicketFlags,
1685 key [1] EncryptionKey,
1686 crealm [2] RealmExt,
1687 cname [3] PrincipalNameExt,
1688 transited [4] TransitedEncoding,
1689 authtime [5] KerberosTime,
1690 starttime [6] KerberosTime OPTIONAL,
1691 endtime [7] KerberosTime,
1692 renew-till [8] KerberosTime OPTIONAL,
1693 caddr [9] HostAddresses OPTIONAL,
1694 authorization-data [10] AuthorizationData OPTIONAL,
1695 ...,
1696 }
1699 crealm
1700 This field contains the client's realm.
1702 cname
1703 This field contains the client's name.
1705 caddr
1706 This field lists the network addresses (if absent, all addresses
1707 are permitted) from which the ticket is valid.
1709 Descriptions of the other fields appear in the following sections.
1711 7.1. Timestamps
1713 Three of the ticket timestamps may be requested from the KDC. The
1714 timestamps may differ from those requested, depending on site policy.
1716 authtime
1717 The time at which the client authenticated, as recorded by the
1718 KDC.
1720 starttime
1721 The earliest time when the ticket is valid. If not present, the
1722 ticket is valid starting at the authtime. This is requested as
1723 the "from" field of KDC-REQ-BODY.
1725 endtime
1726 This time is requested in the "till" field of KDC-REQ-BODY.
1727 Contains the time after which the ticket will not be honored
1728 (its expiration time). Note that individual services MAY place
1729 their own limits on the life of a ticket and MAY reject tickets
1730 which have not yet expired. As such, this is really an upper
1731 bound on the expiration time for the ticket.
1735 Yu Expires: Sep 2007 [Page 31]
1736 \f
1737 Internet-Draft rfc1510ter-04 05 Mar 2007
1739 renew-till
1740 This time is requested in the "rtime" field of KDC-REQ-BODY. It
1741 is only present in tickets that have the "renewable" flag set in
1742 the flags field. It indicates the maximum endtime that may be
1743 included in a renewal. It can be thought of as the absolute
1744 expiration time for the ticket, including all renewals.
1746 7.2. Ticket Flags
1748 A number of flags may be set in the ticket, further defining some of
1749 its capabilities. Some of these flags map to flags in a KDC request.
1751 TicketFlags ::= KerberosFlags { TicketFlagsBits }
1753 TicketFlagsBits ::= BIT STRING {
1754 reserved (0),
1755 forwardable (1),
1756 forwarded (2),
1757 proxiable (3),
1758 proxy (4),
1759 may-postdate (5),
1760 postdated (6),
1761 invalid (7),
1762 renewable (8),
1763 initial (9),
1764 pre-authent (10),
1765 hw-authent (11),
1766 transited-policy-checked (12),
1767 ok-as-delegate (13),
1768 anonymous (14),
1769 cksummed-ticket (15)
1770 }
1773 7.2.1. Flags Relating to Initial Ticket Acquisition
1775 [ adapted RFC4120 2.1. ]
1777 Several flags indicate the details of how the initial ticket was
1778 acquired.
1780 initial
1781 The "initial" flag indicates that a ticket was issued using the
1782 AS protocol, rather than issued based on a ticket-granting
1783 ticket. Application servers (e.g., a password-changing program)
1784 requiring a client's definite knowledge of its secret key can
1785 insist that this flag be set in any tickets they accept, thus
1786 being assured that the client's key was recently presented to
1787 the application client.
1791 Yu Expires: Sep 2007 [Page 32]
1792 \f
1793 Internet-Draft rfc1510ter-04 05 Mar 2007
1795 pre-authent
1796 The "pre-authent" flag indicates that some sort of pre-
1797 authentication was used during the AS exchange.
1799 hw-authent
1800 The "hw-authent" flag indicates that some sort of hardware-based
1801 pre-authentication occurred during the AS exchange.
1803 Both the "pre-authent" and the "hw-authent" flags may be present with
1804 or without the "initial" flag; such tickets with the "initial" flag
1805 clear are ones which are derived from initial tickets with the "pre-
1806 authent" or "hw-authent" flags set.
1808 7.2.2. Invalid Tickets
1810 [ RFC4120 2.2. ]
1812 The "invalid" flag indicates that a ticket is invalid. Application
1813 servers MUST reject tickets which have this flag set. A postdated
1814 ticket will be issued in this form. Invalid tickets MUST be
1815 validated by the KDC before use, by presenting them to the KDC in a
1816 TGS request with the "validate" option specified. The KDC will only
1817 validate tickets after their starttime has passed. The validation is
1818 required so that postdated tickets which have been stolen before
1819 their starttime can be rendered permanently invalid (through a hot-
1820 list mechanism -- see Section 8.3.2.4).
1822 7.2.3. OK as Delegate
1824 [ RFC4120 2.8. ]
1826 The "ok-as-delegate" flag provides a way for a KDC to communicate
1827 local realm policy to a client regarding whether the service for
1828 which the ticket is issued is trusted to accept delegated
1829 credentials. For some applications, a client may need to delegate
1830 credentials to a service to act on its behalf in contacting other
1831 services. The ability of a client to obtain a service ticket for a
1832 service conveys no information to the client about whether the
1833 service should be trusted to accept delegated credentials.
1835 The copy of the ticket flags visible to the client may have the "ok-
1836 as-delegate" flag set to indicate to the client that the service
1837 specified in the ticket has been determined by policy of the realm to
1838 be a suitable recipient of delegation. A client can use the presence
1839 of this flag to help it make a decision whether to delegate
1840 credentials (either grant a proxy or a forwarded ticket-granting
1841 ticket) to this service. It is acceptable to ignore the value of
1842 this flag. When setting this flag, an administrator should consider
1843 the security and placement of the server on which the service will
1844 run, as well as whether the service requires the use of delegated
1845 credentials.
1847 Yu Expires: Sep 2007 [Page 33]
1848 \f
1849 Internet-Draft rfc1510ter-04 05 Mar 2007
1851 7.2.4. Renewable Tickets
1853 [ adapted RFC4120 2.3. ]
1855 The "renewable" flag indicates whether the ticket may be renewed.
1857 Renewable tickets can be used to mitigate the consequences of ticket
1858 theft. Applications may desire to hold credentials which can be
1859 valid for long periods of time. However, this can expose the
1860 credentials to potential theft for equally long periods, and those
1861 stolen credentials would be valid until the expiration time of the
1862 ticket(s). Simply using short-lived tickets and obtaining new ones
1863 periodically would require the application to have long-term access
1864 to the client's secret key, which is an even greater risk.
1866 Renewable tickets have two "expiration times": the first is when the
1867 current instance of the ticket expires, and the second is the latest
1868 permissible value for an individual expiration time. An application
1869 client must periodically present an unexpired renewable ticket to the
1870 KDC, setting the "renew" option in the KDC request. The KDC will
1871 issue a new ticket with a new session key and a later expiration
1872 time. All other fields of the ticket are left unmodified by the
1873 renewal process. When the latest permissible expiration time
1874 arrives, the ticket expires permanently. At each renewal, the KDC
1875 MAY consult a hot-list to determine if the ticket had been reported
1876 stolen since its last renewal; it will refuse to renew such stolen
1877 tickets, and thus the usable lifetime of stolen tickets is reduced.
1879 The "renewable" flag in a ticket is normally only interpreted by the
1880 ticket-granting service. It can usually be ignored by application
1881 servers. However, some particularly careful application servers MAY
1882 disallow renewable tickets.
1884 If a renewable ticket is not renewed by its expiration time, the KDC
1885 will not renew the ticket. The "renewable" flag is clear by default,
1886 but a client can request it be set by setting the "renewable" option
1887 in the AS-REQ message. If it is set, then the "renew-till" field in
1888 the ticket contains the time after which the ticket may not be
1889 renewed.
1891 7.2.5. Postdated Tickets
1893 postdated
1894 indicates a ticket which has been postdated
1896 may-postdate
1897 indicates that postdated tickets may be issued based on this
1898 ticket
1900 [ RFC4120 2.4. ]
1903 Yu Expires: Sep 2007 [Page 34]
1904 \f
1905 Internet-Draft rfc1510ter-04 05 Mar 2007
1907 Applications may occasionally need to obtain tickets for use much
1908 later, e.g., a batch submission system would need tickets to be valid
1909 at the time the batch job is serviced. However, it is dangerous to
1910 hold valid tickets in a batch queue, since they will be on-line
1911 longer and more prone to theft. Postdated tickets provide a way to
1912 obtain these tickets from the KDC at job submission time, but to
1913 leave them "dormant" until they are activated and validated by a
1914 further request of the KDC. If a ticket theft were reported in the
1915 interim, the KDC would refuse to validate the ticket, and the thief
1916 would be foiled.
1918 The "may-postdate" flag in a ticket is normally only interpreted by
1919 the TGS. It can be ignored by application servers. This flag MUST
1920 be set in a ticket-granting ticket in order for the KDC to issue a
1921 postdated ticket based on the presented ticket. It is reset by
1922 default; it MAY be requested by a client by setting the "allow-
1923 postdate" option in the AS-REQ [?also TGS-REQ?] message. This flag
1924 does not allow a client to obtain a postdated ticket-granting ticket;
1925 postdated ticket-granting tickets can only by obtained by requesting
1926 the postdating in the AS-REQ message. The life (endtime minus
1927 starttime) of a postdated ticket will be the remaining life of the
1928 ticket-granting ticket at the time of the request, unless the
1929 "renewable" option is also set, in which case it can be the full life
1930 (endtime minus starttime) of the ticket-granting ticket. The KDC MAY
1931 limit how far in the future a ticket may be postdated.
1933 The "postdated" flag indicates that a ticket has been postdated. The
1934 application server can check the authtime field in the ticket to see
1935 when the original authentication occurred. Some services MAY choose
1936 to reject postdated tickets, or they may only accept them within a
1937 certain period after the original authentication. When the KDC
1938 issues a "postdated" ticket, it will also be marked as "invalid", so
1939 that the application client MUST present the ticket to the KDC for
1940 validation before use.
1942 7.2.6. Proxiable and Proxy Tickets
1944 proxy
1945 indicates a proxy ticket
1947 proxiable
1948 indicates that proxy tickets may be issued based on this ticket
1950 [ RFC4120 2.5. ]
1952 It may be necessary for a principal to allow a service to perform an
1953 operation on its behalf. The service must be able to take on the
1954 identity of the client, but only for a particular purpose. A
1955 principal can allow a service to take on the principal's identity for
1956 a particular purpose by granting it a proxy.
1959 Yu Expires: Sep 2007 [Page 35]
1960 \f
1961 Internet-Draft rfc1510ter-04 05 Mar 2007
1963 The process of granting a proxy using the "proxy" and "proxiable"
1964 flags is used to provide credentials for use with specific services.
1965 Though conceptually also a proxy, users wishing to delegate their
1966 identity in a form usable for all purposes MUST use the ticket
1967 forwarding mechanism described in the next section to forward a
1968 ticket-granting ticket.
1970 The "proxiable" flag in a ticket is normally only interpreted by the
1971 ticket-granting service. It can be ignored by application servers.
1972 When set, this flag tells the ticket-granting server that it is OK to
1973 issue a new ticket (but not a ticket-granting ticket) with a
1974 different network address based on this ticket. This flag is set if
1975 requested by the client on initial authentication. By default, the
1976 client will request that it be set when requesting a ticket-granting
1977 ticket, and reset when requesting any other ticket.
1979 This flag allows a client to pass a proxy to a server to perform a
1980 remote request on its behalf (e.g. a print service client can give
1981 the print server a proxy to access the client's files on a particular
1982 file server in order to satisfy a print request).
1984 In order to complicate the use of stolen credentials, Kerberos
1985 tickets may contain a set of network addresses from which they are
1986 valid. When granting a proxy, the client MUST specify the new
1987 network address from which the proxy is to be used, or indicate that
1988 the proxy is to be issued for use from any address.
1990 The "proxy" flag is set in a ticket by the TGS when it issues a proxy
1991 ticket. Application servers MAY check this flag and at their option
1992 they MAY require additional authentication from the agent presenting
1993 the proxy in order to provide an audit trail.
1995 7.2.7. Forwarded and Forwardable Tickets
1997 forwarded
1998 indicates a forwarded ticket
2000 forwardable
2001 indicates that forwarded tickets may be issued based on this
2002 ticket
2004 [ RFC4120 2.6. ]
2006 Authentication forwarding is an instance of a proxy where the service
2007 that is granted is complete use of the client's identity. An example
2008 where it might be used is when a user logs in to a remote system and
2009 wants authentication to work from that system as if the login were
2010 local.
2012 The "forwardable" flag in a ticket is normally only interpreted by
2013 the ticket-granting service. It can be ignored by application
2015 Yu Expires: Sep 2007 [Page 36]
2016 \f
2017 Internet-Draft rfc1510ter-04 05 Mar 2007
2019 servers. The "forwardable" flag has an interpretation similar to
2020 that of the "proxiable" flag, except ticket-granting tickets may also
2021 be issued with different network addresses. This flag is reset by
2022 default, but users MAY request that it be set by setting the
2023 "forwardable" option in the AS request when they request their
2024 initial ticket-granting ticket.
2026 This flag allows for authentication forwarding without requiring the
2027 user to enter a password again. If the flag is not set, then
2028 authentication forwarding is not permitted, but the same result can
2029 still be achieved if the user engages in the AS exchange specifying
2030 the requested network addresses and supplies a password.
2032 The "forwarded" flag is set by the TGS when a client presents a
2033 ticket with the "forwardable" flag set and requests a forwarded
2034 ticket by specifying the "forwarded" KDC option and supplying a set
2035 of addresses for the new ticket. It is also set in all tickets
2036 issued based on tickets with the "forwarded" flag set. Application
2037 servers may choose to process "forwarded" tickets differently than
2038 non-forwarded tickets.
2040 If addressless tickets are forwarded from one system to another,
2041 clients SHOULD still use this option to obtain a new TGT in order to
2042 have different session keys on the different systems.
2044 7.3. Transited Realms
2046 [ RFC4120 2.7., plus new stuff ]
2048 7.4. Authorization Data
2050 [ RFC4120 5.2.6. ]
2052 ADType ::= TH-id
2054 AuthorizationData ::= SEQUENCE OF SEQUENCE {
2055 ad-type [0] ADType,
2056 ad-data [1] OCTET STRING
2057 }
2060 ad-type
2061 This field identifies the contents of the ad-data. All negative
2062 values are reserved for local use. Non-negative values are
2063 reserved for registered use.
2065 ad-data
2066 This field contains authorization data to be interpreted
2067 according to the value of the corresponding ad-type field.
2071 Yu Expires: Sep 2007 [Page 37]
2072 \f
2073 Internet-Draft rfc1510ter-04 05 Mar 2007
2075 Each sequence of ADType and OCTET STRING is referred to as an
2076 authorization element. Elements MAY be application specific,
2077 however, there is a common set of recursive elements that should be
2078 understood by all implementations. These elements contain other
2079 AuthorizationData, and the interpretation of the encapsulating
2080 element determines which enclosed elements must be interpreted, and
2081 which may be ignored.
2083 Depending on the meaning of the encapsulating element, the
2084 encapsulated AuthorizationData may be ignored, interpreted as issued
2085 directly by the KDC, or be stored in a separate plaintext part of the
2086 ticket. The types of the encapsulating elements are specified as
2087 part of the Kerberos protocol because behavior based on these
2088 container elements should be understood across implementations, while
2089 other elements need only be understood by the applications which they
2090 affect.
2092 Authorization data elements are considered critical if present in a
2093 ticket or authenticator. Unless encapsulated in a known
2094 authorization data element modifying the criticality of the elements
2095 it contains, an application server MUST reject the authentication of
2096 a client whose AP-REQ or ticket contains an unrecognized
2097 authorization data element. Authorization data is intended to
2098 restrict the use of a ticket. If the service cannot determine
2099 whether it is the target of a restriction, a security weakness may
2100 exist if the ticket can be used for that service. Authorization
2101 elements that are truly optional can be enclosed in AD-IF-RELEVANT
2102 element.
2105 ad-type | contents of ad-data
2106 ________|_______________________________________
2107 1 | DER encoding of AD-IF-RELEVANT
2108 4 | DER encoding of AD-KDCIssued
2109 5 | DER encoding of AD-AND-OR
2110 8 | DER encoding of AD-MANDATORY-FOR-KDC
2114 7.4.1. AD-IF-RELEVANT
2116 ad-if-relevant ADType ::= int32 : 1
2118 -- Encapsulates another AuthorizationData.
2119 -- Intended for application servers; receiving application
2120 -- servers MAY ignore.
2121 AD-IF-RELEVANT ::= AuthorizationData
2123 AD elements encapsulated within the if-relevant element are intended
2124 for interpretation only by application servers that understand the
2125 particular ad-type of the embedded element. Application servers that
2127 Yu Expires: Sep 2007 [Page 38]
2128 \f
2129 Internet-Draft rfc1510ter-04 05 Mar 2007
2131 do not understand the type of an element embedded within the if-
2132 relevant element MAY ignore the uninterpretable element. This element
2133 promotes interoperability across implementations which may have local
2134 extensions for authorization. The ad-type for AD-IF-RELEVANT is (1).
2136 7.4.2. AD-KDCIssued
2138 -- KDC-issued privilege attributes
2139 ad-kdcissued ADType ::= int32 : 4
2141 AD-KDCIssued ::= SEQUENCE {
2142 ad-checksum [0] ChecksumOf {
2143 AuthorizationData, { key-session },
2144 { ku-ad-KDCIssued-cksum }},
2145 i-realm [1] Realm OPTIONAL,
2146 i-sname [2] PrincipalName OPTIONAL,
2147 elements [3] AuthorizationData
2148 }
2151 ad-checksum
2152 A cryptographic checksum computed over the DER encoding of the
2153 AuthorizationData in the "elements" field, keyed with the
2154 session key. Its checksumtype is the mandatory checksum type
2155 for the encryption type of the session key, and its key usage
2156 value is 19.
2158 i-realm, i-sname
2159 The name of the issuing principal if different from the KDC
2160 itself. This field would be used when the KDC can verify the
2161 authenticity of elements signed by the issuing principal and it
2162 allows this KDC to notify the application server of the validity
2163 of those elements.
2165 elements
2166 AuthorizationData issued by the KDC.
2168 The KDC-issued ad-data field is intended to provide a means for
2169 Kerberos credentials to embed within themselves privilege attributes
2170 and other mechanisms for positive authorization, amplifying the
2171 privileges of the principal beyond what it would have if using
2172 credentials without such an authorization-data element.
2174 This amplification of privileges cannot be provided without this
2175 element because the definition of the authorization-data field allows
2176 elements to be added at will by the bearer of a TGT at the time that
2177 they request service tickets and elements may also be added to a
2178 delegated ticket by inclusion in the authenticator.
2180 For KDC-issued elements this is prevented because the elements are
2181 signed by the KDC by including a checksum encrypted using the
2183 Yu Expires: Sep 2007 [Page 39]
2184 \f
2185 Internet-Draft rfc1510ter-04 05 Mar 2007
2187 server's key (the same key used to encrypt the ticket -- or a key
2188 derived from that key). AuthorizationData encapsulated with in the
2189 AD-KDCIssued element MUST be ignored by the application server if
2190 this "signature" is not present. Further, AuthorizationData
2191 encapsulated within this element from a ticket-granting ticket MAY be
2192 interpreted by the KDC, and used as a basis according to policy for
2193 including new signed elements within derivative tickets, but they
2194 will not be copied to a derivative ticket directly. If they are
2195 copied directly to a derivative ticket by a KDC that is not aware of
2196 this element, the signature will not be correct for the application
2197 ticket elements, and the field will be ignored by the application
2198 server.
2200 This element and the elements it encapsulates MAY be safely ignored
2201 by applications, application servers, and KDCs that do not implement
2202 this element.
2204 The ad-type for AD-KDC-ISSUED is (4).
2206 7.4.3. AD-AND-OR
2208 ad-and-or ADType ::= int32 : 5
2210 AD-AND-OR ::= SEQUENCE {
2211 condition-count [0] Int32,
2212 elements [1] AuthorizationData
2213 }
2216 When restrictive AD elements are encapsulated within the and-or
2217 element, the and-or element is considered satisfied if and only if at
2218 least the number of encapsulated elements specified in condition-
2219 count are satisfied. Therefore, this element MAY be used to
2220 implement an "or" operation by setting the condition-count field to
2221 1, and it MAY specify an "and" operation by setting the condition
2222 count to the number of embedded elements. Application servers that do
2223 not implement this element MUST reject tickets that contain
2224 authorization data elements of this type.
2226 The ad-type for AD-AND-OR is (5).
2228 7.4.4. AD-MANDATORY-FOR-KDC
2230 -- KDCs MUST interpret any AuthorizationData wrapped in this.
2231 ad-mandatory-for-kdc ADType ::= int32 : 8
2232 AD-MANDATORY-FOR-KDC ::= AuthorizationData
2234 AD elements encapsulated within the mandatory-for-kdc element are to
2235 be interpreted by the KDC. KDCs that do not understand the type of
2236 an element embedded within the mandatory-for-kdc element MUST reject
2237 the request.
2239 Yu Expires: Sep 2007 [Page 40]
2240 \f
2241 Internet-Draft rfc1510ter-04 05 Mar 2007
2243 The ad-type for AD-MANDATORY-FOR-KDC is (8).
2245 7.5. Encrypted Part of Ticket
2247 The complete definition of the encrypted part is
2249 -- Encrypted part of ticket
2250 EncTicketPart ::= CHOICE {
2251 rfc1510 EncTicketPart1510,
2252 ext EncTicketPartExt
2253 }
2256 The encrypted part of the backwards-compatibility form of a ticket
2257 is:
2259 EncTicketPart1510 ::= [APPLICATION 3] SEQUENCE {
2260 flags [0] TicketFlags,
2261 key [1] EncryptionKey,
2262 crealm [2] RealmIA5,
2263 cname [3] PrincipalNameIA5,
2264 transited [4] TransitedEncoding,
2265 authtime [5] KerberosTime,
2266 starttime [6] KerberosTime OPTIONAL,
2267 endtime [7] KerberosTime,
2268 renew-till [8] KerberosTime OPTIONAL,
2269 caddr [9] HostAddresses OPTIONAL,
2270 authorization-data [10] AuthorizationData OPTIONAL
2271 }
2273 The encrypted part of the extensible form of a ticket is:
2275 EncTicketPartExt ::= [APPLICATION 5] SEQUENCE {
2276 flags [0] TicketFlags,
2277 key [1] EncryptionKey,
2278 crealm [2] RealmExt,
2279 cname [3] PrincipalNameExt,
2280 transited [4] TransitedEncoding,
2281 authtime [5] KerberosTime,
2282 starttime [6] KerberosTime OPTIONAL,
2283 endtime [7] KerberosTime,
2284 renew-till [8] KerberosTime OPTIONAL,
2285 caddr [9] HostAddresses OPTIONAL,
2286 authorization-data [10] AuthorizationData OPTIONAL,
2287 ...,
2288 }
2295 Yu Expires: Sep 2007 [Page 41]
2296 \f
2297 Internet-Draft rfc1510ter-04 05 Mar 2007
2299 7.6. Cleartext Part of Ticket
2301 The complete definition of Ticket is:
2303 Ticket ::= CHOICE {
2304 rfc1510 Ticket1510,
2305 ext TicketExt
2306 }
2309 The "sname" field provides the name of the target service principal
2310 in cleartext, as a hint to aid the server in choosing the correct
2311 decryption key.
2313 The backwards-compatibility form of Ticket is:
2315 Ticket1510 ::= [APPLICATION 1] SEQUENCE {
2316 tkt-vno [0] INTEGER (5),
2317 realm [1] RealmIA5,
2318 sname [2] PrincipalNameIA5,
2319 enc-part [3] EncryptedData {
2320 EncTicketPart1510, { key-server }, { ku-Ticket }
2321 }
2322 }
2324 The extensible form of Ticket is:
2326 TicketExt ::= [APPLICATION 4] Signed {
2327 [APPLICATION 4] SEQUENCE {
2328 tkt-vno [0] INTEGER (5),
2329 realm [1] RealmExt,
2330 sname [2] PrincipalNameExt,
2331 enc-part [3] EncryptedData {
2332 EncTicketPartExt, { key-server }, { ku-Ticket }
2333 },
2334 ...,
2335 extensions [4] TicketExtensions OPTIONAL,
2336 ...
2337 },
2338 { key-ticket }, { ku-Ticket-cksum }
2339 }
2342 TicketExtensions, which may only be present in the extensible form of
2343 Ticket, are a cleartext typed hole for extension use.
2344 AuthorizationData already provides an encrypted typed hole.
2351 Yu Expires: Sep 2007 [Page 42]
2352 \f
2353 Internet-Draft rfc1510ter-04 05 Mar 2007
2355 TEType ::= TH-id
2357 -- ticket extensions: for TicketExt only
2358 TicketExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
2359 te-type [0] TEType,
2360 te-data [1] OCTET STRING
2361 }
2364 A client will only receive an extensible Ticket if the application
2365 server supports extensibility.
2367 8. Credential Acquisition
2369 There are two exchanges that can be used for acquiring credentials:
2370 the AS exchange and the TGS exchange. These exchanges have many
2371 similarities, and this document describes them in parallel, noting
2372 which behaviors are specific to one type of exchange. The AS request
2373 (AS-REQ) and TGS request (TGS-REQ) are both forms of KDC requests
2374 (KDC-REQ). Likewise, the AS reply (AS-REP) and TGS reply (TGS-REP)
2375 are forms of KDC replies (KDC-REP).
2377 The credentials acquisition protocol operates over specific
2378 transports. Additionally, specific methods exist to permit a client
2379 to discover the KDC host with which to communicate.
2381 8.1. KDC-REQ
2383 The KDC-REQ has a large number of fields in common between the RFC
2384 1510 and the extensible versions. The KDC-REQ type itself is never
2385 directly encoded; it is always a part of a AS-REQ or a TGS-REQ.
2387 KDC-REQ-1510 ::= SEQUENCE {
2388 -- NOTE: first tag is [1], not [0]
2389 pvno [1] INTEGER (5),
2390 msg-type [2] INTEGER ( 10 -- AS-REQ --
2391 | 12 -- TGS-REQ -- ),
2392 padata [3] SEQUENCE OF PA-DATA OPTIONAL,
2393 req-body [4] KDC-REQ-BODY-1510
2394 }
2407 Yu Expires: Sep 2007 [Page 43]
2408 \f
2409 Internet-Draft rfc1510ter-04 05 Mar 2007
2411 KDC-REQ-EXT ::= SEQUENCE {
2412 pvno [1] INTEGER (5),
2413 msg-type [2] INTEGER ( 6 -- AS-REQ --
2414 | 8 -- TGS-REQ -- ),
2415 padata [3] SEQUENCE (SIZE (1..MAX))
2416 OF PA-DATA OPTIONAL,
2417 req-body [4] KDC-REQ-BODY-EXT,
2418 ...
2419 }
2422 KDC-REQ-BODY-1510 ::= SEQUENCE {
2423 kdc-options [0] KDCOptions,
2424 cname [1] PrincipalNameIA5 OPTIONAL
2425 -- Used only in AS-REQ --,
2427 realm [2] RealmIA5
2428 -- Server's realm; also client's in AS-REQ --,
2430 sname [3] PrincipalNameIA5 OPTIONAL,
2431 from [4] KerberosTime OPTIONAL,
2432 till [5] KerberosTime,
2433 rtime [6] KerberosTime OPTIONAL,
2434 nonce [7] Nonce32,
2435 etype [8] SEQUENCE OF EType
2436 -- in preference order --,
2438 addresses [9] HostAddresses OPTIONAL,
2439 enc-authorization-data [10] EncryptedData {
2440 AuthorizationData, { key-session | key-subsession },
2441 { ku-TGSReqAuthData-subkey |
2442 ku-TGSReqAuthData-sesskey }
2443 } OPTIONAL,
2445 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
2446 -- NOTE: not empty --
2447 }
2463 Yu Expires: Sep 2007 [Page 44]
2464 \f
2465 Internet-Draft rfc1510ter-04 05 Mar 2007
2467 KDC-REQ-BODY-EXT ::= SEQUENCE {
2468 kdc-options [0] KDCOptions,
2469 cname [1] PrincipalName OPTIONAL
2470 -- Used only in AS-REQ --,
2472 realm [2] Realm
2473 -- Server's realm; also client's in AS-REQ --,
2475 sname [3] PrincipalName OPTIONAL,
2476 from [4] KerberosTime OPTIONAL,
2477 till [5] KerberosTime OPTIONAL
2478 -- was required in rfc1510;
2479 -- still required for compat versions
2480 -- of messages --,
2482 rtime [6] KerberosTime OPTIONAL,
2483 nonce [7] Nonce,
2484 etype [8] SEQUENCE OF EType
2485 -- in preference order --,
2487 addresses [9] HostAddresses OPTIONAL,
2488 enc-authorization-data [10] EncryptedData {
2489 AuthorizationData, { key-session | key-subsession },
2490 { ku-TGSReqAuthData-subkey |
2491 ku-TGSReqAuthData-sesskey }
2492 } OPTIONAL,
2494 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
2495 -- NOTE: not empty --,
2496 ...
2497 lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF
2498 LangTag OPTIONAL,
2499 ...
2500 }
2503 Many fields of KDC-REQ-BODY correspond directly to fields of an
2504 EncTicketPart. The KDC copies most of them unchanged, provided that
2505 the requested values meet site policy.
2507 kdc-options
2508 These flags do not correspond directly to "flags" in
2509 EncTicketPart.
2511 cname
2512 This field is copied to the "cname" field in EncTicketPart. The
2513 "cname" field is required in an AS-REQ; the client places its
2514 own name here. In a TGS-REQ, the "cname" in the ticket in the
2515 AP-REQ takes precedence.
2519 Yu Expires: Sep 2007 [Page 45]
2520 \f
2521 Internet-Draft rfc1510ter-04 05 Mar 2007
2523 realm
2524 This field is the server's realm, and also holds the client's
2525 realm in an AS-REQ.
2527 sname
2528 The "sname" field indicates the server's name. It may be absent
2529 in a TGS-REQ which requests user-to-user authentication, in
2530 which case the "sname" of the issued ticket will be taken from
2531 the included additional ticket.
2533 The "from", "till", and "rtime" fields correspond to the "starttime",
2534 "endtime", and "renew-till" fields of EncTicketPart.
2536 addresses
2537 This field corresponds to the "caddr" field of EncTicketPart.
2539 enc-authorization-data
2540 For TGS-REQ, this field contains authorization data encrypted
2541 using either the TGT session key or the AP-REQ subsession key;
2542 the KDC may copy these into the "authorization-data" field of
2543 EncTicketPart if policy permits.
2545 lang-tags
2546 Only present in the extensible messages. Specifies the set of
2547 languages which the client is willing to accept in error
2548 messages.
2550 KDC options used in a KDC-REQ are:
2575 Yu Expires: Sep 2007 [Page 46]
2576 \f
2577 Internet-Draft rfc1510ter-04 05 Mar 2007
2579 KDCOptions ::= KerberosFlags { KDCOptionsBits }
2581 KDCOptionsBits ::= BIT STRING {
2582 reserved (0),
2583 forwardable (1),
2584 forwarded (2),
2585 proxiable (3),
2586 proxy (4),
2587 allow-postdate (5),
2588 postdated (6),
2589 unused7 (7),
2590 renewable (8),
2591 unused9 (9),
2592 unused10 (10),
2593 unused11 (11),
2594 unused12 (12),
2595 unused13 (13),
2596 requestanonymous (14),
2597 canonicalize (15),
2598 disable-transited-check (26),
2599 renewable-ok (27),
2600 enc-tkt-in-skey (28),
2601 renew (30),
2602 validate (31)
2603 -- XXX need "need ticket1" flag?
2604 }
2606 Different options apply to different phases of KDC-REQ processing.
2608 The backwards-compatibility form of a KDC-REQ is:
2610 KDC-REQ-1510 ::= SEQUENCE {
2611 -- NOTE: first tag is [1], not [0]
2612 pvno [1] INTEGER (5),
2613 msg-type [2] INTEGER ( 10 -- AS-REQ --
2614 | 12 -- TGS-REQ -- ),
2615 padata [3] SEQUENCE OF PA-DATA OPTIONAL,
2616 req-body [4] KDC-REQ-BODY-1510
2617 }
2619 The extensible form of a KDC-REQ is:
2631 Yu Expires: Sep 2007 [Page 47]
2632 \f
2633 Internet-Draft rfc1510ter-04 05 Mar 2007
2635 KDC-REQ-EXT ::= SEQUENCE {
2636 pvno [1] INTEGER (5),
2637 msg-type [2] INTEGER ( 6 -- AS-REQ --
2638 | 8 -- TGS-REQ -- ),
2639 padata [3] SEQUENCE (SIZE (1..MAX))
2640 OF PA-DATA OPTIONAL,
2641 req-body [4] KDC-REQ-BODY-EXT,
2642 ...
2643 }
2645 The backwards-compatibility form of a KDC-REQ-BODY is:
2647 KDC-REQ-BODY-1510 ::= SEQUENCE {
2648 kdc-options [0] KDCOptions,
2649 cname [1] PrincipalNameIA5 OPTIONAL
2650 -- Used only in AS-REQ --,
2652 realm [2] RealmIA5
2653 -- Server's realm; also client's in AS-REQ --,
2655 sname [3] PrincipalNameIA5 OPTIONAL,
2656 from [4] KerberosTime OPTIONAL,
2657 till [5] KerberosTime,
2658 rtime [6] KerberosTime OPTIONAL,
2659 nonce [7] Nonce32,
2660 etype [8] SEQUENCE OF EType
2661 -- in preference order --,
2663 addresses [9] HostAddresses OPTIONAL,
2664 enc-authorization-data [10] EncryptedData {
2665 AuthorizationData, { key-session | key-subsession },
2666 { ku-TGSReqAuthData-subkey |
2667 ku-TGSReqAuthData-sesskey }
2668 } OPTIONAL,
2670 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
2671 -- NOTE: not empty --
2672 }
2674 The extensible form of a KDC-REQ-BODY is:
2687 Yu Expires: Sep 2007 [Page 48]
2688 \f
2689 Internet-Draft rfc1510ter-04 05 Mar 2007
2691 KDC-REQ-BODY-EXT ::= SEQUENCE {
2692 kdc-options [0] KDCOptions,
2693 cname [1] PrincipalName OPTIONAL
2694 -- Used only in AS-REQ --,
2696 realm [2] Realm
2697 -- Server's realm; also client's in AS-REQ --,
2699 sname [3] PrincipalName OPTIONAL,
2700 from [4] KerberosTime OPTIONAL,
2701 till [5] KerberosTime OPTIONAL
2702 -- was required in rfc1510;
2703 -- still required for compat versions
2704 -- of messages --,
2706 rtime [6] KerberosTime OPTIONAL,
2707 nonce [7] Nonce,
2708 etype [8] SEQUENCE OF EType
2709 -- in preference order --,
2711 addresses [9] HostAddresses OPTIONAL,
2712 enc-authorization-data [10] EncryptedData {
2713 AuthorizationData, { key-session | key-subsession },
2714 { ku-TGSReqAuthData-subkey |
2715 ku-TGSReqAuthData-sesskey }
2716 } OPTIONAL,
2718 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
2719 -- NOTE: not empty --,
2720 ...
2721 lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF
2722 LangTag OPTIONAL,
2723 ...
2724 }
2726 The AS-REQ is:
2728 AS-REQ ::= CHOICE {
2729 rfc1510 AS-REQ-1510,
2730 ext AS-REQ-EXT
2731 }
2732 AS-REQ-1510 ::= [APPLICATION 10] KDC-REQ-1510
2733 -- AS-REQ must include client name
2735 AS-REQ-EXT ::= [APPLICATION 6] Signed {
2736 [APPLICATION 6] KDC-REQ-EXT,
2737 { key-client }, { ku-ASReq-cksum }
2738 }
2739 -- AS-REQ must include client name
2741 A client SHOULD NOT send the extensible AS-REQ alternative to a KDC
2743 Yu Expires: Sep 2007 [Page 49]
2744 \f
2745 Internet-Draft rfc1510ter-04 05 Mar 2007
2747 if the client does not know that the KDC supports the extensibility
2748 framework. A client SHOULD send the extensible AS-REQ alternative in
2749 a PA-AS-REQ PA-DATA. A KDC supporting extensibility will treat the
2750 AS-REQ contained within the PA-AS-REQ as the actual AS-REQ. [ XXX
2751 what if their contents conflict? ]
2753 The TGS-REQ is:
2755 TGS-REQ ::= CHOICE {
2756 rfc1510 TGS-REQ-1510,
2757 ext TGS-REQ-EXT
2758 }
2760 TGS-REQ-1510 ::= [APPLICATION 12] KDC-REQ-1510
2762 TGS-REQ-EXT ::= [APPLICATION 8] Signed {
2763 [APPLICATION 8] KDC-REQ-EXT,
2764 { key-session }, { ku-TGSReq-cksum }
2765 }
2768 8.2. PA-DATA
2770 PA-DATA have multiple uses in the Kerberos protocol. They may pre-
2771 authenticate an AS-REQ; they may also modify several of the
2772 encryption keys used in a KDC-REP. PA-DATA may also provide "hints"
2773 to the client about which long-term key (usually password-derived) to
2774 use. PA-DATA may also include "hints" about which pre-authentication
2775 mechanisms to use, or include data for input into a pre-
2776 authentication mechanism.
2778 [ XXX enumerate standard padata here ]
2780 8.3. KDC-REQ Processing
2782 Processing of a KDC-REQ proceeds through several steps. An
2783 implementation need not perform these steps exactly as described, as
2784 long as it behaves as if the steps were performed as described. The
2785 KDC performs replay handling upon receiving the request; it then
2786 validates the request, adjusts timestamps, and selects the keys used
2787 in the reply. It copies data from the request into the issued
2788 ticket, adjusting the values to conform with its policies. The KDC
2789 then transmits the reply to the client.
2791 8.3.1. Handling Replays
2793 Because Kerberos can run over unreliable transports such as UDP, the
2794 KDC MUST be prepared to retransmit responses in case they are lost.
2795 If a KDC receives a request identical to one it has recently
2796 successfully processed, the KDC MUST respond with a KDC-REP message
2797 rather than a replay error. In order to reduce the amount of
2799 Yu Expires: Sep 2007 [Page 50]
2800 \f
2801 Internet-Draft rfc1510ter-04 05 Mar 2007
2803 ciphertext given to a potential attacker, KDCs MAY send the same
2804 response generated when the request was first handled. KDCs MUST
2805 obey this replay behavior even if the actual transport in use is
2806 reliable. If the AP-REQ which authenticates a TGS-REQ is a replay,
2807 and the entire request is not identical to a recently successfully
2808 processed request, the KDC SHOULD return "krb-ap-err-repeat", as is
2809 appropriate for AP-REQ processing.
2811 8.3.2. Request Validation
2813 8.3.2.1. AS-REQ Authentication
2815 Site policy determines whether a given client principal is required
2816 to provide some pre-authentication prior to receiving an AS-REP.
2817 Since the default reply key is typically the client's long-term
2818 password-based key, an attacker may easily request known plaintext
2819 (in the form of an AS-REP) upon which to mount a dictionary attack.
2820 Pre-authentication can limit the possibility of such an attack.
2822 If site policy requires pre-authentication for a client principal,
2823 and no pre-authentication is provided, the KDC returns the error
2824 "kdc-err-preauth-required". Accompanying this error are "e-data"
2825 which include hints telling the client which pre-authentication
2826 mechanisms to use, or data for input to pre-authentication mechanisms
2827 (e.g., input to challenge-response systems). If pre-authentication
2828 fails, the KDC returns the error "kdc-err-preauth-failed".
2830 [ may need additional changes based on Sam's preauth draft ]
2832 8.3.2.2. TGS-REQ Authentication
2834 A TGS-REQ has an accompanying AP-REQ, which is included in the "pa-
2835 tgs-req". The KDC MUST validate the checksum in the Authenticator of
2836 the AP-REQ, which is computed over the KDC-REQ-BODY-1510 or KDC-REQ-
2837 BODY-EXT (for TGS-REQ-1510 or TGS-REQ-EXT, respectively) of the
2838 request. [ padata not signed by authenticator! ] Any error from the
2839 AP-REQ validation process SHOULD be returned in a KRB-ERROR message.
2840 The service principal in the ticket of the AP-REQ may be a ticket-
2841 granting service principal, or a normal application service
2842 principal. A ticket which is not a ticket-granting ticket MUST NOT
2843 be used to issue a ticket for any service other than the one named in
2844 the ticket. In this case, the "renew", "validate", or "proxy" [?also
2845 forwarded?] option must be set in the request.
2847 8.3.2.3. Principal Validation
2849 If the client principal in an AS-REQ is unknown, the KDC returns the
2850 error "kdc-err-c-principal-unknown". If the server principal in a
2851 KDC-REQ is unknown, the KDC returns the error "kdc-err-s-principal-
2852 unknown".
2855 Yu Expires: Sep 2007 [Page 51]
2856 \f
2857 Internet-Draft rfc1510ter-04 05 Mar 2007
2859 8.3.2.4. Checking For Revoked or Invalid Tickets
2861 [ RFC4120 3.3.3.1 ]
2863 Whenever a request is made to the ticket-granting server, the
2864 presented ticket(s) is(are) checked against a hot-list of tickets
2865 which have been canceled. This hot-list might be implemented by
2866 storing a range of issue timestamps for "suspect tickets"; if a
2867 presented ticket had an authtime in that range, it would be rejected.
2868 In this way, a stolen ticket-granting ticket or renewable ticket
2869 cannot be used to gain additional tickets (renewals or otherwise)
2870 once the theft has been reported to the KDC for the realm in which
2871 the server resides. Any normal ticket obtained before it was
2872 reported stolen will still be valid (because they require no
2873 interaction with the KDC), but only until their normal expiration
2874 time. If TGTs have been issued for cross-realm authentication, use
2875 of the cross-realm TGT will not be affected unless the hot-list is
2876 propagated to the KDCs for the realms for which such cross-realm
2877 tickets were issued.
2879 If a TGS-REQ ticket has its "invalid" flag set, the KDC MUST NOT
2880 issue any ticket unless the TGS-REQ requests the "validate" option.
2882 8.3.3. Timestamp Handling
2884 [ some aspects of timestamp handling, especially regarding postdating
2885 and renewal, are difficult to read in RFC4120... needs closer
2886 examination here ]
2888 Processing of "starttime" (requested in the "from" field) differs
2889 depending on whether the "postdated" option is set in the request.
2890 If the "postdated" option is not set, and the requested "starttime"
2891 is in the future beyond the window of acceptable clock skew, the KDC
2892 returns the error "kdc-err-cannot-postdate". If the "postdated"
2893 option is not set, and the requested "starttime" is absent or does
2894 not indicate a time in the future beyond the acceptable clock skew,
2895 the KDC sets the "starttime" to the KDC's current time. The
2896 "postdated" option MUST NOT be honored if the ticket is being
2897 requested by TGS-REQ and the "may-postdate" is not set in the TGT.
2898 Otherwise, if the "postdated" option is set, and site policy permits,
2899 the KDC sets the "starttime" as requested, and sets the "invalid"
2900 flag in the new ticket.
2902 The "till" field is required in the RFC 1510 version of the KDC-REQ.
2903 If the "till" field is equal to "19700101000000Z" (midnight, January
2904 1, 1970), the KDC SHOULD behave as if the "till" field were absent.
2906 The KDC MUST NOT issue a ticket whose "starttime", "endtime", or
2907 "renew-till" time is later than the "renew-till" time of the ticket
2908 from which it is derived.
2911 Yu Expires: Sep 2007 [Page 52]
2912 \f
2913 Internet-Draft rfc1510ter-04 05 Mar 2007
2915 8.3.3.1. AS-REQ Timestamp Processing
2917 In the AS exchange, the "authtime" of a ticket is set to the local
2918 time at the KDC.
2920 The "endtime" of the ticket will be set to the earlier of the
2921 requested "till" time and a time determined by local policy, possibly
2922 determined using factors specific to the realm or principal. For
2923 example, the expiration time MAY be set to the earliest of the
2924 following:
2926 * the expiration time ("till" value) requested
2928 * the ticket's start time plus the maximum allowable lifetime
2929 associated with the client principal from the authentication
2930 server's database
2932 * the ticket's start time plus the maximum allowable lifetime
2933 associated with the server principal
2935 * the ticket's start time plus the maximum lifetime set by the
2936 policy of the local realm
2938 If the requested expiration time minus the start time (as determined
2939 above) is less than a site-determined minimum lifetime, an error
2940 message with code "kdc-err-never-valid" is returned. If the
2941 requested expiration time for the ticket exceeds what was determined
2942 as above, and if the "renewable-ok" option was requested, then the
2943 "renewable" flag is set in the new ticket, and the "renew-till" value
2944 is set as if the "renewable" option were requested.
2946 If the "renewable" option has been requested or if the "renewable-ok"
2947 option has been set and a renewable ticket is to be issued, then the
2948 "renew-till" field MAY be set to the earliest of:
2950 * its requested value
2952 * the start time of the ticket plus the minimum of the two maximum
2953 renewable lifetimes associated with the principals' database
2954 entries
2956 * the start time of the ticket plus the maximum renewable lifetime
2957 set by the policy of the local realm
2959 8.3.3.2. TGS-REQ Timestamp Processing
2961 In the TGS exchange, the KDC sets the "authtime" to that of the
2962 ticket in the AP-REQ authenticating the TGS-REQ. [?application
2963 server can print a ticket for itself with a spoofed authtime.
2964 security issues for hot-list?] [ MIT implementation may change
2965 authtime of renewed tickets; needs check... ]
2967 Yu Expires: Sep 2007 [Page 53]
2968 \f
2969 Internet-Draft rfc1510ter-04 05 Mar 2007
2971 If the TGS-REQ has a TGT as the ticket in its AP-REQ, and the TGS-REQ
2972 requests an "endtime" (in the "till" field), then the "endtime" of
2973 the new ticket is set to the minimum of
2975 * the requested "endtime" value,
2977 * the "endtime" in the TGT, and
2979 * an "endtime" determined by site policy on ticket lifetimes.
2981 If the new ticket is a renewal, the "endtime" of the new ticket is
2982 bounded by the minimum of
2984 * the requested "endtime" value,
2986 * the value of the "renew-till" value of the old,
2988 * the "starttime" of the new ticket plus the lifetime (endtime
2989 minus starttime) of the old ticket, i.e., the lifetime of the
2990 new ticket may not exceed that of the ticket being renewed [
2991 adapted from RFC4120 3.3.3. ], and
2993 * an "endtime" determined by site policy on ticket lifetimes.
2995 When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with
2996 a "starttime", "endtime", or "renew-till" time later than the
2997 "renew-till" time of the TGT.
2999 8.3.4. Handling Transited Realms
3001 The KDC checks the ticket in a TGS-REQ against site policy, unless
3002 the "disable-transited-check" option is set in the TGS-REQ. If site
3003 policy permits the transit path in the TGS-REQ ticket, the KDC sets
3004 the "transited-policy-checked" flag in the issued ticket. If the
3005 "disable-transited-check" option is set, the issued ticket will have
3006 the "transited-policy-checked" flag cleared.
3008 8.3.5. Address Processing The requested "addresses" in the KDC-REQ are
3009 copied into the issued ticket. If the "addresses" field is absent or
3010 empty in a TGS-REQ, the KDC copies addresses from the ticket in the
3011 TGS-REQ into the issued ticket, unless the either "forwarded" or
3012 "proxy" option is set. If the "forwarded" option is set, and the
3013 ticket in the TGS-REQ has its "forwardable" flag set, the KDC copies
3014 the addresses from the TGS-REQ, not the from TGS-REQ ticket, into the
3015 issued ticket. The KDC behaves similarly if the "proxy" option is
3016 set in the TGS-REQ and the "proxiable" flag is set in the ticket.
3017 The "proxy" option will not be honored on requests for additional
3018 ticket-granting tickets.
3023 Yu Expires: Sep 2007 [Page 54]
3024 \f
3025 Internet-Draft rfc1510ter-04 05 Mar 2007
3027 8.3.6. Ticket Flag Processing
3029 Many kdc-options request that the KDC set a corresponding flag in the
3030 issued ticket. kdc-options marked with an asterisk (*) in the
3031 following table do not directly request the corresponding ticket flag
3032 and therefore require special handling.
3035 kdc-option | ticket flag affected
3036 ________________________|__________________________
3037 forwardable | forwardable
3038 forwarded | forwarded
3039 proxiable | proxiable
3040 proxy | proxy
3041 allow-postdate | may-postdate
3042 postdated | postdated
3043 renewable | renewable
3044 requestanonymous | anonymous
3045 canonicalize | -
3046 disable-transited-check*| transited-policy-checked
3047 renewable-ok* | renewable
3048 enc-tkt-in-skey | -
3049 renew | -
3050 validate* | invalid
3054 forwarded
3055 The KDC sets the "forwarded" flag in the issued ticket if the
3056 "forwarded" option is set in the TGS-REQ and the "forwardable"
3057 flag is set in the TGS-REQ ticket.
3059 proxy
3060 The KDC sets the "proxy" flag in the issued ticket if the
3061 "proxy" option is set in the TGS-REQ and the "proxiable" flag is
3062 set in the TGS-REQ ticket.
3064 disable-transited-check
3065 The handling of the "disable-transited-check" kdc-option is
3066 described in Section 8.3.4.
3068 renewable-ok
3069 The handling of the "renewable-ok" kdc-option is described in
3070 Section 8.3.3.1.
3072 enc-tkt-in-skey
3073 This flag modifies ticket key selection to use the session key
3074 of an additional ticket included in the TGS-REQ, for the purpose
3075 of user-to-user authentication.
3079 Yu Expires: Sep 2007 [Page 55]
3080 \f
3081 Internet-Draft rfc1510ter-04 05 Mar 2007
3083 validate
3084 If the "validate" kdc-option is set in a TGS-REQ, and the
3085 "starttime" has passed, the KDC will clear the "invalid" bit on
3086 the ticket before re-issuing it.
3088 8.3.7. Key Selection
3090 Three keys are involved in creating a KDC-REP. The reply key
3091 encrypts the encrypted part of the KDC-REP. The session key is
3092 stored in the encrypted part of the ticket, and is also present in
3093 the encrypted part of the KDC-REP so that the client can retrieve it.
3094 The ticket key is used to encrypt the ticket. These keys all have
3095 initial values for a given exchange; pre-authentication and other
3096 extension mechanisms may change the value used for any of these keys.
3098 [ again, may need changes based on Sam's preauth draft ]
3100 8.3.7.1. Reply Key and Session Key Selection
3102 The set of encryption types which the client will understand appears
3103 in the "etype" field of KDC-REQ-BODY. The KDC limits the set of
3104 possible reply keys and the set of session key encryption types based
3105 on the "etype" field.
3107 For the AS exchange, the reply key is initially a long-term key of
3108 the client, limited to those encryption types listed in the "etype"
3109 field. The KDC SHOULD use the first valid strong "etype" for which
3110 an encryption key is available. For the TGS exchange, the reply key
3111 is initially the subsession key of the Authenticator. If the
3112 Authenticator subsesion key is absent, the reply key is initially the
3113 session key of the ticket used to authenticate the TGS-REQ.
3115 The session key is initially randomly generated, and has an
3116 encryption type which both the client and the server will understand.
3117 Typically, the KDC has prior knowledge of which encryption types the
3118 server will understand. It selects the first valid strong "etype"
3119 listed the request which the server also will understand.
3121 8.3.7.2. Ticket Key Selection
3123 The ticket key is initially the long-term key of the service. The
3124 "enc-tkt-in-skey" option requests user-to-user authentication, where
3125 the ticket encryption key of the issued ticket is set equal to the
3126 session key of the additional ticket in the request.
3128 8.4. KDC-REP
3130 The important parts of the KDC-REP are encrypted.
3135 Yu Expires: Sep 2007 [Page 56]
3136 \f
3137 Internet-Draft rfc1510ter-04 05 Mar 2007
3139 EncASRepPart1510 ::= [APPLICATION 25] EncKDCRepPart1510
3140 EncTGSRepPart1510 ::= [APPLICATION 26] EncKDCRepPart1510
3142 EncASRepPartExt ::= [APPLICATION 32] EncKDCRepPartExt
3143 EncTGSRepPartExt ::= [APPLICATION 33] EncKDCRepPartExt
3145 EncKDCRepPart1510 ::= SEQUENCE {
3146 key [0] EncryptionKey,
3147 last-req [1] LastReq,
3148 nonce [2] Nonce32,
3149 key-expiration [3] KerberosTime OPTIONAL,
3150 flags [4] TicketFlags,
3151 authtime [5] KerberosTime,
3152 starttime [6] KerberosTime OPTIONAL,
3153 endtime [7] KerberosTime,
3154 renew-till [8] KerberosTime OPTIONAL,
3155 srealm [9] RealmIA5,
3156 sname [10] PrincipalNameIA5,
3157 caddr [11] HostAddresses OPTIONAL
3158 }
3160 EncKDCRepPartExt ::= SEQUENCE {
3161 key [0] EncryptionKey,
3162 last-req [1] LastReq,
3163 nonce [2] Nonce,
3164 key-expiration [3] KerberosTime OPTIONAL,
3165 flags [4] TicketFlags,
3166 authtime [5] KerberosTime,
3167 starttime [6] KerberosTime OPTIONAL,
3168 endtime [7] KerberosTime,
3169 renew-till [8] KerberosTime OPTIONAL,
3170 srealm [9] Realm,
3171 sname [10] PrincipalName,
3172 caddr [11] HostAddresses OPTIONAL,
3173 ...
3174 }
3177 Most of the fields of EncKDCRepPartCom are duplicates of the
3178 corresponding fields in the returned ticket.
3191 Yu Expires: Sep 2007 [Page 57]
3192 \f
3193 Internet-Draft rfc1510ter-04 05 Mar 2007
3195 KDC-REP-1510 { EncPart } ::= SEQUENCE {
3196 pvno [0] INTEGER (5),
3197 msg-type [1] INTEGER (11 -- AS-REP.rfc1510 -- |
3198 13 -- TGS.rfc1510 -- ),
3199 padata [2] SEQUENCE OF PA-DATA OPTIONAL,
3200 crealm [3] RealmIA5,
3201 cname [4] PrincipalNameIA5,
3202 ticket [5] Ticket,
3204 enc-part [6] EncryptedData {
3205 EncPart,
3206 { key-reply },
3207 -- maybe reach into EncryptedData in AS-REP/TGS-REP
3208 -- definitions to apply constraints on key usages?
3209 { ku-EncASRepPart -- if AS-REP -- |
3210 ku-EncTGSRepPart-subkey -- if TGS-REP and
3211 -- using Authenticator
3212 -- session key -- |
3213 ku-EncTGSRepPart-sesskey -- if TGS-REP and using
3214 -- subsession key -- }
3215 }
3216 }
3247 Yu Expires: Sep 2007 [Page 58]
3248 \f
3249 Internet-Draft rfc1510ter-04 05 Mar 2007
3251 KDC-REP-EXT { EncPart } ::= SEQUENCE {
3252 pvno [0] INTEGER (5),
3253 msg-type [1] INTEGER (7 -- AS-REP.ext -- |
3254 9 -- TGS-REP.ext -- ),
3255 padata [2] SEQUENCE OF PA-DATA OPTIONAL,
3256 crealm [3] RealmExt,
3257 cname [4] PrincipalNameExt,
3258 ticket [5] Ticket,
3260 enc-part [6] EncryptedData {
3261 EncPart,
3262 { key-reply },
3263 -- maybe reach into EncryptedData in AS-REP/TGS-REP
3264 -- definitions to apply constraints on key usages?
3265 { ku-EncASRepPart -- if AS-REP -- |
3266 ku-EncTGSRepPart-subkey -- if TGS-REP and
3267 -- using Authenticator
3268 -- session key -- |
3269 ku-EncTGSRepPart-sesskey -- if TGS-REP and using
3270 -- subsession key -- }
3271 },
3273 ...,
3274 -- In extensible version, KDC signs original request
3275 -- to avoid replay attacks against client.
3276 req-cksum [7] ChecksumOf { CHOICE {
3277 as-req AS-REQ,
3278 tgs-req TGS-REQ
3279 }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
3280 lang-tag [8] LangTag OPTIONAL,
3281 ...
3282 }
3285 req-cksum
3286 Signature of the original request using the reply key, to avoid
3287 replay attacks against the client, among other things. Only
3288 present in the extensible version of KDC-REP.
3290 AS-REP ::= CHOICE {
3291 rfc1510 AS-REP-1510,
3292 ext AS-REP-EXT
3293 }
3294 AS-REP-1510 ::= [APPLICATION 11] KDC-REP-1510
3295 AS-REP-EXT ::= [APPLICATION 7] Signed {
3296 [APPLICATION 7] KDC-REP-EXT,
3297 { key-reply }, { ku-ASRep-cksum }
3298 }
3303 Yu Expires: Sep 2007 [Page 59]
3304 \f
3305 Internet-Draft rfc1510ter-04 05 Mar 2007
3307 TGS-REP ::= CHOICE {
3308 rfc1510 TGS-REP-1510,
3309 ext TGS-REP-EXT
3310 }
3311 TGS-REP-1510 ::= [APPLICATION 13] KDC-REP-1510 {
3312 EncTGSRepPart1510 }
3314 TGS-REP-EXT ::= [APPLICATION 9] Signed {
3315 [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
3316 { key-reply }, { ku-TGSRep-cksum }
3317 }
3320 The extensible versions of AS-REQ and TGS-REQ are signed with the
3321 reply key, to prevent an attacker from performing a delayed denial-
3322 of-service attack by substituting the ticket.
3324 8.5. Reply Validation
3326 [ signature verification ]
3328 8.6. IP Transports
3330 [ RFC4120 7.2 ]
3332 Kerberos defines two IP transport mechanisms for the credentials
3333 acquisition protocol: UDP/IP and TCP/IP.
3335 8.6.1. UDP/IP transport
3337 Kerberos servers (KDCs) supporting IP transports MUST accept UDP
3338 requests and SHOULD listen for such requests on port 88 (decimal)
3339 unless specifically configured to listen on an alternative UDP port.
3340 Alternate ports MAY be used when running multiple KDCs for multiple
3341 realms on the same host.
3343 Kerberos clients supporting IP transports SHOULD support the sending
3344 of UDP requests. Clients SHOULD use KDC discovery (Section 8.6.3) to
3345 identify the IP address and port to which they will send their
3346 request.
3348 When contacting a KDC for a KRB_KDC_REQ request using UDP/IP
3349 transport, the client shall send a UDP datagram containing only an
3350 encoding of the request to the KDC. The KDC will respond with a reply
3351 datagram containing only an encoding of the reply message (either a
3352 KRB-ERROR or a KDC-REP) to the sending port at the sender's IP
3353 address. The response to a request made through UDP/IP transport MUST
3354 also use UDP/IP transport. If the response can not be handled using
3355 UDP (for example because it is too large), the KDC MUST return "krb-
3356 err-response-too-big", forcing the client to retry the request using
3357 the TCP transport.
3359 Yu Expires: Sep 2007 [Page 60]
3360 \f
3361 Internet-Draft rfc1510ter-04 05 Mar 2007
3363 8.6.2. TCP/IP transport
3365 Kerberos servers (KDCs) supporting IP transports MUST accept TCP
3366 requests and SHOULD listen for such requests on port 88 (decimal)
3367 unless specifically configured to listen on an alternate TCP port.
3368 Alternate ports MAY be used when running multiple KDCs for multiple
3369 realms on the same host.
3371 Clients MUST support the sending of TCP requests, but MAY choose to
3372 initially try a request using the UDP transport. Clients SHOULD use
3373 KDC discovery (Section 8.6.3) to identify the IP address and port to
3374 which they will send their request.
3376 Implementation note: Some extensions to the Kerberos protocol will
3377 not succeed if any client or KDC not supporting the TCP transport is
3378 involved. Implementations of RFC 1510 were not required to support
3379 TCP/IP transports.
3381 When the KDC-REQ message is sent to the KDC over a TCP stream, the
3382 response (KDC-REP or KRB-ERROR message) MUST be returned to the
3383 client on the same TCP stream that was established for the request.
3384 The KDC MAY close the TCP stream after sending a response, but MAY
3385 leave the stream open for a reasonable period of time if it expects a
3386 followup. Care must be taken in managing TCP/IP connections on the
3387 KDC to prevent denial of service attacks based on the number of open
3388 TCP/IP connections.
3390 The client MUST be prepared to have the stream closed by the KDC at
3391 anytime after the receipt of a response. A stream closure SHOULD NOT
3392 be treated as a fatal error. Instead, if multiple exchanges are
3393 required (e.g., certain forms of pre-authentication) the client may
3394 need to establish a new connection when it is ready to send
3395 subsequent messages. A client MAY close the stream after receiving a
3396 response, and SHOULD close the stream if it does not expect to send
3397 followup messages.
3399 A client MAY send multiple requests before receiving responses,
3400 though it must be prepared to handle the connection being closed
3401 after the first response.
3403 Each request (KDC-REQ) and response (KDC-REP or KRB-ERROR) sent over
3404 the TCP stream is preceded by the length of the request as 4 octets
3405 in network byte order. The high bit of the length is reserved for
3406 future expansion and MUST currently be set to zero. If a KDC that
3407 does not understand how to interpret a set high bit of the length
3408 encoding receives a request with the high order bit of the length
3409 set, it MUST return a KRB-ERROR message with the error "krb-err-
3410 field-toolong" and MUST close the TCP stream.
3412 If multiple requests are sent over a single TCP connection, and the
3413 KDC sends multiple responses, the KDC is not required to send the
3415 Yu Expires: Sep 2007 [Page 61]
3416 \f
3417 Internet-Draft rfc1510ter-04 05 Mar 2007
3419 responses in the order of the corresponding requests. This may
3420 permit some implementations to send each response as soon as it is
3421 ready even if earlier requests are still being processed (for
3422 example, waiting for a response from an external device or database).
3424 8.6.3. KDC Discovery on IP Networks
3426 Kerberos client implementations MUST provide a means for the client
3427 to determine the location of the Kerberos Key Distribution Centers
3428 (KDCs). Traditionally, Kerberos implementations have stored such
3429 configuration information in a file on each client machine.
3430 Experience has shown this method of storing configuration information
3431 presents problems with out-of-date information and scaling problems,
3432 especially when using cross-realm authentication. This section
3433 describes a method for using the Domain Name System [RFC 1035] for
3434 storing KDC location information.
3436 8.6.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names
3438 In Kerberos, realm names are case sensitive. While it is strongly
3439 encouraged that all realm names be all upper case this recommendation
3440 has not been adopted by all sites. Some sites use all lower case
3441 names and other use mixed case. DNS, on the other hand, is case
3442 insensitive for queries. Since the realm names "MYREALM", "myrealm",
3443 and "MyRealm" are all different, but resolve the same in the domain
3444 name system, it is necessary that only one of the possible
3445 combinations of upper and lower case characters be used in realm
3446 names.
3448 8.6.3.2. DNS SRV records for KDC location
3450 KDC location information is to be stored using the DNS SRV RR [RFC
3451 2782]. The format of this RR is as follows:
3453 _Service._Proto.Realm TTL Class SRV Priority Weight Port Target
3455 The Service name for Kerberos is always "kerberos".
3457 The Proto can be one of "udp", "tcp". If these SRV records are to be
3458 used, both "udp" and "tcp" records MUST be specified for all KDC
3459 deployments.
3461 The Realm is the Kerberos realm that this record corresponds to. The
3462 realm MUST be a domain style realm name.
3464 TTL, Class, SRV, Priority, Weight, and Target have the standard
3465 meaning as defined in RFC 2782.
3467 As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV
3468 records SHOULD be the value assigned to "kerberos" by the Internet
3469 Assigned Number Authority: 88 (decimal) unless the KDC is configured
3471 Yu Expires: Sep 2007 [Page 62]
3472 \f
3473 Internet-Draft rfc1510ter-04 05 Mar 2007
3475 to listen on an alternate TCP port.
3477 Implementation note: Many existing client implementations do not
3478 support KDC Discovery and are configured to send requests to the IANA
3479 assigned port (88 decimal), so it is strongly recommended that KDCs
3480 be configured to listen on that port.
3482 8.6.3.3. KDC Discovery for Domain Style Realm Names on IP Networks
3484 These are DNS records for a Kerberos realm EXAMPLE.COM. It has two
3485 Kerberos servers, kdc1.example.com and kdc2.example.com. Queries
3486 should be directed to kdc1.example.com first as per the specified
3487 priority. Weights are not used in these sample records.
3489 _kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
3490 _kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
3491 _kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
3492 _kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
3495 9. Errors
3497 The KRB-ERROR message is returned by the KDC if an error occurs
3498 during credentials acquisition. It may also be returned by an
3499 application server if an error occurs during authentication.
3501 ErrCode ::= Int32
3503 KRB-ERROR ::= CHOICE {
3504 rfc1510 KRB-ERROR-1510,
3505 ext KRB-ERROR-EXT
3506 }
3509 The extensible KRB-ERROR is only signed if there has been a key
3510 negotiated with its recipient. KRB-ERROR messages sent in response
3511 to AS-REQ messages will probably not be signed unless a
3512 preauthentication mechanism has negotiated a key. (Signing using a
3513 client's long-term key can expose ciphertext to dictionary attacks.)
3527 Yu Expires: Sep 2007 [Page 63]
3528 \f
3529 Internet-Draft rfc1510ter-04 05 Mar 2007
3531 KRB-ERROR-1510 ::= [APPLICATION 30] SEQUENCE {
3532 pvno [0] INTEGER (5),
3533 msg-type [1] INTEGER (30),
3534 ctime [2] KerberosTime OPTIONAL,
3535 cusec [3] Microseconds OPTIONAL,
3536 stime [4] KerberosTime,
3537 susec [5] Microseconds,
3538 error-code [6] ErrCode,
3539 crealm [7] RealmIA5 OPTIONAL,
3540 cname [8] PrincipalNameIA5 OPTIONAL,
3541 realm [9] RealmIA5 -- Correct realm --,
3542 sname [10] PrincipalNameIA5 -- Correct name --,
3543 e-text [11] KerberosString OPTIONAL,
3544 e-data [12] OCTET STRING OPTIONAL
3545 }
3548 KRB-ERROR-EXT ::= [APPLICATION 23] Signed {
3549 [APPLICATION 23] SEQUENCE{
3550 pvno [0] INTEGER (5),
3551 msg-type [1] INTEGER (23),
3552 ctime [2] KerberosTime OPTIONAL,
3553 cusec [3] Microseconds OPTIONAL,
3554 stime [4] KerberosTime,
3555 susec [5] Microseconds,
3556 error-code [6] ErrCode,
3557 crealm [7] Realm OPTIONAL,
3558 cname [8] PrincipalName OPTIONAL,
3559 realm [9] Realm -- Correct realm --,
3560 sname [10] PrincipalName -- Correct name --,
3561 e-text [11] KerberosString OPTIONAL,
3562 e-data [12] OCTET STRING OPTIONAL,
3563 ...,
3564 typed-data [13] TYPED-DATA OPTIONAL,
3565 nonce [14] Nonce OPTIONAL,
3566 lang-tag [15] LangTag OPTIONAL,
3567 ...
3568 }, { }, { ku-KrbError-cksum }
3569 }
3572 ctime, cusec
3573 Client's time, if known from a KDC-REQ or AP-REQ.
3575 stime, susec
3576 KDC or application server's current time.
3578 error-code
3579 Numeric error code designating the error.
3583 Yu Expires: Sep 2007 [Page 64]
3584 \f
3585 Internet-Draft rfc1510ter-04 05 Mar 2007
3587 crealm, cname
3588 Client's realm and name, if known.
3590 realm, sname
3591 server's realm and name. [ XXX what if these aren't known? ]
3593 e-text
3594 Human-readable text providing additional details for the error.
3596 e-data
3597 This field contains additional data about the error for use by
3598 the client to help it recover from or handle the error. If the
3599 "error-code" is "kdc-err-preauth-required", then the e-data
3600 field will contain an encoding of a sequence of padata fields,
3601 each corresponding to an acceptable pre-authentication method
3602 and optionally containing data for the method:
3604 METHOD-DATA ::= SEQUENCE OF PA-DATA
3607 For error codes defined in this document other than "kdc-err-
3608 preauth-required", the format and contents of the e-data field
3609 are implementation-defined. Similarly, for future error codes,
3610 the format and contents of the e-data field are implementation-
3611 defined unless specified.
3613 lang-tag
3614 Indicates the language of the message in the "e-text" field. It
3615 is only present in the extensible KRB-ERROR.
3617 nonce
3618 is the nonce from a KDC-REQ. It is only present in the
3619 extensible KRB-ERROR.
3621 typed-data
3622 TYPED-DATA is a typed hole allowing for additional data to be
3623 returned in error conditions, since "e-data" is insufficiently
3624 flexible for some purposes. TYPED-DATA is only present in the
3625 extensible KRB-ERROR.
3627 TDType ::= TH-id
3629 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
3630 data-type [0] TDType,
3631 data-value [1] OCTET STRING OPTIONAL
3632 }
3639 Yu Expires: Sep 2007 [Page 65]
3640 \f
3641 Internet-Draft rfc1510ter-04 05 Mar 2007
3643 10. Session Key Exchange
3645 Session key exchange consists of the AP-REQ and AP-REP messages. The
3646 client sends the AP-REQ message, and the service responds with an
3647 AP-REP message if mutual authentication is desired. Following
3648 session key exchange, the client and service share a secret session
3649 key, or possibly a subsesion key, which can be used to protect
3650 further communications. Additionally, the session key exchange
3651 process can establish initial sequence numbers which the client and
3652 service can use to detect replayed messages.
3654 10.1. AP-REQ
3656 An AP-REQ message contains a ticket and a authenticator. The
3657 authenticator is ciphertext encrypted with the session key contained
3658 in the ticket. The plaintext contents of the authenticator are:
3660 -- plaintext of authenticator
3661 Authenticator1510 ::= [APPLICATION 2] SEQUENCE {
3662 authenticator-vno [0] INTEGER (5),
3663 crealm [1] RealmIA5,
3664 cname [2] PrincipalNameIA5,
3665 cksum [3] Checksum {{ key-session },
3666 { ku-Authenticator-cksum |
3667 ku-pa-TGSReq-cksum }} OPTIONAL,
3668 cusec [4] Microseconds,
3669 ctime [5] KerberosTime,
3670 subkey [6] EncryptionKey OPTIONAL,
3671 seq-number [7] SeqNum32 OPTIONAL,
3672 authorization-data [8] AuthorizationData OPTIONAL
3673 }
3675 AuthenticatorExt ::= [APPLICATION 35] SEQUENCE {
3676 authenticator-vno [0] INTEGER (5),
3677 crealm [1] RealmExt,
3678 cname [2] PrincipalNameExt,
3679 cksum [3] Checksum {{ key-session },
3680 { ku-Authenticator-cksum |
3681 ku-pa-TGSReq-cksum }} OPTIONAL,
3682 cusec [4] Microseconds,
3683 ctime [5] KerberosTime,
3684 subkey [6] EncryptionKey OPTIONAL,
3685 seq-number [7] SeqNum OPTIONAL,
3686 authorization-data [8] AuthorizationData OPTIONAL,
3687 ...
3688 }
3690 The complete definition of AP-REQ is:
3695 Yu Expires: Sep 2007 [Page 66]
3696 \f
3697 Internet-Draft rfc1510ter-04 05 Mar 2007
3699 AP-REQ ::= CHOICE {
3700 rfc1510 AP-REQ-1510,
3701 ext AP-REQ-EXT
3702 }
3705 AP-REQ-1510 ::= [APPLICATION 14] SEQUENCE {
3706 pvno [0] INTEGER (5),
3707 msg-type [1] INTEGER (14),
3708 ap-options [2] APOptions,
3709 ticket [3] Ticket1510,
3710 authenticator [4] EncryptedData {
3711 Authenticator1510,
3712 { key-session },
3713 { ku-APReq-authenticator |
3714 ku-pa-TGSReq-authenticator }
3715 }
3716 }
3719 AP-REQ-EXT ::= [APPLICATION 18] Signed {
3720 [APPLICATION 18] SEQUENCE {
3721 pvno [0] INTEGER (5),
3722 msg-type [1] INTEGER (18),
3723 ap-options [2] APOptions,
3724 ticket [3] Ticket,
3725 authenticator [4] EncryptedData {
3726 AuthenticatorExt,
3727 { key-session },
3728 { ku-APReq-authenticator |
3729 ku-pa-TGSReq-authenticator }
3730 },
3731 ...,
3732 extensions [5] ApReqExtensions OPTIONAL,
3733 lang-tag [6] SEQUENCE (SIZE (1..MAX))
3734 OF LangTag OPTIONAL,
3735 ...
3736 }, { key-session }, { ku-APReq-cksum }
3737 }
3740 APOptions ::= KerberosFlags { APOptionsBits }
3742 APOptionsBits ::= BIT STRING {
3743 reserved (0),
3744 use-session-key (1),
3745 mutual-required (2)
3746 }
3751 Yu Expires: Sep 2007 [Page 67]
3752 \f
3753 Internet-Draft rfc1510ter-04 05 Mar 2007
3755 10.2. AP-REP
3757 An AP-REP message provides mutual authentication of the service to
3758 the client.
3760 EncAPRepPart ::= CHOICE {
3761 rfc1510 EncAPRepPart1510,
3762 ext EncAPRepPartExt
3763 }
3766 EncAPRepPart1510 ::= [APPLICATION 27] SEQUENCE {
3767 ctime [0] KerberosTime,
3768 cusec [1] Microseconds,
3769 subkey [2] EncryptionKey OPTIONAL,
3770 seq-number [3] SeqNum32 OPTIONAL
3771 }
3774 EncAPRepPartExt ::= [APPLICATION 31] SEQUENCE {
3775 ctime [0] KerberosTime,
3776 cusec [1] Microseconds,
3777 subkey [2] EncryptionKey OPTIONAL,
3778 seq-number [3] SeqNum OPTIONAL,
3779 ...,
3780 authorization-data [4] AuthorizationData OPTIONAL,
3781 ...
3782 }
3785 AP-REP ::= CHOICE {
3786 rfc1510 AP-REP-1510,
3787 ext AP-REP-EXT
3788 }
3791 AP-REP-1510 ::= [APPLICATION 15] SEQUENCE {
3792 pvno [0] INTEGER (5),
3793 msg-type [1] INTEGER (15),
3794 enc-part [2] EncryptedData {
3795 EncApRepPart1510,
3796 { key-session | key-subsession }, { ku-EncAPRepPart }}
3797 }
3807 Yu Expires: Sep 2007 [Page 68]
3808 \f
3809 Internet-Draft rfc1510ter-04 05 Mar 2007
3811 AP-REP-EXT ::= [APPLICATION 19] Signed {
3812 [APPLICATION 19] SEQUENCE {
3813 pvno [0] INTEGER (5),
3814 msg-type [1] INTEGER (19),
3815 enc-part [2] EncryptedData {
3816 EncAPRepPartExt,
3817 { key-session | key-subsession },
3818 { ku-EncAPRepPart }},
3819 ...,
3820 extensions [3] ApRepExtensions OPTIONAL,
3821 ...
3822 }, { key-session | key-subsession }, { ku-APRep-cksum }
3823 }
3826 11. Session Key Use
3828 Once a session key has been established, the client and server can
3829 use several kinds of messages to securely transmit data. KRB-SAFE
3830 provides integrity protection for application data, while KRB-PRIV
3831 provides confidentiality along with integrity protection. The KRB-
3832 CRED message provides a means of securely forwarding credentials from
3833 the client host to the server host.
3835 11.1. KRB-SAFE
3837 The KRB-SAFE message provides integrity protection for an included
3838 cleartext message.
3840 KRB-SAFE ::= CHOICE {
3841 rfc1510 KRB-SAFE-1510,
3842 ext KRB-SAFE-EXT
3843 }
3846 KRB-SAFE-BODY ::= SEQUENCE {
3847 user-data [0] OCTET STRING,
3848 timestamp [1] KerberosTime OPTIONAL,
3849 usec [2] Microseconds OPTIONAL,
3850 seq-number [3] SeqNum OPTIONAL,
3851 s-address [4] HostAddress,
3852 r-address [5] HostAddress OPTIONAL,
3853 ... -- ASN.1 extensions must be excluded
3854 -- when sending to rfc1510 implementations
3855 }
3858 11.2. KRB-PRIV
3860 The KRB-PRIV message provides confidentiality and integrity
3861 protection.
3863 Yu Expires: Sep 2007 [Page 69]
3864 \f
3865 Internet-Draft rfc1510ter-04 05 Mar 2007
3867 KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
3868 pvno [0] INTEGER (5),
3869 msg-type [1] INTEGER (21),
3870 enc-part [3] EncryptedData {
3871 EncKrbPrivPart,
3872 { key-session | key-subsession },
3873 { ku-EncKrbPrivPart }},
3874 ...
3875 }
3878 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
3879 user-data [0] OCTET STRING,
3880 timestamp [1] KerberosTime OPTIONAL,
3881 usec [2] Microseconds OPTIONAL,
3882 seq-number [3] SeqNum OPTIONAL,
3883 s-address [4] HostAddress -- sender's addr --,
3884 r-address [5] HostAddress OPTIONAL -- recip's addr --,
3885 ... -- ASN.1 extensions must be excluded
3886 -- when sending to rfc1510 implementations
3887 }
3890 11.3. KRB-CRED
3892 The KRB-CRED message provides a means of securely transferring
3893 credentials from the client to the service.
3895 KRB-CRED ::= CHOICE {
3896 rfc1510 KRB-CRED-1510,
3897 ext KRB-CRED-EXT
3898 }
3901 KRB-CRED-1510 ::= [APPLICATION 22] SEQUENCE {
3902 pvno [0] INTEGER (5),
3903 msg-type [1] INTEGER (22),
3904 tickets [2] SEQUENCE OF Ticket,
3905 enc-part [3] EncryptedData {
3906 EncKrbCredPart,
3907 { key-session | key-subsession },
3908 { ku-EncKrbCredPart }}
3909 }
3919 Yu Expires: Sep 2007 [Page 70]
3920 \f
3921 Internet-Draft rfc1510ter-04 05 Mar 2007
3923 KRB-CRED-EXT ::= [APPLICATION 24] Signed {
3924 [APPLICATION 24] SEQUENCE {
3925 pvno [0] INTEGER (5),
3926 msg-type [1] INTEGER (24),
3927 tickets [2] SEQUENCE OF Ticket,
3928 enc-part [3] EncryptedData {
3929 EncKrbCredPart,
3930 { key-session | key-subsession },
3931 { ku-EncKrbCredPart }},
3932 ...
3933 }, { key-session | key-subsession }, { ku-KrbCred-cksum }
3934 }
3938 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
3939 ticket-info [0] SEQUENCE OF KrbCredInfo,
3940 nonce [1] Nonce OPTIONAL,
3941 timestamp [2] KerberosTime OPTIONAL,
3942 usec [3] Microseconds OPTIONAL,
3943 s-address [4] HostAddress OPTIONAL,
3944 r-address [5] HostAddress OPTIONAL
3945 }
3948 KrbCredInfo ::= SEQUENCE {
3949 key [0] EncryptionKey,
3950 prealm [1] Realm OPTIONAL,
3951 pname [2] PrincipalName OPTIONAL,
3952 flags [3] TicketFlags OPTIONAL,
3953 authtime [4] KerberosTime OPTIONAL,
3954 starttime [5] KerberosTime OPTIONAL,
3955 endtime [6] KerberosTime OPTIONAL,
3956 renew-till [7] KerberosTime OPTIONAL,
3957 srealm [8] Realm OPTIONAL,
3958 sname [9] PrincipalName OPTIONAL,
3959 caddr [10] HostAddresses OPTIONAL
3960 }
3963 12. Security Considerations
3965 12.1. Time Synchronization
3967 Time synchronization between the KDC and application servers is
3968 necessary to prevent acceptance of expired tickets.
3970 Time synchronization is needed between application servers and
3971 clients to prevent replay attacks if a replay cache is being used.
3972 If negotiated subsession keys are used to encrypt application data,
3973 replay caches may not be necessary.
3975 Yu Expires: Sep 2007 [Page 71]
3976 \f
3977 Internet-Draft rfc1510ter-04 05 Mar 2007
3979 12.2. Replays
3981 12.3. Principal Name Reuse
3983 See Section 5.3.
3985 12.4. Password Guessing
3987 12.5. Forward Secrecy
3989 [from RFC4120 10.; needs some rewriting]
3991 The Kerberos protocol in its basic form does not provide perfect
3992 forward secrecy for communications. If traffic has been recorded by
3993 an eavesdropper, then messages encrypted using the KRB-PRIV message,
3994 or messages encrypted using application-specific encryption under
3995 keys exchanged using Kerberos can be decrypted if any of the user's,
3996 application server's, or KDC's key is subsequently discovered. This
3997 is because the session key used to encrypt such messages is
3998 transmitted over the network encrypted in the key of the application
3999 server, and also encrypted under the session key from the user's
4000 ticket-granting ticket when returned to the user in the TGS-REP
4001 message. The session key from the ticket-granting ticket was sent to
4002 the user in the AS-REP message encrypted in the user's secret key,
4003 and embedded in the ticket-granting ticket, which was encrypted in
4004 the key of the KDC. Application requiring perfect forward secrecy
4005 must exchange keys through mechanisms that provide such assurance,
4006 but may use Kerberos for authentication of the encrypted channel
4007 established through such other means.
4009 12.6. Authorization
4011 As an authentication service, Kerberos provides a means of verifying
4012 the identity of principals on a network. Kerberos does not, by
4013 itself, provide authorization. Applications SHOULD NOT accept the
4014 mere issuance of a service ticket by the Kerberos server as granting
4015 authority to use the service.
4017 12.7. Login Authentication
4019 Some applications, particularly those which provide login access when
4020 provided with a password, SHOULD NOT treat successful acquisition of
4021 credentials as sufficient proof of the user's identity. An attacker
4022 posing as a user could generate an illegitimate KDC-REP message which
4023 decrypts properly. To authenticate a user logging on to a local
4024 system, the credentials obtained SHOULD be used in a TGS exchange to
4025 obtain credentials for a local service. Successful use of those
4026 credentials to authenticate to the local service assures that the
4027 initially obtained credentials are from a valid KDC.
4031 Yu Expires: Sep 2007 [Page 72]
4032 \f
4033 Internet-Draft rfc1510ter-04 05 Mar 2007
4035 13. IANA Considerations
4037 [ needs more work ]
4039 Each use of Int32 in this document defines a number space. [ XXX
4040 enumerate these ] Negative numbers are reserved for private use;
4041 local and experimental extensions should use these values. Zero is
4042 reserved and may not be assigned.
4044 Typed hole contents may be identified by either Int32 values or by
4045 RELATIVE-OID values. Since RELATIVE-OIDs define a hierarchical
4046 namespace, assignments to the top level of the RELATIVE-OID space may
4047 be made on a first-come, first-served basis.
4049 14. Acknowledgments
4051 Much of the text here is adapted from RFC 4120. The description of
4052 the general form of the extensibility framework was derived from text
4053 by Sam Hartman. Some text concerning internationalization of
4054 internationalized domain names in principal names and realm names was
4055 contributed by Jeffrey Altman and Jeffrey Hutzelman.
4057 Appendices
4059 A. ASN.1 Module (Normative)
4061 KerberosV5Spec3 {
4062 iso(1) identified-organization(3) dod(6) internet(1)
4063 security(5) kerberosV5(2) modules(4) krb5spec3(4)
4064 } DEFINITIONS EXPLICIT TAGS ::= BEGIN
4067 -- OID arc for KerberosV5
4068 --
4069 -- This OID may be used to identify Kerberos protocol messages
4070 -- encapsulated in other protocols.
4071 --
4072 -- This OID also designates the OID arc for KerberosV5-related
4073 -- OIDs.
4074 --
4075 -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its
4076 -- OID.
4077 id-krb5 OBJECT IDENTIFIER ::= {
4078 iso(1) identified-organization(3) dod(6) internet(1)
4079 security(5) kerberosV5(2)
4080 }
4087 Yu Expires: Sep 2007 [Page 73]
4088 \f
4089 Internet-Draft rfc1510ter-04 05 Mar 2007
4091 -- top-level type
4092 --
4093 -- Applications should not directly reference any types
4094 -- other than KRB-PDU and its component types.
4095 --
4096 KRB-PDU ::= CHOICE {
4097 ticket Ticket,
4098 as-req AS-REQ,
4099 as-rep AS-REP,
4100 tgs-req TGS-REQ,
4101 tgs-rep TGS-REP,
4102 ap-req AP-REQ,
4103 ap-rep AP-REP,
4104 krb-safe KRB-SAFE,
4105 krb-priv KRB-PRIV,
4106 krb-cred KRB-CRED,
4107 tgt-req TGT-REQ,
4108 krb-error KRB-ERROR,
4109 ...
4110 }
4113 --
4114 -- *** basic types
4115 --
4118 -- signed values representable in 32 bits
4119 --
4120 -- These are often used as assigned numbers for various things.
4121 Int32 ::= INTEGER (-2147483648..2147483647)
4124 -- Typed hole identifiers
4125 TH-id ::= CHOICE {
4126 int32 Int32,
4127 rel-oid RELATIVE-OID
4128 }
4131 -- unsigned 32 bit values
4132 UInt32 ::= INTEGER (0..4294967295)
4135 -- unsigned 64 bit values
4136 UInt64 ::= INTEGER (0..18446744073709551615)
4139 -- sequence numbers
4140 SeqNum ::= UInt64
4143 Yu Expires: Sep 2007 [Page 74]
4144 \f
4145 Internet-Draft rfc1510ter-04 05 Mar 2007
4147 -- nonces
4148 Nonce ::= UInt64
4151 -- microseconds
4152 Microseconds ::= INTEGER (0..999999)
4155 KerberosTime ::= GeneralizedTime (CONSTRAINED BY {
4156 -- MUST NOT include fractional seconds
4157 })
4160 -- used for names and for error messages
4161 KerberosString ::= CHOICE {
4162 ia5 GeneralString (IA5String),
4163 utf8 UTF8String,
4164 ... -- no extension may be sent
4165 -- to an rfc1510 implementation --
4166 }
4169 -- IA5 choice only; useful for constraints
4170 KerberosStringIA5 ::= KerberosString
4171 (WITH COMPONENTS { ia5 PRESENT })
4173 -- IA5 excluded; useful for constraints
4174 KerberosStringExt ::= KerberosString
4175 (WITH COMPONENTS { ia5 ABSENT })
4178 -- used for language tags
4179 LangTag ::= PrintableString
4180 (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
4199 Yu Expires: Sep 2007 [Page 75]
4200 \f
4201 Internet-Draft rfc1510ter-04 05 Mar 2007
4203 -- assigned numbers for name types (used in principal names)
4204 NameType ::= Int32
4206 -- Name type not known
4207 nt-unknown NameType ::= 0
4208 -- Just the name of the principal as in DCE, or for users
4209 nt-principal NameType ::= 1
4210 -- Service and other unique instance (krbtgt)
4211 nt-srv-inst NameType ::= 2
4212 -- Service with host name as instance (telnet, rcommands)
4213 nt-srv-hst NameType ::= 3
4214 -- Service with host as remaining components
4215 nt-srv-xhst NameType ::= 4
4216 -- Unique ID
4217 nt-uid NameType ::= 5
4218 -- Encoded X.509 Distingished name [RFC 2253]
4219 nt-x500-principal NameType ::= 6
4220 -- Name in form of SMTP email name (e.g. user@foo.com)
4221 nt-smtp-name NameType ::= 7
4222 -- Enterprise name - may be mapped to principal name
4223 nt-enterprise NameType ::= 10
4224 -- reserved principal names [krb-wg-naming]
4225 nt-wellknown NameType ::= 11
4228 PrincipalName { StrType } ::= SEQUENCE {
4229 name-type [0] NameType,
4230 -- May have zero elements, or individual elements may be
4231 -- zero-length, but this is NOT RECOMMENDED.
4232 name-string [1] SEQUENCE OF KerberosString (StrType)
4233 }
4236 -- IA5 only
4237 PrincipalNameIA5 ::= PrincipalName { KerberosStringIA5 }
4238 -- IA5 excluded
4239 PrincipalNameExt ::= PrincipalName { KerberosStringExt }
4240 -- Either one?
4241 PrincipalNameEither ::= PrincipalName { KerberosString }
4255 Yu Expires: Sep 2007 [Page 76]
4256 \f
4257 Internet-Draft rfc1510ter-04 05 Mar 2007
4259 Realm { StrType } ::= KerberosString (StrType)
4261 -- IA5 only
4262 RealmIA5 ::= Realm { KerberosStringIA5 }
4264 -- IA5 excluded
4265 RealmExt ::= Realm { KerberosStringExt }
4267 -- Either
4268 RealmEither ::= Realm { KerberosString }
4272 KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
4273 (CONSTRAINED BY {
4274 -- MUST be a valid value of -- NamedBits
4276 -- but if the value to be sent would be truncated to
4277 -- shorter than 32 bits according to DER, the value MUST be
4278 -- padded with trailing zero bits to 32 bits. Otherwise,
4279 -- no trailing zero bits may be present.
4281 })
4284 AddrType ::= Int32
4286 HostAddress ::= SEQUENCE {
4287 addr-type [0] AddrType,
4288 address [1] OCTET STRING
4289 }
4291 -- NOTE: HostAddresses is always used as an OPTIONAL field and
4292 -- should not be a zero-length SEQUENCE OF.
4293 --
4294 -- The extensible messages explicitly constrain this to be
4295 -- non-empty.
4296 HostAddresses ::= SEQUENCE OF HostAddress
4299 --
4300 -- *** crypto-related types and assignments
4301 --
4311 Yu Expires: Sep 2007 [Page 77]
4312 \f
4313 Internet-Draft rfc1510ter-04 05 Mar 2007
4315 -- Assigned numbers denoting encryption mechanisms.
4316 EType ::= Int32
4318 -- assigned numbers for encryption schemes
4319 et-des-cbc-crc EType ::= 1
4320 et-des-cbc-md4 EType ::= 2
4321 et-des-cbc-md5 EType ::= 3
4322 -- [reserved] 4
4323 et-des3-cbc-md5 EType ::= 5
4324 -- [reserved] 6
4325 et-des3-cbc-sha1 EType ::= 7
4326 et-dsaWithSHA1-CmsOID EType ::= 9
4327 et-md5WithRSAEncryption-CmsOID EType ::= 10
4328 et-sha1WithRSAEncryption-CmsOID EType ::= 11
4329 et-rc2CBC-EnvOID EType ::= 12
4330 et-rsaEncryption-EnvOID EType ::= 13
4331 et-rsaES-OAEP-ENV-OID EType ::= 14
4332 et-des-ede3-cbc-Env-OID EType ::= 15
4333 et-des3-cbc-sha1-kd EType ::= 16
4334 -- AES
4335 et-aes128-cts-hmac-sha1-96 EType ::= 17
4336 -- AES
4337 et-aes256-cts-hmac-sha1-96 EType ::= 18
4338 -- Microsoft
4339 et-rc4-hmac EType ::= 23
4340 -- Microsoft
4341 et-rc4-hmac-exp EType ::= 24
4342 -- opaque; PacketCable
4343 et-subkey-keymaterial EType ::= 65
4367 Yu Expires: Sep 2007 [Page 78]
4368 \f
4369 Internet-Draft rfc1510ter-04 05 Mar 2007
4371 -- Assigned numbers denoting key usages.
4372 KeyUsage ::= UInt32
4374 --
4375 -- Actual identifier names are provisional and subject to
4376 -- change.
4377 --
4378 ku-pa-enc-ts KeyUsage ::= 1
4379 ku-Ticket KeyUsage ::= 2
4380 ku-EncASRepPart KeyUsage ::= 3
4381 ku-TGSReqAuthData-sesskey KeyUsage ::= 4
4382 ku-TGSReqAuthData-subkey KeyUsage ::= 5
4383 ku-pa-TGSReq-cksum KeyUsage ::= 6
4384 ku-pa-TGSReq-authenticator KeyUsage ::= 7
4385 ku-EncTGSRepPart-sesskey KeyUsage ::= 8
4386 ku-EncTGSRepPart-subkey KeyUsage ::= 9
4387 ku-Authenticator-cksum KeyUsage ::= 10
4388 ku-APReq-authenticator KeyUsage ::= 11
4389 ku-EncAPRepPart KeyUsage ::= 12
4390 ku-EncKrbPrivPart KeyUsage ::= 13
4391 ku-EncKrbCredPart KeyUsage ::= 14
4392 ku-KrbSafe-cksum KeyUsage ::= 15
4393 ku-ad-KDCIssued-cksum KeyUsage ::= 19
4423 Yu Expires: Sep 2007 [Page 79]
4424 \f
4425 Internet-Draft rfc1510ter-04 05 Mar 2007
4427 -- The following numbers are provisional...
4428 -- conflicts may exist elsewhere.
4429 ku-Ticket-cksum KeyUsage ::= 29
4430 ku-ASReq-cksum KeyUsage ::= 30
4431 ku-TGSReq-cksum KeyUsage ::= 31
4432 ku-ASRep-cksum KeyUsage ::= 32
4433 ku-TGSRep-cksum KeyUsage ::= 33
4434 ku-APReq-cksum KeyUsage ::= 34
4435 ku-APRep-cksum KeyUsage ::= 35
4436 ku-KrbCred-cksum KeyUsage ::= 36
4437 ku-KrbError-cksum KeyUsage ::= 37
4438 ku-KDCRep-cksum KeyUsage ::= 38
4440 ku-kg-acceptor-seal KeyUsage ::= 22
4441 ku-kg-acceptor-sign KeyUsage ::= 23
4442 ku-kg-intiator-seal KeyUsage ::= 24
4443 ku-kg-intiator-sign KeyUsage ::= 25
4445 -- KeyUsage values 25..27 used by hardware preauth?
4447 -- for KINK
4448 ku-kink-encrypt KeyUsage ::= 39
4449 ku-kink-cksum KeyUsage ::= 40
4451 -- IAKERB
4452 ku-iakerb-finished KeyUsage ::= 41
4479 Yu Expires: Sep 2007 [Page 80]
4480 \f
4481 Internet-Draft rfc1510ter-04 05 Mar 2007
4483 -- KeyToUse identifies which key is to be used to encrypt or
4484 -- sign a given value.
4485 --
4486 -- Values of KeyToUse are never actually transmitted over the
4487 -- wire, or even used directly by the implementation in any
4488 -- way, as key usages are; it exists primarily to identify
4489 -- which key gets used for what purpose. Thus, the specific
4490 -- numeric values associated with this type are irrelevant.
4491 KeyToUse ::= ENUMERATED {
4492 -- unspecified
4493 key-unspecified,
4494 -- server long term key
4495 key-server,
4496 -- client long term key
4497 key-client,
4498 -- key selected by KDC for encryption of a KDC-REP
4499 key-kdc-rep,
4500 -- session key from ticket
4501 key-session,
4502 -- subsession key negotiated via AP-REQ/AP-REP
4503 key-subsession,
4504 ...
4505 }
4508 EncryptionKey ::= SEQUENCE {
4509 keytype [0] EType,
4510 keyvalue [1] OCTET STRING
4511 }
4535 Yu Expires: Sep 2007 [Page 81]
4536 \f
4537 Internet-Draft rfc1510ter-04 05 Mar 2007
4540 -- "Type" specifies which ASN.1 type is encrypted to the
4541 -- ciphertext in the EncryptedData. "Keys" specifies a set of
4542 -- keys of which one key may be used to encrypt the data.
4543 -- "KeyUsages" specifies a set of key usages, one of which may
4544 -- be used to encrypt.
4545 --
4546 -- None of the parameters is transmitted over the wire.
4547 EncryptedData {
4548 Type, KeyToUse:Keys, KeyUsage:KeyUsages
4549 } ::= SEQUENCE {
4550 etype [0] EType,
4551 kvno [1] UInt32 OPTIONAL,
4552 cipher [2] OCTET STRING (CONSTRAINED BY {
4553 -- must be encryption of --
4554 OCTET STRING (CONTAINING Type),
4555 -- with one of the keys -- KeyToUse:Keys,
4556 -- with key usage being one of --
4557 KeyUsage:KeyUsages
4558 }),
4559 ...
4560 }
4564 CksumType ::= Int32
4566 -- The parameters specify which key to use to produce the
4567 -- signature, as well as which key usage to use. The
4568 -- parameters are not actually sent over the wire.
4569 Checksum {
4570 KeyToUse:Keys, KeyUsage:KeyUsages
4571 } ::= SEQUENCE {
4572 cksumtype [0] CksumType,
4573 checksum [1] OCTET STRING (CONSTRAINED BY {
4574 -- signed using one of the keys --
4575 KeyToUse:Keys,
4576 -- with key usage being one of --
4577 KeyUsage:KeyUsages
4578 })
4579 }
4591 Yu Expires: Sep 2007 [Page 82]
4592 \f
4593 Internet-Draft rfc1510ter-04 05 Mar 2007
4595 -- a Checksum that must contain the checksum
4596 -- of a particular type
4597 ChecksumOf {
4598 Type, KeyToUse:Keys, KeyUsage:KeyUsages
4599 } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
4600 ...,
4601 checksum (CONSTRAINED BY {
4602 -- must be checksum of --
4603 OCTET STRING (CONTAINING Type)
4604 })
4605 })
4608 -- parameterized type for wrapping authenticated plaintext
4609 Signed {
4610 InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
4611 } ::= SEQUENCE {
4612 cksum [0] ChecksumOf {
4613 InnerType, Keys, KeyUsages
4614 } OPTIONAL,
4615 inner [1] InnerType,
4616 ...
4617 }
4620 --
4621 -- *** Tickets
4622 --
4625 Ticket ::= CHOICE {
4626 rfc1510 Ticket1510,
4627 ext TicketExt
4628 }
4631 Ticket1510 ::= [APPLICATION 1] SEQUENCE {
4632 tkt-vno [0] INTEGER (5),
4633 realm [1] RealmIA5,
4634 sname [2] PrincipalNameIA5,
4635 enc-part [3] EncryptedData {
4636 EncTicketPart1510, { key-server }, { ku-Ticket }
4637 }
4638 }
4647 Yu Expires: Sep 2007 [Page 83]
4648 \f
4649 Internet-Draft rfc1510ter-04 05 Mar 2007
4651 TicketExt ::= [APPLICATION 4] Signed {
4652 [APPLICATION 4] SEQUENCE {
4653 tkt-vno [0] INTEGER (5),
4654 realm [1] RealmExt,
4655 sname [2] PrincipalNameExt,
4656 enc-part [3] EncryptedData {
4657 EncTicketPartExt, { key-server }, { ku-Ticket }
4658 },
4659 ...,
4660 extensions [4] TicketExtensions OPTIONAL,
4661 ...
4662 },
4663 { key-ticket }, { ku-Ticket-cksum }
4664 }
4667 -- Encrypted part of ticket
4668 EncTicketPart ::= CHOICE {
4669 rfc1510 EncTicketPart1510,
4670 ext EncTicketPartExt
4671 }
4674 EncTicketPart1510 ::= [APPLICATION 3] SEQUENCE {
4675 flags [0] TicketFlags,
4676 key [1] EncryptionKey,
4677 crealm [2] RealmIA5,
4678 cname [3] PrincipalNameIA5,
4679 transited [4] TransitedEncoding,
4680 authtime [5] KerberosTime,
4681 starttime [6] KerberosTime OPTIONAL,
4682 endtime [7] KerberosTime,
4683 renew-till [8] KerberosTime OPTIONAL,
4684 caddr [9] HostAddresses OPTIONAL,
4685 authorization-data [10] AuthorizationData OPTIONAL
4686 }
4703 Yu Expires: Sep 2007 [Page 84]
4704 \f
4705 Internet-Draft rfc1510ter-04 05 Mar 2007
4707 EncTicketPartExt ::= [APPLICATION 5] SEQUENCE {
4708 flags [0] TicketFlags,
4709 key [1] EncryptionKey,
4710 crealm [2] RealmExt,
4711 cname [3] PrincipalNameExt,
4712 transited [4] TransitedEncoding,
4713 authtime [5] KerberosTime,
4714 starttime [6] KerberosTime OPTIONAL,
4715 endtime [7] KerberosTime,
4716 renew-till [8] KerberosTime OPTIONAL,
4717 caddr [9] HostAddresses OPTIONAL,
4718 authorization-data [10] AuthorizationData OPTIONAL,
4719 ...,
4720 }
4723 --
4724 -- *** Authorization Data
4725 --
4728 ADType ::= TH-id
4730 AuthorizationData ::= SEQUENCE OF SEQUENCE {
4731 ad-type [0] ADType,
4732 ad-data [1] OCTET STRING
4733 }
4736 ad-if-relevant ADType ::= int32 : 1
4738 -- Encapsulates another AuthorizationData.
4739 -- Intended for application servers; receiving application
4740 -- servers MAY ignore.
4741 AD-IF-RELEVANT ::= AuthorizationData
4744 -- KDC-issued privilege attributes
4745 ad-kdcissued ADType ::= int32 : 4
4747 AD-KDCIssued ::= SEQUENCE {
4748 ad-checksum [0] ChecksumOf {
4749 AuthorizationData, { key-session },
4750 { ku-ad-KDCIssued-cksum }},
4751 i-realm [1] Realm OPTIONAL,
4752 i-sname [2] PrincipalName OPTIONAL,
4753 elements [3] AuthorizationData
4754 }
4759 Yu Expires: Sep 2007 [Page 85]
4760 \f
4761 Internet-Draft rfc1510ter-04 05 Mar 2007
4763 ad-and-or ADType ::= int32 : 5
4765 AD-AND-OR ::= SEQUENCE {
4766 condition-count [0] Int32,
4767 elements [1] AuthorizationData
4768 }
4771 -- KDCs MUST interpret any AuthorizationData wrapped in this.
4772 ad-mandatory-for-kdc ADType ::= int32 : 8
4773 AD-MANDATORY-FOR-KDC ::= AuthorizationData
4776 ad-initial-verified-cas ADType ::= int32 : 9
4779 TrType ::= TH-id -- must be registered
4781 -- encoded Transited field
4782 TransitedEncoding ::= SEQUENCE {
4783 tr-type [0] TrType,
4784 contents [1] OCTET STRING
4785 }
4788 TEType ::= TH-id
4790 -- ticket extensions: for TicketExt only
4791 TicketExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
4792 te-type [0] TEType,
4793 te-data [1] OCTET STRING
4794 }
4815 Yu Expires: Sep 2007 [Page 86]
4816 \f
4817 Internet-Draft rfc1510ter-04 05 Mar 2007
4819 TicketFlags ::= KerberosFlags { TicketFlagsBits }
4821 TicketFlagsBits ::= BIT STRING {
4822 reserved (0),
4823 forwardable (1),
4824 forwarded (2),
4825 proxiable (3),
4826 proxy (4),
4827 may-postdate (5),
4828 postdated (6),
4829 invalid (7),
4830 renewable (8),
4831 initial (9),
4832 pre-authent (10),
4833 hw-authent (11),
4834 transited-policy-checked (12),
4835 ok-as-delegate (13),
4836 anonymous (14),
4837 cksummed-ticket (15)
4838 }
4841 --
4842 -- *** KDC protocol
4843 --
4846 AS-REQ ::= CHOICE {
4847 rfc1510 AS-REQ-1510,
4848 ext AS-REQ-EXT
4849 }
4850 AS-REQ-1510 ::= [APPLICATION 10] KDC-REQ-1510
4851 -- AS-REQ must include client name
4853 AS-REQ-EXT ::= [APPLICATION 6] Signed {
4854 [APPLICATION 6] KDC-REQ-EXT,
4855 { key-client }, { ku-ASReq-cksum }
4856 }
4857 -- AS-REQ must include client name
4871 Yu Expires: Sep 2007 [Page 87]
4872 \f
4873 Internet-Draft rfc1510ter-04 05 Mar 2007
4875 TGS-REQ ::= CHOICE {
4876 rfc1510 TGS-REQ-1510,
4877 ext TGS-REQ-EXT
4878 }
4880 TGS-REQ-1510 ::= [APPLICATION 12] KDC-REQ-1510
4882 TGS-REQ-EXT ::= [APPLICATION 8] Signed {
4883 [APPLICATION 8] KDC-REQ-EXT,
4884 { key-session }, { ku-TGSReq-cksum }
4885 }
4888 KDC-REQ-1510 ::= SEQUENCE {
4889 -- NOTE: first tag is [1], not [0]
4890 pvno [1] INTEGER (5),
4891 msg-type [2] INTEGER ( 10 -- AS-REQ --
4892 | 12 -- TGS-REQ -- ),
4893 padata [3] SEQUENCE OF PA-DATA OPTIONAL,
4894 req-body [4] KDC-REQ-BODY-1510
4895 }
4898 KDC-REQ-EXT ::= SEQUENCE {
4899 pvno [1] INTEGER (5),
4900 msg-type [2] INTEGER ( 6 -- AS-REQ --
4901 | 8 -- TGS-REQ -- ),
4902 padata [3] SEQUENCE (SIZE (1..MAX))
4903 OF PA-DATA OPTIONAL,
4904 req-body [4] KDC-REQ-BODY-EXT,
4905 ...
4906 }
4927 Yu Expires: Sep 2007 [Page 88]
4928 \f
4929 Internet-Draft rfc1510ter-04 05 Mar 2007
4931 KDC-REQ-BODY-1510 ::= SEQUENCE {
4932 kdc-options [0] KDCOptions,
4933 cname [1] PrincipalNameIA5 OPTIONAL
4934 -- Used only in AS-REQ --,
4936 realm [2] RealmIA5
4937 -- Server's realm; also client's in AS-REQ --,
4939 sname [3] PrincipalNameIA5 OPTIONAL,
4940 from [4] KerberosTime OPTIONAL,
4941 till [5] KerberosTime,
4942 rtime [6] KerberosTime OPTIONAL,
4943 nonce [7] Nonce32,
4944 etype [8] SEQUENCE OF EType
4945 -- in preference order --,
4947 addresses [9] HostAddresses OPTIONAL,
4948 enc-authorization-data [10] EncryptedData {
4949 AuthorizationData, { key-session | key-subsession },
4950 { ku-TGSReqAuthData-subkey |
4951 ku-TGSReqAuthData-sesskey }
4952 } OPTIONAL,
4954 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
4955 -- NOTE: not empty --
4956 }
4983 Yu Expires: Sep 2007 [Page 89]
4984 \f
4985 Internet-Draft rfc1510ter-04 05 Mar 2007
4987 KDC-REQ-BODY-EXT ::= SEQUENCE {
4988 kdc-options [0] KDCOptions,
4989 cname [1] PrincipalName OPTIONAL
4990 -- Used only in AS-REQ --,
4992 realm [2] Realm
4993 -- Server's realm; also client's in AS-REQ --,
4995 sname [3] PrincipalName OPTIONAL,
4996 from [4] KerberosTime OPTIONAL,
4997 till [5] KerberosTime OPTIONAL
4998 -- was required in rfc1510;
4999 -- still required for compat versions
5000 -- of messages --,
5002 rtime [6] KerberosTime OPTIONAL,
5003 nonce [7] Nonce,
5004 etype [8] SEQUENCE OF EType
5005 -- in preference order --,
5007 addresses [9] HostAddresses OPTIONAL,
5008 enc-authorization-data [10] EncryptedData {
5009 AuthorizationData, { key-session | key-subsession },
5010 { ku-TGSReqAuthData-subkey |
5011 ku-TGSReqAuthData-sesskey }
5012 } OPTIONAL,
5014 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
5015 -- NOTE: not empty --,
5016 ...
5017 lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF
5018 LangTag OPTIONAL,
5019 ...
5020 }
5039 Yu Expires: Sep 2007 [Page 90]
5040 \f
5041 Internet-Draft rfc1510ter-04 05 Mar 2007
5043 KDCOptions ::= KerberosFlags { KDCOptionsBits }
5045 KDCOptionsBits ::= BIT STRING {
5046 reserved (0),
5047 forwardable (1),
5048 forwarded (2),
5049 proxiable (3),
5050 proxy (4),
5051 allow-postdate (5),
5052 postdated (6),
5053 unused7 (7),
5054 renewable (8),
5055 unused9 (9),
5056 unused10 (10),
5057 unused11 (11),
5058 unused12 (12),
5059 unused13 (13),
5060 requestanonymous (14),
5061 canonicalize (15),
5062 disable-transited-check (26),
5063 renewable-ok (27),
5064 enc-tkt-in-skey (28),
5065 renew (30),
5066 validate (31)
5067 -- XXX need "need ticket1" flag?
5068 }
5071 AS-REP ::= CHOICE {
5072 rfc1510 AS-REP-1510,
5073 ext AS-REP-EXT
5074 }
5075 AS-REP-1510 ::= [APPLICATION 11] KDC-REP-1510
5076 AS-REP-EXT ::= [APPLICATION 7] Signed {
5077 [APPLICATION 7] KDC-REP-EXT,
5078 { key-reply }, { ku-ASRep-cksum }
5079 }
5082 TGS-REP ::= CHOICE {
5083 rfc1510 TGS-REP-1510,
5084 ext TGS-REP-EXT
5085 }
5086 TGS-REP-1510 ::= [APPLICATION 13] KDC-REP-1510 {
5087 EncTGSRepPart1510 }
5089 TGS-REP-EXT ::= [APPLICATION 9] Signed {
5090 [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
5091 { key-reply }, { ku-TGSRep-cksum }
5092 }
5095 Yu Expires: Sep 2007 [Page 91]
5096 \f
5097 Internet-Draft rfc1510ter-04 05 Mar 2007
5099 KDC-REP-1510 { EncPart } ::= SEQUENCE {
5100 pvno [0] INTEGER (5),
5101 msg-type [1] INTEGER (11 -- AS-REP.rfc1510 -- |
5102 13 -- TGS.rfc1510 -- ),
5103 padata [2] SEQUENCE OF PA-DATA OPTIONAL,
5104 crealm [3] RealmIA5,
5105 cname [4] PrincipalNameIA5,
5106 ticket [5] Ticket,
5108 enc-part [6] EncryptedData {
5109 EncPart,
5110 { key-reply },
5111 -- maybe reach into EncryptedData in AS-REP/TGS-REP
5112 -- definitions to apply constraints on key usages?
5113 { ku-EncASRepPart -- if AS-REP -- |
5114 ku-EncTGSRepPart-subkey -- if TGS-REP and
5115 -- using Authenticator
5116 -- session key -- |
5117 ku-EncTGSRepPart-sesskey -- if TGS-REP and using
5118 -- subsession key -- }
5119 }
5120 }
5151 Yu Expires: Sep 2007 [Page 92]
5152 \f
5153 Internet-Draft rfc1510ter-04 05 Mar 2007
5155 KDC-REP-EXT { EncPart } ::= SEQUENCE {
5156 pvno [0] INTEGER (5),
5157 msg-type [1] INTEGER (7 -- AS-REP.ext -- |
5158 9 -- TGS-REP.ext -- ),
5159 padata [2] SEQUENCE OF PA-DATA OPTIONAL,
5160 crealm [3] RealmExt,
5161 cname [4] PrincipalNameExt,
5162 ticket [5] Ticket,
5164 enc-part [6] EncryptedData {
5165 EncPart,
5166 { key-reply },
5167 -- maybe reach into EncryptedData in AS-REP/TGS-REP
5168 -- definitions to apply constraints on key usages?
5169 { ku-EncASRepPart -- if AS-REP -- |
5170 ku-EncTGSRepPart-subkey -- if TGS-REP and
5171 -- using Authenticator
5172 -- session key -- |
5173 ku-EncTGSRepPart-sesskey -- if TGS-REP and using
5174 -- subsession key -- }
5175 },
5177 ...,
5178 -- In extensible version, KDC signs original request
5179 -- to avoid replay attacks against client.
5180 req-cksum [7] ChecksumOf { CHOICE {
5181 as-req AS-REQ,
5182 tgs-req TGS-REQ
5183 }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
5184 lang-tag [8] LangTag OPTIONAL,
5185 ...
5186 }
5207 Yu Expires: Sep 2007 [Page 93]
5208 \f
5209 Internet-Draft rfc1510ter-04 05 Mar 2007
5211 EncASRepPart1510 ::= [APPLICATION 25] EncKDCRepPart1510
5212 EncTGSRepPart1510 ::= [APPLICATION 26] EncKDCRepPart1510
5214 EncASRepPartExt ::= [APPLICATION 32] EncKDCRepPartExt
5215 EncTGSRepPartExt ::= [APPLICATION 33] EncKDCRepPartExt
5217 EncKDCRepPart1510 ::= SEQUENCE {
5218 key [0] EncryptionKey,
5219 last-req [1] LastReq,
5220 nonce [2] Nonce32,
5221 key-expiration [3] KerberosTime OPTIONAL,
5222 flags [4] TicketFlags,
5223 authtime [5] KerberosTime,
5224 starttime [6] KerberosTime OPTIONAL,
5225 endtime [7] KerberosTime,
5226 renew-till [8] KerberosTime OPTIONAL,
5227 srealm [9] RealmIA5,
5228 sname [10] PrincipalNameIA5,
5229 caddr [11] HostAddresses OPTIONAL
5230 }
5232 EncKDCRepPartExt ::= SEQUENCE {
5233 key [0] EncryptionKey,
5234 last-req [1] LastReq,
5235 nonce [2] Nonce,
5236 key-expiration [3] KerberosTime OPTIONAL,
5237 flags [4] TicketFlags,
5238 authtime [5] KerberosTime,
5239 starttime [6] KerberosTime OPTIONAL,
5240 endtime [7] KerberosTime,
5241 renew-till [8] KerberosTime OPTIONAL,
5242 srealm [9] Realm,
5243 sname [10] PrincipalName,
5244 caddr [11] HostAddresses OPTIONAL,
5245 ...
5246 }
5249 LRType ::= TH-id
5250 LastReq ::= SEQUENCE OF SEQUENCE {
5251 lr-type [0] LRType,
5252 lr-value [1] KerberosTime
5253 }
5256 --
5257 -- *** preauth
5258 --
5263 Yu Expires: Sep 2007 [Page 94]
5264 \f
5265 Internet-Draft rfc1510ter-04 05 Mar 2007
5267 PaDataType ::= TH-id
5268 PaDataOID ::= RELATIVE-OID
5270 PA-DATA ::= SEQUENCE {
5271 -- NOTE: first tag is [1], not [0]
5272 padata-type [1] PaDataType,
5273 padata-value [2] OCTET STRING
5274 }
5277 -- AP-REQ authenticating a TGS-REQ
5278 pa-tgs-req PaDataType ::= int32 : 1
5279 PA-TGS-REQ ::= AP-REQ
5282 -- Encrypted timestamp preauth
5283 -- Encryption key used is client's long-term key.
5284 pa-enc-timestamp PaDataType ::= int32 : 2
5286 PA-ENC-TIMESTAMP ::= EncryptedData {
5287 PA-ENC-TS-ENC, { key-client }, { ku-pa-enc-ts }
5288 }
5290 PA-ENC-TS-ENC ::= SEQUENCE {
5291 patimestamp [0] KerberosTime -- client's time --,
5292 pausec [1] Microseconds OPTIONAL
5293 }
5296 -- Hints returned in AS-REP or KRB-ERROR to help client
5297 -- choose a password-derived key, either for preauthentication
5298 -- or for decryption of the reply.
5299 pa-etype-info PaDataType ::= int32 : 11
5301 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY
5303 ETYPE-INFO-ENTRY ::= SEQUENCE {
5304 etype [0] EType,
5305 salt [1] OCTET STRING OPTIONAL
5306 }
5319 Yu Expires: Sep 2007 [Page 95]
5320 \f
5321 Internet-Draft rfc1510ter-04 05 Mar 2007
5323 -- Similar to etype-info, but with parameters provided for
5324 -- the string-to-key function.
5325 pa-etype-info2 PaDataType ::= int32 : 19
5327 ETYPE-INFO2 ::= SEQUENCE (SIZE (1..MAX))
5328 OF ETYPE-INFO-ENTRY
5330 ETYPE-INFO2-ENTRY ::= SEQUENCE {
5331 etype [0] EType,
5332 salt [1] KerberosString OPTIONAL,
5333 s2kparams [2] OCTET STRING OPTIONAL
5334 }
5337 -- Obsolescent. Salt for client long-term key
5338 -- Its character encoding is unspecified.
5339 pa-pw-salt PaDataType ::= int32 : 3
5341 -- The "padata-value" does not encode an ASN.1 type.
5342 -- Instead, "padata-value" must consist of the salt string to
5343 -- be used by the client, in an unspecified character
5344 -- encoding.
5347 -- An extensible AS-REQ may be sent as a padata in a
5348 -- non-extensible AS-REQ to allow for backwards compatibility.
5349 pa-as-req PaDataType ::= int32 : 42 -- provisional
5350 PA-AS-REQ ::= AS-REQ (WITH COMPONENTS ext)
5353 --
5354 -- *** Session key exchange
5355 --
5358 AP-REQ ::= CHOICE {
5359 rfc1510 AP-REQ-1510,
5360 ext AP-REQ-EXT
5361 }
5375 Yu Expires: Sep 2007 [Page 96]
5376 \f
5377 Internet-Draft rfc1510ter-04 05 Mar 2007
5379 AP-REQ-1510 ::= [APPLICATION 14] SEQUENCE {
5380 pvno [0] INTEGER (5),
5381 msg-type [1] INTEGER (14),
5382 ap-options [2] APOptions,
5383 ticket [3] Ticket1510,
5384 authenticator [4] EncryptedData {
5385 Authenticator1510,
5386 { key-session },
5387 { ku-APReq-authenticator |
5388 ku-pa-TGSReq-authenticator }
5389 }
5390 }
5393 AP-REQ-EXT ::= [APPLICATION 18] Signed {
5394 [APPLICATION 18] SEQUENCE {
5395 pvno [0] INTEGER (5),
5396 msg-type [1] INTEGER (18),
5397 ap-options [2] APOptions,
5398 ticket [3] Ticket,
5399 authenticator [4] EncryptedData {
5400 AuthenticatorExt,
5401 { key-session },
5402 { ku-APReq-authenticator |
5403 ku-pa-TGSReq-authenticator }
5404 },
5405 ...,
5406 extensions [5] ApReqExtensions OPTIONAL,
5407 lang-tag [6] SEQUENCE (SIZE (1..MAX))
5408 OF LangTag OPTIONAL,
5409 ...
5410 }, { key-session }, { ku-APReq-cksum }
5411 }
5414 ApReqExtType ::= TH-id
5416 ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
5417 apReqExt-Type [0] ApReqExtType,
5418 apReqExt-Data [1] OCTET STRING
5419 }
5422 APOptions ::= KerberosFlags { APOptionsBits }
5424 APOptionsBits ::= BIT STRING {
5425 reserved (0),
5426 use-session-key (1),
5427 mutual-required (2)
5428 }
5431 Yu Expires: Sep 2007 [Page 97]
5432 \f
5433 Internet-Draft rfc1510ter-04 05 Mar 2007
5435 -- plaintext of authenticator
5436 Authenticator1510 ::= [APPLICATION 2] SEQUENCE {
5437 authenticator-vno [0] INTEGER (5),
5438 crealm [1] RealmIA5,
5439 cname [2] PrincipalNameIA5,
5440 cksum [3] Checksum {{ key-session },
5441 { ku-Authenticator-cksum |
5442 ku-pa-TGSReq-cksum }} OPTIONAL,
5443 cusec [4] Microseconds,
5444 ctime [5] KerberosTime,
5445 subkey [6] EncryptionKey OPTIONAL,
5446 seq-number [7] SeqNum32 OPTIONAL,
5447 authorization-data [8] AuthorizationData OPTIONAL
5448 }
5450 AuthenticatorExt ::= [APPLICATION 35] SEQUENCE {
5451 authenticator-vno [0] INTEGER (5),
5452 crealm [1] RealmExt,
5453 cname [2] PrincipalNameExt,
5454 cksum [3] Checksum {{ key-session },
5455 { ku-Authenticator-cksum |
5456 ku-pa-TGSReq-cksum }} OPTIONAL,
5457 cusec [4] Microseconds,
5458 ctime [5] KerberosTime,
5459 subkey [6] EncryptionKey OPTIONAL,
5460 seq-number [7] SeqNum OPTIONAL,
5461 authorization-data [8] AuthorizationData OPTIONAL,
5462 ...
5463 }
5466 AP-REP ::= CHOICE {
5467 rfc1510 AP-REP-1510,
5468 ext AP-REP-EXT
5469 }
5472 AP-REP-1510 ::= [APPLICATION 15] SEQUENCE {
5473 pvno [0] INTEGER (5),
5474 msg-type [1] INTEGER (15),
5475 enc-part [2] EncryptedData {
5476 EncApRepPart1510,
5477 { key-session | key-subsession }, { ku-EncAPRepPart }}
5478 }
5487 Yu Expires: Sep 2007 [Page 98]
5488 \f
5489 Internet-Draft rfc1510ter-04 05 Mar 2007
5491 AP-REP-EXT ::= [APPLICATION 19] Signed {
5492 [APPLICATION 19] SEQUENCE {
5493 pvno [0] INTEGER (5),
5494 msg-type [1] INTEGER (19),
5495 enc-part [2] EncryptedData {
5496 EncAPRepPartExt,
5497 { key-session | key-subsession },
5498 { ku-EncAPRepPart }},
5499 ...,
5500 extensions [3] ApRepExtensions OPTIONAL,
5501 ...
5502 }, { key-session | key-subsession }, { ku-APRep-cksum }
5503 }
5506 ApRepExtType ::= TH-id
5508 ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
5509 apRepExt-Type [0] ApRepExtType,
5510 apRepExt-Data [1] OCTET STRING
5511 }
5514 EncAPRepPart ::= CHOICE {
5515 rfc1510 EncAPRepPart1510,
5516 ext EncAPRepPartExt
5517 }
5520 EncAPRepPart1510 ::= [APPLICATION 27] SEQUENCE {
5521 ctime [0] KerberosTime,
5522 cusec [1] Microseconds,
5523 subkey [2] EncryptionKey OPTIONAL,
5524 seq-number [3] SeqNum32 OPTIONAL
5525 }
5528 EncAPRepPartExt ::= [APPLICATION 31] SEQUENCE {
5529 ctime [0] KerberosTime,
5530 cusec [1] Microseconds,
5531 subkey [2] EncryptionKey OPTIONAL,
5532 seq-number [3] SeqNum OPTIONAL,
5533 ...,
5534 authorization-data [4] AuthorizationData OPTIONAL,
5535 ...
5536 }
5543 Yu Expires: Sep 2007 [Page 99]
5544 \f
5545 Internet-Draft rfc1510ter-04 05 Mar 2007
5547 --
5548 -- *** Application messages
5549 --
5552 KRB-SAFE ::= CHOICE {
5553 rfc1510 KRB-SAFE-1510,
5554 ext KRB-SAFE-EXT
5555 }
5558 KRB-SAFE-1510 ::= [APPLICATION 20] SEQUENCE {
5559 pvno [0] INTEGER (5),
5560 msg-type [1] INTEGER (20),
5561 safe-body [2] KRB-SAFE-BODY,
5562 cksum [3] ChecksumOf {
5563 KRB-SAFE-BODY,
5564 { key-session | key-subsession }, { ku-KrbSafe-cksum }}
5565 }
5568 -- Has safe-body optional to allow for GSS-MIC type
5569 -- functionality
5570 KRB-SAFE-EXT ::= [APPLICATION 34] SEQUENCE {
5571 pvno [0] INTEGER (5),
5572 msg-type [1] INTEGER (20),
5573 safe-body [2] KRB-SAFE-BODY OPTIONAL,
5574 cksum [3] ChecksumOf {
5575 KRB-SAFE-BODY,
5576 { key-session | key-subsession },
5577 { ku-KrbSafe-cksum }},
5578 ...
5579 }
5582 KRB-SAFE-BODY ::= SEQUENCE {
5583 user-data [0] OCTET STRING,
5584 timestamp [1] KerberosTime OPTIONAL,
5585 usec [2] Microseconds OPTIONAL,
5586 seq-number [3] SeqNum OPTIONAL,
5587 s-address [4] HostAddress,
5588 r-address [5] HostAddress OPTIONAL,
5589 ... -- ASN.1 extensions must be excluded
5590 -- when sending to rfc1510 implementations
5591 }
5599 Yu Expires: Sep 2007 [Page 100]
5600 \f
5601 Internet-Draft rfc1510ter-04 05 Mar 2007
5603 KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
5604 pvno [0] INTEGER (5),
5605 msg-type [1] INTEGER (21),
5606 enc-part [3] EncryptedData {
5607 EncKrbPrivPart,
5608 { key-session | key-subsession },
5609 { ku-EncKrbPrivPart }},
5610 ...
5611 }
5614 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
5615 user-data [0] OCTET STRING,
5616 timestamp [1] KerberosTime OPTIONAL,
5617 usec [2] Microseconds OPTIONAL,
5618 seq-number [3] SeqNum OPTIONAL,
5619 s-address [4] HostAddress -- sender's addr --,
5620 r-address [5] HostAddress OPTIONAL -- recip's addr --,
5621 ... -- ASN.1 extensions must be excluded
5622 -- when sending to rfc1510 implementations
5623 }
5626 KRB-CRED ::= CHOICE {
5627 rfc1510 KRB-CRED-1510,
5628 ext KRB-CRED-EXT
5629 }
5632 KRB-CRED-1510 ::= [APPLICATION 22] SEQUENCE {
5633 pvno [0] INTEGER (5),
5634 msg-type [1] INTEGER (22),
5635 tickets [2] SEQUENCE OF Ticket,
5636 enc-part [3] EncryptedData {
5637 EncKrbCredPart,
5638 { key-session | key-subsession },
5639 { ku-EncKrbCredPart }}
5640 }
5655 Yu Expires: Sep 2007 [Page 101]
5656 \f
5657 Internet-Draft rfc1510ter-04 05 Mar 2007
5659 KRB-CRED-EXT ::= [APPLICATION 24] Signed {
5660 [APPLICATION 24] SEQUENCE {
5661 pvno [0] INTEGER (5),
5662 msg-type [1] INTEGER (24),
5663 tickets [2] SEQUENCE OF Ticket,
5664 enc-part [3] EncryptedData {
5665 EncKrbCredPart,
5666 { key-session | key-subsession },
5667 { ku-EncKrbCredPart }},
5668 ...
5669 }, { key-session | key-subsession }, { ku-KrbCred-cksum }
5670 }
5674 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
5675 ticket-info [0] SEQUENCE OF KrbCredInfo,
5676 nonce [1] Nonce OPTIONAL,
5677 timestamp [2] KerberosTime OPTIONAL,
5678 usec [3] Microseconds OPTIONAL,
5679 s-address [4] HostAddress OPTIONAL,
5680 r-address [5] HostAddress OPTIONAL
5681 }
5684 KrbCredInfo ::= SEQUENCE {
5685 key [0] EncryptionKey,
5686 prealm [1] Realm OPTIONAL,
5687 pname [2] PrincipalName OPTIONAL,
5688 flags [3] TicketFlags OPTIONAL,
5689 authtime [4] KerberosTime OPTIONAL,
5690 starttime [5] KerberosTime OPTIONAL,
5691 endtime [6] KerberosTime OPTIONAL,
5692 renew-till [7] KerberosTime OPTIONAL,
5693 srealm [8] Realm OPTIONAL,
5694 sname [9] PrincipalName OPTIONAL,
5695 caddr [10] HostAddresses OPTIONAL
5696 }
5699 TGT-REQ ::= [APPLICATION 16] SEQUENCE {
5700 pvno [0] INTEGER (5),
5701 msg-type [1] INTEGER (16),
5702 sname [2] PrincipalName OPTIONAL,
5703 srealm [3] Realm OPTIONAL,
5704 ...
5705 }
5711 Yu Expires: Sep 2007 [Page 102]
5712 \f
5713 Internet-Draft rfc1510ter-04 05 Mar 2007
5715 --
5716 -- *** Error messages
5717 --
5720 ErrCode ::= Int32
5722 KRB-ERROR ::= CHOICE {
5723 rfc1510 KRB-ERROR-1510,
5724 ext KRB-ERROR-EXT
5725 }
5728 KRB-ERROR-1510 ::= [APPLICATION 30] SEQUENCE {
5729 pvno [0] INTEGER (5),
5730 msg-type [1] INTEGER (30),
5731 ctime [2] KerberosTime OPTIONAL,
5732 cusec [3] Microseconds OPTIONAL,
5733 stime [4] KerberosTime,
5734 susec [5] Microseconds,
5735 error-code [6] ErrCode,
5736 crealm [7] RealmIA5 OPTIONAL,
5737 cname [8] PrincipalNameIA5 OPTIONAL,
5738 realm [9] RealmIA5 -- Correct realm --,
5739 sname [10] PrincipalNameIA5 -- Correct name --,
5740 e-text [11] KerberosString OPTIONAL,
5741 e-data [12] OCTET STRING OPTIONAL
5742 }
5767 Yu Expires: Sep 2007 [Page 103]
5768 \f
5769 Internet-Draft rfc1510ter-04 05 Mar 2007
5771 KRB-ERROR-EXT ::= [APPLICATION 23] Signed {
5772 [APPLICATION 23] SEQUENCE{
5773 pvno [0] INTEGER (5),
5774 msg-type [1] INTEGER (23),
5775 ctime [2] KerberosTime OPTIONAL,
5776 cusec [3] Microseconds OPTIONAL,
5777 stime [4] KerberosTime,
5778 susec [5] Microseconds,
5779 error-code [6] ErrCode,
5780 crealm [7] Realm OPTIONAL,
5781 cname [8] PrincipalName OPTIONAL,
5782 realm [9] Realm -- Correct realm --,
5783 sname [10] PrincipalName -- Correct name --,
5784 e-text [11] KerberosString OPTIONAL,
5785 e-data [12] OCTET STRING OPTIONAL,
5786 ...,
5787 typed-data [13] TYPED-DATA OPTIONAL,
5788 nonce [14] Nonce OPTIONAL,
5789 lang-tag [15] LangTag OPTIONAL,
5790 ...
5791 }, { }, { ku-KrbError-cksum }
5792 }
5795 METHOD-DATA ::= SEQUENCE OF PA-DATA
5798 TDType ::= TH-id
5800 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
5801 data-type [0] TDType,
5802 data-value [1] OCTET STRING OPTIONAL
5803 }
5806 td-dh-parameters TDType ::= int32 : 109
5807 -- iakerb
5808 td-iakerb-finished TDType ::= int32 : 110
5809 -- pkinit-alg-agility
5810 td-cms-data-digest-algorithms TDType ::= int32 : 111
5811 -- pkinit-alg-agility
5812 td-cert-digest-algorithms TDType ::= int32 : 112
5823 Yu Expires: Sep 2007 [Page 104]
5824 \f
5825 Internet-Draft rfc1510ter-04 05 Mar 2007
5827 --
5828 -- *** Error codes
5829 --
5831 -- No error
5832 kdc-err-none ErrCode ::= 0
5833 -- Client's entry in database has expired
5834 kdc-err-name-exp ErrCode ::= 1
5835 -- Server's entry in database has expired
5836 kdc-err-service-exp ErrCode ::= 2
5837 -- Requested protocol version number not supported
5838 kdc-err-bad-pvno ErrCode ::= 3
5839 -- Client's key encrypted in old master key
5840 kdc-err-c-old-mast-kvno ErrCode ::= 4
5841 -- Server's key encrypted in old master key
5842 kdc-err-s-old-mast-kvno ErrCode ::= 5
5843 -- Client not found in Kerberos database
5844 kdc-err-c-principal-unknown ErrCode ::= 6
5845 -- Server not found in Kerberos database
5846 kdc-err-s-principal-unknown ErrCode ::= 7
5847 -- Multiple principal entries in database
5848 kdc-err-principal-not-unique ErrCode ::= 8
5849 -- The client or server has a null key
5850 kdc-err-null-key ErrCode ::= 9
5851 -- Ticket not eligible for postdating
5852 kdc-err-cannot-postdate ErrCode ::= 10
5853 -- Requested start time is later than end time
5854 kdc-err-never-valid ErrCode ::= 11
5855 -- KDC policy rejects request
5856 kdc-err-policy ErrCode ::= 12
5857 -- KDC cannot accommodate requested option
5858 kdc-err-badoption ErrCode ::= 13
5859 -- KDC has no support for encryption type
5860 kdc-err-etype-nosupp ErrCode ::= 14
5861 -- KDC has no support for checksum type
5862 kdc-err-sumtype-nosupp ErrCode ::= 15
5863 -- KDC has no support for padata type
5864 kdc-err-padata-type-nosupp ErrCode ::= 16
5865 -- KDC has no support for transited type
5866 kdc-err-trtype-nosupp ErrCode ::= 17
5867 -- Clients credentials have been revoked
5868 kdc-err-client-revoked ErrCode ::= 18
5869 -- Credentials for server have been revoked
5870 kdc-err-service-revoked ErrCode ::= 19
5871 -- TGT has been revoked
5872 kdc-err-tgt-revoked ErrCode ::= 20
5879 Yu Expires: Sep 2007 [Page 105]
5880 \f
5881 Internet-Draft rfc1510ter-04 05 Mar 2007
5883 -- Client not yet valid - try again later
5884 kdc-err-client-notyet ErrCode ::= 21
5885 -- Server not yet valid - try again later
5886 kdc-err-service-notyet ErrCode ::= 22
5887 -- Password has expired - change password to reset
5888 kdc-err-key-expired ErrCode ::= 23
5889 -- Pre-authentication information was invalid
5890 kdc-err-preauth-failed ErrCode ::= 24
5891 -- Additional pre-authenticationrequired
5892 kdc-err-preauth-required ErrCode ::= 25
5893 -- Requested server and ticket don't match
5894 kdc-err-server-nomatch ErrCode ::= 26
5895 -- Server principal valid for user2user only
5896 kdc-err-must-use-user2user ErrCode ::= 27
5897 -- KDC Policy rejects transited path
5898 kdc-err-path-not-accpeted ErrCode ::= 28
5899 -- A service is not available
5900 kdc-err-svc-unavailable ErrCode ::= 29
5901 -- Integrity check on decrypted field failed
5902 krb-ap-err-bad-integrity ErrCode ::= 31
5903 -- Ticket expired
5904 krb-ap-err-tkt-expired ErrCode ::= 32
5905 -- Ticket not yet valid
5906 krb-ap-err-tkt-nyv ErrCode ::= 33
5907 -- Request is a replay
5908 krb-ap-err-repeat ErrCode ::= 34
5909 -- The ticket isn't for us
5910 krb-ap-err-not-us ErrCode ::= 35
5911 -- Ticket and authenticator don't match
5912 krb-ap-err-badmatch ErrCode ::= 36
5913 -- Clock skew too great
5914 krb-ap-err-skew ErrCode ::= 37
5915 -- Incorrect net address
5916 krb-ap-err-badaddr ErrCode ::= 38
5917 -- Protocol version mismatch
5918 krb-ap-err-badversion ErrCode ::= 39
5919 -- Invalid msg type
5920 krb-ap-err-msg-type ErrCode ::= 40
5935 Yu Expires: Sep 2007 [Page 106]
5936 \f
5937 Internet-Draft rfc1510ter-04 05 Mar 2007
5939 -- Message stream modified
5940 krb-ap-err-modified ErrCode ::= 41
5941 -- Message out of order
5942 krb-ap-err-badorder ErrCode ::= 42
5943 -- Specified version of key is not available
5944 krb-ap-err-badkeyver ErrCode ::= 44
5945 -- Service key not available
5946 krb-ap-err-nokey ErrCode ::= 45
5947 -- Mutual authentication failed
5948 krb-ap-err-mut-fail ErrCode ::= 46
5949 -- Incorrect message direction
5950 krb-ap-err-baddirection ErrCode ::= 47
5951 -- Alternative authentication method required
5952 krb-ap-err-method ErrCode ::= 48
5953 -- Incorrect sequence number in message
5954 krb-ap-err-badseq ErrCode ::= 49
5955 -- Inappropriate type of checksum in message
5956 krb-ap-err-inapp-cksum ErrCode ::= 50
5957 -- Policy rejects transited path
5958 krb-ap-path-not-accepted ErrCode ::= 51
5959 -- Response too big for UDP, retry with TCP
5960 krb-err-response-too-big ErrCode ::= 52
5961 -- Generic error (description in e-text)
5962 krb-err-generic ErrCode ::= 60
5991 Yu Expires: Sep 2007 [Page 107]
5992 \f
5993 Internet-Draft rfc1510ter-04 05 Mar 2007
5995 -- Field is too long for this implementation
5996 krb-err-field-toolong ErrCode ::= 61
5997 -- Reserved for PKINIT
5998 kdc-error-client-not-trusted ErrCode ::= 62
5999 -- Reserved for PKINIT
6000 kdc-error-kdc-not-trusted ErrCode ::= 63
6001 -- Reserved for PKINIT
6002 kdc-error-invalid-sig ErrCode ::= 64
6003 -- Reserved for PKINIT
6004 kdc-err-key-too-weak ErrCode ::= 65
6005 -- Reserved for PKINIT
6006 kdc-err-certificate-mismatch ErrCode ::= 66
6007 -- No TGT available to validate USER-TO-USER
6008 krb-ap-err-no-tgt ErrCode ::= 67
6009 -- USER-TO-USER TGT issued different KDC
6010 kdc-err-wrong-realm ErrCode ::= 68
6011 -- Ticket must be for USER-TO-USER
6012 krb-ap-err-user-to-user-required ErrCode ::= 69
6013 -- Reserved for PKINIT
6014 kdc-err-cant-verify-certificate ErrCode ::= 70
6015 -- Reserved for PKINIT
6016 kdc-err-invalid-certificate ErrCode ::= 71
6017 -- Reserved for PKINIT
6018 kdc-err-revoked-certificate ErrCode ::= 72
6019 -- Reserved for PKINIT
6020 kdc-err-revocation-status-unknown ErrCode ::= 73
6021 -- Reserved for PKINIT
6022 kdc-err-revocation-status-unavailable ErrCode ::= 74
6023 -- Reserved for PKINIT
6024 kdc-err-client-name-mismatch ErrCode ::= 75
6025 -- Reserved for PKINIT
6026 kdc-err-kdc-name-mismatch ErrCode ::= 76
6027 -- Reserved for PKINIT
6028 kdc-err-inconsistent-key-purpose ErrCode ::= 77
6029 -- Reserved for PKINIT
6030 kdc-err-digest-in-cert-not-accepted ErrCode ::= 78
6031 -- Reserved for PKINIT
6032 kdc-err-pa-checksum-must-be-included ErrCode ::= 79
6033 -- Reserved for PKINIT
6034 kdc-err-digest-in-signed-data-not-accepted ErrCode ::= 80
6035 -- Reserved for PKINIT
6036 kdc-err-public-key-encryption-not-supported ErrCode ::= 81
6037 -- [krb-wg-naming]
6038 krb-ap-err-wellknown-principal-name-unsupported ErrCode ::= 82
6039 -- [krb-wg-naming]
6040 krb-ap-err-wellknown-realm-name-not-supported ErrCode ::= 83
6041 -- [krb-wg-naming]
6042 krb-ap-err-reserved-principal-name-unknown ErrCode ::= 84
6043 -- IAKERB proxy could not find a KDC
6044 krb-ap-err-iakerb-kdc-not-found ErrCode ::= 85
6045 -- KDC did not respond to IAKERB proxy
6047 Yu Expires: Sep 2007 [Page 108]
6048 \f
6049 Internet-Draft rfc1510ter-04 05 Mar 2007
6051 krb-ap-err-iakerb-kdc-no-response ErrCode ::= 86
6054 END
6057 B. Kerberos and Character Encodings (Informative)
6059 [adapted from RFC4120 5.2.1]
6061 The original specification of the Kerberos protocol in RFC 1510 uses
6062 GeneralString in numerous places for human-readable string data.
6063 Historical implementations of Kerberos cannot utilize the full power
6064 of GeneralString. This ASN.1 type requires the use of designation
6065 and invocation escape sequences as specified in ISO 2022 | ECMA-35
6066 [ISO2022] to switch character sets, and the default character set
6067 that is designated as G0 is the ISO 646 | ECMA-6 [ISO646]
6068 International Reference Version (IRV) (aka U.S. ASCII), which mostly
6069 works.
6071 ISO 2022 | ECMA-35 defines four character-set code elements (G0..G3)
6072 and two Control-function code elements (C0..C1). DER previously
6073 [X690-1997] prohibited the designation of character sets as any but
6074 the G0 and C0 sets. This had the side effect of prohibiting the use
6075 of (ISO Latin) character-sets such as ISO 8859-1 [ISO8859-1] or any
6076 other character-sets that utilize a 96-character set, since it is
6077 prohibited by ISO 2022 | ECMA-35 to designate them as the G0 code
6078 element. Recent revisions to the ASN.1 standards resolve this
6079 contradiction.
6081 In practice, many implementations treat RFC 1510 GeneralStrings as if
6082 they were 8-bit strings of whichever character set the implementation
6083 defaults to, without regard for correct usage of character-set
6084 designation escape sequences. The default character set is often
6085 determined by the current user's operating system dependent locale.
6086 At least one major implementation places unescaped UTF-8 encoded
6087 Unicode characters in the GeneralString. This failure to conform to
6088 the GeneralString specifications results in interoperability issues
6089 when conflicting character encodings are utilized by the Kerberos
6090 clients, services, and KDC.
6092 This unfortunate situation is the result of improper documentation of
6093 the restrictions of the ASN.1 GeneralString type in prior Kerberos
6094 specifications.
6096 [the following should probably be rewritten and moved into the
6097 principal name section]
6099 For compatibility, implementations MAY choose to accept GeneralString
6100 values that contain characters other than those permitted by
6101 IA5String, but they should be aware that character set designation
6103 Yu Expires: Sep 2007 [Page 109]
6104 \f
6105 Internet-Draft rfc1510ter-04 05 Mar 2007
6107 codes will likely be absent, and that the encoding should probably be
6108 treated as locale-specific in almost every way. Implementations MAY
6109 also choose to emit GeneralString values that are beyond those
6110 permitted by IA5String, but should be aware that doing so is
6111 extraordinarily risky from an interoperability perspective.
6113 Some existing implementations use GeneralString to encode unescaped
6114 locale-specific characters. This is a violation of the ASN.1
6115 standard. Most of these implementations encode US-ASCII in the left-
6116 hand half, so as long the implementation transmits only US-ASCII, the
6117 ASN.1 standard is not violated in this regard. As soon as such an
6118 implementation encodes unescaped locale-specific characters with the
6119 high bit set, it violates the ASN.1 standard.
6121 Other implementations have been known to use GeneralString to contain
6122 a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8
6123 is a different encoding, not a 94 or 96 character "G" set as defined
6124 by ISO 2022. It is believed that these implementations do not even
6125 use the ISO 2022 escape sequence to change the character encoding.
6126 Even if implementations were to announce the change of encoding by
6127 using that escape sequence, the ASN.1 standard prohibits the use of
6128 any escape sequences other than those used to designate/invoke "G" or
6129 "C" sets allowed by GeneralString.
6131 C. Kerberos History (Informative)
6133 [Adapted from RFC4120 "BACKGROUND"]
6135 The Kerberos model is based in part on Needham and Schroeder's
6136 trusted third-party authentication protocol [NS78] and on
6137 modifications suggested by Denning and Sacco [DS81]. The original
6138 design and implementation of Kerberos Versions 1 through 4 was the
6139 work of two former Project Athena staff members, Steve Miller of
6140 Digital Equipment Corporation and Clifford Neuman (now at the
6141 Information Sciences Institute of the University of Southern
6142 California), along with Jerome Saltzer, Technical Director of Project
6143 Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other
6144 members of Project Athena have also contributed to the work on
6145 Kerberos.
6147 Version 5 of the Kerberos protocol (described in this document) has
6148 evolved from Version 4 based on new requirements and desires for
6149 features not available in Version 4. The design of Version 5 of the
6150 Kerberos protocol was led by Clifford Neuman and John Kohl with much
6151 input from the community. The development of the MIT reference
6152 implementation was led at MIT by John Kohl and Theodore Ts'o, with
6153 help and contributed code from many others. Since RFC1510 was
6154 issued, extensions and revisions to the protocol have been proposed
6155 by many individuals. Some of these proposals are reflected in this
6156 document. Where such changes involved significant effort, the
6157 document cites the contribution of the proposer.
6159 Yu Expires: Sep 2007 [Page 110]
6160 \f
6161 Internet-Draft rfc1510ter-04 05 Mar 2007
6163 Reference implementations of both version 4 and version 5 of Kerberos
6164 are publicly available and commercial implementations have been
6165 developed and are widely used. Details on the differences between
6166 Kerberos Versions 4 and 5 can be found in [KNT94].
6168 D. Notational Differences from [RFC4120]
6170 [ possible point for discussion ]
6172 [RFC4120] uses notational conventions slightly different from this
6173 document. As a derivative of RFC 1510, the text of [RFC4120] uses
6174 C-language style identifier names for defined values. In ASN.1
6175 notation, identifiers referencing defined values must begin with a
6176 lowercase letter and contain hyphen (-) characters rather than
6177 underscore (_) characters, while identifiers referencing types begin
6178 with an uppercase letter. [RFC4120] and RFC 1510 use all-uppercase
6179 identifiers with underscores to identify defined values. This has
6180 the potential to create confusion, but neither document defines
6181 values using actual ASN.1 value-assignment notation.
6183 It is debatable whether it is advantageous to write all identifier
6184 names (regardless of their ASN.1 token type) in all-uppercase letters
6185 for the purpose of emphasis in running text. The alternative is to
6186 use double-quote characters (") when ambiguity is possible.
6188 Normative References
6190 [RFC2119]
6191 S. Bradner, "Key words for use in RFC's to Indicate Requirement
6192 Levels", RFC 2119, March 1997.
6194 [RFC3490]
6195 P. Faltstrom, P. Hoffman, A. Costello, "Internationalizing
6196 Domain Names in Applications (IDNA)", RFC 3490, March 2003.
6198 [RFC3961]
6199 K. Raeburn, "Encryption and Checksum Specifications for Kerberos
6200 5", RFC 3961, February 2005.
6202 [RFC4013]
6203 Kurt D. Zeilenga, "SASLprep: Stringprep profile for user names
6204 and passwords", RFC 4013, February 2005.
6206 [RFC4291]
6207 R. Hinden and S. Deering, "IP Version 6 Addressing
6208 Architecture", RFC 4291, February 2006.
6210 [RFC4646]
6211 A. Philllips and M. Davis, "Tags for Identifying Languages",
6212 RFC 4646, January 2001.
6215 Yu Expires: Sep 2007 [Page 111]
6216 \f
6217 Internet-Draft rfc1510ter-04 05 Mar 2007
6219 [X680]
6220 "Information technology -- Abstract Syntax Notation One (ASN.1):
6221 Specification of basic notation", ITU-T Recommendation X.680
6222 (2002) | ISO/IEC 8824-1:2002.
6224 [X682]
6225 "Information technology -- Abstract Syntax Notation One (ASN.1):
6226 Constraint specification", ITU-T Recommendation X.682 (2002) |
6227 ISO/IEC 8824-3:2002.
6229 [X683]
6230 "Information technology -- Abstract Syntax Notation One (ASN.1):
6231 Parameterization of ASN.1 specifications", ITU-T Recommendation
6232 X.683 (2002) | ISO/IEC 8824-4:2002.
6234 [X690]
6235 "Information technology -- ASN.1 encoding Rules: Specification
6236 of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
6237 and Distinguished Encoding Rules (DER)", ITU-T Recommendation
6238 X.690 (2002) | ISO/IEC 8825-1:2002.
6240 Informative References
6242 [DS81]
6243 Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key
6244 Distribution Protocols," Communications of the ACM, Vol. 24(8),
6245 pp. 533-536 (August 1981).
6247 [Dub00]
6248 Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous
6249 Systems", Elsevier-Morgan Kaufmann, 2000.
6250 <http://www.oss.com/asn1/dubuisson.html>
6252 [ISO646]
6253 "7-bit coded character set", ISO/IEC 646:1991 | ECMA-6:1991.
6255 [ISO2022]
6256 "Information technology -- Character code structure and
6257 extension techniques", ISO/IEC 2022:1994 | ECMA-35:1994.
6259 [ISO8859-1]
6260 "Information technology -- 8-bit single-byte coded graphic
6261 character sets -- Part 1: Latin alphabet No. 1",
6262 ISO/IEC 8859-1:1998.
6264 [KNT94]
6265 John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
6266 Evolution of the Kerberos Authentication System". In
6267 Distributed Open Systems, pages 78-94. IEEE Computer Society
6268 Press, 1994.
6271 Yu Expires: Sep 2007 [Page 112]
6272 \f
6273 Internet-Draft rfc1510ter-04 05 Mar 2007
6275 [Lar96]
6276 John Larmouth, "Understanding OSI", International Thomson
6277 Computer Press, 1996.
6278 <http://www.isi.salford.ac.uk/books/osi.html>
6280 [Lar99]
6281 John Larmouth, "ASN.1 Complete", Elsevier-Morgan Kaufmann,
6282 1999. <http://www.oss.com/asn1/larmouth.html>
6284 [NS78]
6285 Roger M. Needham and Michael D. Schroeder, "Using Encryption for
6286 Authentication in Large Networks of Computers", Communications
6287 of the ACM, Vol. 21(12), pp. 993-999 (December, 1978).
6289 [RFC1510]
6290 J. Kohl and B. C. Neuman, "The Kerberos Network Authentication
6291 Service (v5)", RFC1510, September 1993, Status: Proposed
6292 Standard.
6294 [RFC1964]
6295 J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
6296 June 1996, Status: Proposed Standard.
6298 [RFC4120]
6299 C. Neuman, T. Yu, S. Hartman, K. Raeburn, "The Kerberos Network
6300 Authentication Service (V5)", RFC 4120, July 2005.
6302 Author's Address
6304 Tom Yu
6305 77 Massachusetts Ave
6306 Cambridge, MA 02139
6307 USA
6308 tlyu@mit.edu
6310 Full Copyright Statement
6312 Copyright (C) The IETF Trust (2007).
6314 This document is subject to the rights, licenses and restrictions
6315 contained in BCP 78, and except as set forth therein, the authors
6316 retain all their rights.
6318 This document and the information contained herein are provided on an
6319 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
6320 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
6321 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
6322 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
6323 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
6324 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
6327 Yu Expires: Sep 2007 [Page 113]
6328 \f
6329 Internet-Draft rfc1510ter-04 05 Mar 2007
6331 Intellectual Property
6333 The IETF takes no position regarding the validity or scope of any
6334 Intellectual Property Rights or other rights that might be claimed to
6335 pertain to the implementation or use of the technology described in
6336 this document or the extent to which any license under such rights
6337 might or might not be available; nor does it represent that it has
6338 made any independent effort to identify any such rights. Information
6339 on the procedures with respect to rights in RFC documents can be
6340 found in BCP 78 and BCP 79.
6342 Copies of IPR disclosures made to the IETF Secretariat and any
6343 assurances of licenses to be made available, or the result of an
6344 attempt made to obtain a general license or permission for the use of
6345 such proprietary rights by implementers or users of this
6346 specification can be obtained from the IETF on-line IPR repository at
6347 http://www.ietf.org/ipr.
6349 The IETF invites any interested party to bring to its attention any
6350 copyrights, patents or patent applications, or other proprietary
6351 rights that may cover technology that may be required to implement
6352 this standard. Please address the information to the IETF at
6353 ietf-ipr@ietf.org.
6383 Yu Expires: Sep 2007 [Page 114]
6384 \f