| blob | 52f736b160c818a4d0e19d8a99615d6da166b08a |
1 INTERNET-DRAFT Tom Yu
2 draft-yu-krb-wg-kerberos-extensions-02.txt MIT
3 Expires: 25 April 2005 25 October 2004
6 The Kerberos Network Authentication Service (Version 5)
9 Status of This Memo
12 By submitting this Internet-Draft, I certify that any applicable
13 patent or other IPR claims of which I am aware have been disclosed,
14 or will be disclosed, and any of which I become aware will be
15 disclosed, in accordance with RFC 3668.
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as Internet-
21 Drafts.
24 Internet-Drafts are draft documents valid for a maximum of six months
25 and may be updated, replaced, or obsoleted by other documents at any
26 time. It is inappropriate to use Internet-Drafts as reference
27 material or to cite them other than as "work in progress."
30 The list of current Internet-Drafts can be accessed at
33 http://www.ietf.org/ietf/1id-abstracts.txt
36 The list of Internet-Draft Shadow Directories can be accessed at
39 http://www.ietf.org/shadow.html
43 Copyright Notice
46 Copyright (C) The Internet Society (2004). All Rights Reserved.
49 Abstract
52 This document describes version 5 of the Kerberos network
53 authentication protocol. It describes a framework to allow for
54 extensions to be made to the protocol without creating
55 interoperability problems.
58 Key Words for Requirements
61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
62 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
63 to be interpreted as described in RFC 2119.
69 Yu Expires: Apr 2005 [Page 1]
70 Internet-Draft yu-krb-extensions-02 25 Oct 2004
73 Table of Contents
76 Status of This Memo .............................................. 1
77 Copyright Notice ................................................. 1
78 Abstract ......................................................... 1
79 Key Words for Requirements ....................................... 1
80 Table of Contents ................................................ 2
81 1. Introduction ................................................. 5
82 1.1. Kerberos Protocol Overview ................................. 5
83 1.2. Document Organization ...................................... 6
84 2. Compatibility Considerations ................................. 6
85 2.1. Extensibility .............................................. 7
86 2.2. Compatibility with RFC 1510 ................................ 7
87 2.3. Backwards Compatibility .................................... 7
88 2.4. 1.4.2. Sending Extensible Messages ......................... 8
89 2.5. Criticality ................................................ 8
90 2.6. Authenticating Cleartext Portions of Messages .............. 9
91 2.7. Capability Negotiation ..................................... 10
92 3. Use of ASN.1 in Kerberos ..................................... 10
93 3.1. Module Header .............................................. 11
94 3.2. Top-Level Type ............................................. 11
95 3.3. Previously Unused ASN.1 Notation (informative) ............. 12
96 3.3.1. Parameterized Types ...................................... 12
97 3.3.2. COMPONENTS OF Notation ................................... 12
98 3.3.3. Constraints .............................................. 12
99 3.4. New Types .................................................. 13
100 4. Basic Types .................................................. 14
101 4.1. Constrained Integer Types .................................. 14
102 4.2. KerberosTime ............................................... 15
103 4.3. KerberosString ............................................. 15
104 4.4. Language Tags .............................................. 16
105 4.5. KerberosFlags .............................................. 16
106 4.6. Typed Holes ................................................ 16
107 4.7. HostAddress and HostAddresses .............................. 17
108 4.7.1. Internet (IPv4) Addresses ................................ 17
109 4.7.2. Internet (IPv6) Addresses ................................ 17
110 4.7.3. DECnet Phase IV addresses ................................ 18
111 4.7.4. Netbios addresses ........................................ 18
112 4.7.5. Directional Addresses .................................... 18
113 5. Principals ................................................... 19
114 5.1. Name Types ................................................. 19
115 5.2. Principal Type Definition .................................. 19
116 5.3. Principal Name Reuse ....................................... 20
117 5.4. Realm Names ................................................ 20
118 5.5. Printable Representations of Principal Names ............... 21
119 5.6. Ticket-Granting Service Principal .......................... 21
120 5.6.1. Cross-Realm TGS Principals ............................... 21
121 6. Types Relating to Encryption ................................. 21
122 6.1. Assigned Numbers for Encryption ............................ 22
123 6.1.1. EType .................................................... 22
124 6.1.2. Key Usages ............................................... 22
127 Yu Expires: Apr 2005 [Page 2]
128 Internet-Draft yu-krb-extensions-02 25 Oct 2004
131 6.2. Which Key to Use ........................................... 23
132 6.3. EncryptionKey .............................................. 24
133 6.4. EncryptedData .............................................. 24
134 6.5. Checksums .................................................. 25
135 6.5.1. ChecksumOf ............................................... 26
136 6.5.2. Signed ................................................... 27
137 7. Tickets ...................................................... 27
138 7.1. Timestamps ................................................. 28
139 7.2. Ticket Flags ............................................... 28
140 7.2.1. Flags Relating to Initial Ticket Acquisition ............. 29
141 7.2.2. Invalid Tickets .......................................... 29
142 7.2.3. OK as Delegate ........................................... 30
143 7.2.4. Renewable Tickets ........................................ 30
144 7.2.5. Postdated Tickets ........................................ 31
145 7.2.6. Proxiable and Proxy Tickets .............................. 32
146 7.2.7. Forwarded and Forwardable Tickets ........................ 33
147 7.3. Transited Realms ........................................... 34
148 7.4. Authorization Data ......................................... 34
149 7.4.1. AD-IF-RELEVANT ........................................... 35
150 7.4.2. AD-KDCIssued ............................................. 35
151 7.4.3. AD-AND-OR ................................................ 37
152 7.4.4. AD-MANDATORY-FOR-KDC ..................................... 37
153 7.5. Encrypted Part of Ticket ................................... 37
154 7.6. Cleartext Part of Ticket ................................... 38
155 8. Credential Acquisition ....................................... 40
156 8.1. KDC-REQ .................................................... 40
157 8.2. PA-DATA .................................................... 46
158 8.3. KDC-REQ Processing ......................................... 46
159 8.3.1. Handling Replays ......................................... 46
160 8.3.2. Request Validation ....................................... 47
161 8.3.2.1. AS-REQ Authentication .................................. 47
162 8.3.2.2. TGS-REQ Authentication ................................. 47
163 8.3.2.3. Principal Validation ................................... 47
164 8.3.2.4. Checking For Revoked or Invalid Tickets ................ 48
165 8.3.3. Timestamp Handling ....................................... 48
166 8.3.3.1. AS-REQ Timestamp Processing ............................ 49
167 8.3.3.2. TGS-REQ Timestamp Processing ........................... 49
168 8.3.4. Handling Transited Realms ................................ 50
169 8.3.5. Address Processing ....................................... 50
170 8.3.6. Ticket Flag Processing ................................... 51
171 8.3.7. Key Selection ............................................ 52
172 8.3.7.1. Reply Key and Session Key Selection .................... 52
173 8.3.7.2. Ticket Key Selection ................................... 52
174 8.4. KDC-REP .................................................... 52
175 8.5. Reply Validation ........................................... 55
176 8.6. IP Transports .............................................. 55
177 8.6.1. UDP/IP transport ......................................... 55
178 8.6.2. TCP/IP transport ......................................... 56
179 8.6.3. KDC Discovery on IP Networks ............................. 57
180 8.6.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names ..... 57
181 8.6.3.2. DNS SRV records for KDC location ....................... 58
184 Yu Expires: Apr 2005 [Page 3]
185 Internet-Draft yu-krb-extensions-02 25 Oct 2004
188 8.6.3.3. KDC Discovery for Domain Style Realm Names on IP
189 Networks ............................................ 58
190 9. Errors ....................................................... 58
191 10. Session Key Exchange ........................................ 61
192 10.1. AP-REQ .................................................... 61
193 10.2. AP-REP .................................................... 63
194 11. Session Key Use ............................................. 65
195 11.1. KRB-SAFE .................................................. 65
196 11.2. KRB-PRIV .................................................. 65
197 11.3. KRB-CRED .................................................. 66
198 12. Security Considerations ..................................... 67
199 12.1. Time Synchronization ...................................... 67
200 12.2. Replays ................................................... 67
201 12.3. Principal Name Reuse ...................................... 67
202 12.4. Password Guessing ......................................... 67
203 12.5. Forward Secrecy ........................................... 67
204 12.6. Authorization ............................................. 68
205 12.7. Login Authentication ...................................... 68
206 13. IANA Considerations ......................................... 68
207 14. Acknowledgments ............................................. 69
208 Appendices ....................................................... 69
209 A. ASN.1 Module (Normative) ..................................... 69
210 B. Kerberos and Character Encodings (Informative) ...............103
211 C. Kerberos History (Informative) ...............................104
212 D. Notational Differences from [KCLAR] ..........................105
213 Normative References .............................................106
214 Informative References ...........................................106
215 Author's Address .................................................108
216 Full Copyright Statement .........................................108
241 Yu Expires: Apr 2005 [Page 4]
242 Internet-Draft yu-krb-extensions-02 25 Oct 2004
245 1. Introduction
248 The Kerberos network authentication protocol is a trusted-third-party
249 protocol utilizing symmetric-key cryptography. It assumes that all
250 communications between parties in the protocol may be arbitrarily
251 tampered with or monitored, and that the security of the overall
252 system depends only on the effectiveness of the cryptographic
253 techniques and the secrecy of the cryptographic keys used. The
254 Kerberos protocol authenticates an application client's identity to
255 an application server, and likewise authenticates the application
256 server's identity to the application client. These assurances are
257 made possible by the client and the server sharing secrets with the
258 trusted third party: the Kerberos server, also known as the Key
259 Distribution Center (KDC). In addition, the protocol establishes an
260 ephemeral shared secret (the session key) between the client and the
261 server, allowing the protection of further communications between
262 them.
265 The Kerberos protocol, as originally specified, provides insufficient
266 means for extending the protocol in a backwards-compatible way. This
267 deficiency has caused problems for interoperability. This document
268 describes a framework which enables backwards-compatible extensions
269 to the Kerberos protocol.
272 1.1. Kerberos Protocol Overview
275 Kerberos comprises three main sub-protocols: credentials acquisition,
276 session key exchange, and session key usage. A client acquires
277 credentials by asking the KDC for a credential for a service; the KDC
278 issues the credential, which contains a ticket and a session key.
279 The ticket, containing the client's identity, timestamps, expiration
280 time, and a session key, is a encrypted in a key known to the
281 application server. The KDC encrypts the credential using a key
282 known to the client, and transmits the credential to the client.
285 There are two means of requesting credentials: the Authentication
286 Service (AS) exchange, and the Ticket-Granting Service (TGS)
287 exchange. In the typical AS exchange, a client uses a password-
288 derived key to decrypt the response. In the TGS exchange, the KDC
289 behaves as an application server; the client authenticates to the TGS
290 by using a Ticket-Granting Ticket (TGT). The client usually obtains
291 the TGT by using the AS exchange.
294 Session key exchange consists of the client transmitting the ticket
295 to the application server, accompanied by an authenticator. The
296 authenticator contains a timestamp and additional data encrypted
297 using the ticket's session key. The application server decrypts the
298 ticket, extracting the session key. The application server then uses
299 the session key to decrypt the authenticator. Upon successful
300 decryption of the authenticator, the application server knows that
301 the data in the authenticator were sent by the client named in the
304 Yu Expires: Apr 2005 [Page 5]
305 Internet-Draft yu-krb-extensions-02 25 Oct 2004
308 associated ticket. Additionally, since authenticators expire more
309 quickly than tickets, the application server has some assurance that
310 the transaction is not a replay. The application server may send an
311 encrypted acknowledgment to the client, verifying its identity to the
312 client.
315 Once session key exchange has occurred, the client and server may use
316 the established session key to protect further traffic. This
317 protection may consist of protection of integrity only, or of
318 protection of confidentiality and integrity. Additional measures
319 exist for a client to securely forward credentials to a server.
322 The entire scheme depends on loosely synchronized clocks.
323 Synchronization of the clock on the KDC with the application server
324 clock allows the application server to accurately determine whether a
325 credential is expired. Likewise, synchronization of the clock on the
326 client with the application server clock prevents replay attacks
327 utilizing the same credential. Careful design of the application
328 protocol may allow replay prevention without requiring client-server
329 clock synchronization.
332 After establishing a session key, application client and the
333 application server can exchange Kerberos protocol messages that use
334 the session key to protect the integrity or confidentiality of
335 communications between the client and the server. Additionally, the
336 client may forward credentials to the application server.
339 The credentials acquisition protocol takes place over specific,
340 defined transports (UDP and TCP). Application protocols define which
341 transport to use for the session key establishment protocol and for
342 messages using the session key; the application may choose to perform
343 its own encapsulation of the Kerberos messages, for example.
346 1.2. Document Organization
349 The remainder of this document begins by describing the general
350 frameworks for protocol extensibility, including whether to interpret
351 unknown extensions as critical. It then defines the protocol
352 messages and exchanges.
355 The definition of the Kerberos protocol uses Abstract Syntax Notation
356 One (ASN.1) [X680], which specifies notation for describing the
357 abstract content of protocol messages. This document defines a
358 number of base types using ASN.1; these base types subsequently
359 appear in multiple types which define actual protocol messages.
360 Definitions of principal names and of tickets, which are central to
361 the protocol, also appear preceding the protocol message definitions.
368 Yu Expires: Apr 2005 [Page 6]
369 Internet-Draft yu-krb-extensions-02 25 Oct 2004
372 2. Compatibility Considerations
375 2.1. Extensibility
378 In the past, significant interoperability problems have resulted from
379 conflicting assumptions about how the Kerberos protocol can be
380 extended. As the deployed base of Kerberos grows, the ability to
381 extend the Kerberos protocol becomes more important. In order to
382 ensure that vendors and the IETF can extend the protocol while
383 maintaining backwards compatibility, this document outlines a
384 framework for extending Kerberos.
387 Kerberos provides two general mechanisms for protocol extensibility.
388 Many protocol messages, including some defined in RFC 1510, contain
389 typed holes--sub-messages containing an octet string along with an
390 integer that identifies how to interpret the octet string. The
391 integer identifiers are registered centrally, but can be used both
392 for vendor extensions and for extensions standardized in the IETF.
393 This document adds typed holes to a number of messages which
394 previously lacked typed holes.
397 Many new messages defined in this document also contain ASN.1
398 extension markers. These markers allow future revisions of this
399 document to add additional elements to messages, for cases where
400 typed holes are inadequate for some reason. Because tag numbers and
401 position in a sequence need to be coordinated in order to maintain
402 interoperability, implementations MUST NOT include ASN.1 extensions
403 except when those extensions are specified by IETF standards-track
404 documents.
407 2.2. Compatibility with RFC 1510
410 Implementations of RFC 1510 did not use extensible ASN.1 types.
411 Sending additional fields not in RFC 1510 to these implementations
412 results in undefined behavior. Examples of this behavior are known
413 to include discarding messages with no error indications.
416 Where messages have been changed since RFC 1510, ASN.1 CHOICE types
417 are used; one alternative of the CHOICE provides a message which is
418 wire-encoding compatible with RFC 1510, and the other alternative
419 provides the new, extensible message.
422 Implementations sending new messages MUST ensure that the recipient
423 supports these new messages. Along with each extensible message is a
424 guideline for when that message MAY be used. IF that guideline is
425 followed, then the recipient is guaranteed to understand the message.
428 2.3. Backwards Compatibility
431 This document describes two sets (for the most part) of ASN.1 types.
432 The first set of types is wire-encoding compatible with RFC 1510 and
435 Yu Expires: Apr 2005 [Page 7]
436 Internet-Draft yu-krb-extensions-02 25 Oct 2004
439 [KCLAR]. The second set of types is the set of types enabling
440 extensibility. This second set may be referred to as
441 "extensibility-enabled types". [ need to make this consistent
442 throughout? ]
445 A major difference between the new extensibility-enabled types and
446 the types for RFC 1510 compatibility is that the extensibility-
447 enabled types allow for the use of UTF-8 encodings in various
448 character strings in the protocol. Each party in the protocol must
449 have some knowledge of the capabilities of the other parties in the
450 protocol. There are methods for establishing this knowledge without
451 necessarily requiring explicit configuration.
454 An extensibility-enabled client can detect whether a KDC supports the
455 extensibility-enabled types by requesting an extensibility-enabled
456 reply. If the KDC replies with an extensibility-enabled reply, the
457 client knows that the KDC supports extensibility. If the KDC issues
458 an extensibility-enabled ticket, the client knows that the service
459 named in the ticket is extensibility-enabled.
462 2.4. 1.4.2. Sending Extensible Messages
465 Care must be taken to make sure that old implementations can
466 understand messages sent to them even if they do not understand an
467 extension that is used. Unless the sender knows the extension is
468 supported, the extension cannot change the semantics of the core
469 message or previously defined extensions.
472 For example, an extension including key information necessary to
473 decrypt the encrypted part of a KDC-REP could only be used in
474 situations where the recipient was known to support the extension.
475 Thus when designing such extensions it is important to provide a way
476 for the recipient to notify the sender of support for the extension.
477 For example in the case of an extension that changes the KDC-REP
478 reply key, the client could indicate support for the extension by
479 including a padata element in the AS-REQ sequence. The KDC should
480 only use the extension if this padata element is present in the AS-
481 REQ. Even if policy requires the use of the extension, it is better
482 to return an error indicating that the extension is required than to
483 use the extension when the recipient may not support it; debugging
484 why implementations do not interoperate is easier when errors are
485 returned.
488 2.5. Criticality
491 Recipients of unknown message extensions (including typed holes, new
492 flags, and ASN.1 extension elements) should preserve the encoding of
493 the extension but otherwise ignore the presence of the extension;
494 i.e., unknown extensions SHOULD be treated as non-critical. If a
495 copy of the message is used later--for example, when a Ticket
496 received in a KDC-REP is later used in an AP-REQ--then the unknown
499 Yu Expires: Apr 2005 [Page 8]
500 Internet-Draft yu-krb-extensions-02 25 Oct 2004
503 extensions MUST be included.
506 An implementation SHOULD NOT reject a request merely because it does
507 not understand some element of the request. As a related
508 consequence, implementations SHOULD handle communicating with other
509 implementations which do not implement some requested options. This
510 may require designers of options to provide means to determine
511 whether an option has been rejected, not understood, or (perhaps
512 maliciously) deleted or modified in transit.
515 There is one exception to non-criticality described above: if an
516 unknown authorization data element is received by a server either in
517 an AP-REQ or in a Ticket contained in an AP-REQ, then the
518 authentication SHOULD fail. Authorization data is intended to
519 restrict the use of a ticket. If the service cannot determine
520 whether the restriction applies to that service then a security
521 weakness may result if authentication succeeds. Authorization
522 elements meant to be truly optional can be enclosed in the AD-IF-
523 RELEVANT element.
526 Many RFC 1510 implementations ignore unknown authorization data
527 elements. Depending on these implementations to honor authorization
528 data restrictions may create a security weakness.
531 2.6. Authenticating Cleartext Portions of Messages
534 Various denial of service attacks and downgrade attacks against
535 Kerberos are possible unless plaintexts are somehow protected against
536 modification. An early design goal of Kerberos Version 5 was to
537 avoid encrypting more of the authentication exchange that was
538 required. (Version 4 doubly-encrypted the encrypted part of a ticket
539 in a KDC reply, for example.) This minimization of encryption
540 reduces the load on the KDC and busy servers. Also, during the
541 initial design of Version 5, the existence of legal restrictions on
542 the export of cryptography made it desirable to minimize of the
543 number of uses of encryption in the protocol. Unfortunately,
544 performing this minimization created numerous instances of
545 unauthenticated security-relevant plaintext fields.
548 The extensible variants of the messages described in this document
549 wrap the actual message in an ASN.1 sequence containing a keyed
550 checksum of the contents of the message. Guidelines in [XXX] section
551 3 specify when the checksum MUST be included and what key MUST be
552 used. Guidelines on when to include a checksum are never ambiguous:
553 a particular PDU is never correct both with and without a checksum.
554 With the exception of the KRB-ERROR message, receiving
555 implementations MUST reject messages where a checksum is included and
556 not expected or where a checksum is expected but not included. The
557 receiving implementation does not always have sufficient information
558 to know whether a KRB-ERROR should contain a checksum. Even so,
559 KRB-ERROR messages with invalid checksums MUST be rejected and
562 Yu Expires: Apr 2005 [Page 9]
563 Internet-Draft yu-krb-extensions-02 25 Oct 2004
566 implementations MAY consider the presence or absence of a checksum
567 when evaluating whether to trust the error.
570 This authenticated cleartext protection is provided only in the
571 extensible variants of the messages; it is never used when
572 communicating with an RFC 1510 implementation.
575 2.7. Capability Negotiation
578 Kerberos is a three-party protocol. Each of the three parties
579 involved needs a means of detecting the capabilities supported by the
580 others. Two of the parties, the KDC and the application server, do
581 not communicate directly in the Kerberos protocol. Communicating
582 capabilities from the KDC to the application server requires using a
583 ticket as an intermediary.
586 The main capability requiring negotiation is the support of the
587 extensibility framework described in this document. Negotiation of
588 this capability while remaining compatible with RFC 1510
589 implementations is possible. The main complication is that the
590 client needs to know whether the application server supports the
591 extensibility framework prior to sending any message to the
592 application server. This can be accomplished if the KDC has
593 knowledge of whether an application server supports the extensibility
594 framework.
597 Client software advertizes its capabilities when requesting
598 credentials from the KDC. If the KDC recognizes the capabilities, it
599 acknowledges this fact to the client in its reply. In addition, if
600 the KDC has knowledge that the application server supports certain
601 capabilities, it also communicates this knowledge to the client in
602 its reply. The KDC can encode its own capabilities in the ticket so
603 that the application server may discover these capabilities. The
604 client advertizes its capabilities to the application server when it
605 initiates authentication to the application server.
608 3. Use of ASN.1 in Kerberos
611 Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690].
612 Even though ASN.1 theoretically allows the description of protocol
613 messages to be independent of the encoding rules used to encode the
614 messages, Kerberos messages MUST be encoded with DER. Subtleties in
615 the semantics of the notation, such as whether tags carry any
616 semantic content to the application, may cause the use of other ASN.1
617 encoding rules to be problematic.
620 Implementors not using existing ASN.1 tools (e.g., compilers or
621 support libraries) are cautioned to thoroughly read and understand
622 the actual ASN.1 specification to ensure correct implementation
623 behavior. There is more complexity in the notation than is
624 immediately obvious, and some tutorials and guides to ASN.1 are
627 Yu Expires: Apr 2005 [Page 10]
628 Internet-Draft yu-krb-extensions-02 25 Oct 2004
631 misleading or erroneous. Recommended tutorials and guides include
632 [Dub00], [Lar99], though there is still no substitute for reading the
633 actual ASN.1 specification.
636 3.1. Module Header
639 The type definitions in this document assume an ASN.1 module
640 definition of the following form:
643 KerberosV5Spec3 {
644 iso(1) identified-organization(3) dod(6) internet(1)
645 security(5) kerberosV5(2) modules(4) krb5spec3(4)
646 } DEFINITIONS EXPLICIT TAGS ::= BEGIN
649 -- Rest of definitions here
652 END
655 This specifies that the tagging context for the module will be
656 explicit and that automatic tagging is not done.
659 Some other publications [RFC1510] [RFC1964] erroneously specify an
660 object identifier (OID) having an incorrect value of "5" for the
661 "dod" component of the OID. In the case of RFC 1964, use of the
662 "correct" OID value would result in a change in the wire protocol;
663 therefore, the RFC 1964 OID remains unchanged for now.
666 3.2. Top-Level Type
669 The ASN.1 type "KRB-PDU" is a CHOICE over all the types (Protocol
670 Data Units or PDUs) which an application may directly reference.
671 Applications SHOULD NOT transmit any types other than those which are
672 alternatives of the KRB-PDU CHOICE.
693 Yu Expires: Apr 2005 [Page 11]
694 Internet-Draft yu-krb-extensions-02 25 Oct 2004
697 -- top-level type
698 --
699 -- Applications should not directly reference any types
700 -- other than KRB-PDU and its component types.
701 --
702 KRB-PDU ::= CHOICE {
703 ticket Ticket,
704 as-req AS-REQ,
705 as-rep AS-REP,
706 tgs-req TGS-REQ,
707 tgs-rep TGS-REP,
708 ap-req AP-REQ,
709 ap-rep AP-REP,
710 krb-safe KRB-SAFE,
711 krb-priv KRB-PRIV,
712 krb-cred KRB-CRED,
713 tgt-req TGT-REQ,
714 krb-error KRB-ERROR,
715 ...
716 }
720 3.3. Previously Unused ASN.1 Notation (informative)
723 Some aspects of ASN.1 notation used in this document were not used in
724 [KCLAR], and may be unfamiliar to some readers. This subsection is
725 informative; for normative definitions of the notation, see the
726 actual ASN.1 specifications [X680], [X682], [X683].
729 3.3.1. Parameterized Types
732 This document uses ASN.1 parameterized types [X683] to make
733 definitions of types more readable. For some types, some or all of
734 the parameters are advisory, i.e., they are not encoded in any form
735 for transmission in a protocol message. These advisory parameters
736 can describe implementation behavior associated with the type.
739 3.3.2. COMPONENTS OF Notation
742 The "COMPONENTS OF" notation, used to define the RFC 1510
743 compatibility types, extracts all of the component types of an ASN.1
744 SEQUENCE type. The extension marker (the "..." notation) and any
745 extension components are not extracted by "COMPONENTS OF". The
746 "COMPONENTS OF" notation permits concise definition of multiple types
747 which have many components in common with each other.
750 3.3.3. Constraints
753 This document uses ASN.1 constraints, including the
754 "UserDefinedConstraint" notation [X682]. Some constraints can be
755 handled automatically by tools that can parse them. Uses of the
758 Yu Expires: Apr 2005 [Page 12]
759 Internet-Draft yu-krb-extensions-02 25 Oct 2004
762 "UserDefinedConstraint" notation (the "CONSTRAINED BY" notation) will
763 typically need to have behavior manually coded; the notation provides
764 a formalized way of conveying intended implementation behavior.
767 The "WITH COMPONENTS" constraint notation allows constraints to apply
768 to component types of a SEQUENCE type. This constraint notation
769 effectively allows constraints to "reach into" a type to constrain
770 its component types.
773 3.4. New Types
776 This document defines a number of ASN.1 types which are new since
777 [KCLAR]. The names of these types will typically have a suffix like
778 "Ext", indicating that the types are intended to support
779 extensibility. Types original to RFC 1510 and [KCLAR] have been
780 renamed to have a suffix like "1510". The "Ext" and "1510" types
781 often contain a number of common elements; these common elements have
782 a suffix like "Common". The "1510" types have various ASN.1
783 constraints applied to them; the constraints limit the possible
784 values of the "1510" types to those permitted by RFC 1510 or by
785 [KCLAR]. The "Ext" types may have different constraints, typically
786 to force string values to be sent as UTF-8.
789 For example, consider
792 -- example "common" type
793 Foo-Common ::= SEQUENCE {
794 a [0] INTEGER,
795 b [1] OCTET STRING,
796 ...,
797 c [2] INTEGER,
798 ...
799 }
802 -- example "RFC 1510 compatibility" type
803 Foo-1510 ::= SEQUENCE {
804 -- the COMPONENTS OF notation drops the extension marker
805 -- and all extension additions.
806 COMPONENTS OF Foo-Common
807 }
810 -- example "extensibility-enabled" type
811 Foo-Ext ::= Foo-Common
814 where "Foo-Common" is a common type used to define both the "1510"
815 and "Ext" versions of a type. "Foo-1510" is the RFC 1510 version of
816 the type, while "Foo-Ext" is the extensible version. "Foo-1510" does
817 not contain the extension marker, nor does it contain the extension
818 component "c". The type "Foo-1510" is equivalent to "Foo-1510-
819 Equiv", shown below.
823 Yu Expires: Apr 2005 [Page 13]
824 Internet-Draft yu-krb-extensions-02 25 Oct 2004
827 -- example type equivalent to Foo-1510
828 Foo-1510-Equiv ::= SEQUENCE {
829 a [0] INTEGER,
830 b [1] OCTET STRING
831 }
835 4. Basic Types
838 These "basic" Kerberos ASN.1 types appear in multiple other Kerberos
839 types.
842 4.1. Constrained Integer Types
845 In RFC 1510, many types contained references to the unconstrained
846 INTEGER type. Since an unconstrained INTEGER can contain almost any
847 possible abstract integer value, most of the unconstrained references
848 to INTEGER in RFC 1510 were constrained to 32 bits or smaller in
849 [KCLAR].
852 -- signed values representable in 32 bits
853 --
854 -- These are often used as assigned numbers for various things.
855 Int32 ::= INTEGER (-2147483648..2147483647)
858 The "Int32" type often contains an assigned number identifying the
859 contents of a typed hole. Unless otherwise stated, non-negative
860 values are registered, and negative values are available for local
861 use.
864 -- unsigned 32 bit values
865 UInt32 ::= INTEGER (0..4294967295)
868 The "UInt32" type is used in some places where an unsigned 32-bit
869 integer is needed.
872 -- unsigned 64 bit values
873 UInt64 ::= INTEGER (0..18446744073709551615)
876 The "UInt64" type is used in places where 32 bits of precision may
877 provide inadequate security.
880 -- sequence numbers
881 SeqNum ::= UInt64
884 Sequence numbers were constrained to 32 bits in [KCLAR], but this
885 document allows for 64-bit sequence numbers.
888 -- nonces
889 Nonce ::= UInt64
893 Yu Expires: Apr 2005 [Page 14]
894 Internet-Draft yu-krb-extensions-02 25 Oct 2004
897 Likewise, nonces were constrained to 32 bits in [KCLAR], but expanded
898 to 64 bits here.
901 -- microseconds
902 Microseconds ::= INTEGER (0..999999)
905 The "microseconds" type is intended to carry the microseconds part of
906 a time value.
909 4.2. KerberosTime
912 KerberosTime ::= GeneralizedTime (CONSTRAINED BY {
913 -- MUST NOT include fractional seconds
914 })
917 The timestamps used in Kerberos are encoded as GeneralizedTimes. A
918 KerberosTime value MUST NOT include any fractional portions of the
919 seconds. As required by the DER, it further MUST NOT include any
920 separators, and it specifies the UTC time zone (Z). Example: The
921 only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
922 November 1985 is "19851106210627Z".
925 4.3. KerberosString
928 -- used for names and for error messages
929 KerberosString ::= CHOICE {
930 ia5 GeneralString (IA5String),
931 utf8 UTF8String,
932 ... -- no extension may be sent
933 -- to an rfc1510 implementation --
934 }
937 The KerberosString type is used for character strings in various
938 places in the Kerberos protocol. For compatibility with RFC 1510,
939 GeneralString values constrained to IA5String (US-ASCII) are
940 permitted in messages exchanged with RFC 1510 implementations. The
941 new protocol messages contain strings encoded as UTF-8, and these
942 strings MUST be normalized using [SASLPREP]. KerberosString values
943 are present in principal names and in error messages. Control
944 characters SHOULD NOT be used in principal names, and used with
945 caution in error messages.
948 -- IA5 choice only; useful for constraints
949 KerberosStringIA5 ::= KerberosString
950 (WITH COMPONENTS { ia5 PRESENT })
953 -- IA5 excluded; useful for constraints
954 KerberosStringExt ::= KerberosString
955 (WITH COMPONENTS { ia5 ABSENT })
958 KerberosStringIA5 requires the use of the "ia5" alternative, while
961 Yu Expires: Apr 2005 [Page 15]
962 Internet-Draft yu-krb-extensions-02 25 Oct 2004
965 KerberosStringExt forbids it. These types appear in ASN.1
966 constraints on messages.
969 For detailed background regarding the history of character string use
970 in Kerberos, as well as discussion of some compatibility issues, see
971 Appendix B.
974 4.4. Language Tags
977 -- used for language tags
978 LangTag ::= PrintableString
979 (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
982 The "LangTag" type is used to specify language tags for localization
983 purposes, using the [RFC3066] format.
986 4.5. KerberosFlags
989 For several message types, a specific constrained bit string type,
990 KerberosFlags, is used.
993 KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
994 (CONSTRAINED BY {
995 -- MUST be a valid value of -- NamedBits
996 -- but if the value to be sent would be truncated to shorter
997 -- than 32 bits according to DER, the value MUST be padded
998 -- with trailing zero bits to 32 bits. Otherwise, no
999 -- trailing zero bits may be present.
1002 })
1006 The actual bit string type encoded in Kerberos messages does not use
1007 named bits. The advisory parameter of the KerberosFlags type names a
1008 bit string type defined using named bits, whose value is encoded as
1009 if it were a bit string with unnamed bits. This practice is
1010 necessary because the DER require trailing zero bits to be removed
1011 when encoding bit strings defined using named bits. Existing
1012 implementations of Kerberos send exactly 32 bits rather than
1013 truncating, so the size constraint requires the transmission of at
1014 least 32 bits. Trailing zero bits beyond the first 32 bits are
1015 truncated.
1018 4.6. Typed Holes
1021 -- Typed hole identifiers
1022 TH-id ::= CHOICE {
1023 int32 Int32,
1024 rel-oid RELATIVE-OID
1025 }
1029 Yu Expires: Apr 2005 [Page 16]
1030 Internet-Draft yu-krb-extensions-02 25 Oct 2004
1033 The "TH-id" type is a generalized means to identify the contents of a
1034 typed hole. The "int32" alternative may be used for simple integer
1035 assignments, in the same manner as "Int32", while the "rel-oid"
1036 alternative may be used for hierarchical delegation.
1039 4.7. HostAddress and HostAddresses
1042 AddrType ::= Int32
1045 HostAddress ::= SEQUENCE {
1046 addr-type [0] AddrType,
1047 address [1] OCTET STRING
1048 }
1051 -- NOTE: HostAddresses is always used as an OPTIONAL field and
1052 -- should not be a zero-length SEQUENCE OF.
1053 --
1054 -- The extensible messages explicitly constrain this to be
1055 -- non-empty.
1056 HostAddresses ::= SEQUENCE OF HostAddress
1060 addr-type
1061 This field specifies the type of address that follows.
1064 address
1065 This field encodes a single address of the type identified by
1066 "addr-type".
1069 All negative values for the host address type are reserved for local
1070 use. All non-negative values are reserved for officially assigned
1071 type fields and interpretations.
1075 addr-type | meaning
1076 __________|______________
1077 2 | IPv4
1078 3 | directional
1079 12 | DECnet
1080 20 | NetBIOS
1081 24 | IPv6
1086 4.7.1. Internet (IPv4) Addresses
1089 Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in
1090 MSB order (most significant byte first). The IPv4 loopback address
1091 SHOULD NOT appear in a Kerberos PDU. The type of IPv4 addresses is
1092 two (2).
1096 Yu Expires: Apr 2005 [Page 17]
1097 Internet-Draft yu-krb-extensions-02 25 Oct 2004
1100 4.7.2. Internet (IPv6) Addresses
1103 IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities, encoded
1104 in MSB order (most significant byte first). The type of IPv6
1105 addresses is twenty-four (24). The following addresses MUST NOT
1106 appear in any Kerberos PDU:
1109 * the Unspecified Address
1112 * the Loopback Address
1115 * Link-Local addresses
1118 This restriction applies to the inclusion in the address fields of
1119 Kerberos PDUs, but not to the address fields of packets that might
1120 carry such PDUs. The restriction is necessary because the use of an
1121 address with non-global scope could allow the acceptance of a message
1122 sent from a node that may have the same address, but which is not the
1123 host intended by the entity that added the restriction. If the
1124 link-local address type needs to be used for communication, then the
1125 address restriction in tickets must not be used (i.e. addressless
1126 tickets must be used).
1129 IPv4-mapped IPv6 addresses MUST be represented as addresses of type
1130 2.
1133 4.7.3. DECnet Phase IV addresses
1136 DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order.
1137 The type of DECnet Phase IV addresses is twelve (12).
1140 4.7.4. Netbios addresses
1143 Netbios addresses are 16-octet addresses typically composed of 1 to
1144 15 alphanumeric characters and padded with the US-ASCII SPC character
1145 (code 32). The 16th octet MUST be the US-ASCII NUL character (code
1146 0). The type of Netbios addresses is twenty (20).
1149 4.7.5. Directional Addresses
1152 In many environments, including the sender address in KRB-SAFE and
1153 KRB-PRIV messages is undesirable because the addresses may be changed
1154 in transport by network address translators. However, if these
1155 addresses are removed, the messages may be subject to a reflection
1156 attack in which a message is reflected back to its originator. The
1157 directional address type provides a way to avoid transport addresses
1158 and reflection attacks. Directional addresses are encoded as four
1159 byte unsigned integers in network byte order. If the message is
1160 originated by the party sending the original AP-REQ message, then an
1161 address of 0 SHOULD be used. If the message is originated by the
1162 party to whom that AP-REQ was sent, then the address 1 SHOULD be
1165 Yu Expires: Apr 2005 [Page 18]
1166 Internet-Draft yu-krb-extensions-02 25 Oct 2004
1169 used. Applications involving multiple parties can specify the use of
1170 other addresses.
1173 Directional addresses MUST only be used for the sender address field
1174 in the KRB-SAFE or KRB-PRIV messages. They MUST NOT be used as a
1175 ticket address or in a AP-REQ message. This address type SHOULD only
1176 be used in situations where the sending party knows that the
1177 receiving party supports the address type. This generally means that
1178 directional addresses may only be used when the application protocol
1179 requires their support. Directional addresses are type (3).
1182 5. Principals
1185 Principals are participants in the Kerberos protocol. A "realm"
1186 consists of principals in one administrative domain, served by one
1187 KDC (or one replicated set of KDCs). Each principal name has an
1188 arbitrary number of components, though typical principal names will
1189 only have one or two components. A principal name is meant to be
1190 readable by and meaningful to humans, especially in a realm lacking a
1191 centrally adminstered authorization infrastructure.
1194 5.1. Name Types
1197 Each PrincipalName has NameType indicating what sort of name it is.
1198 The name-type SHOULD be treated as a hint. Ignoring the name type,
1199 no two names can be the same (i.e., at least one of the components,
1200 or the realm, must be different).
1203 -- assigned numbers for name types (used in principal names)
1204 NameType ::= Int32
1207 -- Name type not known
1208 nt-unknown NameType ::= 0
1209 -- Just the name of the principal as in DCE, or for users
1210 nt-principal NameType ::= 1
1211 -- Service and other unique instance (krbtgt)
1212 nt-srv-inst NameType ::= 2
1213 -- Service with host name as instance (telnet, rcommands)
1214 nt-srv-hst NameType ::= 3
1215 -- Service with host as remaining components
1216 nt-srv-xhst NameType ::= 4
1217 -- Unique ID
1218 nt-uid NameType ::= 5
1219 -- Encoded X.509 Distingished name [RFC 2253]
1220 nt-x500-principal NameType ::= 6
1221 -- Name in form of SMTP email name (e.g. user@foo.com)
1222 nt-smtp-name NameType ::= 7
1223 -- Enterprise name - may be mapped to principal name
1224 nt-enterprise NameType ::= 10
1229 Yu Expires: Apr 2005 [Page 19]
1230 Internet-Draft yu-krb-extensions-02 25 Oct 2004
1233 5.2. Principal Type Definition
1236 PrincipalName ::= SEQUENCE {
1237 name-type [0] NameType,
1238 -- May have zero elements, or individual elements may be
1239 -- zero-length, but this is NOT RECOMMENDED.
1240 name-string [1] SEQUENCE OF KerberosString
1241 }
1245 name-type
1246 hint of the type of name that follows
1249 name-string
1250 The "name-string" encodes a sequence of components that form a
1251 name, each component encoded as a KerberosString. Taken
1252 together, a PrincipalName and a Realm form a principal
1253 identifier. Most PrincipalNames will have only a few components
1254 (typically one or two).
1257 5.3. Principal Name Reuse
1260 Realm administrators SHOULD use extreme caution when considering
1261 reusing a principal name. A service administrator might explicitly
1262 enter principal names into a local access control list (ACL) for the
1263 service. If such local ACLs exist independently of a centrally
1264 administered authorization infrastructure, realm administrators
1265 SHOULD NOT reuse principal names until confirming that all extant ACL
1266 entries referencing that principal name have been updated. Failure
1267 to perform this check can result in a security vulnerability, as a
1268 new principal can inadvertently inherit unauthorized privileges upon
1269 receiving a reused principal name. An organization whose Kerberos-
1270 authenticated services all use a centrally-adminstered authorization
1271 infrastructure may not need to take these precautions regarding
1272 principal name reuse.
1275 5.4. Realm Names
1278 Realm ::= KerberosString
1281 -- IA5 only
1282 RealmIA5 ::= Realm (KerberosStringIA5)
1285 -- IA5 excluded
1286 RealmExt ::= Realm (KerberosStringExt)
1290 Kerberos realm names are KerberosStrings. Realms MUST NOT contain a
1291 character with the code 0 (the US-ASCII NUL). Most realms will
1292 usually consist of several components separated by periods (.), in
1293 the style of Internet Domain Names, or separated by slashes (/) in
1296 Yu Expires: Apr 2005 [Page 20]
1297 Internet-Draft yu-krb-extensions-02 25 Oct 2004
1300 the style of X.500 names.
1303 5.5. Printable Representations of Principal Names
1306 [ perhaps non-normative? ]
1309 The printable form of a principal name consists of the concatenation
1310 of components of the PrincipalName value using the slash character
1311 (/), followed by an at-sign (@), followed by the realm name. Any
1312 occurrence of a backslash (\), slash (/) or at-sign (@) in the
1313 PrincipalName value is quoted by a backslash.
1316 5.6. Ticket-Granting Service Principal
1319 The PrincipalName value corresponding to a ticket-granting service
1320 has two components: the first component is the string "krbtgt", and
1321 the second component is the realm name of the TGS which will accept a
1322 ticket-granting ticket having this service principal name. The realm
1323 name of service always indicates which realm issued the ticket. A
1324 ticket-granting ticket issued by "A.EXAMPLE.COM" which is valid for
1325 obtaining tickets in the same realm would have the following ASN.1
1326 values for its "realm" and "sname" components, respectively:
1329 -- Example Realm and PrincipalName for a TGS
1332 tgtRealm1 Realm ::= ia5 : "A.EXAMPLE.COM"
1335 tgtPrinc1 PrincipalName ::= {
1336 name-type nt-srv-inst,
1337 name-string { ia5 : "krbtgt", ia5 : "A.EXAMPLE.COM" }
1338 }
1341 Its printable representation would be written as
1342 "krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM".
1345 5.6.1. Cross-Realm TGS Principals
1348 It is possible for a principal in one realm to authenticate to a
1349 service in another realm. A KDC can issue a cross-realm ticket-
1350 granting ticket to allow one of its principals to authenticate to a
1351 service in a foreign realm. For example, the TGS principal
1352 "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" is a principal that permits a
1353 client principal in the realm A.EXAMPLE.COM to authenticate to a
1354 service in the realm B.EXAMPLE.COM. When the KDC for B.EXAMPLE.COM
1355 issues a ticket to a client originating in A.EXAMPLE.COM, the
1356 client's realm name remains "A.EXAMPLE.COM", even though the service
1357 principal will have the realm "B.EXAMPLE.COM".
1364 Yu Expires: Apr 2005 [Page 21]
1365 Internet-Draft yu-krb-extensions-02 25 Oct 2004
1368 6. Types Relating to Encryption
1371 Many Kerberos protocol messages contain encrypted encodings of
1372 various data types. Some Kerberos protocol messages also contain
1373 checksums (signatures) of encodings of various types.
1376 6.1. Assigned Numbers for Encryption
1379 Encryption algorithm identifiers and key usages both have assigned
1380 numbers, described in [KCRYPTO].
1383 6.1.1. EType
1386 EType is the integer type for assigned numbers for encryption
1387 algorithms. Defined in [KCRYPTO].
1390 -- Assigned numbers denoting encryption mechanisms.
1391 EType ::= Int32
1394 -- assigned numbers for encryption schemes
1395 et-des-cbc-crc EType ::= 1
1396 et-des-cbc-md4 EType ::= 2
1397 et-des-cbc-md5 EType ::= 3
1398 -- [reserved] 4
1399 et-des3-cbc-md5 EType ::= 5
1400 -- [reserved] 6
1401 et-des3-cbc-sha1 EType ::= 7
1402 et-dsaWithSHA1-CmsOID EType ::= 9
1403 et-md5WithRSAEncryption-CmsOID EType ::= 10
1404 et-sha1WithRSAEncryption-CmsOID EType ::= 11
1405 et-rc2CBC-EnvOID EType ::= 12
1406 et-rsaEncryption-EnvOID EType ::= 13
1407 et-rsaES-OAEP-ENV-OID EType ::= 14
1408 et-des-ede3-cbc-Env-OID EType ::= 15
1409 et-des3-cbc-sha1-kd EType ::= 16
1410 -- AES
1411 et-aes128-cts-hmac-sha1-96 EType ::= 17
1412 -- AES
1413 et-aes256-cts-hmac-sha1-96 EType ::= 18
1414 -- Microsoft
1415 et-rc4-hmac EType ::= 23
1416 -- Microsoft
1417 et-rc4-hmac-exp EType ::= 24
1418 -- opaque; PacketCable
1419 et-subkey-keymaterial EType ::= 65
1423 6.1.2. Key Usages
1426 KeyUsage is the integer type for assigned numbers for key usages.
1427 Key usage values are inputs to the encryption and decryption
1430 Yu Expires: Apr 2005 [Page 22]
1431 Internet-Draft yu-krb-extensions-02 25 Oct 2004
1434 functions described in [KCRYPTO].
1437 -- Assigned numbers denoting key usages.
1438 KeyUsage ::= UInt32
1441 --
1442 -- Actual identifier names are provisional and subject to
1443 -- change.
1444 --
1445 ku-pa-enc-ts KeyUsage ::= 1
1446 ku-Ticket KeyUsage ::= 2
1447 ku-EncASRepPart KeyUsage ::= 3
1448 ku-TGSReqAuthData-sesskey KeyUsage ::= 4
1449 ku-TGSReqAuthData-subkey KeyUsage ::= 5
1450 ku-pa-TGSReq-cksum KeyUsage ::= 6
1451 ku-pa-TGSReq-authenticator KeyUsage ::= 7
1452 ku-EncTGSRepPart-sesskey KeyUsage ::= 8
1453 ku-EncTGSRepPart-subkey KeyUsage ::= 9
1454 ku-Authenticator-cksum KeyUsage ::= 10
1455 ku-APReq-authenticator KeyUsage ::= 11
1456 ku-EncAPRepPart KeyUsage ::= 12
1457 ku-EncKrbPrivPart KeyUsage ::= 13
1458 ku-EncKrbCredPart KeyUsage ::= 14
1459 ku-KrbSafe-cksum KeyUsage ::= 15
1460 ku-ad-KDCIssued-cksum KeyUsage ::= 19
1464 -- The following numbers are provisional...
1465 -- conflicts may exist elsewhere.
1466 ku-Ticket-cksum KeyUsage ::= 25
1467 ku-ASReq-cksum KeyUsage ::= 26
1468 ku-TGSReq-cksum KeyUsage ::= 27
1469 ku-ASRep-cksum KeyUsage ::= 28
1470 ku-TGSRep-cksum KeyUsage ::= 29
1471 ku-APReq-cksum KeyUsage ::= 30
1472 ku-APRep-cksum KeyUsage ::= 31
1473 ku-KrbCred-cksum KeyUsage ::= 32
1474 ku-KrbError-cksum KeyUsage ::= 33
1475 ku-KDCRep-cksum KeyUsage ::= 34
1479 6.2. Which Key to Use
1491 Yu Expires: Apr 2005 [Page 23]
1492 Internet-Draft yu-krb-extensions-02 25 Oct 2004
1495 -- KeyToUse identifies which key is to be used to encrypt or
1496 -- sign a given value.
1497 --
1498 -- Values of KeyToUse are never actually transmitted over the
1499 -- wire, or even used directly by the implementation in any
1500 -- way, as key usages are; it exists primarily to identify
1501 -- which key gets used for what purpose. Thus, the specific
1502 -- numeric values associated with this type are irrelevant.
1503 KeyToUse ::= ENUMERATED {
1504 -- unspecified
1505 key-unspecified,
1506 -- server long term key
1507 key-server,
1508 -- client long term key
1509 key-client,
1510 -- key selected by KDC for encryption of a KDC-REP
1511 key-kdc-rep,
1512 -- session key from ticket
1513 key-session,
1514 -- subsession key negotiated via AP-REQ/AP-REP
1515 key-subsession,
1516 ...
1517 }
1521 6.3. EncryptionKey
1524 The "EncryptionKey" type holds an encryption key.
1527 EncryptionKey ::= SEQUENCE {
1528 keytype [0] EType,
1529 keyvalue [1] OCTET STRING
1530 }
1534 keytype
1535 This "EType" identifies the encryption algorithm, described in
1536 [KCRYPTO].
1539 keyvalue
1540 Contains the actual key.
1543 6.4. EncryptedData
1546 The "EncryptedData" type contains the encryption of another data
1547 type. The recipient uses fields within EncryptedData to determine
1548 which key to use for decryption.
1555 Yu Expires: Apr 2005 [Page 24]
1556 Internet-Draft yu-krb-extensions-02 25 Oct 2004
1560 -- "Type" specifies which ASN.1 type is encrypted to the
1561 -- ciphertext in the EncryptedData. "Keys" specifies a set of
1562 -- keys of which one key may be used to encrypt the data.
1563 -- "KeyUsages" specifies a set of key usages, one of which may
1564 -- be used to encrypt.
1565 --
1566 -- None of the parameters is transmitted over the wire.
1567 EncryptedData {
1568 Type, KeyToUse:Keys, KeyUsage:KeyUsages
1569 } ::= SEQUENCE {
1570 etype [0] EType,
1571 kvno [1] UInt32 OPTIONAL,
1572 cipher [2] OCTET STRING (CONSTRAINED BY {
1573 -- must be encryption of --
1574 OCTET STRING (CONTAINING Type),
1575 -- with one of the keys -- KeyToUse:Keys,
1576 -- with key usage being one of --
1577 KeyUsage:KeyUsages
1578 }),
1579 ...
1580 }
1585 KeyUsages
1586 Advisory parameter indicating which key usage to use when
1587 encrypting the ciphertext. If "KeyUsages" indicate multiple
1588 "KeyUsage" values, the detailed description of the containing
1589 message will indicate which key to use under which conditions.
1592 Type
1593 Advisory parameter indicating the ASN.1 type whose DER encoding
1594 is the plaintext encrypted into the EncryptedData.
1597 Keys
1598 Advisory parameter indicating which key to use to perform the
1599 encryption. If "Keys" indicate multiple "KeyToUse" values, the
1600 detailed description of the containing message will indicate
1601 which key to use under which conditions.
1604 KeyUsages
1605 Advisory parameter indicating which "KeyUsage" value is used to
1606 encrypt. If "KeyUsages" indicates multiple "KeyUsage" values,
1607 the detailed description of the containing message will indicate
1608 which key usage to use under which conditions.
1611 6.5. Checksums
1614 Several types contain checksums (actually signatures) of data.
1618 Yu Expires: Apr 2005 [Page 25]
1619 Internet-Draft yu-krb-extensions-02 25 Oct 2004
1622 CksumType ::= Int32
1625 -- The parameters specify which key to use to produce the
1626 -- signature, as well as which key usage to use. The
1627 -- parameters are not actually sent over the wire.
1628 Checksum {
1629 KeyToUse:Keys, KeyUsage:KeyUsages
1630 } ::= SEQUENCE {
1631 cksumtype [0] CksumType,
1632 checksum [1] OCTET STRING (CONSTRAINED BY {
1633 -- signed using one of the keys --
1634 KeyToUse:Keys,
1635 -- with key usage being one of --
1636 KeyUsage:KeyUsages
1637 })
1638 }
1642 CksumType
1643 Integer type for assigned numbers for signature algorithms.
1644 Defined in [KCRYPTO]
1647 Keys
1648 As in EncryptedData
1651 KeyUsages
1652 As in EncryptedData
1655 cksumtype
1656 Signature algorithm used to produce the signature.
1659 checksum
1660 The actual checksum.
1663 6.5.1. ChecksumOf
1666 ChecksumOf is similar to "Checksum", but specifies which type is
1667 signed.
1670 -- a Checksum that must contain the checksum
1671 -- of a particular type
1672 ChecksumOf {
1673 Type, KeyToUse:Keys, KeyUsage:KeyUsages
1674 } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
1675 ...,
1676 checksum (CONSTRAINED BY {
1677 -- must be checksum of --
1678 OCTET STRING (CONTAINING Type)
1679 })
1680 })
1684 Yu Expires: Apr 2005 [Page 26]
1685 Internet-Draft yu-krb-extensions-02 25 Oct 2004
1688 Type
1689 Indicates the ASN.1 type whose DER encoding is signed.
1692 6.5.2. Signed
1695 Signed is similar to "ChecksumOf", but contains an actual instance of
1696 the type being signed in addition to the signature.
1699 -- parameterized type for wrapping authenticated plaintext
1700 Signed {
1701 InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
1702 } ::= SEQUENCE {
1703 cksum [0] ChecksumOf {
1704 InnerType, Keys, KeyUsages
1705 } OPTIONAL,
1706 inner [1] InnerType,
1707 ...
1708 }
1712 7. Tickets
1715 [ A large number of items described here are duplicated in the
1716 sections describing KDC-REQ processing. Should find a way to avoid
1717 this duplication. ]
1720 A ticket binds a principal name to a session key. The important
1721 fields of a ticket are in the encrypted part. The components in
1722 common between the RFC 1510 and the extensible versions are
1725 EncTicketPartCommon ::= SEQUENCE {
1726 flags [0] TicketFlags,
1727 key [1] EncryptionKey,
1728 crealm [2] Realm,
1729 cname [3] PrincipalName,
1730 transited [4] TransitedEncoding,
1731 authtime [5] KerberosTime,
1732 starttime [6] KerberosTime OPTIONAL,
1733 endtime [7] KerberosTime,
1734 renew-till [8] KerberosTime OPTIONAL,
1735 caddr [9] HostAddresses OPTIONAL,
1736 authorization-data [10] AuthorizationData OPTIONAL,
1737 ...
1738 }
1742 crealm
1743 This field contains the client's realm.
1746 cname
1747 This field contains the client's name.
1750 Yu Expires: Apr 2005 [Page 27]
1751 Internet-Draft yu-krb-extensions-02 25 Oct 2004
1754 caddr
1755 This field lists the network addresses (if absent, all addresses
1756 are permitted) from which the ticket is valid.
1759 Descriptions of the other fields appear in the following sections.
1762 7.1. Timestamps
1765 Three of the ticket timestamps may be requested from the KDC. The
1766 timestamps may differ from those requested, depending on site policy.
1769 authtime
1770 The time at which the client authenticated, as recorded by the
1771 KDC.
1774 starttime
1775 The earliest time when the ticket is valid. If not present, the
1776 ticket is valid starting at the authtime. This is requested as
1777 the "from" field of KDC-REQ-BODY-COMMON.
1780 endtime
1781 This time is requested in the "till" field of KDC-REQ-BODY-
1782 COMMON. Contains the time after which the ticket will not be
1783 honored (its expiration time). Note that individual services
1784 MAY place their own limits on the life of a ticket and MAY
1785 reject tickets which have not yet expired. As such, this is
1786 really an upper bound on the expiration time for the ticket.
1789 renew-till
1790 This time is requested in the "rtime" field of KDC-REQ-BODY-
1791 COMMON. It is only present in tickets that have the "renewable"
1792 flag set in the flags field. It indicates the maximum endtime
1793 that may be included in a renewal. It can be thought of as the
1794 absolute expiration time for the ticket, including all renewals.
1797 7.2. Ticket Flags
1800 A number of flags may be set in the ticket, further defining some of
1801 its capabilities. Some of these flags map to flags in a KDC request.
1816 Yu Expires: Apr 2005 [Page 28]
1817 Internet-Draft yu-krb-extensions-02 25 Oct 2004
1820 TicketFlags ::= KerberosFlags { TicketFlagsBits }
1823 TicketFlagsBits ::= BIT STRING {
1824 reserved (0),
1825 forwardable (1),
1826 forwarded (2),
1827 proxiable (3),
1828 proxy (4),
1829 may-postdate (5),
1830 postdated (6),
1831 invalid (7),
1832 renewable (8),
1833 initial (9),
1834 pre-authent (10),
1835 hw-authent (11),
1836 transited-policy-checked (12),
1837 ok-as-delegate (13),
1838 anonymous (14),
1839 cksummed-ticket (15)
1840 }
1844 7.2.1. Flags Relating to Initial Ticket Acquisition
1847 [ adapted KCLAR 2.1. ]
1850 Several flags indicate the details of how the initial ticket was
1851 acquired.
1854 initial
1855 The "initial" flag indicates that a ticket was issued using the
1856 AS protocol, rather than issued based on a ticket-granting
1857 ticket. Application servers (e.g., a password-changing program)
1858 requiring a client's definite knowledge of its secret key can
1859 insist that this flag be set in any tickets they accept, thus
1860 being assured that the client's key was recently presented to
1861 the application client.
1864 pre-authent
1865 The "pre-authent" flag indicates that some sort of pre-
1866 authentication was used during the AS exchange.
1869 hw-authent
1870 The "hw-authent" flag indicates that some sort of hardware-based
1871 pre-authentication occurred during the AS exchange.
1874 Both the "pre-authent" and the "hw-authent" flags may be present with
1875 or without the "initial" flag; such tickets with the "initial" flag
1876 clear are ones which are derived from initial tickets with the "pre-
1877 authent" or "hw-authent" flags set.
1881 Yu Expires: Apr 2005 [Page 29]
1882 Internet-Draft yu-krb-extensions-02 25 Oct 2004
1885 7.2.2. Invalid Tickets
1888 [ KCLAR 2.2. ]
1891 The "invalid" flag indicates that a ticket is invalid. Application
1892 servers MUST reject tickets which have this flag set. A postdated
1893 ticket will be issued in this form. Invalid tickets MUST be
1894 validated by the KDC before use, by presenting them to the KDC in a
1895 TGS request with the "validate" option specified. The KDC will only
1896 validate tickets after their starttime has passed. The validation is
1897 required so that postdated tickets which have been stolen before
1898 their starttime can be rendered permanently invalid (through a hot-
1899 list mechanism -- see Section 8.3.2.4).
1902 7.2.3. OK as Delegate
1905 [ KCLAR 2.8. ]
1908 The "ok-as-delegate" flag provides a way for a KDC to communicate
1909 local realm policy to a client regarding whether the service for
1910 which the ticket is issued is trusted to accept delegated
1911 credentials. For some applications, a client may need to delegate
1912 credentials to a service to act on its behalf in contacting other
1913 services. The ability of a client to obtain a service ticket for a
1914 service conveys no information to the client about whether the
1915 service should be trusted to accept delegated credentials.
1918 The copy of the ticket flags visible to the client may have the "ok-
1919 as-delegate" flag set to indicate to the client that the service
1920 specified in the ticket has been determined by policy of the realm to
1921 be a suitable recipient of delegation. A client can use the presence
1922 of this flag to help it make a decision whether to delegate
1923 credentials (either grant a proxy or a forwarded ticket-granting
1924 ticket) to this service. It is acceptable to ignore the value of
1925 this flag. When setting this flag, an administrator should consider
1926 the security and placement of the server on which the service will
1927 run, as well as whether the service requires the use of delegated
1928 credentials.
1931 7.2.4. Renewable Tickets
1934 [ adapted KCLAR 2.3. ]
1937 The "renewable" flag indicates whether the ticket may be renewed.
1940 Renewable tickets can be used to mitigate the consequences of ticket
1941 theft. Applications may desire to hold credentials which can be
1942 valid for long periods of time. However, this can expose the
1943 credentials to potential theft for equally long periods, and those
1944 stolen credentials would be valid until the expiration time of the
1945 ticket(s). Simply using short-lived tickets and obtaining new ones
1948 Yu Expires: Apr 2005 [Page 30]
1949 Internet-Draft yu-krb-extensions-02 25 Oct 2004
1952 periodically would require the application to have long-term access
1953 to the client's secret key, which is an even greater risk.
1956 Renewable tickets have two "expiration times": the first is when the
1957 current instance of the ticket expires, and the second is the latest
1958 permissible value for an individual expiration time. An application
1959 client must periodically present an unexpired renewable ticket to the
1960 KDC, setting the "renew" option in the KDC request. The KDC will
1961 issue a new ticket with a new session key and a later expiration
1962 time. All other fields of the ticket are left unmodified by the
1963 renewal process. When the latest permissible expiration time
1964 arrives, the ticket expires permanently. At each renewal, the KDC
1965 MAY consult a hot-list to determine if the ticket had been reported
1966 stolen since its last renewal; it will refuse to renew such stolen
1967 tickets, and thus the usable lifetime of stolen tickets is reduced.
1970 The "renewable" flag in a ticket is normally only interpreted by the
1971 ticket-granting service. It can usually be ignored by application
1972 servers. However, some particularly careful application servers MAY
1973 disallow renewable tickets.
1976 If a renewable ticket is not renewed by its expiration time, the KDC
1977 will not renew the ticket. The "renewable" flag is clear by default,
1978 but a client can request it be set by setting the "renewable" option
1979 in the AS-REQ message. If it is set, then the "renew-till" field in
1980 the ticket contains the time after which the ticket may not be
1981 renewed.
1984 7.2.5. Postdated Tickets
1987 postdated
1988 indicates a ticket which has been postdated
1991 may-postdate
1992 indicates that postdated tickets may be issued based on this
1993 ticket
1996 [ KCLAR 2.4. ]
1999 Applications may occasionally need to obtain tickets for use much
2000 later, e.g., a batch submission system would need tickets to be valid
2001 at the time the batch job is serviced. However, it is dangerous to
2002 hold valid tickets in a batch queue, since they will be on-line
2003 longer and more prone to theft. Postdated tickets provide a way to
2004 obtain these tickets from the KDC at job submission time, but to
2005 leave them "dormant" until they are activated and validated by a
2006 further request of the KDC. If a ticket theft were reported in the
2007 interim, the KDC would refuse to validate the ticket, and the thief
2008 would be foiled.
2013 Yu Expires: Apr 2005 [Page 31]
2014 Internet-Draft yu-krb-extensions-02 25 Oct 2004
2017 The "may-postdate" flag in a ticket is normally only interpreted by
2018 the TGS. It can be ignored by application servers. This flag MUST
2019 be set in a ticket-granting ticket in order for the KDC to issue a
2020 postdated ticket based on the presented ticket. It is reset by
2021 default; it MAY be requested by a client by setting the "allow-
2022 postdate" option in the AS-REQ [?also TGS-REQ?] message. This flag
2023 does not allow a client to obtain a postdated ticket-granting ticket;
2024 postdated ticket-granting tickets can only by obtained by requesting
2025 the postdating in the AS-REQ message. The life (endtime minus
2026 starttime) of a postdated ticket will be the remaining life of the
2027 ticket-granting ticket at the time of the request, unless the
2028 "renewable" option is also set, in which case it can be the full life
2029 (endtime minus starttime) of the ticket-granting ticket. The KDC MAY
2030 limit how far in the future a ticket may be postdated.
2033 The "postdated" flag indicates that a ticket has been postdated. The
2034 application server can check the authtime field in the ticket to see
2035 when the original authentication occurred. Some services MAY choose
2036 to reject postdated tickets, or they may only accept them within a
2037 certain period after the original authentication. When the KDC
2038 issues a "postdated" ticket, it will also be marked as "invalid", so
2039 that the application client MUST present the ticket to the KDC for
2040 validation before use.
2043 7.2.6. Proxiable and Proxy Tickets
2046 proxy
2047 indicates a proxy ticket
2050 proxiable
2051 indicates that proxy tickets may be issued based on this ticket
2054 [ KCLAR 2.5. ]
2057 It may be necessary for a principal to allow a service to perform an
2058 operation on its behalf. The service must be able to take on the
2059 identity of the client, but only for a particular purpose. A
2060 principal can allow a service to take on the principal's identity for
2061 a particular purpose by granting it a proxy.
2064 The process of granting a proxy using the "proxy" and "proxiable"
2065 flags is used to provide credentials for use with specific services.
2066 Though conceptually also a proxy, users wishing to delegate their
2067 identity in a form usable for all purposes MUST use the ticket
2068 forwarding mechanism described in the next section to forward a
2069 ticket-granting ticket.
2072 The "proxiable" flag in a ticket is normally only interpreted by the
2073 ticket-granting service. It can be ignored by application servers.
2074 When set, this flag tells the ticket-granting server that it is OK to
2075 issue a new ticket (but not a ticket-granting ticket) with a
2078 Yu Expires: Apr 2005 [Page 32]
2079 Internet-Draft yu-krb-extensions-02 25 Oct 2004
2082 different network address based on this ticket. This flag is set if
2083 requested by the client on initial authentication. By default, the
2084 client will request that it be set when requesting a ticket-granting
2085 ticket, and reset when requesting any other ticket.
2088 This flag allows a client to pass a proxy to a server to perform a
2089 remote request on its behalf (e.g. a print service client can give
2090 the print server a proxy to access the client's files on a particular
2091 file server in order to satisfy a print request).
2094 In order to complicate the use of stolen credentials, Kerberos
2095 tickets may contain a set of network addresses from which they are
2096 valid. When granting a proxy, the client MUST specify the new
2097 network address from which the proxy is to be used, or indicate that
2098 the proxy is to be issued for use from any address.
2101 The "proxy" flag is set in a ticket by the TGS when it issues a proxy
2102 ticket. Application servers MAY check this flag and at their option
2103 they MAY require additional authentication from the agent presenting
2104 the proxy in order to provide an audit trail.
2107 7.2.7. Forwarded and Forwardable Tickets
2110 forwarded
2111 indicates a forwarded ticket
2114 forwardable
2115 indicates that forwarded tickets may be issued based on this
2116 ticket
2119 [ KCLAR 2.6. ]
2122 Authentication forwarding is an instance of a proxy where the service
2123 that is granted is complete use of the client's identity. An example
2124 where it might be used is when a user logs in to a remote system and
2125 wants authentication to work from that system as if the login were
2126 local.
2129 The "forwardable" flag in a ticket is normally only interpreted by
2130 the ticket-granting service. It can be ignored by application
2131 servers. The "forwardable" flag has an interpretation similar to
2132 that of the "proxiable" flag, except ticket-granting tickets may also
2133 be issued with different network addresses. This flag is reset by
2134 default, but users MAY request that it be set by setting the
2135 "forwardable" option in the AS request when they request their
2136 initial ticket-granting ticket.
2139 This flag allows for authentication forwarding without requiring the
2140 user to enter a password again. If the flag is not set, then
2141 authentication forwarding is not permitted, but the same result can
2142 still be achieved if the user engages in the AS exchange specifying
2145 Yu Expires: Apr 2005 [Page 33]
2146 Internet-Draft yu-krb-extensions-02 25 Oct 2004
2149 the requested network addresses and supplies a password.
2152 The "forwarded" flag is set by the TGS when a client presents a
2153 ticket with the "forwardable" flag set and requests a forwarded
2154 ticket by specifying the "forwarded" KDC option and supplying a set
2155 of addresses for the new ticket. It is also set in all tickets
2156 issued based on tickets with the "forwarded" flag set. Application
2157 servers may choose to process "forwarded" tickets differently than
2158 non-forwarded tickets.
2161 If addressless tickets are forwarded from one system to another,
2162 clients SHOULD still use this option to obtain a new TGT in order to
2163 have different session keys on the different systems.
2166 7.3. Transited Realms
2169 [ KCLAR 2.7., plus new stuff ]
2172 7.4. Authorization Data
2175 [ KCLAR 5.2.6. ]
2178 ADType ::= TH-id
2181 AuthorizationData ::= SEQUENCE OF SEQUENCE {
2182 ad-type [0] ADType,
2183 ad-data [1] OCTET STRING
2184 }
2188 ad-type
2189 This field identifies the contents of the ad-data. All negative
2190 values are reserved for local use. Non-negative values are
2191 reserved for registered use.
2194 ad-data
2195 This field contains authorization data to be interpreted
2196 according to the value of the corresponding ad-type field.
2199 Each sequence of ADType and OCTET STRING is referred to as an
2200 authorization element. Elements MAY be application specific,
2201 however, there is a common set of recursive elements that should be
2202 understood by all implementations. These elements contain other
2203 AuthorizationData, and the interpretation of the encapsulating
2204 element determines which enclosed elements must be interpreted, and
2205 which may be ignored.
2208 Depending on the meaning of the encapsulating element, the
2209 encapsulated AuthorizationData may be ignored, interpreted as issued
2210 directly by the KDC, or be stored in a separate plaintext part of the
2211 ticket. The types of the encapsulating elements are specified as
2214 Yu Expires: Apr 2005 [Page 34]
2215 Internet-Draft yu-krb-extensions-02 25 Oct 2004
2218 part of the Kerberos protocol because behavior based on these
2219 container elements should be understood across implementations, while
2220 other elements need only be understood by the applications which they
2221 affect.
2224 Authorization data elements are considered critical if present in a
2225 ticket or authenticator. Unless encapsulated in a known
2226 authorization data element modifying the criticality of the elements
2227 it contains, an application server MUST reject the authentication of
2228 a client whose AP-REQ or ticket contains an unrecognized
2229 authorization data element. Authorization data is intended to
2230 restrict the use of a ticket. If the service cannot determine
2231 whether it is the target of a restriction, a security weakness may
2232 exist if the ticket can be used for that service. Authorization
2233 elements that are truly optional can be enclosed in AD-IF-RELEVANT
2234 element.
2238 ad-type | contents of ad-data
2239 ________|_______________________________________
2240 1 | DER encoding of AD-IF-RELEVANT
2241 4 | DER encoding of AD-KDCIssued
2242 5 | DER encoding of AD-AND-OR
2243 8 | DER encoding of AD-MANDATORY-FOR-KDC
2248 7.4.1. AD-IF-RELEVANT
2251 ad-if-relevant ADType ::= int32 : 1
2254 -- Encapsulates another AuthorizationData.
2255 -- Intended for application servers; receiving application servers
2256 -- MAY ignore.
2257 AD-IF-RELEVANT ::= AuthorizationData
2260 AD elements encapsulated within the if-relevant element are intended
2261 for interpretation only by application servers that understand the
2262 particular ad-type of the embedded element. Application servers that
2263 do not understand the type of an element embedded within the if-
2264 relevant element MAY ignore the uninterpretable element. This element
2265 promotes interoperability across implementations which may have local
2266 extensions for authorization. The ad-type for AD-IF-RELEVANT is (1).
2269 7.4.2. AD-KDCIssued
2278 Yu Expires: Apr 2005 [Page 35]
2279 Internet-Draft yu-krb-extensions-02 25 Oct 2004
2282 -- KDC-issued privilege attributes
2283 ad-kdcissued ADType ::= int32 : 4
2286 AD-KDCIssued ::= SEQUENCE {
2287 ad-checksum [0] ChecksumOf {
2288 AuthorizationData, { key-session },
2289 { ku-ad-KDCIssued-cksum }},
2290 i-realm [1] Realm OPTIONAL,
2291 i-sname [2] PrincipalName OPTIONAL,
2292 elements [3] AuthorizationData
2293 }
2297 ad-checksum
2298 A cryptographic checksum computed over the DER encoding of the
2299 AuthorizationData in the "elements" field, keyed with the
2300 session key. Its checksumtype is the mandatory checksum type
2301 for the encryption type of the session key, and its key usage
2302 value is 19.
2305 i-realm, i-sname
2306 The name of the issuing principal if different from the KDC
2307 itself. This field would be used when the KDC can verify the
2308 authenticity of elements signed by the issuing principal and it
2309 allows this KDC to notify the application server of the validity
2310 of those elements.
2313 elements
2314 AuthorizationData issued by the KDC.
2317 The KDC-issued ad-data field is intended to provide a means for
2318 Kerberos credentials to embed within themselves privilege attributes
2319 and other mechanisms for positive authorization, amplifying the
2320 privileges of the principal beyond what it would have if using
2321 credentials without such an authorization-data element.
2324 This amplification of privileges cannot be provided without this
2325 element because the definition of the authorization-data field allows
2326 elements to be added at will by the bearer of a TGT at the time that
2327 they request service tickets and elements may also be added to a
2328 delegated ticket by inclusion in the authenticator.
2331 For KDC-issued elements this is prevented because the elements are
2332 signed by the KDC by including a checksum encrypted using the
2333 server's key (the same key used to encrypt the ticket -- or a key
2334 derived from that key). AuthorizationData encapsulated with in the
2335 AD-KDCIssued element MUST be ignored by the application server if
2336 this "signature" is not present. Further, AuthorizationData
2337 encapsulated within this element from a ticket-granting ticket MAY be
2338 interpreted by the KDC, and used as a basis according to policy for
2339 including new signed elements within derivative tickets, but they
2342 Yu Expires: Apr 2005 [Page 36]
2343 Internet-Draft yu-krb-extensions-02 25 Oct 2004
2346 will not be copied to a derivative ticket directly. If they are
2347 copied directly to a derivative ticket by a KDC that is not aware of
2348 this element, the signature will not be correct for the application
2349 ticket elements, and the field will be ignored by the application
2350 server.
2353 This element and the elements it encapsulates MAY be safely ignored
2354 by applications, application servers, and KDCs that do not implement
2355 this element.
2358 The ad-type for AD-KDC-ISSUED is (4).
2361 7.4.3. AD-AND-OR
2364 ad-and-or ADType ::= int32 : 5
2367 AD-AND-OR ::= SEQUENCE {
2368 condition-count [0] INTEGER,
2369 elements [1] AuthorizationData
2370 }
2374 When restrictive AD elements are encapsulated within the and-or
2375 element, the and-or element is considered satisfied if and only if at
2376 least the number of encapsulated elements specified in condition-
2377 count are satisfied. Therefore, this element MAY be used to
2378 implement an "or" operation by setting the condition-count field to
2379 1, and it MAY specify an "and" operation by setting the condition
2380 count to the number of embedded elements. Application servers that do
2381 not implement this element MUST reject tickets that contain
2382 authorization data elements of this type.
2385 The ad-type for AD-AND-OR is (5).
2388 7.4.4. AD-MANDATORY-FOR-KDC
2391 -- KDCs MUST interpret any AuthorizationData wrapped in this.
2392 ad-mandatory-for-kdc ADType ::= int32 : 8
2393 AD-MANDATORY-FOR-KDC ::= AuthorizationData
2396 AD elements encapsulated within the mandatory-for-kdc element are to
2397 be interpreted by the KDC. KDCs that do not understand the type of
2398 an element embedded within the mandatory-for-kdc element MUST reject
2399 the request.
2402 The ad-type for AD-MANDATORY-FOR-KDC is (8).
2405 7.5. Encrypted Part of Ticket
2408 The complete definition of the encrypted part is
2412 Yu Expires: Apr 2005 [Page 37]
2413 Internet-Draft yu-krb-extensions-02 25 Oct 2004
2416 -- Encrypted part of ticket
2417 EncTicketPart ::= CHOICE {
2418 rfc1510 [APPLICATION 3] EncTicketPart1510,
2419 ext [APPLICATION 5] EncTicketPartExt
2420 }
2423 with the common portion being
2426 EncTicketPartCommon ::= SEQUENCE {
2427 flags [0] TicketFlags,
2428 key [1] EncryptionKey,
2429 crealm [2] Realm,
2430 cname [3] PrincipalName,
2431 transited [4] TransitedEncoding,
2432 authtime [5] KerberosTime,
2433 starttime [6] KerberosTime OPTIONAL,
2434 endtime [7] KerberosTime,
2435 renew-till [8] KerberosTime OPTIONAL,
2436 caddr [9] HostAddresses OPTIONAL,
2437 authorization-data [10] AuthorizationData OPTIONAL,
2438 ...
2439 }
2443 The encrypted part of the backwards-compatibility form of a ticket
2444 is:
2447 EncTicketPart1510 ::= SEQUENCE {
2448 COMPONENTS OF EncTicketPartCommon
2449 } (WITH COMPONENTS {
2450 ...,
2451 -- explicitly force IA5 in strings
2452 crealm (RealmIA5),
2453 cname (PrincipalNameIA5)
2454 })
2457 The encrypted part of the extensible form of a ticket is:
2460 EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS {
2461 ...,
2462 -- explicitly force UTF-8 in strings
2463 crealm (RealmExt),
2464 cname (PrincipalNameExt),
2465 -- explicitly constrain caddr to be non-empty if present
2466 caddr (SIZE (1..MAX)),
2467 -- forbid empty authorization-data encodings
2468 authorization-data (SIZE (1..MAX))
2469 })
2475 Yu Expires: Apr 2005 [Page 38]
2476 Internet-Draft yu-krb-extensions-02 25 Oct 2004
2479 7.6. Cleartext Part of Ticket
2482 The complete definition of Ticket is:
2485 Ticket ::= CHOICE {
2486 rfc1510 [APPLICATION 1] Ticket1510,
2487 ext [APPLICATION 4] Signed {
2488 TicketExt, { key-server }, { ku-Ticket-cksum }
2489 }
2490 }
2493 with the common portion being:
2496 -- takes a parameter specifying which type gets encrypted
2497 TicketCommon { EncPart } ::= SEQUENCE {
2498 tkt-vno [0] INTEGER (5),
2499 realm [1] Realm,
2500 sname [2] PrincipalName,
2501 enc-part [3] EncryptedData {
2502 EncPart, { key-server }, { ku-Ticket }
2503 },
2504 ...,
2505 extensions [4] TicketExtensions OPTIONAL,
2506 ...
2507 }
2511 The "sname" field provides the name of the target service principal
2512 in cleartext, as a hint to aid the server in choosing the correct
2513 decryption key.
2516 The backwards-compatibility form of Ticket is:
2519 Ticket1510 ::= SEQUENCE {
2520 COMPONENTS OF TicketCommon { EncTicketPart1510 }
2521 } (WITH COMPONENTS {
2522 ...,
2523 -- explicitly force IA5 in strings
2524 realm (RealmIA5),
2525 sname (PrincipalNameIA5)
2526 })
2529 The extensible form of Ticket is:
2540 Yu Expires: Apr 2005 [Page 39]
2541 Internet-Draft yu-krb-extensions-02 25 Oct 2004
2544 -- APPLICATION tag goes inside Signed{} as well as outside,
2545 -- to prevent possible substitution attacks.
2546 TicketExt ::= [APPLICATION 4] TicketCommon {
2547 EncTicketPartExt
2548 } (WITH COMPONENTS {
2549 ...,
2550 -- explicitly force UTF-8 in strings
2551 realm (RealmExt),
2552 sname (PrincipalNameExt)
2553 })
2557 TicketExtensions, which may only be present in the extensible form of
2558 Ticket, are a cleartext typed hole for extension use.
2559 AuthorizationData already provides an encrypted typed hole.
2562 TEType ::= TH-id
2565 -- ticket extensions: for TicketExt only
2566 TicketExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
2567 te-type [0] TEType,
2568 te-data [1] OCTET STRING
2569 }
2573 A client will only receive an extensible Ticket if the application
2574 server supports extensibility.
2577 8. Credential Acquisition
2580 There are two exchanges that can be used for acquiring credentials:
2581 the AS exchange and the TGS exchange. These exchanges have many
2582 similarities, and this document describes them in parallel, noting
2583 which behaviors are specific to one type of exchange. The AS request
2584 (AS-REQ) and TGS request (TGS-REQ) are both forms of KDC requests
2585 (KDC-REQ). Likewise, the AS reply (AS-REP) and TGS reply (TGS-REP)
2586 are forms of KDC replies (KDC-REP).
2589 The credentials acquisition protocol operates over specific
2590 transports. Additionally, specific methods exist to permit a client
2591 to discover the KDC host with which to communicate.
2594 8.1. KDC-REQ
2597 The KDC-REQ has a large number of fields in common between the RFC
2598 1510 and the extensible versions. The KDC-REQ type itself is never
2599 directly encoded; it is always a part of a AS-REQ or a TGS-REQ.
2606 Yu Expires: Apr 2005 [Page 40]
2607 Internet-Draft yu-krb-extensions-02 25 Oct 2004
2610 KDC-REQ-COMMON ::= SEQUENCE {
2611 -- NOTE: first tag is [1], not [0]
2612 pvno [1] INTEGER (5),
2613 msg-type [2] INTEGER (10 -- AS-REQ.rfc1510 --
2614 | 12 -- TGS-REQ.rfc1510 --
2615 | 6 -- AS-REQ.ext --
2616 | 8 -- TGS-REQ.ext -- ),
2617 padata [3] SEQUENCE OF PA-DATA OPTIONAL
2618 -- NOTE: not empty
2619 }
2623 KDC-REQ-BODY-COMMON ::= SEQUENCE {
2624 kdc-options [0] KDCOptions,
2625 cname [1] PrincipalName OPTIONAL
2626 -- Used only in AS-REQ --,
2629 realm [2] Realm
2630 -- Server's realm; also client's in AS-REQ --,
2633 sname [3] PrincipalName OPTIONAL,
2634 from [4] KerberosTime OPTIONAL,
2635 till [5] KerberosTime OPTIONAL
2636 -- was required in rfc1510;
2637 -- still required for compat versions
2638 -- of messages --,
2641 rtime [6] KerberosTime OPTIONAL,
2642 nonce [7] Nonce,
2643 etype [8] SEQUENCE OF EType
2644 -- in preference order --,
2647 addresses [9] HostAddresses OPTIONAL,
2648 enc-authorization-data [10] EncryptedData {
2649 AuthorizationData, { key-session | key-subsession },
2650 { ku-TGSReqAuthData-subkey |
2651 ku-TGSReqAuthData-sesskey }
2652 } OPTIONAL,
2655 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
2656 -- NOTE: not empty --,
2657 ...
2658 lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF
2659 LangTag OPTIONAL,
2660 ...
2661 }
2665 Many fields of KDC-REQ-BODY-COMMON correspond directly to fields of
2666 an EncTicketPartCommon. The KDC copies most of them unchanged,
2667 provided that the requested values meet site policy.
2670 Yu Expires: Apr 2005 [Page 41]
2671 Internet-Draft yu-krb-extensions-02 25 Oct 2004
2674 kdc-options
2675 These flags do not correspond directly to "flags" in
2676 EncTicketPartCommon.
2679 cname
2680 This field is copied to the "cname" field in
2681 EncTicketPartCommon. The "cname" field is required in an AS-
2682 REQ; the client places its own name here. In a TGS-REQ, the
2683 "cname" in the ticket in the AP-REQ takes precedence.
2686 realm
2687 This field is the server's realm, and also holds the client's
2688 realm in an AS-REQ.
2691 sname
2692 The "sname" field indicates the server's name. It may be absent
2693 in a TGS-REQ which requests user-to-user authentication, in
2694 which case the "sname" of the issued ticket will be taken from
2695 the included additional ticket.
2698 The "from", "till", and "rtime" fields correspond to the "starttime",
2699 "endtime", and "renew-till" fields of EncTicketPartCommon.
2702 addresses
2703 This field corresponds to the "caddr" field of
2704 EncTicketPartCommon.
2707 enc-authorization-data
2708 For TGS-REQ, this field contains authorization data encrypted
2709 using either the TGT session key or the AP-REQ subsession key;
2710 the KDC may copy these into the "authorization-data" field of
2711 EncTicketPartCommon if policy permits.
2714 lang-tags
2715 Only present in the extensible messages. Specifies the set of
2716 languages which the client is willing to accept in error
2717 messages.
2720 KDC options used in a KDC-REQ are:
2735 Yu Expires: Apr 2005 [Page 42]
2736 Internet-Draft yu-krb-extensions-02 25 Oct 2004
2739 KDCOptions ::= KerberosFlags { KDCOptionsBits }
2742 KDCOptionsBits ::= BIT STRING {
2743 reserved (0),
2744 forwardable (1),
2745 forwarded (2),
2746 proxiable (3),
2747 proxy (4),
2748 allow-postdate (5),
2749 postdated (6),
2750 unused7 (7),
2751 renewable (8),
2752 unused9 (9),
2753 unused10 (10),
2754 unused11 (11),
2755 unused12 (12),
2756 unused13 (13),
2757 requestanonymous (14),
2758 canonicalize (15),
2759 disable-transited-check (26),
2760 renewable-ok (27),
2761 enc-tkt-in-skey (28),
2762 renew (30),
2763 validate (31)
2764 -- XXX need "need ticket1" flag?
2765 }
2768 Different options apply to different phases of KDC-REQ processing.
2771 The backwards-compatibility form of a KDC-REQ is:
2774 KDC-REQ-1510 ::= SEQUENCE {
2775 COMPONENTS OF KDC-REQ-COMMON,
2776 req-body [4] KDC-REQ-BODY-1510
2777 } (WITH COMPONENTS { ..., msg-type (10 | 12) })
2780 The extensible form of a KDC-REQ is:
2783 -- APPLICATION tag goes inside Signed{} as well as outside,
2784 -- to prevent possible substitution attacks.
2785 KDC-REQ-EXT ::= SEQUENCE {
2786 COMPONENTS OF KDC-REQ-COMMON,
2787 req-body [4] KDC-REQ-BODY-EXT,
2788 ...
2789 } (WITH COMPONENTS {
2790 ...,
2791 msg-type (6 | 8),
2792 padata (SIZE (1..MAX))
2793 })
2796 The backwards-compatibility form of a KDC-REQ-BODY is:
2799 Yu Expires: Apr 2005 [Page 43]
2800 Internet-Draft yu-krb-extensions-02 25 Oct 2004
2803 KDC-REQ-BODY-1510 ::= SEQUENCE {
2804 COMPONENTS OF KDC-REQ-BODY-COMMON
2805 } (WITH COMPONENTS {
2806 ...,
2807 cname (PrincipalNameIA5),
2808 realm (RealmIA5),
2809 sname (PrincipalNameIA5),
2810 till PRESENT,
2811 nonce (UInt32)
2812 })
2815 The extensible form of a KDC-REQ-BODY is:
2818 KDC-REQ-BODY-EXT ::= KDC-REQ-BODY-COMMON
2819 (WITH COMPONENTS {
2820 ...,
2821 cname (PrincipalNameExt),
2822 realm (RealmExt),
2823 sname (PrincipalNameExt),
2824 addresses (SIZE (1..MAX)),
2825 enc-authorization-data (EncryptedData {
2826 AuthorizationData (SIZE (1..MAX)),
2827 { key-session | key-subsession },
2828 { ku-TGSReqAuthData-subkey |
2829 ku-TGSReqAuthData-sesskey }
2830 }),
2831 additional-tickets (SIZE (1..MAX))
2832 })
2835 The AS-REQ is:
2859 Yu Expires: Apr 2005 [Page 44]
2860 Internet-Draft yu-krb-extensions-02 25 Oct 2004
2863 AS-REQ ::= CHOICE {
2864 rfc1510 [APPLICATION 10] KDC-REQ-1510
2865 (WITH COMPONENTS {
2866 ...,
2867 msg-type (10),
2868 -- AS-REQ must include client name
2869 req-body (WITH COMPONENTS { ..., cname PRESENT })
2870 }),
2871 ext [APPLICATION 6] Signed {
2872 -- APPLICATION tag goes inside Signed{} as well as
2873 -- outside, to prevent possible substitution attacks.
2874 [APPLICATION 6] KDC-REQ-EXT,
2875 -- not sure this is correct key to use; do we even want
2876 -- to sign AS-REQ?
2877 { key-client },
2878 { ku-ASReq-cksum }
2879 }
2880 (WITH COMPONENTS {
2881 ...,
2882 msg-type (6),
2883 -- AS-REQ must include client name
2884 req-body (WITH COMPONENTS { ..., cname PRESENT })
2885 })
2886 }
2889 A client SHOULD NOT send the extensible AS-REQ alternative to a KDC
2890 if the client does not know that the KDC supports the extensibility
2891 framework. A client SHOULD send the extensible AS-REQ alternative in
2892 a PA-AS-REQ PA-DATA. A KDC supporting extensibility will treat the
2893 AS-REQ contained within the PA-AS-REQ as the actual AS-REQ. [ XXX
2894 what if their contents conflict? ]
2897 The TGS-REQ is:
2918 Yu Expires: Apr 2005 [Page 45]
2919 Internet-Draft yu-krb-extensions-02 25 Oct 2004
2922 TGS-REQ ::= CHOICE {
2923 rfc1510 [APPLICATION 12] KDC-REQ-1510
2924 (WITH COMPONENTS {
2925 ...,
2926 msg-type (12),
2927 -- client name optional in TGS-REQ
2928 req-body (WITH COMPONENTS { ..., cname ABSENT })
2929 }),
2930 ext [APPLICATION 8] Signed {
2931 -- APPLICATION tag goes inside Signed{} as well as
2932 -- outside, to prevent possible substitution attacks.
2933 [APPLICATION 8] KDC-REQ-EXT,
2934 { key-session }, { ku-TGSReq-cksum }
2935 }
2936 (WITH COMPONENTS {
2937 ...,
2938 msg-type (8),
2939 -- client name optional in TGS-REQ
2940 req-body (WITH COMPONENTS { ..., cname ABSENT })
2941 })
2942 }
2946 8.2. PA-DATA
2949 PA-DATA have multiple uses in the Kerberos protocol. They may pre-
2950 authenticate an AS-REQ; they may also modify several of the
2951 encryption keys used in a KDC-REP. PA-DATA may also provide "hints"
2952 to the client about which long-term key (usually password-derived) to
2953 use. PA-DATA may also include "hints" about which pre-authentication
2954 mechanisms to use, or include data for input into a pre-
2955 authentication mechanism.
2958 [ XXX enumerate standard padata here ]
2961 8.3. KDC-REQ Processing
2964 Processing of a KDC-REQ proceeds through several steps. An
2965 implementation need not perform these steps exactly as described, as
2966 long as it behaves as if the steps were performed as described. The
2967 KDC performs replay handling upon receiving the request; it then
2968 validates the request, adjusts timestamps, and selects the keys used
2969 in the reply. It copies data from the request into the issued
2970 ticket, adjusting the values to conform with its policies. The KDC
2971 then transmits the reply to the client.
2974 8.3.1. Handling Replays
2977 Because Kerberos can run over unreliable transports such as UDP, the
2978 KDC MUST be prepared to retransmit responses in case they are lost.
2979 If a KDC receives a request identical to one it has recently
2982 Yu Expires: Apr 2005 [Page 46]
2983 Internet-Draft yu-krb-extensions-02 25 Oct 2004
2986 successfully processed, the KDC MUST respond with a KDC-REP message
2987 rather than a replay error. In order to reduce the amount of
2988 ciphertext given to a potential attacker, KDCs MAY send the same
2989 response generated when the request was first handled. KDCs MUST
2990 obey this replay behavior even if the actual transport in use is
2991 reliable. If the AP-REQ which authenticates a TGS-REQ is a replay,
2992 and the entire request is not identical to a recently successfully
2993 processed request, the KDC SHOULD return "krb-ap-err-repeat", as is
2994 appropriate for AP-REQ processing.
2997 8.3.2. Request Validation
3000 8.3.2.1. AS-REQ Authentication
3003 Site policy determines whether a given client principal is required
3004 to provide some pre-authentication prior to receiving an AS-REP.
3005 Since the default reply key is typically the client's long-term
3006 password-based key, an attacker may easily request known plaintext
3007 (in the form of an AS-REP) upon which to mount a dictionary attack.
3008 Pre-authentication can limit the possibility of such an attack.
3011 If site policy requires pre-authentication for a client principal,
3012 and no pre-authentication is provided, the KDC returns the error
3013 "kdc-err-preauth-required". Accompanying this error are "e-data"
3014 which include hints telling the client which pre-authentication
3015 mechanisms to use, or data for input to pre-authentication mechanisms
3016 (e.g., input to challenge-response systems). If pre-authentication
3017 fails, the KDC returns the error "kdc-err-preauth-failed".
3020 [ may need additional changes based on Sam's preauth draft ]
3023 8.3.2.2. TGS-REQ Authentication
3026 A TGS-REQ has an accompanying AP-REQ, which is included in the "pa-
3027 tgs-req". The KDC MUST validate the checksum in the Authenticator of
3028 the AP-REQ, which is computed over the KDC-REQ-BODY-1510 or KDC-REQ-
3029 BODY-EXT (for TGS-REQ-1510 or TGS-REQ-EXT, respectively) of the
3030 request. [ padata not signed by authenticator! ] Any error from the
3031 AP-REQ validation process SHOULD be returned in a KRB-ERROR message.
3032 The service principal in the ticket of the AP-REQ may be a ticket-
3033 granting service principal, or a normal application service
3034 principal. A ticket which is not a ticket-granting ticket MUST NOT
3035 be used to issue a ticket for any service other than the one named in
3036 the ticket. In this case, the "renew", "validate", or "proxy" [?also
3037 forwarded?] option must be set in the request.
3040 8.3.2.3. Principal Validation
3043 If the client principal in an AS-REQ is unknown, the KDC returns the
3044 error "kdc-err-c-principal-unknown". If the server principal in a
3045 KDC-REQ is unknown, the KDC returns the error "kdc-err-s-principal-
3048 Yu Expires: Apr 2005 [Page 47]
3049 Internet-Draft yu-krb-extensions-02 25 Oct 2004
3052 unknown".
3055 8.3.2.4. Checking For Revoked or Invalid Tickets
3058 [ KCLAR 3.3.3.1 ]
3061 Whenever a request is made to the ticket-granting server, the
3062 presented ticket(s) is(are) checked against a hot-list of tickets
3063 which have been canceled. This hot-list might be implemented by
3064 storing a range of issue timestamps for "suspect tickets"; if a
3065 presented ticket had an authtime in that range, it would be rejected.
3066 In this way, a stolen ticket-granting ticket or renewable ticket
3067 cannot be used to gain additional tickets (renewals or otherwise)
3068 once the theft has been reported to the KDC for the realm in which
3069 the server resides. Any normal ticket obtained before it was
3070 reported stolen will still be valid (because they require no
3071 interaction with the KDC), but only until their normal expiration
3072 time. If TGTs have been issued for cross-realm authentication, use
3073 of the cross-realm TGT will not be affected unless the hot-list is
3074 propagated to the KDCs for the realms for which such cross-realm
3075 tickets were issued.
3078 If a TGS-REQ ticket has its "invalid" flag set, the KDC MUST NOT
3079 issue any ticket unless the TGS-REQ requests the "validate" option.
3082 8.3.3. Timestamp Handling
3085 [ some aspects of timestamp handling, especially regarding postdating
3086 and renewal, are difficult to read in KCLAR... needs closer
3087 examination here ]
3090 Processing of "starttime" (requested in the "from" field) differs
3091 depending on whether the "postdated" option is set in the request.
3092 If the "postdated" option is not set, and the requested "starttime"
3093 is in the future beyond the window of acceptable clock skew, the KDC
3094 returns the error "kdc-err-cannot-postdate". If the "postdated"
3095 option is not set, and the requested "starttime" is absent or does
3096 not indicate a time in the future beyond the acceptable clock skew,
3097 the KDC sets the "starttime" to the KDC's current time. The
3098 "postdated" option MUST NOT be honored if the ticket is being
3099 requested by TGS-REQ and the "may-postdate" is not set in the TGT.
3100 Otherwise, if the "postdated" option is set, and site policy permits,
3101 the KDC sets the "starttime" as requested, and sets the "invalid"
3102 flag in the new ticket.
3105 The "till" field is required in the RFC 1510 version of the KDC-REQ.
3106 If the "till" field is equal to "19700101000000Z" (midnight, January
3107 1, 1970), the KDC SHOULD behave as if the "till" field were absent.
3110 The KDC MUST NOT issue a ticket whose "starttime", "endtime", or
3111 "renew-till" time is later than the "renew-till" time of the ticket
3114 Yu Expires: Apr 2005 [Page 48]
3115 Internet-Draft yu-krb-extensions-02 25 Oct 2004
3118 from which it is derived.
3121 8.3.3.1. AS-REQ Timestamp Processing
3124 In the AS exchange, the "authtime" of a ticket is set to the local
3125 time at the KDC.
3128 The "endtime" of the ticket will be set to the earlier of the
3129 requested "till" time and a time determined by local policy, possibly
3130 determined using factors specific to the realm or principal. For
3131 example, the expiration time MAY be set to the earliest of the
3132 following:
3135 * the expiration time ("till" value) requested
3138 * the ticket's start time plus the maximum allowable lifetime
3139 associated with the client principal from the authentication
3140 server's database
3143 * the ticket's start time plus the maximum allowable lifetime
3144 associated with the server principal
3147 * the ticket's start time plus the maximum lifetime set by the
3148 policy of the local realm
3151 If the requested expiration time minus the start time (as determined
3152 above) is less than a site-determined minimum lifetime, an error
3153 message with code "kdc-err-never-valid" is returned. If the
3154 requested expiration time for the ticket exceeds what was determined
3155 as above, and if the "renewable-ok" option was requested, then the
3156 "renewable" flag is set in the new ticket, and the "renew-till" value
3157 is set as if the "renewable" option were requested.
3160 If the "renewable" option has been requested or if the "renewable-ok"
3161 option has been set and a renewable ticket is to be issued, then the
3162 "renew-till" field MAY be set to the earliest of:
3165 * its requested value
3168 * the start time of the ticket plus the minimum of the two maximum
3169 renewable lifetimes associated with the principals' database
3170 entries
3173 * the start time of the ticket plus the maximum renewable lifetime
3174 set by the policy of the local realm
3177 8.3.3.2. TGS-REQ Timestamp Processing
3180 In the TGS exchange, the KDC sets the "authtime" to that of the
3181 ticket in the AP-REQ authenticating the TGS-REQ. [?application
3182 server can print a ticket for itself with a spoofed authtime.
3185 Yu Expires: Apr 2005 [Page 49]
3186 Internet-Draft yu-krb-extensions-02 25 Oct 2004
3189 security issues for hot-list?] [ MIT implementation may change
3190 authtime of renewed tickets; needs check... ]
3193 If the TGS-REQ has a TGT as the ticket in its AP-REQ, and the TGS-REQ
3194 requests an "endtime" (in the "till" field), then the "endtime" of
3195 the new ticket is set to the minimum of
3198 * the requested "endtime" value,
3201 * the "endtime" in the TGT, and
3204 * an "endtime" determined by site policy on ticket lifetimes.
3207 If the new ticket is a renewal, the "endtime" of the new ticket is
3208 bounded by the minimum of
3211 * the requested "endtime" value,
3214 * the value of the "renew-till" value of the old,
3217 * the "starttime" of the new ticket plus the lifetime (endtime
3218 minus starttime) of the old ticket, i.e., the lifetime of the
3219 new ticket may not exceed that of the ticket being renewed [
3220 adapted from KCLAR 3.3.3. ], and
3223 * an "endtime" determined by site policy on ticket lifetimes.
3226 When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with
3227 a "starttime", "endtime", or "renew-till" time later than the
3228 "renew-till" time of the TGT.
3231 8.3.4. Handling Transited Realms
3234 The KDC checks the ticket in a TGS-REQ against site policy, unless
3235 the "disable-transited-check" option is set in the TGS-REQ. If site
3236 policy permits the transit path in the TGS-REQ ticket, the KDC sets
3237 the "transited-policy-checked" flag in the issued ticket. If the
3238 "disable-transited-check" option is set, the issued ticket will have
3239 the "transited-policy-checked" flag cleared.
3242 8.3.5. Address Processing The requested "addresses" in the KDC-REQ are
3243 copied into the issued ticket. If the "addresses" field is absent or
3244 empty in a TGS-REQ, the KDC copies addresses from the ticket in the
3245 TGS-REQ into the issued ticket, unless the either "forwarded" or
3246 "proxy" option is set. If the "forwarded" option is set, and the
3247 ticket in the TGS-REQ has its "forwardable" flag set, the KDC copies
3248 the addresses from the TGS-REQ, not the from TGS-REQ ticket, into the
3249 issued ticket. The KDC behaves similarly if the "proxy" option is
3250 set in the TGS-REQ and the "proxiable" flag is set in the ticket.
3251 The "proxy" option will not be honored on requests for additional
3252 ticket-granting tickets.
3255 Yu Expires: Apr 2005 [Page 50]
3256 Internet-Draft yu-krb-extensions-02 25 Oct 2004
3259 8.3.6. Ticket Flag Processing
3262 Many kdc-options request that the KDC set a corresponding flag in the
3263 issued ticket. kdc-options marked with an asterisk (*) in the
3264 following table do not directly request the corresponding ticket flag
3265 and therefore require special handling.
3269 kdc-option | ticket flag affected
3270 ________________________|__________________________
3271 forwardable | forwardable
3272 forwarded | forwarded
3273 proxiable | proxiable
3274 proxy | proxy
3275 allow-postdate | may-postdate
3276 postdated | postdated
3277 renewable | renewable
3278 requestanonymous | anonymous
3279 canonicalize | -
3280 disable-transited-check*| transited-policy-checked
3281 renewable-ok* | renewable
3282 enc-tkt-in-skey | -
3283 renew | -
3284 validate* | invalid
3289 forwarded
3290 The KDC sets the "forwarded" flag in the issued ticket if the
3291 "forwarded" option is set in the TGS-REQ and the "forwardable"
3292 flag is set in the TGS-REQ ticket.
3295 proxy
3296 The KDC sets the "proxy" flag in the issued ticket if the
3297 "proxy" option is set in the TGS-REQ and the "proxiable" flag is
3298 set in the TGS-REQ ticket.
3301 disable-transited-check
3302 The handling of the "disable-transited-check" kdc-option is
3303 described in Section 8.3.4.
3306 renewable-ok
3307 The handling of the "renewable-ok" kdc-option is described in
3308 Section 8.3.3.1.
3311 enc-tkt-in-skey
3312 This flag modifies ticket key selection to use the session key
3313 of an additional ticket included in the TGS-REQ, for the purpose
3314 of user-to-user authentication.
3319 Yu Expires: Apr 2005 [Page 51]
3320 Internet-Draft yu-krb-extensions-02 25 Oct 2004
3323 validate
3324 If the "validate" kdc-option is set in a TGS-REQ, and the
3325 "starttime" has passed, the KDC will clear the "invalid" bit on
3326 the ticket before re-issuing it.
3329 8.3.7. Key Selection
3332 Three keys are involved in creating a KDC-REP. The reply key
3333 encrypts the encrypted part of the KDC-REP. The session key is
3334 stored in the encrypted part of the ticket, and is also present in
3335 the encrypted part of the KDC-REP so that the client can retrieve it.
3336 The ticket key is used to encrypt the ticket. These keys all have
3337 initial values for a given exchange; pre-authentication and other
3338 extension mechanisms may change the value used for any of these keys.
3341 [ again, may need changes based on Sam's preauth draft ]
3344 8.3.7.1. Reply Key and Session Key Selection
3347 The set of encryption types which the client will understand appears
3348 in the "etype" field of KDC-REQ-BODY-COMMON. The KDC limits the set
3349 of possible reply keys and the set of session key encryption types
3350 based on the "etype" field.
3353 For the AS exchange, the reply key is initially a long-term key of
3354 the client, limited to those encryption types listed in the "etype"
3355 field. The KDC SHOULD use the first valid strong "etype" for which
3356 an encryption key is available. For the TGS exchange, the reply key
3357 is initially the subsession key of the Authenticator. If the
3358 Authenticator subsesion key is absent, the reply key is initially the
3359 session key of the ticket used to authenticate the TGS-REQ.
3362 The session key is initially randomly generated, and has an
3363 encryption type which both the client and the server will understand.
3364 Typically, the KDC has prior knowledge of which encryption types the
3365 server will understand. It selects the first valid strong "etype"
3366 listed the request which the server also will understand.
3369 8.3.7.2. Ticket Key Selection
3372 The ticket key is initially the long-term key of the service. The
3373 "enc-tkt-in-skey" option requests user-to-user authentication, where
3374 the ticket encryption key of the issued ticket is set equal to the
3375 session key of the additional ticket in the request.
3378 8.4. KDC-REP
3381 The important parts of the KDC-REP are encrypted.
3387 Yu Expires: Apr 2005 [Page 52]
3388 Internet-Draft yu-krb-extensions-02 25 Oct 2004
3391 EncASRepPart1510 ::= [APPLICATION 25] EncKDCRepPart1510
3392 EncTGSRepPart1510 ::= [APPLICATION 26] EncKDCRepPart1510
3395 EncASRepPartExt ::= [APPLICATION 32] EncKDCRepPartExt
3396 EncTGSRepPartExt ::= [APPLICATION 33] EncKDCRepPartExt
3399 EncKDCRepPartCom ::= SEQUENCE {
3400 key [0] EncryptionKey,
3401 last-req [1] LastReq,
3402 nonce [2] Nonce,
3403 key-expiration [3] KerberosTime OPTIONAL,
3404 flags [4] TicketFlags,
3405 authtime [5] KerberosTime,
3406 starttime [6] KerberosTime OPTIONAL,
3407 endtime [7] KerberosTime,
3408 renew-till [8] KerberosTime OPTIONAL,
3409 srealm [9] Realm,
3410 sname [10] PrincipalName,
3411 caddr [11] HostAddresses OPTIONAL,
3412 ...
3413 }
3416 EncKDCRepPart1510 ::= SEQUENCE {
3417 COMPONENTS OF EncKDCRepPartCom
3418 } (WITH COMPONENTS {
3419 ...,
3420 srealm (RealmIA5),
3421 sname (PrincipalNameIA5),
3422 nonce UInt32 })
3425 EncKdcRepPartExt ::= EncKDCRepPartCom (WITH COMPONENTS {
3426 ...,
3427 srealm (RealmExt),
3428 sname (PrincipalNameExt)
3429 })
3433 Most of the fields of EncKDCRepPartCom are duplicates of the
3434 corresponding fields in the returned ticket.
3449 Yu Expires: Apr 2005 [Page 53]
3450 Internet-Draft yu-krb-extensions-02 25 Oct 2004
3453 KDC-REP-COMMON { EncPart } ::= SEQUENCE {
3454 pvno [0] INTEGER (5),
3455 msg-type [1] INTEGER (11 -- AS-REP.rfc1510 -- |
3456 13 -- TGS.rfc1510 -- |
3457 7 -- AS-REP.ext -- |
3458 9 -- TGS-REP.ext -- ),
3459 padata [2] SEQUENCE OF PA-DATA OPTIONAL,
3460 crealm [3] Realm,
3461 cname [4] PrincipalName,
3462 ticket [5] Ticket,
3465 enc-part [6] EncryptedData {
3466 EncPart,
3467 { key-reply },
3468 -- maybe reach into EncryptedData in AS-REP/TGS-REP
3469 -- definitions to apply constraints on key usages?
3470 { ku-EncASRepPart -- if AS-REP -- |
3471 ku-EncTGSRepPart-subkey -- if TGS-REP and
3472 -- using Authenticator
3473 -- session key -- |
3474 ku-EncTGSRepPart-sesskey -- if TGS-REP and using
3475 -- subsession key -- }
3476 },
3479 ...,
3480 -- In extensible version, KDC signs original request
3481 -- to avoid replay attacks against client.
3482 req-cksum [7] ChecksumOf { CHOICE {
3483 as-req AS-REQ,
3484 tgs-req TGS-REQ
3485 }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
3486 lang-tag [8] LangTag OPTIONAL,
3487 ...
3488 }
3492 KDC-REP-1510 { EncPart } ::= SEQUENCE {
3493 COMPONENTS OF KDC-REP-COMMON { EncPart }
3494 } (WITH COMPONENTS {
3495 ...,
3496 msg-type (11 | 13),
3497 crealm (RealmIA5),
3498 cname (PrincipalNameIA5)
3499 })
3509 Yu Expires: Apr 2005 [Page 54]
3510 Internet-Draft yu-krb-extensions-02 25 Oct 2004
3513 KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart }
3514 (WITH COMPONENTS {
3515 ...,
3516 msg-type (7 | 9),
3517 crealm (RealmExt),
3518 cname (PrincipalNameExt)
3519 })
3523 req-cksum
3524 Signature of the original request using the reply key, to avoid
3525 replay attacks against the client, among other things. Only
3526 present in the extensible version of KDC-REP.
3529 AS-REP ::= CHOICE {
3530 rfc1510 [APPLICATION 11] KDC-REP-1510 {
3531 EncASRepPart1510
3532 } (WITH COMPONENTS { ..., msg-type (11) }),
3533 ext [APPLICATION 7] Signed {
3534 [APPLICATION 7] KDC-REP-EXT { EncASRepPartExt },
3535 { key-reply }, { ku-ASRep-cksum }
3536 } (WITH COMPONENTS { ..., msg-type (7) })
3537 }
3541 TGS-REP ::= CHOICE {
3542 rfc1510 [APPLICATION 13] KDC-REP-1510 {
3543 EncTGSRepPart1510
3544 } (WITH COMPONENTS { ..., msg-type (13) }),
3545 ext [APPLICATION 9] Signed {
3546 [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
3547 { key-reply }, { ku-TGSRep-cksum }
3548 } (WITH COMPONENTS { ..., msg-type (9) })
3549 }
3553 The extensible versions of AS-REQ and TGS-REQ are signed with the
3554 reply key, to prevent an attacker from performing a delayed denial-
3555 of-service attack by substituting the ticket.
3558 8.5. Reply Validation
3561 [ signature verification ]
3564 8.6. IP Transports
3567 [ KCLAR 7.2 ]
3570 Kerberos defines two IP transport mechanisms for the credentials
3571 acquisition protocol: UDP/IP and TCP/IP.
3575 Yu Expires: Apr 2005 [Page 55]
3576 Internet-Draft yu-krb-extensions-02 25 Oct 2004
3579 8.6.1. UDP/IP transport
3582 Kerberos servers (KDCs) supporting IP transports MUST accept UDP
3583 requests and SHOULD listen for such requests on port 88 (decimal)
3584 unless specifically configured to listen on an alternative UDP port.
3585 Alternate ports MAY be used when running multiple KDCs for multiple
3586 realms on the same host.
3589 Kerberos clients supporting IP transports SHOULD support the sending
3590 of UDP requests. Clients SHOULD use KDC discovery (Section 8.6.3) to
3591 identify the IP address and port to which they will send their
3592 request.
3595 When contacting a KDC for a KRB_KDC_REQ request using UDP/IP
3596 transport, the client shall send a UDP datagram containing only an
3597 encoding of the request to the KDC. The KDC will respond with a reply
3598 datagram containing only an encoding of the reply message (either a
3599 KRB-ERROR or a KDC-REP) to the sending port at the sender's IP
3600 address. The response to a request made through UDP/IP transport MUST
3601 also use UDP/IP transport. If the response can not be handled using
3602 UDP (for example because it is too large), the KDC MUST return "krb-
3603 err-response-too-big", forcing the client to retry the request using
3604 the TCP transport.
3607 8.6.2. TCP/IP transport
3610 Kerberos servers (KDCs) supporting IP transports MUST accept TCP
3611 requests and SHOULD listen for such requests on port 88 (decimal)
3612 unless specifically configured to listen on an alternate TCP port.
3613 Alternate ports MAY be used when running multiple KDCs for multiple
3614 realms on the same host.
3617 Clients MUST support the sending of TCP requests, but MAY choose to
3618 initially try a request using the UDP transport. Clients SHOULD use
3619 KDC discovery (Section 8.6.3) to identify the IP address and port to
3620 which they will send their request.
3623 Implementation note: Some extensions to the Kerberos protocol will
3624 not succeed if any client or KDC not supporting the TCP transport is
3625 involved. Implementations of RFC 1510 were not required to support
3626 TCP/IP transports.
3629 When the KDC-REQ message is sent to the KDC over a TCP stream, the
3630 response (KDC-REP or KRB-ERROR message) MUST be returned to the
3631 client on the same TCP stream that was established for the request.
3632 The KDC MAY close the TCP stream after sending a response, but MAY
3633 leave the stream open for a reasonable period of time if it expects a
3634 followup. Care must be taken in managing TCP/IP connections on the
3635 KDC to prevent denial of service attacks based on the number of open
3636 TCP/IP connections.
3640 Yu Expires: Apr 2005 [Page 56]
3641 Internet-Draft yu-krb-extensions-02 25 Oct 2004
3644 The client MUST be prepared to have the stream closed by the KDC at
3645 anytime after the receipt of a response. A stream closure SHOULD NOT
3646 be treated as a fatal error. Instead, if multiple exchanges are
3647 required (e.g., certain forms of pre-authentication) the client may
3648 need to establish a new connection when it is ready to send
3649 subsequent messages. A client MAY close the stream after receiving a
3650 response, and SHOULD close the stream if it does not expect to send
3651 followup messages.
3654 A client MAY send multiple requests before receiving responses,
3655 though it must be prepared to handle the connection being closed
3656 after the first response.
3659 Each request (KDC-REQ) and response (KDC-REP or KRB-ERROR) sent over
3660 the TCP stream is preceded by the length of the request as 4 octets
3661 in network byte order. The high bit of the length is reserved for
3662 future expansion and MUST currently be set to zero. If a KDC that
3663 does not understand how to interpret a set high bit of the length
3664 encoding receives a request with the high order bit of the length
3665 set, it MUST return a KRB-ERROR message with the error "krb-err-
3666 field-toolong" and MUST close the TCP stream.
3669 If multiple requests are sent over a single TCP connection, and the
3670 KDC sends multiple responses, the KDC is not required to send the
3671 responses in the order of the corresponding requests. This may
3672 permit some implementations to send each response as soon as it is
3673 ready even if earlier requests are still being processed (for
3674 example, waiting for a response from an external device or database).
3677 8.6.3. KDC Discovery on IP Networks
3680 Kerberos client implementations MUST provide a means for the client
3681 to determine the location of the Kerberos Key Distribution Centers
3682 (KDCs). Traditionally, Kerberos implementations have stored such
3683 configuration information in a file on each client machine.
3684 Experience has shown this method of storing configuration information
3685 presents problems with out-of-date information and scaling problems,
3686 especially when using cross-realm authentication. This section
3687 describes a method for using the Domain Name System [RFC 1035] for
3688 storing KDC location information.
3691 8.6.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names
3694 In Kerberos, realm names are case sensitive. While it is strongly
3695 encouraged that all realm names be all upper case this recommendation
3696 has not been adopted by all sites. Some sites use all lower case
3697 names and other use mixed case. DNS, on the other hand, is case
3698 insensitive for queries. Since the realm names "MYREALM", "myrealm",
3699 and "MyRealm" are all different, but resolve the same in the domain
3700 name system, it is necessary that only one of the possible
3701 combinations of upper and lower case characters be used in realm
3704 Yu Expires: Apr 2005 [Page 57]
3705 Internet-Draft yu-krb-extensions-02 25 Oct 2004
3708 names.
3711 8.6.3.2. DNS SRV records for KDC location
3714 KDC location information is to be stored using the DNS SRV RR [RFC
3715 2782]. The format of this RR is as follows:
3718 _Service._Proto.Realm TTL Class SRV Priority Weight Port Target
3721 The Service name for Kerberos is always "kerberos".
3724 The Proto can be one of "udp", "tcp". If these SRV records are to be
3725 used, both "udp" and "tcp" records MUST be specified for all KDC
3726 deployments.
3729 The Realm is the Kerberos realm that this record corresponds to. The
3730 realm MUST be a domain style realm name.
3733 TTL, Class, SRV, Priority, Weight, and Target have the standard
3734 meaning as defined in RFC 2782.
3737 As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV
3738 records SHOULD be the value assigned to "kerberos" by the Internet
3739 Assigned Number Authority: 88 (decimal) unless the KDC is configured
3740 to listen on an alternate TCP port.
3743 Implementation note: Many existing client implementations do not
3744 support KDC Discovery and are configured to send requests to the IANA
3745 assigned port (88 decimal), so it is strongly recommended that KDCs
3746 be configured to listen on that port.
3749 8.6.3.3. KDC Discovery for Domain Style Realm Names on IP Networks
3752 These are DNS records for a Kerberos realm EXAMPLE.COM. It has two
3753 Kerberos servers, kdc1.example.com and kdc2.example.com. Queries
3754 should be directed to kdc1.example.com first as per the specified
3755 priority. Weights are not used in these sample records.
3758 _kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
3759 _kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
3760 _kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
3761 _kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
3765 9. Errors
3768 The KRB-ERROR message is returned by the KDC if an error occurs
3769 during credentials acquisition. It may also be returned by an
3770 application server if an error occurs during authentication.
3775 Yu Expires: Apr 2005 [Page 58]
3776 Internet-Draft yu-krb-extensions-02 25 Oct 2004
3779 ErrCode ::= Int32
3782 KRB-ERROR ::= CHOICE {
3783 rfc1510 [APPLICATION 30] KRB-ERROR-1510,
3784 ext [APPLICATION 23] Signed {
3785 KRB-ERROR-EXT, { ku-KrbError-cksum } }
3786 }
3790 The extensible KRB-ERROR is only signed if there has been a key
3791 negotiated with its recipient. KRB-ERROR messages sent in response
3792 to AS-REQ messages will probably not be signed unless a
3793 preauthentication mechanism has negotiated a key. (Signing using a
3794 client's long-term key can expose ciphertext to dictionary attacks.)
3797 The parts of a KRB-ERROR common to both the backwards-compatibility
3798 and the extensibile messages are
3801 KRB-ERROR-COMMON ::= SEQUENCE {
3802 pvno [0] INTEGER (5),
3803 msg-type [1] INTEGER (30 | 23),
3804 ctime [2] KerberosTime OPTIONAL,
3805 cusec [3] Microseconds OPTIONAL,
3806 stime [4] KerberosTime,
3807 susec [5] Microseconds,
3808 error-code [6] ErrCode,
3809 crealm [7] Realm OPTIONAL,
3810 cname [8] PrincipalName OPTIONAL,
3811 realm [9] Realm -- Correct realm --,
3812 sname [10] PrincipalName -- Correct name --,
3813 e-text [11] KerberosString OPTIONAL,
3814 e-data [12] OCTET STRING OPTIONAL,
3815 ...,
3816 typed-data [13] TYPED-DATA OPTIONAL,
3817 nonce [14] Nonce OPTIONAL,
3818 lang-tag [15] LangTag OPTIONAL,
3819 ...
3820 }
3824 KRB-ERROR-1510 ::= SEQUENCE {
3825 COMPONENTS OF KRB-ERROR-COMMON
3826 } (WITH COMPONENTS {
3827 ...,
3828 msg-type (30)
3829 })
3833 KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON
3834 (WITH COMPONENTS { ..., msg-type (23) })
3838 Yu Expires: Apr 2005 [Page 59]
3839 Internet-Draft yu-krb-extensions-02 25 Oct 2004
3842 ctime, cusec
3843 Client's time, if known from a KDC-REQ or AP-REQ.
3846 stime, susec
3847 KDC or application server's current time.
3850 error-code
3851 Numeric error code designating the error.
3854 crealm, cname
3855 Client's realm and name, if known.
3858 realm, sname
3859 server's realm and name. [ XXX what if these aren't known? ]
3862 e-text
3863 Human-readable text providing additional details for the error.
3866 e-data
3867 This field contains additional data about the error for use by
3868 the client to help it recover from or handle the error. If the
3869 "error-code" is "kdc-err-preauth-required", then the e-data
3870 field will contain an encoding of a sequence of padata fields,
3871 each corresponding to an acceptable pre-authentication method
3872 and optionally containing data for the method:
3875 METHOD-DATA ::= SEQUENCE OF PA-DATA
3879 For error codes defined in this document other than "kdc-err-
3880 preauth-required", the format and contents of the e-data field
3881 are implementation-defined. Similarly, for future error codes,
3882 the format and contents of the e-data field are implementation-
3883 defined unless specified.
3886 lang-tag
3887 Indicates the language of the message in the "e-text" field. It
3888 is only present in the extensible KRB-ERROR.
3891 nonce
3892 is the nonce from a KDC-REQ. It is only present in the
3893 extensible KRB-ERROR.
3896 typed-data
3897 TYPED-DATA is a typed hole allowing for additional data to be
3898 returned in error conditions, since "e-data" is insufficiently
3899 flexible for some purposes. TYPED-DATA is only present in the
3900 extensible KRB-ERROR.
3906 Yu Expires: Apr 2005 [Page 60]
3907 Internet-Draft yu-krb-extensions-02 25 Oct 2004
3910 TDType ::= TH-id
3913 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
3914 data-type [0] TDType,
3915 data-value [1] OCTET STRING OPTIONAL
3916 }
3920 10. Session Key Exchange
3923 Session key exchange consists of the AP-REQ and AP-REP messages. The
3924 client sends the AP-REQ message, and the service responds with an
3925 AP-REP message if mutual authentication is desired. Following
3926 session key exchange, the client and service share a secret session
3927 key, or possibly a subsesion key, which can be used to protect
3928 further communications. Additionally, the session key exchange
3929 process can establish initial sequence numbers which the client and
3930 service can use to detect replayed messages.
3933 10.1. AP-REQ
3936 An AP-REQ message contains a ticket and a authenticator. The
3937 authenticator is ciphertext encrypted with the session key contained
3938 in the ticket. The plaintext contents of the authenticator are:
3941 -- plaintext of authenticator
3942 Authenticator ::= [APPLICATION 2] SEQUENCE {
3943 authenticator-vno [0] INTEGER (5),
3944 crealm [1] Realm,
3945 cname [2] PrincipalName,
3946 cksum [3] Checksum {{ key-session },
3947 { ku-Authenticator-cksum |
3948 ku-pa-TGSReq-cksum }} OPTIONAL,
3949 cusec [4] Microseconds,
3950 ctime [5] KerberosTime,
3951 subkey [6] EncryptionKey OPTIONAL,
3952 seq-number [7] SeqNum OPTIONAL,
3953 authorization-data [8] AuthorizationData OPTIONAL
3954 }
3957 The common parts between the RFC 1510 and the extensible versions of
3958 the AP-REQ are:
3970 Yu Expires: Apr 2005 [Page 61]
3971 Internet-Draft yu-krb-extensions-02 25 Oct 2004
3974 AP-REQ-COMMON ::= SEQUENCE {
3975 pvno [0] INTEGER (5),
3976 msg-type [1] INTEGER (14 | 18),
3977 ap-options [2] APOptions,
3978 ticket [3] Ticket,
3979 authenticator [4] EncryptedData {
3980 Authenticator,
3981 { key-session },
3982 { ku-APReq-authenticator |
3983 ku-pa-TGSReq-authenticator }
3984 },
3985 ...,
3986 extensions [5] ApReqExtensions OPTIONAL,
3987 lang-tag [6] SEQUENCE (SIZE (1..MAX))
3988 OF LangTag OPTIONAL,
3989 ...
3990 }
3993 The complete definition of AP-REQ is:
3996 AP-REQ ::= CHOICE {
3997 rfc1510 [APPLICATION 14] AP-REQ-1510,
3998 ext [APPLICATION 18] Signed {
3999 AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
4000 }
4001 }
4005 AP-REQ-COMMON ::= SEQUENCE {
4006 pvno [0] INTEGER (5),
4007 msg-type [1] INTEGER (14 | 18),
4008 ap-options [2] APOptions,
4009 ticket [3] Ticket,
4010 authenticator [4] EncryptedData {
4011 Authenticator,
4012 { key-session },
4013 { ku-APReq-authenticator |
4014 ku-pa-TGSReq-authenticator }
4015 },
4016 ...,
4017 extensions [5] ApReqExtensions OPTIONAL,
4018 lang-tag [6] SEQUENCE (SIZE (1..MAX))
4019 OF LangTag OPTIONAL,
4020 ...
4021 }
4030 Yu Expires: Apr 2005 [Page 62]
4031 Internet-Draft yu-krb-extensions-02 25 Oct 2004
4034 AP-REQ-1510 ::= SEQUENCE {
4035 COMPONENTS OF AP-REQ-COMMON
4036 } (WITH COMPONENTS {
4037 ...,
4038 msg-type (14),
4039 authenticator (EncryptedData {
4040 Authenticator (WITH COMPONENTS {
4041 ...,
4042 crealm (RealmIA5),
4043 cname (PrincipalNameIA5),
4044 seqnum (UInt32)
4045 }), { key-session }, { ku-APReq-authenticator }})
4046 })
4050 AP-REQ-EXT ::= AP-REQ-COMMON
4051 (WITH COMPONENTS {
4052 ...,
4053 msg-type (18),
4054 -- The following constraints on Authenticator assume that
4055 -- we want to restrict the use of AP-REQ-EXT with TicketExt
4056 -- only, since that is the only way we can enforce UTF-8.
4057 authenticator (EncryptedData {
4058 Authenticator (WITH COMPONENTS {
4059 ...,
4060 crealm (RealmExt),
4061 cname (PrincipalNameExt),
4062 authorization-data (SIZE (1..MAX))
4063 }), { key-session }, { ku-APReq-authenticator }})
4064 })
4068 APOptions ::= KerberosFlags { APOptionsBits }
4071 APOptionsBits ::= BIT STRING {
4072 reserved (0),
4073 use-session-key (1),
4074 mutual-required (2)
4075 }
4079 10.2. AP-REP
4082 An AP-REP message provides mutual authentication of the service to
4083 the client.
4086 EncAPRepPart ::= CHOICE {
4087 rfc1510 [APPLICATION 27] EncAPRepPart1510,
4088 ext [APPLICATION 31] EncAPRepPartExt
4089 }
4093 Yu Expires: Apr 2005 [Page 63]
4094 Internet-Draft yu-krb-extensions-02 25 Oct 2004
4097 EncAPRepPartCom ::= SEQUENCE {
4098 ctime [0] KerberosTime,
4099 cusec [1] Microseconds,
4100 subkey [2] EncryptionKey OPTIONAL,
4101 seq-number [3] SeqNum OPTIONAL,
4102 ...,
4103 authorization-data [4] AuthorizationData OPTIONAL,
4104 ...
4105 }
4109 EncAPRepPart1510 ::= SEQUENCE {
4110 COMPONENTS OF ENCAPRepPartCom
4111 } (WITH COMPONENTS {
4112 ...,
4113 seq-number (UInt32),
4114 authorization-data ABSENT
4115 })
4119 EncAPRepPartExt ::= EncAPRepPartCom
4123 AP-REP ::= CHOICE {
4124 rfc1510 [APPLICATION 15] AP-REP-1510,
4125 ext [APPLICATION 19] Signed {
4126 AP-REP-EXT,
4127 { key-session | key-subsession }, { ku-APRep-cksum }}
4128 }
4132 AP-REP-COMMON { EncPart } ::= SEQUENCE {
4133 pvno [0] INTEGER (5),
4134 msg-type [1] INTEGER (15 | 19),
4135 enc-part [2] EncryptedData {
4136 EncPart,
4137 { key-session | key-subsession }, { ku-EncAPRepPart }},
4138 ...,
4139 extensions [3] ApRepExtensions OPTIONAL,
4140 ...
4141 }
4145 AP-REP-1510 ::= SEQUENCE {
4146 COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
4147 } (WITH COMPONENTS {
4148 ...,
4149 msg-type (15)
4150 })
4155 Yu Expires: Apr 2005 [Page 64]
4156 Internet-Draft yu-krb-extensions-02 25 Oct 2004
4159 AP-REP-EXT ::= [APPLICATION 19] AP-REP-COMMON {
4160 EncAPRepPartExt
4161 } (WITH COMPONENTS { ..., msg-type (19) })
4165 11. Session Key Use
4168 Once a session key has been established, the client and server can
4169 use several kinds of messages to securely transmit data. KRB-SAFE
4170 provides integrity protection for application data, while KRB-PRIV
4171 provides confidentiality along with integrity protection. The KRB-
4172 CRED message provides a means of securely forwarding credentials from
4173 the client host to the server host.
4176 11.1. KRB-SAFE
4179 The KRB-SAFE message provides integrity protection for an included
4180 cleartext message.
4183 -- Do we chew up another tag for KRB-SAFE-EXT? That would
4184 -- allow us to make safe-body optional, allowing for a GSS-MIC
4185 -- sort of message.
4186 KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
4187 pvno [0] INTEGER (5),
4188 msg-type [1] INTEGER (20),
4189 safe-body [2] KRB-SAFE-BODY,
4190 cksum [3] ChecksumOf {
4191 KRB-SAFE-BODY,
4192 { key-session | key-subsession }, { ku-KrbSafe-cksum }},
4193 ... -- ASN.1 extensions must be excluded
4194 -- when sending to rfc1510 implementations
4195 }
4199 KRB-SAFE-BODY ::= SEQUENCE {
4200 user-data [0] OCTET STRING,
4201 timestamp [1] KerberosTime OPTIONAL,
4202 usec [2] Microseconds OPTIONAL,
4203 seq-number [3] SeqNum OPTIONAL,
4204 s-address [4] HostAddress,
4205 r-address [5] HostAddress OPTIONAL,
4206 ... -- ASN.1 extensions must be excluded
4207 -- when sending to rfc1510 implementations
4208 }
4212 11.2. KRB-PRIV
4215 The KRB-PRIV message provides confidentiality and integrity
4216 protection.
4220 Yu Expires: Apr 2005 [Page 65]
4221 Internet-Draft yu-krb-extensions-02 25 Oct 2004
4224 KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
4225 pvno [0] INTEGER (5),
4226 msg-type [1] INTEGER (21),
4227 enc-part [3] EncryptedData {
4228 EncKrbPrivPart,
4229 { key-session | key-subsession }, { ku-EncKrbPrivPart }},
4230 ...
4231 }
4235 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
4236 user-data [0] OCTET STRING,
4237 timestamp [1] KerberosTime OPTIONAL,
4238 usec [2] Microseconds OPTIONAL,
4239 seq-number [3] SeqNum OPTIONAL,
4240 s-address [4] HostAddress -- sender's addr --,
4241 r-address [5] HostAddress OPTIONAL -- recip's addr --,
4242 ... -- ASN.1 extensions must be excluded
4243 -- when sending to rfc1510 implementations
4244 }
4248 11.3. KRB-CRED
4251 The KRB-CRED message provides a means of securely transferring
4252 credentials from the client to the service.
4255 KRB-CRED ::= CHOICE {
4256 rfc1510 [APPLICATION 22] KRB-CRED-1510,
4257 ext [APPLICATION 24] Signed {
4258 KRB-CRED-EXT,
4259 { key-session | key-subsession }, { ku-KrbCred-cksum }}
4260 }
4264 KRB-CRED-COMMON ::= SEQUENCE {
4265 pvno [0] INTEGER (5),
4266 msg-type [1] INTEGER (22 | 24),
4267 tickets [2] SEQUENCE OF Ticket,
4268 enc-part [3] EncryptedData {
4269 EncKrbCredPart,
4270 { key-session | key-subsession }, { ku-EncKrbCredPart }},
4271 ...
4272 }
4276 KRB-CRED-1510 ::= SEQUENCE {
4277 COMPONENTS OF KRB-CRED-COMMON
4278 } (WITH COMPONENTS { ..., msg-type (22) })
4283 Yu Expires: Apr 2005 [Page 66]
4284 Internet-Draft yu-krb-extensions-02 25 Oct 2004
4287 KRB-CRED-EXT ::= [APPLICATION 24] KRB-CRED-COMMON
4288 (WITH COMPONENTS { ..., msg-type (24) })
4292 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
4293 ticket-info [0] SEQUENCE OF KrbCredInfo,
4294 nonce [1] Nonce OPTIONAL,
4295 timestamp [2] KerberosTime OPTIONAL,
4296 usec [3] Microseconds OPTIONAL,
4297 s-address [4] HostAddress OPTIONAL,
4298 r-address [5] HostAddress OPTIONAL
4299 }
4303 KrbCredInfo ::= SEQUENCE {
4304 key [0] EncryptionKey,
4305 prealm [1] Realm OPTIONAL,
4306 pname [2] PrincipalName OPTIONAL,
4307 flags [3] TicketFlags OPTIONAL,
4308 authtime [4] KerberosTime OPTIONAL,
4309 starttime [5] KerberosTime OPTIONAL,
4310 endtime [6] KerberosTime OPTIONAL,
4311 renew-till [7] KerberosTime OPTIONAL,
4312 srealm [8] Realm OPTIONAL,
4313 sname [9] PrincipalName OPTIONAL,
4314 caddr [10] HostAddresses OPTIONAL
4315 }
4319 12. Security Considerations
4322 12.1. Time Synchronization
4325 Time synchronization between the KDC and application servers is
4326 necessary to prevent acceptance of expired tickets.
4329 Time synchronization is needed between application servers and
4330 clients to prevent replay attacks if a replay cache is being used.
4331 If negotiated subsession keys are used to encrypt application data,
4332 replay caches may not be necessary.
4335 12.2. Replays
4338 12.3. Principal Name Reuse
4341 See Section 5.3.
4344 12.4. Password Guessing
4350 Yu Expires: Apr 2005 [Page 67]
4351 Internet-Draft yu-krb-extensions-02 25 Oct 2004
4354 12.5. Forward Secrecy
4357 [from KCLAR 10.; needs some rewriting]
4360 The Kerberos protocol in its basic form does not provide perfect
4361 forward secrecy for communications. If traffic has been recorded by
4362 an eavesdropper, then messages encrypted using the KRB-PRIV message,
4363 or messages encrypted using application-specific encryption under
4364 keys exchanged using Kerberos can be decrypted if any of the user's,
4365 application server's, or KDC's key is subsequently discovered. This
4366 is because the session key used to encrypt such messages is
4367 transmitted over the network encrypted in the key of the application
4368 server, and also encrypted under the session key from the user's
4369 ticket-granting ticket when returned to the user in the TGS-REP
4370 message. The session key from the ticket-granting ticket was sent to
4371 the user in the AS-REP message encrypted in the user's secret key,
4372 and embedded in the ticket-granting ticket, which was encrypted in
4373 the key of the KDC. Application requiring perfect forward secrecy
4374 must exchange keys through mechanisms that provide such assurance,
4375 but may use Kerberos for authentication of the encrypted channel
4376 established through such other means.
4379 12.6. Authorization
4382 As an authentication service, Kerberos provides a means of verifying
4383 the identity of principals on a network. Kerberos does not, by
4384 itself, provide authorization. Applications SHOULD NOT accept the
4385 mere issuance of a service ticket by the Kerberos server as granting
4386 authority to use the service.
4389 12.7. Login Authentication
4392 Some applications, particularly those which provide login access when
4393 provided with a password, SHOULD NOT treat successful acquisition of
4394 credentials as sufficient proof of the user's identity. An attacker
4395 posing as a user could generate an illegitimate KDC-REP message which
4396 decrypts properly. To authenticate a user logging on to a local
4397 system, the credentials obtained SHOULD be used in a TGS exchange to
4398 obtain credentials for a local service. Successful use of those
4399 credentials to authenticate to the local service assures that the
4400 initially obtained credentials are from a valid KDC.
4403 13. IANA Considerations
4406 [ needs more work ]
4409 Each use of Int32 in this document defines a number space. [ XXX
4410 enumerate these ] Negative numbers are reserved for private use;
4411 local and experimental extensions should use these values. Zero is
4412 reserved and may not be assigned.
4416 Yu Expires: Apr 2005 [Page 68]
4417 Internet-Draft yu-krb-extensions-02 25 Oct 2004
4420 Typed hole contents may be identified by either Int32 values or by
4421 RELATIVE-OID values. Since RELATIVE-OIDs define a hierarchical
4422 namespace, assignments to the top level of the RELATIVE-OID space may
4423 be made on a first-come, first-served basis.
4426 14. Acknowledgments
4429 Much of the text here is adapted from draft-ietf-krb-wg-kerberos-
4430 clarifications-07. The description of the general form of the
4431 extensibility framework was derived from text by Sam Hartman.
4434 Appendices
4437 A. ASN.1 Module (Normative)
4440 KerberosV5Spec3 {
4441 iso(1) identified-organization(3) dod(6) internet(1)
4442 security(5) kerberosV5(2) modules(4) krb5spec3(4)
4443 } DEFINITIONS EXPLICIT TAGS ::= BEGIN
4447 -- OID arc for KerberosV5
4448 --
4449 -- This OID may be used to identify Kerberos protocol messages
4450 -- encapsulated in other protocols.
4451 --
4452 -- This OID also designates the OID arc for KerberosV5-related
4453 -- OIDs.
4454 --
4455 -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its
4456 -- OID.
4457 id-krb5 OBJECT IDENTIFIER ::= {
4458 iso(1) identified-organization(3) dod(6) internet(1)
4459 security(5) kerberosV5(2)
4460 }
4479 Yu Expires: Apr 2005 [Page 69]
4480 Internet-Draft yu-krb-extensions-02 25 Oct 2004
4483 -- top-level type
4484 --
4485 -- Applications should not directly reference any types
4486 -- other than KRB-PDU and its component types.
4487 --
4488 KRB-PDU ::= CHOICE {
4489 ticket Ticket,
4490 as-req AS-REQ,
4491 as-rep AS-REP,
4492 tgs-req TGS-REQ,
4493 tgs-rep TGS-REP,
4494 ap-req AP-REQ,
4495 ap-rep AP-REP,
4496 krb-safe KRB-SAFE,
4497 krb-priv KRB-PRIV,
4498 krb-cred KRB-CRED,
4499 tgt-req TGT-REQ,
4500 krb-error KRB-ERROR,
4501 ...
4502 }
4506 --
4507 -- *** basic types
4508 --
4512 -- signed values representable in 32 bits
4513 --
4514 -- These are often used as assigned numbers for various things.
4515 Int32 ::= INTEGER (-2147483648..2147483647)
4519 -- Typed hole identifiers
4520 TH-id ::= CHOICE {
4521 int32 Int32,
4522 rel-oid RELATIVE-OID
4523 }
4527 -- unsigned 32 bit values
4528 UInt32 ::= INTEGER (0..4294967295)
4532 -- unsigned 64 bit values
4533 UInt64 ::= INTEGER (0..18446744073709551615)
4537 -- sequence numbers
4538 SeqNum ::= UInt64
4542 Yu Expires: Apr 2005 [Page 70]
4543 Internet-Draft yu-krb-extensions-02 25 Oct 2004
4546 -- nonces
4547 Nonce ::= UInt64
4551 -- microseconds
4552 Microseconds ::= INTEGER (0..999999)
4556 KerberosTime ::= GeneralizedTime (CONSTRAINED BY {
4557 -- MUST NOT include fractional seconds
4558 })
4562 -- used for names and for error messages
4563 KerberosString ::= CHOICE {
4564 ia5 GeneralString (IA5String),
4565 utf8 UTF8String,
4566 ... -- no extension may be sent
4567 -- to an rfc1510 implementation --
4568 }
4572 -- IA5 choice only; useful for constraints
4573 KerberosStringIA5 ::= KerberosString
4574 (WITH COMPONENTS { ia5 PRESENT })
4577 -- IA5 excluded; useful for constraints
4578 KerberosStringExt ::= KerberosString
4579 (WITH COMPONENTS { ia5 ABSENT })
4583 -- used for language tags
4584 LangTag ::= PrintableString
4585 (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
4605 Yu Expires: Apr 2005 [Page 71]
4606 Internet-Draft yu-krb-extensions-02 25 Oct 2004
4609 -- assigned numbers for name types (used in principal names)
4610 NameType ::= Int32
4613 -- Name type not known
4614 nt-unknown NameType ::= 0
4615 -- Just the name of the principal as in DCE, or for users
4616 nt-principal NameType ::= 1
4617 -- Service and other unique instance (krbtgt)
4618 nt-srv-inst NameType ::= 2
4619 -- Service with host name as instance (telnet, rcommands)
4620 nt-srv-hst NameType ::= 3
4621 -- Service with host as remaining components
4622 nt-srv-xhst NameType ::= 4
4623 -- Unique ID
4624 nt-uid NameType ::= 5
4625 -- Encoded X.509 Distingished name [RFC 2253]
4626 nt-x500-principal NameType ::= 6
4627 -- Name in form of SMTP email name (e.g. user@foo.com)
4628 nt-smtp-name NameType ::= 7
4629 -- Enterprise name - may be mapped to principal name
4630 nt-enterprise NameType ::= 10
4634 PrincipalName ::= SEQUENCE {
4635 name-type [0] NameType,
4636 -- May have zero elements, or individual elements may be
4637 -- zero-length, but this is NOT RECOMMENDED.
4638 name-string [1] SEQUENCE OF KerberosString
4639 }
4643 -- IA5 only
4644 PrincipalNameIA5 ::= PrincipalName (WITH COMPONENTS {
4645 ...,
4646 name-string (WITH COMPONENT (KerberosStringIA5))
4647 })
4650 -- IA5 excluded
4651 PrincipalNameExt ::= PrincpalName (WITH COMPONENTS {
4652 ...,
4653 name-string (WITH COMPONENT (KerberosStringExt))
4654 })
4666 Yu Expires: Apr 2005 [Page 72]
4667 Internet-Draft yu-krb-extensions-02 25 Oct 2004
4670 Realm ::= KerberosString
4673 -- IA5 only
4674 RealmIA5 ::= Realm (KerberosStringIA5)
4677 -- IA5 excluded
4678 RealmExt ::= Realm (KerberosStringExt)
4682 KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
4683 (CONSTRAINED BY {
4684 -- MUST be a valid value of -- NamedBits
4685 -- but if the value to be sent would be truncated to shorter
4686 -- than 32 bits according to DER, the value MUST be padded
4687 -- with trailing zero bits to 32 bits. Otherwise, no
4688 -- trailing zero bits may be present.
4691 })
4695 AddrType ::= Int32
4698 HostAddress ::= SEQUENCE {
4699 addr-type [0] AddrType,
4700 address [1] OCTET STRING
4701 }
4704 -- NOTE: HostAddresses is always used as an OPTIONAL field and
4705 -- should not be a zero-length SEQUENCE OF.
4706 --
4707 -- The extensible messages explicitly constrain this to be
4708 -- non-empty.
4709 HostAddresses ::= SEQUENCE OF HostAddress
4713 --
4714 -- *** crypto-related types and assignments
4715 --
4731 Yu Expires: Apr 2005 [Page 73]
4732 Internet-Draft yu-krb-extensions-02 25 Oct 2004
4735 -- Assigned numbers denoting encryption mechanisms.
4736 EType ::= Int32
4739 -- assigned numbers for encryption schemes
4740 et-des-cbc-crc EType ::= 1
4741 et-des-cbc-md4 EType ::= 2
4742 et-des-cbc-md5 EType ::= 3
4743 -- [reserved] 4
4744 et-des3-cbc-md5 EType ::= 5
4745 -- [reserved] 6
4746 et-des3-cbc-sha1 EType ::= 7
4747 et-dsaWithSHA1-CmsOID EType ::= 9
4748 et-md5WithRSAEncryption-CmsOID EType ::= 10
4749 et-sha1WithRSAEncryption-CmsOID EType ::= 11
4750 et-rc2CBC-EnvOID EType ::= 12
4751 et-rsaEncryption-EnvOID EType ::= 13
4752 et-rsaES-OAEP-ENV-OID EType ::= 14
4753 et-des-ede3-cbc-Env-OID EType ::= 15
4754 et-des3-cbc-sha1-kd EType ::= 16
4755 -- AES
4756 et-aes128-cts-hmac-sha1-96 EType ::= 17
4757 -- AES
4758 et-aes256-cts-hmac-sha1-96 EType ::= 18
4759 -- Microsoft
4760 et-rc4-hmac EType ::= 23
4761 -- Microsoft
4762 et-rc4-hmac-exp EType ::= 24
4763 -- opaque; PacketCable
4764 et-subkey-keymaterial EType ::= 65
4789 Yu Expires: Apr 2005 [Page 74]
4790 Internet-Draft yu-krb-extensions-02 25 Oct 2004
4793 -- Assigned numbers denoting key usages.
4794 KeyUsage ::= UInt32
4797 --
4798 -- Actual identifier names are provisional and subject to
4799 -- change.
4800 --
4801 ku-pa-enc-ts KeyUsage ::= 1
4802 ku-Ticket KeyUsage ::= 2
4803 ku-EncASRepPart KeyUsage ::= 3
4804 ku-TGSReqAuthData-sesskey KeyUsage ::= 4
4805 ku-TGSReqAuthData-subkey KeyUsage ::= 5
4806 ku-pa-TGSReq-cksum KeyUsage ::= 6
4807 ku-pa-TGSReq-authenticator KeyUsage ::= 7
4808 ku-EncTGSRepPart-sesskey KeyUsage ::= 8
4809 ku-EncTGSRepPart-subkey KeyUsage ::= 9
4810 ku-Authenticator-cksum KeyUsage ::= 10
4811 ku-APReq-authenticator KeyUsage ::= 11
4812 ku-EncAPRepPart KeyUsage ::= 12
4813 ku-EncKrbPrivPart KeyUsage ::= 13
4814 ku-EncKrbCredPart KeyUsage ::= 14
4815 ku-KrbSafe-cksum KeyUsage ::= 15
4816 ku-ad-KDCIssued-cksum KeyUsage ::= 19
4820 -- The following numbers are provisional...
4821 -- conflicts may exist elsewhere.
4822 ku-Ticket-cksum KeyUsage ::= 25
4823 ku-ASReq-cksum KeyUsage ::= 26
4824 ku-TGSReq-cksum KeyUsage ::= 27
4825 ku-ASRep-cksum KeyUsage ::= 28
4826 ku-TGSRep-cksum KeyUsage ::= 29
4827 ku-APReq-cksum KeyUsage ::= 30
4828 ku-APRep-cksum KeyUsage ::= 31
4829 ku-KrbCred-cksum KeyUsage ::= 32
4830 ku-KrbError-cksum KeyUsage ::= 33
4831 ku-KDCRep-cksum KeyUsage ::= 34
4848 Yu Expires: Apr 2005 [Page 75]
4849 Internet-Draft yu-krb-extensions-02 25 Oct 2004
4852 -- KeyToUse identifies which key is to be used to encrypt or
4853 -- sign a given value.
4854 --
4855 -- Values of KeyToUse are never actually transmitted over the
4856 -- wire, or even used directly by the implementation in any
4857 -- way, as key usages are; it exists primarily to identify
4858 -- which key gets used for what purpose. Thus, the specific
4859 -- numeric values associated with this type are irrelevant.
4860 KeyToUse ::= ENUMERATED {
4861 -- unspecified
4862 key-unspecified,
4863 -- server long term key
4864 key-server,
4865 -- client long term key
4866 key-client,
4867 -- key selected by KDC for encryption of a KDC-REP
4868 key-kdc-rep,
4869 -- session key from ticket
4870 key-session,
4871 -- subsession key negotiated via AP-REQ/AP-REP
4872 key-subsession,
4873 ...
4874 }
4878 EncryptionKey ::= SEQUENCE {
4879 keytype [0] EType,
4880 keyvalue [1] OCTET STRING
4881 }
4906 Yu Expires: Apr 2005 [Page 76]
4907 Internet-Draft yu-krb-extensions-02 25 Oct 2004
4911 -- "Type" specifies which ASN.1 type is encrypted to the
4912 -- ciphertext in the EncryptedData. "Keys" specifies a set of
4913 -- keys of which one key may be used to encrypt the data.
4914 -- "KeyUsages" specifies a set of key usages, one of which may
4915 -- be used to encrypt.
4916 --
4917 -- None of the parameters is transmitted over the wire.
4918 EncryptedData {
4919 Type, KeyToUse:Keys, KeyUsage:KeyUsages
4920 } ::= SEQUENCE {
4921 etype [0] EType,
4922 kvno [1] UInt32 OPTIONAL,
4923 cipher [2] OCTET STRING (CONSTRAINED BY {
4924 -- must be encryption of --
4925 OCTET STRING (CONTAINING Type),
4926 -- with one of the keys -- KeyToUse:Keys,
4927 -- with key usage being one of --
4928 KeyUsage:KeyUsages
4929 }),
4930 ...
4931 }
4936 CksumType ::= Int32
4939 -- The parameters specify which key to use to produce the
4940 -- signature, as well as which key usage to use. The
4941 -- parameters are not actually sent over the wire.
4942 Checksum {
4943 KeyToUse:Keys, KeyUsage:KeyUsages
4944 } ::= SEQUENCE {
4945 cksumtype [0] CksumType,
4946 checksum [1] OCTET STRING (CONSTRAINED BY {
4947 -- signed using one of the keys --
4948 KeyToUse:Keys,
4949 -- with key usage being one of --
4950 KeyUsage:KeyUsages
4951 })
4952 }
4965 Yu Expires: Apr 2005 [Page 77]
4966 Internet-Draft yu-krb-extensions-02 25 Oct 2004
4969 -- a Checksum that must contain the checksum
4970 -- of a particular type
4971 ChecksumOf {
4972 Type, KeyToUse:Keys, KeyUsage:KeyUsages
4973 } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
4974 ...,
4975 checksum (CONSTRAINED BY {
4976 -- must be checksum of --
4977 OCTET STRING (CONTAINING Type)
4978 })
4979 })
4983 -- parameterized type for wrapping authenticated plaintext
4984 Signed {
4985 InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
4986 } ::= SEQUENCE {
4987 cksum [0] ChecksumOf {
4988 InnerType, Keys, KeyUsages
4989 } OPTIONAL,
4990 inner [1] InnerType,
4991 ...
4992 }
4996 --
4997 -- *** Tickets
4998 --
5002 Ticket ::= CHOICE {
5003 rfc1510 [APPLICATION 1] Ticket1510,
5004 ext [APPLICATION 4] Signed {
5005 TicketExt, { key-server }, { ku-Ticket-cksum }
5006 }
5007 }
5011 -- takes a parameter specifying which type gets encrypted
5012 TicketCommon { EncPart } ::= SEQUENCE {
5013 tkt-vno [0] INTEGER (5),
5014 realm [1] Realm,
5015 sname [2] PrincipalName,
5016 enc-part [3] EncryptedData {
5017 EncPart, { key-server }, { ku-Ticket }
5018 },
5019 ...,
5020 extensions [4] TicketExtensions OPTIONAL,
5021 ...
5022 }
5026 Yu Expires: Apr 2005 [Page 78]
5027 Internet-Draft yu-krb-extensions-02 25 Oct 2004
5030 Ticket1510 ::= SEQUENCE {
5031 COMPONENTS OF TicketCommon { EncTicketPart1510 }
5032 } (WITH COMPONENTS {
5033 ...,
5034 -- explicitly force IA5 in strings
5035 realm (RealmIA5),
5036 sname (PrincipalNameIA5)
5037 })
5041 -- APPLICATION tag goes inside Signed{} as well as outside,
5042 -- to prevent possible substitution attacks.
5043 TicketExt ::= [APPLICATION 4] TicketCommon {
5044 EncTicketPartExt
5045 } (WITH COMPONENTS {
5046 ...,
5047 -- explicitly force UTF-8 in strings
5048 realm (RealmExt),
5049 sname (PrincipalNameExt)
5050 })
5054 -- Encrypted part of ticket
5055 EncTicketPart ::= CHOICE {
5056 rfc1510 [APPLICATION 3] EncTicketPart1510,
5057 ext [APPLICATION 5] EncTicketPartExt
5058 }
5062 EncTicketPartCommon ::= SEQUENCE {
5063 flags [0] TicketFlags,
5064 key [1] EncryptionKey,
5065 crealm [2] Realm,
5066 cname [3] PrincipalName,
5067 transited [4] TransitedEncoding,
5068 authtime [5] KerberosTime,
5069 starttime [6] KerberosTime OPTIONAL,
5070 endtime [7] KerberosTime,
5071 renew-till [8] KerberosTime OPTIONAL,
5072 caddr [9] HostAddresses OPTIONAL,
5073 authorization-data [10] AuthorizationData OPTIONAL,
5074 ...
5075 }
5086 Yu Expires: Apr 2005 [Page 79]
5087 Internet-Draft yu-krb-extensions-02 25 Oct 2004
5090 EncTicketPart1510 ::= SEQUENCE {
5091 COMPONENTS OF EncTicketPartCommon
5092 } (WITH COMPONENTS {
5093 ...,
5094 -- explicitly force IA5 in strings
5095 crealm (RealmIA5),
5096 cname (PrincipalNameIA5)
5097 })
5101 EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS {
5102 ...,
5103 -- explicitly force UTF-8 in strings
5104 crealm (RealmExt),
5105 cname (PrincipalNameExt),
5106 -- explicitly constrain caddr to be non-empty if present
5107 caddr (SIZE (1..MAX)),
5108 -- forbid empty authorization-data encodings
5109 authorization-data (SIZE (1..MAX))
5110 })
5114 --
5115 -- *** Authorization Data
5116 --
5120 ADType ::= TH-id
5123 AuthorizationData ::= SEQUENCE OF SEQUENCE {
5124 ad-type [0] ADType,
5125 ad-data [1] OCTET STRING
5126 }
5130 ad-if-relevant ADType ::= int32 : 1
5133 -- Encapsulates another AuthorizationData.
5134 -- Intended for application servers; receiving application servers
5135 -- MAY ignore.
5136 AD-IF-RELEVANT ::= AuthorizationData
5149 Yu Expires: Apr 2005 [Page 80]
5150 Internet-Draft yu-krb-extensions-02 25 Oct 2004
5153 -- KDC-issued privilege attributes
5154 ad-kdcissued ADType ::= int32 : 4
5157 AD-KDCIssued ::= SEQUENCE {
5158 ad-checksum [0] ChecksumOf {
5159 AuthorizationData, { key-session },
5160 { ku-ad-KDCIssued-cksum }},
5161 i-realm [1] Realm OPTIONAL,
5162 i-sname [2] PrincipalName OPTIONAL,
5163 elements [3] AuthorizationData
5164 }
5168 ad-and-or ADType ::= int32 : 5
5171 AD-AND-OR ::= SEQUENCE {
5172 condition-count [0] INTEGER,
5173 elements [1] AuthorizationData
5174 }
5178 -- KDCs MUST interpret any AuthorizationData wrapped in this.
5179 ad-mandatory-for-kdc ADType ::= int32 : 8
5180 AD-MANDATORY-FOR-KDC ::= AuthorizationData
5184 TrType ::= TH-id -- must be registered
5187 -- encoded Transited field
5188 TransitedEncoding ::= SEQUENCE {
5189 tr-type [0] TrType,
5190 contents [1] OCTET STRING
5191 }
5195 TEType ::= TH-id
5198 -- ticket extensions: for TicketExt only
5199 TicketExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
5200 te-type [0] TEType,
5201 te-data [1] OCTET STRING
5202 }
5214 Yu Expires: Apr 2005 [Page 81]
5215 Internet-Draft yu-krb-extensions-02 25 Oct 2004
5218 TicketFlags ::= KerberosFlags { TicketFlagsBits }
5221 TicketFlagsBits ::= BIT STRING {
5222 reserved (0),
5223 forwardable (1),
5224 forwarded (2),
5225 proxiable (3),
5226 proxy (4),
5227 may-postdate (5),
5228 postdated (6),
5229 invalid (7),
5230 renewable (8),
5231 initial (9),
5232 pre-authent (10),
5233 hw-authent (11),
5234 transited-policy-checked (12),
5235 ok-as-delegate (13),
5236 anonymous (14),
5237 cksummed-ticket (15)
5238 }
5242 --
5243 -- *** KDC protocol
5244 --
5273 Yu Expires: Apr 2005 [Page 82]
5274 Internet-Draft yu-krb-extensions-02 25 Oct 2004
5277 AS-REQ ::= CHOICE {
5278 rfc1510 [APPLICATION 10] KDC-REQ-1510
5279 (WITH COMPONENTS {
5280 ...,
5281 msg-type (10),
5282 -- AS-REQ must include client name
5283 req-body (WITH COMPONENTS { ..., cname PRESENT })
5284 }),
5285 ext [APPLICATION 6] Signed {
5286 -- APPLICATION tag goes inside Signed{} as well as
5287 -- outside, to prevent possible substitution attacks.
5288 [APPLICATION 6] KDC-REQ-EXT,
5289 -- not sure this is correct key to use; do we even want
5290 -- to sign AS-REQ?
5291 { key-client },
5292 { ku-ASReq-cksum }
5293 }
5294 (WITH COMPONENTS {
5295 ...,
5296 msg-type (6),
5297 -- AS-REQ must include client name
5298 req-body (WITH COMPONENTS { ..., cname PRESENT })
5299 })
5300 }
5304 TGS-REQ ::= CHOICE {
5305 rfc1510 [APPLICATION 12] KDC-REQ-1510
5306 (WITH COMPONENTS {
5307 ...,
5308 msg-type (12),
5309 -- client name optional in TGS-REQ
5310 req-body (WITH COMPONENTS { ..., cname ABSENT })
5311 }),
5312 ext [APPLICATION 8] Signed {
5313 -- APPLICATION tag goes inside Signed{} as well as
5314 -- outside, to prevent possible substitution attacks.
5315 [APPLICATION 8] KDC-REQ-EXT,
5316 { key-session }, { ku-TGSReq-cksum }
5317 }
5318 (WITH COMPONENTS {
5319 ...,
5320 msg-type (8),
5321 -- client name optional in TGS-REQ
5322 req-body (WITH COMPONENTS { ..., cname ABSENT })
5323 })
5324 }
5331 Yu Expires: Apr 2005 [Page 83]
5332 Internet-Draft yu-krb-extensions-02 25 Oct 2004
5335 KDC-REQ-COMMON ::= SEQUENCE {
5336 -- NOTE: first tag is [1], not [0]
5337 pvno [1] INTEGER (5),
5338 msg-type [2] INTEGER (10 -- AS-REQ.rfc1510 --
5339 | 12 -- TGS-REQ.rfc1510 --
5340 | 6 -- AS-REQ.ext --
5341 | 8 -- TGS-REQ.ext -- ),
5342 padata [3] SEQUENCE OF PA-DATA OPTIONAL
5343 -- NOTE: not empty
5344 }
5348 KDC-REQ-1510 ::= SEQUENCE {
5349 COMPONENTS OF KDC-REQ-COMMON,
5350 req-body [4] KDC-REQ-BODY-1510
5351 } (WITH COMPONENTS { ..., msg-type (10 | 12) })
5355 -- APPLICATION tag goes inside Signed{} as well as outside,
5356 -- to prevent possible substitution attacks.
5357 KDC-REQ-EXT ::= SEQUENCE {
5358 COMPONENTS OF KDC-REQ-COMMON,
5359 req-body [4] KDC-REQ-BODY-EXT,
5360 ...
5361 } (WITH COMPONENTS {
5362 ...,
5363 msg-type (6 | 8),
5364 padata (SIZE (1..MAX))
5365 })
5390 Yu Expires: Apr 2005 [Page 84]
5391 Internet-Draft yu-krb-extensions-02 25 Oct 2004
5394 KDC-REQ-BODY-COMMON ::= SEQUENCE {
5395 kdc-options [0] KDCOptions,
5396 cname [1] PrincipalName OPTIONAL
5397 -- Used only in AS-REQ --,
5400 realm [2] Realm
5401 -- Server's realm; also client's in AS-REQ --,
5404 sname [3] PrincipalName OPTIONAL,
5405 from [4] KerberosTime OPTIONAL,
5406 till [5] KerberosTime OPTIONAL
5407 -- was required in rfc1510;
5408 -- still required for compat versions
5409 -- of messages --,
5412 rtime [6] KerberosTime OPTIONAL,
5413 nonce [7] Nonce,
5414 etype [8] SEQUENCE OF EType
5415 -- in preference order --,
5418 addresses [9] HostAddresses OPTIONAL,
5419 enc-authorization-data [10] EncryptedData {
5420 AuthorizationData, { key-session | key-subsession },
5421 { ku-TGSReqAuthData-subkey |
5422 ku-TGSReqAuthData-sesskey }
5423 } OPTIONAL,
5426 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
5427 -- NOTE: not empty --,
5428 ...
5429 lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF
5430 LangTag OPTIONAL,
5431 ...
5432 }
5436 KDC-REQ-BODY-1510 ::= SEQUENCE {
5437 COMPONENTS OF KDC-REQ-BODY-COMMON
5438 } (WITH COMPONENTS {
5439 ...,
5440 cname (PrincipalNameIA5),
5441 realm (RealmIA5),
5442 sname (PrincipalNameIA5),
5443 till PRESENT,
5444 nonce (UInt32)
5445 })
5453 Yu Expires: Apr 2005 [Page 85]
5454 Internet-Draft yu-krb-extensions-02 25 Oct 2004
5457 KDC-REQ-BODY-EXT ::= KDC-REQ-BODY-COMMON
5458 (WITH COMPONENTS {
5459 ...,
5460 cname (PrincipalNameExt),
5461 realm (RealmExt),
5462 sname (PrincipalNameExt),
5463 addresses (SIZE (1..MAX)),
5464 enc-authorization-data (EncryptedData {
5465 AuthorizationData (SIZE (1..MAX)),
5466 { key-session | key-subsession },
5467 { ku-TGSReqAuthData-subkey |
5468 ku-TGSReqAuthData-sesskey }
5469 }),
5470 additional-tickets (SIZE (1..MAX))
5471 })
5475 KDCOptions ::= KerberosFlags { KDCOptionsBits }
5478 KDCOptionsBits ::= BIT STRING {
5479 reserved (0),
5480 forwardable (1),
5481 forwarded (2),
5482 proxiable (3),
5483 proxy (4),
5484 allow-postdate (5),
5485 postdated (6),
5486 unused7 (7),
5487 renewable (8),
5488 unused9 (9),
5489 unused10 (10),
5490 unused11 (11),
5491 unused12 (12),
5492 unused13 (13),
5493 requestanonymous (14),
5494 canonicalize (15),
5495 disable-transited-check (26),
5496 renewable-ok (27),
5497 enc-tkt-in-skey (28),
5498 renew (30),
5499 validate (31)
5500 -- XXX need "need ticket1" flag?
5501 }
5512 Yu Expires: Apr 2005 [Page 86]
5513 Internet-Draft yu-krb-extensions-02 25 Oct 2004
5516 AS-REP ::= CHOICE {
5517 rfc1510 [APPLICATION 11] KDC-REP-1510 {
5518 EncASRepPart1510
5519 } (WITH COMPONENTS { ..., msg-type (11) }),
5520 ext [APPLICATION 7] Signed {
5521 [APPLICATION 7] KDC-REP-EXT { EncASRepPartExt },
5522 { key-reply }, { ku-ASRep-cksum }
5523 } (WITH COMPONENTS { ..., msg-type (7) })
5524 }
5528 TGS-REP ::= CHOICE {
5529 rfc1510 [APPLICATION 13] KDC-REP-1510 {
5530 EncTGSRepPart1510
5531 } (WITH COMPONENTS { ..., msg-type (13) }),
5532 ext [APPLICATION 9] Signed {
5533 [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
5534 { key-reply }, { ku-TGSRep-cksum }
5535 } (WITH COMPONENTS { ..., msg-type (9) })
5536 }
5570 Yu Expires: Apr 2005 [Page 87]
5571 Internet-Draft yu-krb-extensions-02 25 Oct 2004
5574 KDC-REP-COMMON { EncPart } ::= SEQUENCE {
5575 pvno [0] INTEGER (5),
5576 msg-type [1] INTEGER (11 -- AS-REP.rfc1510 -- |
5577 13 -- TGS.rfc1510 -- |
5578 7 -- AS-REP.ext -- |
5579 9 -- TGS-REP.ext -- ),
5580 padata [2] SEQUENCE OF PA-DATA OPTIONAL,
5581 crealm [3] Realm,
5582 cname [4] PrincipalName,
5583 ticket [5] Ticket,
5586 enc-part [6] EncryptedData {
5587 EncPart,
5588 { key-reply },
5589 -- maybe reach into EncryptedData in AS-REP/TGS-REP
5590 -- definitions to apply constraints on key usages?
5591 { ku-EncASRepPart -- if AS-REP -- |
5592 ku-EncTGSRepPart-subkey -- if TGS-REP and
5593 -- using Authenticator
5594 -- session key -- |
5595 ku-EncTGSRepPart-sesskey -- if TGS-REP and using
5596 -- subsession key -- }
5597 },
5600 ...,
5601 -- In extensible version, KDC signs original request
5602 -- to avoid replay attacks against client.
5603 req-cksum [7] ChecksumOf { CHOICE {
5604 as-req AS-REQ,
5605 tgs-req TGS-REQ
5606 }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
5607 lang-tag [8] LangTag OPTIONAL,
5608 ...
5609 }
5613 KDC-REP-1510 { EncPart } ::= SEQUENCE {
5614 COMPONENTS OF KDC-REP-COMMON { EncPart }
5615 } (WITH COMPONENTS {
5616 ...,
5617 msg-type (11 | 13),
5618 crealm (RealmIA5),
5619 cname (PrincipalNameIA5)
5620 })
5630 Yu Expires: Apr 2005 [Page 88]
5631 Internet-Draft yu-krb-extensions-02 25 Oct 2004
5634 KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart }
5635 (WITH COMPONENTS {
5636 ...,
5637 msg-type (7 | 9),
5638 crealm (RealmExt),
5639 cname (PrincipalNameExt)
5640 })
5644 EncASRepPart1510 ::= [APPLICATION 25] EncKDCRepPart1510
5645 EncTGSRepPart1510 ::= [APPLICATION 26] EncKDCRepPart1510
5648 EncASRepPartExt ::= [APPLICATION 32] EncKDCRepPartExt
5649 EncTGSRepPartExt ::= [APPLICATION 33] EncKDCRepPartExt
5652 EncKDCRepPartCom ::= SEQUENCE {
5653 key [0] EncryptionKey,
5654 last-req [1] LastReq,
5655 nonce [2] Nonce,
5656 key-expiration [3] KerberosTime OPTIONAL,
5657 flags [4] TicketFlags,
5658 authtime [5] KerberosTime,
5659 starttime [6] KerberosTime OPTIONAL,
5660 endtime [7] KerberosTime,
5661 renew-till [8] KerberosTime OPTIONAL,
5662 srealm [9] Realm,
5663 sname [10] PrincipalName,
5664 caddr [11] HostAddresses OPTIONAL,
5665 ...
5666 }
5669 EncKDCRepPart1510 ::= SEQUENCE {
5670 COMPONENTS OF EncKDCRepPartCom
5671 } (WITH COMPONENTS {
5672 ...,
5673 srealm (RealmIA5),
5674 sname (PrincipalNameIA5),
5675 nonce UInt32 })
5678 EncKdcRepPartExt ::= EncKDCRepPartCom (WITH COMPONENTS {
5679 ...,
5680 srealm (RealmExt),
5681 sname (PrincipalNameExt)
5682 })
5692 Yu Expires: Apr 2005 [Page 89]
5693 Internet-Draft yu-krb-extensions-02 25 Oct 2004
5696 LRType ::= TH-id
5697 LastReq ::= SEQUENCE OF SEQUENCE {
5698 lr-type [0] LRType,
5699 lr-value [1] KerberosTime
5700 }
5704 --
5705 -- *** preauth
5706 --
5710 PaDataType ::= TH-id
5711 PaDataOID ::= RELATIVE-OID
5714 PA-DATA ::= SEQUENCE {
5715 -- NOTE: first tag is [1], not [0]
5716 padata-type [1] PaDataType,
5717 padata-value [2] OCTET STRING
5718 }
5722 -- AP-REQ authenticating a TGS-REQ
5723 pa-tgs-req PaDataType ::= int32 : 1
5724 PA-TGS-REQ ::= AP-REQ
5728 -- Encrypted timestamp preauth
5729 -- Encryption key used is client's long-term key.
5730 pa-enc-timestamp PaDataType ::= int32 : 2
5733 PA-ENC-TIMESTAMP ::= EncryptedData {
5734 PA-ENC-TS-ENC, { key-client }, { ku-pa-enc-ts }
5735 }
5738 PA-ENC-TS-ENC ::= SEQUENCE {
5739 patimestamp [0] KerberosTime -- client's time --,
5740 pausec [1] Microseconds OPTIONAL
5741 }
5756 Yu Expires: Apr 2005 [Page 90]
5757 Internet-Draft yu-krb-extensions-02 25 Oct 2004
5760 -- Hints returned in AS-REP or KRB-ERROR to help client
5761 -- choose a password-derived key, either for preauthentication
5762 -- or for decryption of the reply.
5763 pa-etype-info PaDataType ::= int32 : 11
5766 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY
5769 ETYPE-INFO-ENTRY ::= SEQUENCE {
5770 etype [0] EType,
5771 salt [1] OCTET STRING OPTIONAL
5772 }
5776 -- Similar to etype-info, but with parameters provided for
5777 -- the string-to-key function.
5778 pa-etype-info2 PaDataType ::= int32 : 19
5781 ETYPE-INFO2 ::= SEQUENCE (SIZE (1..MAX))
5782 OF ETYPE-INFO-ENTRY
5785 ETYPE-INFO2-ENTRY ::= SEQUENCE {
5786 etype [0] EType,
5787 salt [1] KerberosString OPTIONAL,
5788 s2kparams [2] OCTET STRING OPTIONAL
5789 }
5793 -- Obsolescent. Salt for client's long-term key.
5794 -- Its character encoding is unspecified.
5795 pa-pw-salt PaDataType ::= int32 : 3
5796 -- The "padata-value" does not encode an ASN.1 type.
5797 -- Instead, "padata-value" must consist of the salt string to
5798 -- be used by the client, in an unspecified character
5799 -- encoding.
5803 -- An extensible AS-REQ may be sent as a padata in a
5804 -- non-extensible AS-REQ to allow for backwards compatibility.
5805 pa-as-req PaDataType ::= int32 : 42 -- provisional
5806 PA-AS-REQ ::= AS-REQ (WITH COMPONENTS ext)
5810 --
5811 -- *** Session key exchange
5812 --
5821 Yu Expires: Apr 2005 [Page 91]
5822 Internet-Draft yu-krb-extensions-02 25 Oct 2004
5825 AP-REQ ::= CHOICE {
5826 rfc1510 [APPLICATION 14] AP-REQ-1510,
5827 ext [APPLICATION 18] Signed {
5828 AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
5829 }
5830 }
5834 AP-REQ-COMMON ::= SEQUENCE {
5835 pvno [0] INTEGER (5),
5836 msg-type [1] INTEGER (14 | 18),
5837 ap-options [2] APOptions,
5838 ticket [3] Ticket,
5839 authenticator [4] EncryptedData {
5840 Authenticator,
5841 { key-session },
5842 { ku-APReq-authenticator |
5843 ku-pa-TGSReq-authenticator }
5844 },
5845 ...,
5846 extensions [5] ApReqExtensions OPTIONAL,
5847 lang-tag [6] SEQUENCE (SIZE (1..MAX))
5848 OF LangTag OPTIONAL,
5849 ...
5850 }
5854 AP-REQ-1510 ::= SEQUENCE {
5855 COMPONENTS OF AP-REQ-COMMON
5856 } (WITH COMPONENTS {
5857 ...,
5858 msg-type (14),
5859 authenticator (EncryptedData {
5860 Authenticator (WITH COMPONENTS {
5861 ...,
5862 crealm (RealmIA5),
5863 cname (PrincipalNameIA5),
5864 seqnum (UInt32)
5865 }), { key-session }, { ku-APReq-authenticator }})
5866 })
5880 Yu Expires: Apr 2005 [Page 92]
5881 Internet-Draft yu-krb-extensions-02 25 Oct 2004
5884 AP-REQ-EXT ::= AP-REQ-COMMON
5885 (WITH COMPONENTS {
5886 ...,
5887 msg-type (18),
5888 -- The following constraints on Authenticator assume that
5889 -- we want to restrict the use of AP-REQ-EXT with TicketExt
5890 -- only, since that is the only way we can enforce UTF-8.
5891 authenticator (EncryptedData {
5892 Authenticator (WITH COMPONENTS {
5893 ...,
5894 crealm (RealmExt),
5895 cname (PrincipalNameExt),
5896 authorization-data (SIZE (1..MAX))
5897 }), { key-session }, { ku-APReq-authenticator }})
5898 })
5902 ApReqExtType ::= TH-id
5905 ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
5906 apReqExt-Type [0] ApReqExtType,
5907 apReqExt-Data [1] OCTET STRING
5908 }
5912 APOptions ::= KerberosFlags { APOptionsBits }
5915 APOptionsBits ::= BIT STRING {
5916 reserved (0),
5917 use-session-key (1),
5918 mutual-required (2)
5919 }
5923 -- plaintext of authenticator
5924 Authenticator ::= [APPLICATION 2] SEQUENCE {
5925 authenticator-vno [0] INTEGER (5),
5926 crealm [1] Realm,
5927 cname [2] PrincipalName,
5928 cksum [3] Checksum {{ key-session },
5929 { ku-Authenticator-cksum |
5930 ku-pa-TGSReq-cksum }} OPTIONAL,
5931 cusec [4] Microseconds,
5932 ctime [5] KerberosTime,
5933 subkey [6] EncryptionKey OPTIONAL,
5934 seq-number [7] SeqNum OPTIONAL,
5935 authorization-data [8] AuthorizationData OPTIONAL
5936 }
5942 Yu Expires: Apr 2005 [Page 93]
5943 Internet-Draft yu-krb-extensions-02 25 Oct 2004
5946 AP-REP ::= CHOICE {
5947 rfc1510 [APPLICATION 15] AP-REP-1510,
5948 ext [APPLICATION 19] Signed {
5949 AP-REP-EXT,
5950 { key-session | key-subsession }, { ku-APRep-cksum }}
5951 }
5955 AP-REP-COMMON { EncPart } ::= SEQUENCE {
5956 pvno [0] INTEGER (5),
5957 msg-type [1] INTEGER (15 | 19),
5958 enc-part [2] EncryptedData {
5959 EncPart,
5960 { key-session | key-subsession }, { ku-EncAPRepPart }},
5961 ...,
5962 extensions [3] ApRepExtensions OPTIONAL,
5963 ...
5964 }
5968 AP-REP-1510 ::= SEQUENCE {
5969 COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
5970 } (WITH COMPONENTS {
5971 ...,
5972 msg-type (15)
5973 })
5977 AP-REP-EXT ::= [APPLICATION 19] AP-REP-COMMON {
5978 EncAPRepPartExt
5979 } (WITH COMPONENTS { ..., msg-type (19) })
5983 ApRepExtType ::= TH-id
5986 ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
5987 apRepExt-Type [0] ApRepExtType,
5988 apRepExt-Data [1] OCTET STRING
5989 }
5993 EncAPRepPart ::= CHOICE {
5994 rfc1510 [APPLICATION 27] EncAPRepPart1510,
5995 ext [APPLICATION 31] EncAPRepPartExt
5996 }
6005 Yu Expires: Apr 2005 [Page 94]
6006 Internet-Draft yu-krb-extensions-02 25 Oct 2004
6009 EncAPRepPart1510 ::= SEQUENCE {
6010 COMPONENTS OF ENCAPRepPartCom
6011 } (WITH COMPONENTS {
6012 ...,
6013 seq-number (UInt32),
6014 authorization-data ABSENT
6015 })
6019 EncAPRepPartExt ::= EncAPRepPartCom
6023 EncAPRepPartCom ::= SEQUENCE {
6024 ctime [0] KerberosTime,
6025 cusec [1] Microseconds,
6026 subkey [2] EncryptionKey OPTIONAL,
6027 seq-number [3] SeqNum OPTIONAL,
6028 ...,
6029 authorization-data [4] AuthorizationData OPTIONAL,
6030 ...
6031 }
6035 --
6036 -- *** Application messages
6037 --
6041 -- Do we chew up another tag for KRB-SAFE-EXT? That would
6042 -- allow us to make safe-body optional, allowing for a GSS-MIC
6043 -- sort of message.
6044 KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
6045 pvno [0] INTEGER (5),
6046 msg-type [1] INTEGER (20),
6047 safe-body [2] KRB-SAFE-BODY,
6048 cksum [3] ChecksumOf {
6049 KRB-SAFE-BODY,
6050 { key-session | key-subsession }, { ku-KrbSafe-cksum }},
6051 ... -- ASN.1 extensions must be excluded
6052 -- when sending to rfc1510 implementations
6053 }
6066 Yu Expires: Apr 2005 [Page 95]
6067 Internet-Draft yu-krb-extensions-02 25 Oct 2004
6070 KRB-SAFE-BODY ::= SEQUENCE {
6071 user-data [0] OCTET STRING,
6072 timestamp [1] KerberosTime OPTIONAL,
6073 usec [2] Microseconds OPTIONAL,
6074 seq-number [3] SeqNum OPTIONAL,
6075 s-address [4] HostAddress,
6076 r-address [5] HostAddress OPTIONAL,
6077 ... -- ASN.1 extensions must be excluded
6078 -- when sending to rfc1510 implementations
6079 }
6083 KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
6084 pvno [0] INTEGER (5),
6085 msg-type [1] INTEGER (21),
6086 enc-part [3] EncryptedData {
6087 EncKrbPrivPart,
6088 { key-session | key-subsession }, { ku-EncKrbPrivPart }},
6089 ...
6090 }
6094 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
6095 user-data [0] OCTET STRING,
6096 timestamp [1] KerberosTime OPTIONAL,
6097 usec [2] Microseconds OPTIONAL,
6098 seq-number [3] SeqNum OPTIONAL,
6099 s-address [4] HostAddress -- sender's addr --,
6100 r-address [5] HostAddress OPTIONAL -- recip's addr --,
6101 ... -- ASN.1 extensions must be excluded
6102 -- when sending to rfc1510 implementations
6103 }
6107 KRB-CRED ::= CHOICE {
6108 rfc1510 [APPLICATION 22] KRB-CRED-1510,
6109 ext [APPLICATION 24] Signed {
6110 KRB-CRED-EXT,
6111 { key-session | key-subsession }, { ku-KrbCred-cksum }}
6112 }
6126 Yu Expires: Apr 2005 [Page 96]
6127 Internet-Draft yu-krb-extensions-02 25 Oct 2004
6130 KRB-CRED-COMMON ::= SEQUENCE {
6131 pvno [0] INTEGER (5),
6132 msg-type [1] INTEGER (22 | 24),
6133 tickets [2] SEQUENCE OF Ticket,
6134 enc-part [3] EncryptedData {
6135 EncKrbCredPart,
6136 { key-session | key-subsession }, { ku-EncKrbCredPart }},
6137 ...
6138 }
6142 KRB-CRED-1510 ::= SEQUENCE {
6143 COMPONENTS OF KRB-CRED-COMMON
6144 } (WITH COMPONENTS { ..., msg-type (22) })
6148 KRB-CRED-EXT ::= [APPLICATION 24] KRB-CRED-COMMON
6149 (WITH COMPONENTS { ..., msg-type (24) })
6153 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
6154 ticket-info [0] SEQUENCE OF KrbCredInfo,
6155 nonce [1] Nonce OPTIONAL,
6156 timestamp [2] KerberosTime OPTIONAL,
6157 usec [3] Microseconds OPTIONAL,
6158 s-address [4] HostAddress OPTIONAL,
6159 r-address [5] HostAddress OPTIONAL
6160 }
6164 KrbCredInfo ::= SEQUENCE {
6165 key [0] EncryptionKey,
6166 prealm [1] Realm OPTIONAL,
6167 pname [2] PrincipalName OPTIONAL,
6168 flags [3] TicketFlags OPTIONAL,
6169 authtime [4] KerberosTime OPTIONAL,
6170 starttime [5] KerberosTime OPTIONAL,
6171 endtime [6] KerberosTime OPTIONAL,
6172 renew-till [7] KerberosTime OPTIONAL,
6173 srealm [8] Realm OPTIONAL,
6174 sname [9] PrincipalName OPTIONAL,
6175 caddr [10] HostAddresses OPTIONAL
6176 }
6187 Yu Expires: Apr 2005 [Page 97]
6188 Internet-Draft yu-krb-extensions-02 25 Oct 2004
6191 TGT-REQ ::= [APPLICATION 16] SEQUENCE {
6192 pvno [0] INTEGER (5),
6193 msg-type [1] INTEGER (16),
6194 sname [2] PrincipalName OPTIONAL,
6195 srealm [3] Realm OPTIONAL,
6196 ...
6197 }
6201 --
6202 -- *** Error messages
6203 --
6207 ErrCode ::= Int32
6210 KRB-ERROR ::= CHOICE {
6211 rfc1510 [APPLICATION 30] KRB-ERROR-1510,
6212 ext [APPLICATION 23] Signed {
6213 KRB-ERROR-EXT, { ku-KrbError-cksum } }
6214 }
6218 KRB-ERROR-COMMON ::= SEQUENCE {
6219 pvno [0] INTEGER (5),
6220 msg-type [1] INTEGER (30 | 23),
6221 ctime [2] KerberosTime OPTIONAL,
6222 cusec [3] Microseconds OPTIONAL,
6223 stime [4] KerberosTime,
6224 susec [5] Microseconds,
6225 error-code [6] ErrCode,
6226 crealm [7] Realm OPTIONAL,
6227 cname [8] PrincipalName OPTIONAL,
6228 realm [9] Realm -- Correct realm --,
6229 sname [10] PrincipalName -- Correct name --,
6230 e-text [11] KerberosString OPTIONAL,
6231 e-data [12] OCTET STRING OPTIONAL,
6232 ...,
6233 typed-data [13] TYPED-DATA OPTIONAL,
6234 nonce [14] Nonce OPTIONAL,
6235 lang-tag [15] LangTag OPTIONAL,
6236 ...
6237 }
6248 Yu Expires: Apr 2005 [Page 98]
6249 Internet-Draft yu-krb-extensions-02 25 Oct 2004
6252 KRB-ERROR-1510 ::= SEQUENCE {
6253 COMPONENTS OF KRB-ERROR-COMMON
6254 } (WITH COMPONENTS {
6255 ...,
6256 msg-type (30)
6257 })
6261 KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON
6262 (WITH COMPONENTS { ..., msg-type (23) })
6266 METHOD-DATA ::= SEQUENCE OF PA-DATA
6270 TDType ::= TH-id
6273 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
6274 data-type [0] TDType,
6275 data-value [1] OCTET STRING OPTIONAL
6276 }
6309 Yu Expires: Apr 2005 [Page 99]
6310 Internet-Draft yu-krb-extensions-02 25 Oct 2004
6313 --
6314 -- *** Error codes
6315 --
6318 -- No error
6319 kdc-err-none ErrCode ::= 0
6320 -- Client's entry in database has expired
6321 kdc-err-name-exp ErrCode ::= 1
6322 -- Server's entry in database has expired
6323 kdc-err-service-exp ErrCode ::= 2
6324 -- Requested protocol version number not supported
6325 kdc-err-bad-pvno ErrCode ::= 3
6326 -- Client's key encrypted in old master key
6327 kdc-err-c-old-mast-kvno ErrCode ::= 4
6328 -- Server's key encrypted in old master key
6329 kdc-err-s-old-mast-kvno ErrCode ::= 5
6330 -- Client not found in Kerberos database
6331 kdc-err-c-principal-unknown ErrCode ::= 6
6332 -- Server not found in Kerberos database
6333 kdc-err-s-principal-unknown ErrCode ::= 7
6334 -- Multiple principal entries in database
6335 kdc-err-principal-not-unique ErrCode ::= 8
6336 -- The client or server has a null key
6337 kdc-err-null-key ErrCode ::= 9
6338 -- Ticket not eligible for postdating
6339 kdc-err-cannot-postdate ErrCode ::= 10
6340 -- Requested start time is later than end time
6341 kdc-err-never-valid ErrCode ::= 11
6342 -- KDC policy rejects request
6343 kdc-err-policy ErrCode ::= 12
6344 -- KDC cannot accommodate requested option
6345 kdc-err-badoption ErrCode ::= 13
6346 -- KDC has no support for encryption type
6347 kdc-err-etype-nosupp ErrCode ::= 14
6348 -- KDC has no support for checksum type
6349 kdc-err-sumtype-nosupp ErrCode ::= 15
6350 -- KDC has no support for padata type
6351 kdc-err-padata-type-nosupp ErrCode ::= 16
6352 -- KDC has no support for transited type
6353 kdc-err-trtype-nosupp ErrCode ::= 17
6354 -- Clients credentials have been revoked
6355 kdc-err-client-revoked ErrCode ::= 18
6356 -- Credentials for server have been revoked
6357 kdc-err-service-revoked ErrCode ::= 19
6358 -- TGT has been revoked
6359 kdc-err-tgt-revoked ErrCode ::= 20
6367 Yu Expires: Apr 2005 [Page 100]
6368 Internet-Draft yu-krb-extensions-02 25 Oct 2004
6371 -- Client not yet valid - try again later
6372 kdc-err-client-notyet ErrCode ::= 21
6373 -- Server not yet valid - try again later
6374 kdc-err-service-notyet ErrCode ::= 22
6375 -- Password has expired - change password to reset
6376 kdc-err-key-expired ErrCode ::= 23
6377 -- Pre-authentication information was invalid
6378 kdc-err-preauth-failed ErrCode ::= 24
6379 -- Additional pre-authenticationrequired
6380 kdc-err-preauth-required ErrCode ::= 25
6381 -- Requested server and ticket don't match
6382 kdc-err-server-nomatch ErrCode ::= 26
6383 -- Server principal valid for user2user only
6384 kdc-err-must-use-user2user ErrCode ::= 27
6385 -- KDC Policy rejects transited path
6386 kdc-err-path-not-accpeted ErrCode ::= 28
6387 -- A service is not available
6388 kdc-err-svc-unavailable ErrCode ::= 29
6389 -- Integrity check on decrypted field failed
6390 krb-ap-err-bad-integrity ErrCode ::= 31
6391 -- Ticket expired
6392 krb-ap-err-tkt-expired ErrCode ::= 32
6393 -- Ticket not yet valid
6394 krb-ap-err-tkt-nyv ErrCode ::= 33
6395 -- Request is a replay
6396 krb-ap-err-repeat ErrCode ::= 34
6397 -- The ticket isn't for us
6398 krb-ap-err-not-us ErrCode ::= 35
6399 -- Ticket and authenticator don't match
6400 krb-ap-err-badmatch ErrCode ::= 36
6401 -- Clock skew too great
6402 krb-ap-err-skew ErrCode ::= 37
6403 -- Incorrect net address
6404 krb-ap-err-badaddr ErrCode ::= 38
6405 -- Protocol version mismatch
6406 krb-ap-err-badversion ErrCode ::= 39
6407 -- Invalid msg type
6408 krb-ap-err-msg-type ErrCode ::= 40
6424 Yu Expires: Apr 2005 [Page 101]
6425 Internet-Draft yu-krb-extensions-02 25 Oct 2004
6428 -- Message stream modified
6429 krb-ap-err-modified ErrCode ::= 41
6430 -- Message out of order
6431 krb-ap-err-badorder ErrCode ::= 42
6432 -- Specified version of key is not available
6433 krb-ap-err-badkeyver ErrCode ::= 44
6434 -- Service key not available
6435 krb-ap-err-nokey ErrCode ::= 45
6436 -- Mutual authentication failed
6437 krb-ap-err-mut-fail ErrCode ::= 46
6438 -- Incorrect message direction
6439 krb-ap-err-baddirection ErrCode ::= 47
6440 -- Alternative authentication method required
6441 krb-ap-err-method ErrCode ::= 48
6442 -- Incorrect sequence number in message
6443 krb-ap-err-badseq ErrCode ::= 49
6444 -- Inappropriate type of checksum in message
6445 krb-ap-err-inapp-cksum ErrCode ::= 50
6446 -- Policy rejects transited path
6447 krb-ap-path-not-accepted ErrCode ::= 51
6448 -- Response too big for UDP, retry with TCP
6449 krb-err-response-too-big ErrCode ::= 52
6450 -- Generic error (description in e-text)
6451 krb-err-generic ErrCode ::= 60
6481 Yu Expires: Apr 2005 [Page 102]
6482 Internet-Draft yu-krb-extensions-02 25 Oct 2004
6485 -- Field is too long for this implementation
6486 krb-err-field-toolong ErrCode ::= 61
6487 -- Reserved for PKINIT
6488 kdc-error-client-not-trusted ErrCode ::= 62
6489 -- Reserved for PKINIT
6490 kdc-error-kdc-not-trusted ErrCode ::= 63
6491 -- Reserved for PKINIT
6492 kdc-error-invalid-sig ErrCode ::= 64
6493 -- Reserved for PKINIT
6494 kdc-err-key-too-weak ErrCode ::= 65
6495 -- Reserved for PKINIT
6496 kdc-err-certificate-mismatch ErrCode ::= 66
6497 -- No TGT available to validate USER-TO-USER
6498 krb-ap-err-no-tgt ErrCode ::= 67
6499 -- USER-TO-USER TGT issued different KDC
6500 kdc-err-wrong-realm ErrCode ::= 68
6501 -- Ticket must be for USER-TO-USER
6502 krb-ap-err-user-to-user-required ErrCode ::= 69
6503 -- Reserved for PKINIT
6504 kdc-err-cant-verify-certificate ErrCode ::= 70
6505 -- Reserved for PKINIT
6506 kdc-err-invalid-certificate ErrCode ::= 71
6507 -- Reserved for PKINIT
6508 kdc-err-revoked-certificate ErrCode ::= 72
6509 -- Reserved for PKINIT
6510 kdc-err-revocation-status-unknown ErrCode ::= 73
6511 -- Reserved for PKINIT
6512 kdc-err-revocation-status-unavailable ErrCode ::= 74
6516 END
6520 B. Kerberos and Character Encodings (Informative)
6523 [adapted from KCLAR 5.2.1]
6526 The original specification of the Kerberos protocol in RFC 1510 uses
6527 GeneralString in numerous places for human-readable string data.
6528 Historical implementations of Kerberos cannot utilize the full power
6529 of GeneralString. This ASN.1 type requires the use of designation
6530 and invocation escape sequences as specified in ISO 2022 | ECMA-35
6531 [ISO2022] to switch character sets, and the default character set
6532 that is designated as G0 is the ISO 646 | ECMA-6 [ISO646]
6533 International Reference Version (IRV) (aka U.S. ASCII), which mostly
6534 works.
6537 ISO 2022 | ECMA-35 defines four character-set code elements (G0..G3)
6538 and two Control-function code elements (C0..C1). DER previously
6539 [X690-1997] prohibited the designation of character sets as any but
6540 the G0 and C0 sets. This had the side effect of prohibiting the use
6543 Yu Expires: Apr 2005 [Page 103]
6544 Internet-Draft yu-krb-extensions-02 25 Oct 2004
6547 of (ISO Latin) character-sets such as ISO 8859-1 [ISO8859-1] or any
6548 other character-sets that utilize a 96-character set, since it is
6549 prohibited by ISO 2022 | ECMA-35 to designate them as the G0 code
6550 element. Recent revisions to the ASN.1 standards resolve this
6551 contradiction.
6554 In practice, many implementations treat RFC 1510 GeneralStrings as if
6555 they were 8-bit strings of whichever character set the implementation
6556 defaults to, without regard for correct usage of character-set
6557 designation escape sequences. The default character set is often
6558 determined by the current user's operating system dependent locale.
6559 At least one major implementation places unescaped UTF-8 encoded
6560 Unicode characters in the GeneralString. This failure to conform to
6561 the GeneralString specifications results in interoperability issues
6562 when conflicting character encodings are utilized by the Kerberos
6563 clients, services, and KDC.
6566 This unfortunate situation is the result of improper documentation of
6567 the restrictions of the ASN.1 GeneralString type in prior Kerberos
6568 specifications.
6571 [the following should probably be rewritten and moved into the
6572 principal name section]
6575 For compatibility, implementations MAY choose to accept GeneralString
6576 values that contain characters other than those permitted by
6577 IA5String, but they should be aware that character set designation
6578 codes will likely be absent, and that the encoding should probably be
6579 treated as locale-specific in almost every way. Implementations MAY
6580 also choose to emit GeneralString values that are beyond those
6581 permitted by IA5String, but should be aware that doing so is
6582 extraordinarily risky from an interoperability perspective.
6585 Some existing implementations use GeneralString to encode unescaped
6586 locale-specific characters. This is a violation of the ASN.1
6587 standard. Most of these implementations encode US-ASCII in the left-
6588 hand half, so as long the implementation transmits only US-ASCII, the
6589 ASN.1 standard is not violated in this regard. As soon as such an
6590 implementation encodes unescaped locale-specific characters with the
6591 high bit set, it violates the ASN.1 standard.
6594 Other implementations have been known to use GeneralString to contain
6595 a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8
6596 is a different encoding, not a 94 or 96 character "G" set as defined
6597 by ISO 2022. It is believed that these implementations do not even
6598 use the ISO 2022 escape sequence to change the character encoding.
6599 Even if implementations were to announce the change of encoding by
6600 using that escape sequence, the ASN.1 standard prohibits the use of
6601 any escape sequences other than those used to designate/invoke "G" or
6602 "C" sets allowed by GeneralString.
6606 Yu Expires: Apr 2005 [Page 104]
6607 Internet-Draft yu-krb-extensions-02 25 Oct 2004
6610 C. Kerberos History (Informative)
6613 [Adapted from KCLAR "BACKGROUND"]
6616 The Kerberos model is based in part on Needham and Schroeder's
6617 trusted third-party authentication protocol [NS78] and on
6618 modifications suggested by Denning and Sacco [DS81]. The original
6619 design and implementation of Kerberos Versions 1 through 4 was the
6620 work of two former Project Athena staff members, Steve Miller of
6621 Digital Equipment Corporation and Clifford Neuman (now at the
6622 Information Sciences Institute of the University of Southern
6623 California), along with Jerome Saltzer, Technical Director of Project
6624 Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other
6625 members of Project Athena have also contributed to the work on
6626 Kerberos.
6629 Version 5 of the Kerberos protocol (described in this document) has
6630 evolved from Version 4 based on new requirements and desires for
6631 features not available in Version 4. The design of Version 5 of the
6632 Kerberos protocol was led by Clifford Neuman and John Kohl with much
6633 input from the community. The development of the MIT reference
6634 implementation was led at MIT by John Kohl and Theodore Ts'o, with
6635 help and contributed code from many others. Since RFC1510 was
6636 issued, extensions and revisions to the protocol have been proposed
6637 by many individuals. Some of these proposals are reflected in this
6638 document. Where such changes involved significant effort, the
6639 document cites the contribution of the proposer.
6642 Reference implementations of both version 4 and version 5 of Kerberos
6643 are publicly available and commercial implementations have been
6644 developed and are widely used. Details on the differences between
6645 Kerberos Versions 4 and 5 can be found in [KNT94].
6648 D. Notational Differences from [KCLAR]
6651 [ possible point for discussion ]
6654 [KCLAR] uses notational conventions slightly different from this
6655 document. As a derivative of RFC 1510, the text of [KCLAR] uses C-
6656 language style identifier names for defined values. In ASN.1
6657 notation, identifiers referencing defined values must begin with a
6658 lowercase letter and contain hyphen (-) characters rather than
6659 underscore (_) characters, while identifiers referencing types begin
6660 with an uppercase letter. [KCLAR] and RFC 1510 use all-uppercase
6661 identifiers with underscores to identify defined values. This has
6662 the potential to create confusion, but neither document defines
6663 values using actual ASN.1 value-assignment notation.
6666 It is debatable whether it is advantageous to write all identifier
6667 names (regardless of their ASN.1 token type) in all-uppercase letters
6668 for the purpose of emphasis in running text. The alternative is to
6671 Yu Expires: Apr 2005 [Page 105]
6672 Internet-Draft yu-krb-extensions-02 25 Oct 2004
6675 use double-quote characters (") when ambiguity is possible.
6678 Normative References
6681 [ISO646]
6682 "7-bit coded character set", ISO/IEC 646:1991 | ECMA-6:1991.
6685 [ISO2022]
6686 "Information technology -- Character code structure and
6687 extension techniques", ISO/IEC 2022:1994 | ECMA-35:1994.
6690 [KCRYPTO]
6691 K. Raeburn, "Encryption and Checksum Specifications for Kerberos
6692 5", draft-ietf-krb-wg-crypto-07.txt, work in progress.
6695 [RFC2119]
6696 S. Bradner, RFC2119: "Key words for use in RFC's to Indicate
6697 Requirement Levels", March 1997.
6700 [RFC3660]
6701 H. Alvestrand, "Tags for the Identification of Languages",
6702 RFC 3660, January 2001.
6705 [SASLPREP]
6706 Kurt D. Zeilenga, "SASLprep: Stringprep profile for user names
6707 and passwords", draft-ietf-sasl-saslprep-10.txt, work in
6708 progress.
6711 [X680]
6712 "Information technology -- Abstract Syntax Notation One (ASN.1):
6713 Specification of basic notation", ITU-T Recommendation X.680
6714 (2002) | ISO/IEC 8824-1:2002.
6717 [X682]
6718 "Information technology -- Abstract Syntax Notation One (ASN.1):
6719 Constraint specification", ITU-T Recommendation X.682 (2002) |
6720 ISO/IEC 8824-3:2002.
6723 [X683]
6724 "Information technology -- Abstract Syntax Notation One (ASN.1):
6725 Parameterization of ASN.1 specifications", ITU-T Recommendation
6726 X.683 (2002) | ISO/IEC 8824-4:2002.
6729 [X690]
6730 "Information technology -- ASN.1 encoding Rules: Specification
6731 of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
6732 and Distinguished Encoding Rules (DER)", ITU-T Recommendation
6733 X.690 (2002) | ISO/IEC 8825-1:2002.
6739 Yu Expires: Apr 2005 [Page 106]
6740 Internet-Draft yu-krb-extensions-02 25 Oct 2004
6743 Informative References
6746 [DS81]
6747 Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key
6748 Distribution Protocols," Communications of the ACM, Vol. 24(8),
6749 pp. 533-536 (August 1981).
6752 [Dub00]
6753 Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous
6754 Systems", Elsevier-Morgan Kaufmann, 2000.
6755 <http://www.oss.com/asn1/dubuisson.html>
6758 [ISO8859-1]
6759 "Information technology -- 8-bit single-byte coded graphic
6760 character sets -- Part 1: Latin alphabet No. 1", ISO/IEC 8859-
6761 1:1998.
6764 [KCLAR]
6765 Clifford Neuman, Tom Yu, Sam Hartman, Ken Raeburn, "The Kerberos
6766 Network Authentication Service (V5)", draft-ietf-krb-wg-
6767 kerberos-clarifications-07.txt, work in progress.
6770 [KNT94]
6771 John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
6772 Evolution of the Kerberos Authentication System". In
6773 Distributed Open Systems, pages 78-94. IEEE Computer Society
6774 Press, 1994.
6777 [Lar96]
6778 John Larmouth, "Understanding OSI", International Thomson
6779 Computer Press, 1996.
6780 <http://www.isi.salford.ac.uk/books/osi.html>
6783 [Lar99]
6784 John Larmouth, "ASN.1 Complete", Elsevier-Morgan Kaufmann,
6785 1999. <http://www.oss.com/asn1/larmouth.html>
6788 [NS78]
6789 Roger M. Needham and Michael D. Schroeder, "Using Encryption for
6790 Authentication in Large Networks of Computers", Communications
6791 of the ACM, Vol. 21(12), pp. 993-999 (December, 1978).
6794 [RFC1510]
6795 J. Kohl and B. C. Neuman, "The Kerberos Network Authentication
6796 Service (v5)", RFC1510, September 1993, Status: Proposed
6797 Standard.
6800 [RFC1964]
6801 J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
6802 June 1996, Status: Proposed Standard.
6806 Yu Expires: Apr 2005 [Page 107]
6807 Internet-Draft yu-krb-extensions-02 25 Oct 2004
6810 [X690-2002]
6811 "Information technology -- ASN.1 encoding rules: Specification
6812 of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
6813 and Distinguished Encoding Rules (DER)", ITU-T Recommendation
6814 X.690 (2002) | ISO/IEC 8825-1:2002.
6817 Author's Address
6820 Tom Yu
6821 77 Massachusetts Ave
6822 Cambridge, MA 02139
6823 USA
6824 tlyu@mit.edu
6827 Full Copyright Statement
6830 Copyright (C) The Internet Society (2004). This document is subject
6831 to the rights, licenses and restrictions contained in BCP 78, and
6832 except as set forth therein, the authors retain all their rights.
6835 This document and the information contained herein are provided on an
6836 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
6837 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
6838 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
6839 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
6840 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
6841 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
6867 Yu Expires: Apr 2005 [Page 108]