2 draft-yu-krb-wg-kerberos-extensions-01.txt MIT
3 Expires: 19 Jan 2005 19 July 2004
6 The Kerberos Network Authentication Service (Version 5)
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-
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
46 Copyright (C) The Internet Society (2004). All Rights Reserved.
52 This document describes version 5 of the Kerberos network
53 authentication protocol. It describes changes to the protocol which
54 allow for 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: Jan 2005 [Page 1]
70 Internet-Draft yu-krb-extensions-01 19 Jul 2004
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 .......................................... 4
82 1.1. Kerberos Protocol Overview .......................... 4
83 1.2. Overview of Document ................................ 5
84 2. Extensibility ......................................... 5
85 3. Backwards Compatibility ............................... 6
86 4. Criticality ........................................... 6
87 5. Use of ASN.1 in Kerberos .............................. 6
88 5.1. Module Header ....................................... 7
89 5.2. Top-Level Type ...................................... 7
90 5.3. Previously Unused ASN.1 Notation .................... 8
91 5.3.1. Parameterized Types ............................... 8
92 5.3.2. COMPONENTS OF Notation ............................ 8
93 5.3.3. Constraints ....................................... 8
94 5.4. New Types ........................................... 9
95 6. Basic Types ........................................... 10
96 6.1. Constrained Integer Types ........................... 10
97 6.2. KerberosTime ........................................ 11
98 6.3. KerberosString ...................................... 11
99 7. Principals ............................................ 11
100 7.1. Name Types .......................................... 12
101 7.2. Principal Type Definition ........................... 12
102 7.3. Principal Name Reuse ................................ 13
103 7.4. Realm Names ......................................... 13
104 7.5. Printable Representations of Principal Names ........ 13
105 7.6. Ticket-Granting Service Principal ................... 13
106 7.6.1. Cross-Realm TGS Principals ........................ 14
107 8. Types Relating to Encryption .......................... 14
108 8.1. Assigned Numbers for Encryption ..................... 14
109 8.1.1. EType ............................................. 14
110 8.1.2. Key Usages ........................................ 15
111 8.2. Which Key to Use .................................... 16
112 8.3. EncryptionKey ....................................... 17
113 8.4. EncryptedData ....................................... 17
114 8.5. Checksums ........................................... 18
115 8.5.1. ChecksumOf ........................................ 19
116 8.5.2. Signed ............................................ 20
117 9. Tickets ............................................... 20
118 9.1. Timestamps .......................................... 21
119 9.2. Ticket Flags ........................................ 21
120 9.2.1. Flags Relating to Initial Ticket Acquisition ...... 22
121 9.2.2. Invalid Tickets ................................... 22
122 9.2.3. OK as Delegate .................................... 23
123 9.3. Renewable Tickets ................................... 23
124 9.4. Postdated Tickets ................................... 24
127 Yu Expires: Jan 2005 [Page 2]
128 Internet-Draft yu-krb-extensions-01 19 Jul 2004
131 9.5. Proxiable and Proxy Tickets ......................... 25
132 9.6. Forwardable Tickets ................................. 26
133 9.7. Transited Realms .................................... 27
134 9.8. Authorization Data .................................. 27
135 9.9. Encrypted Part of Ticket ............................ 27
136 9.10. Cleartext Part of Ticket ........................... 28
137 10. Credential Acquisition ............................... 28
138 10.1. KDC-REQ ............................................ 29
139 10.2. PA-DATA ............................................ 31
140 10.3. KDC-REQ Processing ................................. 31
141 10.3.1. Handling Replays ................................. 31
142 10.3.2. Request Validation ............................... 32
143 10.3.2.1. AS-REQ Authentication .......................... 32
144 10.3.2.2. TGS-REQ Authentication ......................... 32
145 10.3.2.3. Principal Validation ........................... 32
146 10.3.2.4. Checking For Revoked or Invalid Tickets ........ 32
147 10.3.3. Timestamp Handling ............................... 33
148 10.3.3.1. AS-REQ Timestamp Processing .................... 33
149 10.3.3.2. TGS-REQ Timestamp Processing ................... 34
150 10.3.4. Handling Transited Realms ........................ 35
151 10.3.5. Address Processing ............................... 35
152 10.3.6. Ticket Flag Processing ........................... 35
153 10.3.7. Key Selection .................................... 36
154 10.3.7.1. Reply Key and Session Key Selection ............ 37
155 10.3.7.2. Ticket Key Selection ........................... 37
156 10.4. Reply Validation ................................... 37
157 11. Session Key Exchange ................................. 37
158 11.1. AP-REQ ............................................. 37
159 11.2. AP-REP ............................................. 40
160 12. Session Key Use ...................................... 41
161 12.1. KRB-SAFE ........................................... 41
162 12.2. KRB-PRIV ........................................... 42
163 12.3. KRB-CRED ........................................... 42
164 13. Security Considerations .............................. 43
165 13.1. Time Synchronization ............................... 43
166 13.2. Replays ............................................ 44
167 13.3. Principal Name Reuse ............................... 44
168 13.4. Password Guessing .................................. 44
169 13.5. Forward Secrecy .................................... 44
170 13.6. Authorization ...................................... 44
171 13.7. Login Authentication ............................... 44
172 14. Acknowledgments ...................................... 45
173 Appendices ................................................ 45
174 A. ASN.1 Module (Normative) .............................. 45
175 B. Kerberos and Character Encodings (Informative) ........ 76
176 C. Kerberos History (Informative) ........................ 77
177 D. Notational Differences from [KCLAR] ................... 78
178 Normative References ...................................... 79
179 Informative References .................................... 79
180 Author's Address .......................................... 80
181 Full Copyright Statement .................................. 80
184 Yu Expires: Jan 2005 [Page 3]
185 Internet-Draft yu-krb-extensions-01 19 Jul 2004
191 The Kerberos network authentication protocol is a trusted third-party
192 protocol utilizing symmetric-key cryptography. It assumes that all
193 communications between parties in the protocol may be arbitrarily
194 tampered with or monitored, and that the security of the overall
195 system depends only on the effectiveness of the cryptographic
196 techniques and the secrecy of the keys used. The protocol
197 authenticates an application client's identity to an application
198 server, and likewise authenticates the application server's identity
199 to the application client. These assurances are made possible by the
200 client and the server sharing secrets with the trusted third party:
201 the Kerberos server, also known as the Key Distribution Center (KDC).
202 In addition, the protocol establishes an ephemeral shared secret (the
203 session key) between the client and the server, allowing the
204 protection of further communications between them.
207 1.1. Kerberos Protocol Overview
210 Kerberos comprises three main sub-protocols: credentials acquisition,
211 session key exchange, and session key usage. A client acquires
212 credentials by asking the KDC for a credential for a service; the KDC
213 issues the credential, which contains a ticket and a session key.
214 The ticket, containing the client's identity, timestamps, expiration
215 time, and a session key, is a encrypted in a key known to the
216 application server. The KDC encrypts the credential using a key
217 known to the client, and transmits the credential to the client.
220 There are two means of requesting credentials: the Authentication
221 Service (AS) exchange, and the Ticket-Granting Service (TGS)
222 exchange. In the typical AS exchange, a client uses a password-
223 derived key to decrypt the response. In the TGS exchange, the KDC
224 behaves as an application, which the client authenticates to using a
225 Ticket-Granting Ticket (TGT). The client usually obtains the TGT by
226 using the AS exchange.
229 Session key exchange consists of the client transmitting the ticket
230 to the application server, accompanied by an authenticator. The
231 authenticator contains a timestamp and additional data encrypted
232 using the ticket's session key. The application server decrypts the
233 ticket, extracting the session key. The application server then uses
234 the session key to decrypt the authenticator. Upon successful
235 decryption of the authenticator, the application server knows that
236 the data in the authenticator were sent by the client named in the
237 associated ticket. Additionally, since authenticators expire more
238 quickly than tickets, the application server has some assurance that
239 the transaction is not a replay. The application server may send an
240 encrypted acknowledgment to the client, verifying its identity to the
246 Yu Expires: Jan 2005 [Page 4]
247 Internet-Draft yu-krb-extensions-01 19 Jul 2004
250 Once session key exchange has occurred, the client and server may use
251 the established session key to protect further traffic. This
252 protection may consist of protection of integrity only, or of
253 protection of confidentiality and integrity. Additional measures
254 exist for a client to securely forward credentials to a server.
257 The entire scheme depends on loosely synchronized clocks.
258 Synchronization of the clock on the KDC with the application server
259 clock allows the application server to accurately determine whether a
260 credential is expired. Likewise, synchronization of the clock on the
261 client with the application server clock prevents replay attacks
262 utilizing the same credential. Careful design of the application
263 protocol may allow replay prevention without requiring client-server
264 clock synchronization.
267 After establishing a session key, application client and the
268 application server can exchange Kerberos protocol messages that use
269 the session key to protect the integrity or confidentiality of
270 communications between the client and the server. Additionally, the
271 client may forward credentials to the application server.
274 The credentials acquisition protocol takes place over specific,
275 defined transports (UDP and TCP). Application protocols define which
276 transport to use for the session key establishment protocol and for
277 messages using the session key; the application may choose to perform
278 its own encapsulation of the Kerberos messages, for example.
281 1.2. Overview of Document
284 The remainder of this document begins by describing the general
285 frameworks for protocol extensibility, including whether to interpret
286 unknown extensions as critical. It then defines the protocol
287 messages and exchanges.
290 The definition of the Kerberos protocol uses Abstract Syntax Notation
291 One (ASN.1) [X680], which specifies notation for describing the
292 abstract content of protocol messages. This document defines a
293 number of base types using ASN.1; these base types subsequently
294 appear in multiple types which define actual protocol messages.
295 Definitions of principal names and of tickets, which are central to
296 the protocol, also appear preceding the protocol message definitions.
302 As originally defined in RFC 1510, the Kerberos protocol does not
303 readily allow for backwards-compatible extensions to the protocol.
304 Various proposals to extend the Kerberos protocol have appeared since
305 RFC 1510, many of them creating problems for backwards compatibility.
306 This document adopts the technique of creating new extensible types
307 which encode to messages which are very similar to RFC 1510 messages
308 on the wire. This similarity allows implementors to use shared code
311 Yu Expires: Jan 2005 [Page 5]
312 Internet-Draft yu-krb-extensions-01 19 Jul 2004
315 paths for encoding and decoding both new and old messages.
318 The protocol defined in RFC 1510 already contains some elements
319 allowing for limited backwards-compatible extensions to the protocol.
320 Most of these elements consist of "typed holes"; these are octet
321 strings having associated assigned numbers indicating the intended
322 interpretation of the octet string. This document typed holes to
323 some types which have previously lacked typed holes. This document
324 also describes procedures for the IETF to use the extensibility model
325 of ASN.1 to make further backwards-compatible extensions of the
326 Kerberos protocol, if typed holes prove inadequate for some desired
330 3. Backwards Compatibility
333 This document describes two sets (for the most part) of ASN.1 types.
334 The first set of types is wire-encoding compatible with RFC 1510 and
335 [KCLAR]. The second set of types is the set of types enabling
336 extensibility. This second set may be referred to as "extensibility-
337 enabled types". [ need to make this consistent throughout? ]
340 A major difference between the new extensibility-enabled types and
341 the types for RFC 1510 compatibility is that the extensibility-
342 enabled types allow for the use of UTF-8 encodings in various
343 character strings in the protocol. Each party in the protocol must
344 have some knowledge of the capabilities of the other parties in the
345 protocol. There are methods for establishing this knowledge without
346 necessarily requiring explicit configuration.
349 An extensibility-enabled client can detect whether a KDC supports the
350 extensibility-enabled types by requesting an extensibility-enabled
351 reply. If the KDC replies with an extensibility-enabled reply, the
352 client knows that the KDC supports extensibility. If the KDC issues
353 an extensibility-enabled ticket, the client knows that the service
354 named in the ticket is extensibility-enabled.
360 In general, implementations SHOULD treat unknown extension, flags,
361 etc. as non-critical; i.e., they should ignore them when they do not
362 understand them. Exceptions are clearly marked. An implementation
363 SHOULD NOT reject a request merely because it does not understand
364 some element of the request. As a related consequence,
365 implementations SHOULD handle talking to other implementations which
366 do not implement some requested options. This may require designers
367 of extensions or options to provide means to detect whether
368 extensions or options are rejected, or whether such extensions or
369 options are merely not understood, or whether such extensions or
370 options are (perhaps maliciously) deleted or modified in transit.
375 Yu Expires: Jan 2005 [Page 6]
376 Internet-Draft yu-krb-extensions-01 19 Jul 2004
379 5. Use of ASN.1 in Kerberos
382 Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690].
383 Even though ASN.1 theoretically allows the description of protocol
384 messages to be independent of the encoding rules used to encode the
385 messages, Kerberos messages MUST be encoded with DER. Subtleties in
386 the semantics of the notation, such as whether tags carry any
387 semantic content to the application, may cause the use of other ASN.1
388 encoding rules to be problematic.
391 Implementors not using existing ASN.1 tools (e.g., compilers or
392 support libraries) are cautioned to thoroughly read and understand
393 the actual ASN.1 specification to ensure correct implementation
394 behavior. There is more complexity in the notation than is
395 immediately obvious, and some tutorials and guides to ASN.1 are
396 misleading or erroneous. Recommended tutorials and guides include
397 [Dub00], [Lar99], though there is still no substitute for reading the
398 actual ASN.1 specification.
404 The type definitions in this document assume an ASN.1 module
405 definition of the following form:
409 iso(1) identified-organization(3) dod(6) internet(1)
410 security(5) kerberosV5(2) modules(4) krb5spec3(4)
411 } DEFINITIONS EXPLICIT TAGS ::= BEGIN
414 -- Rest of definitions here
420 This specifies that the tagging context for the module will be
421 explicit and that automatic tagging is not done.
424 Some other publications [RFC1510] [RFC1964] erroneously specify an
425 object identifier (OID) having an incorrect value of "5" for the
426 "dod" component of the OID. In the case of RFC 1964, use of the
427 "correct" OID value would result in a change in the wire protocol;
428 therefore, the RFC 1964 OID remains unchanged for now.
434 The ASN.1 type "KRB-PDU" is a CHOICE over all the types (Protocol
435 Data Units or PDUs) which an application may directly reference.
436 Applications SHOULD NOT transmit any types other than those which are
437 alternatives of the KRB-PDU CHOICE.
443 Yu Expires: Jan 2005 [Page 7]
444 Internet-Draft yu-krb-extensions-01 19 Jul 2004
449 -- Applications should not directly reference any types
450 -- other than KRB-PDU and its component types.
470 5.3. Previously Unused ASN.1 Notation
473 Some aspects of ASN.1 notation used in this document were not used in
474 [KCLAR], and may be unfamiliar to some readers.
477 5.3.1. Parameterized Types
480 This document uses ASN.1 parameterized types [X683] to make
481 definitions of types more readable. For some types, some or all of
482 the parameters are advisory, i.e., they are not encoded in any form
483 for transmission in a protocol message. These advisory parameters
484 can describe implementation behavior associated with the type.
487 5.3.2. COMPONENTS OF Notation
490 The "COMPONENTS OF" notation, used to define the RFC 1510
491 compatibility types, extracts all of the component types of an ASN.1
492 SEQUENCE type. The extension marker (the "..." notation) and any
493 extension components are not extracted by "COMPONENTS OF". The
494 "COMPONENTS OF" notation permits concise definition of multiple types
495 which have many components in common with each other.
501 This document uses ASN.1 constraints, including the
502 "UserDefinedConstraint" syntax [X682]. Some constraints can be
503 handled automatically by tools that can parse them. Uses of the
504 "UserDefinedConstraint" syntax (the "CONSTRAINED BY" syntax) will
505 typically need to have behavior manually coded; these uses provide a
508 Yu Expires: Jan 2005 [Page 8]
509 Internet-Draft yu-krb-extensions-01 19 Jul 2004
512 formalized way of conveying intended implementation behavior.
515 The "WITH COMPONENTS" constraint notation allows constraints to apply
516 to component types of a SEQUENCE type. This constraint notation
517 effectively allows constraints to "reach into" a type to constrain
524 This document defines a number of ASN.1 types which are new since
525 RFC 1510. The names of these types will typically have a suffix like
526 "Ext", indicating that the types are intended to support
527 extensibility. Types original to RFC 1510 have been renamed to have
528 a suffix like "1510". The "Ext" and "1510" types often contain a
529 number of common elements; these common elements have a suffix like
530 "Common". The "1510" types have various ASN.1 constraints applied to
531 them; the constraints limit the possible values of the "1510" types
532 to those permitted by RFC 1510 or by [KCLAR]. The "Ext" types may
533 have different constraints, typically to force string values to be
537 For example, consider
540 -- example "common" type
541 Foo-Common ::= SEQUENCE {
550 -- example "RFC 1510 compatibility" type
551 Foo-1510 ::= SEQUENCE {
552 -- the COMPONENTS OF notation drops the extension marker
553 -- and all extension additions.
554 COMPONENTS OF Foo-Common
558 -- example "extensibility-enabled" type
559 Foo-Ext ::= Foo-Common
562 where "Foo-Common" is a common type used to define both the "1510"
563 and "Ext" versions of a type. "Foo-1510" is the RFC 1510 version of
564 the type, while "Foo-Ext" is the extensible version. "Foo-1510" does
565 not contain the extension marker, nor does it contain the extension
566 component "c". The type "Foo-1510" is equivalent to
567 "Foo-1510-Equiv", shown below.
573 Yu Expires: Jan 2005 [Page 9]
574 Internet-Draft yu-krb-extensions-01 19 Jul 2004
577 -- example type equivalent to Foo-1510
578 Foo-1510-Equiv ::= SEQUENCE {
588 Certain ASN.1 types in Kerberos appear repeatedly in other Kerberos
592 6.1. Constrained Integer Types
595 In RFC 1510, many types contained references to the unconstrained
596 INTEGER type. Since an unconstrained INTEGER may contain any
597 possible abstract integer value, most of the unconstrained references
598 to INTEGER in RFC 1510 have been constrained to 32 bits or smaller.
601 -- signed values representable in 32 bits
603 -- These are often used as assigned numbers for various things.
604 Int32 ::= INTEGER (-2147483648..2147483647)
607 -- unsigned 32 bit values
608 UInt32 ::= INTEGER (0..4294967295)
611 The "Int32" type often contains an assigned number identifying the
612 type of a protocol element. Unless otherwise stated, non-negative
613 values are registered, and negative values are available for local
617 -- unsigned 64 bit values
618 UInt64 ::= INTEGER (0..18446744073709551615)
621 The "UInt64" type is used in places where 32 bits of precision may
622 provide inadequate security.
626 Microseconds ::= INTEGER (0..999999)
639 While these types have different abstract types from their
640 equivalents in RFC 1510, their DER encodings remain identical.
643 Yu Expires: Jan 2005 [Page 10]
644 Internet-Draft yu-krb-extensions-01 19 Jul 2004
647 Nonces and sequence numbers are constrained to 32 bits in the
648 RFC 1510 backwards-compatibility types.
654 -- must not have fractional seconds
655 KerberosTime ::= GeneralizedTime
658 The timestamps used in Kerberos are encoded as GeneralizedTimes. A
659 KerberosTime value MUST NOT include any fractional portions of the
660 seconds. As required by the DER, it further MUST NOT include any
661 separators, and it specifies the UTC time zone (Z). Example: The
662 only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
663 November 1985 is "19851106210627Z".
669 -- used for names and for error messages
670 KerberosString ::= CHOICE {
671 ia5 GeneralString (IA5String),
673 ... -- no extension may be sent
674 -- to an rfc1510 implementation --
678 The KerberosString type is used for strings in various places in the
679 Kerberos protocol. For compatibility with RFC 1510, GeneralString
680 values constrained to IA5String (US-ASCII) are permitted in messages
681 exchanged with RFC 1510 implementations. The new protocol messages
682 contain strings encoded as UTF-8. KerberosString values are present
683 in principal names and in error messages. Control characters SHOULD
684 NOT be used in principal names, and used with caution in error
688 -- IA5 choice only; useful for constraints
689 KerberosStringIA5 ::= KerberosString
690 (WITH COMPONENTS { ia5 PRESENT })
693 -- IA5 excluded; useful for constraints
694 KerberosStringExt ::= KerberosString
695 (WITH COMPONENTS { ia5 ABSENT })
698 KerberosStringIA5 and KerberosStringExt respectively force and forbid
699 the use of the "ia5" alternative. These types are used as
700 constraints on other types for backwards compatibility purposes.
703 For detailed background regarding the history of character string use
704 in Kerberos, as well as discussion of some compatibility issues, see
710 Yu Expires: Jan 2005 [Page 11]
711 Internet-Draft yu-krb-extensions-01 19 Jul 2004
717 Principals are participants in the Kerberos protocol. A "realm"
718 consists of principals in one administrative domain, served by one
719 KDC (or one replicated set of KDCs). Each principal name has an
720 arbitrary number of components, though typical principal names will
721 only have one or two components. A principal name is meant to be
722 readable by and meaningful to humans, especially in a realm lacking a
723 centrally adminstered authorization infrastructure.
729 Each Principal has NameType indicating what sort of name it is. The
730 name-type SHOULD be treated as a hint. Ignoring the name type, no
731 two names can be the same (i.e., at least one of the components, or
732 the realm, must be different).
735 -- assigned numbers for name types (used in principal names)
739 -- Name type not known
740 nt-unknown NameType ::= 0
741 -- Just the name of the principal as in DCE, or for users
742 nt-principal NameType ::= 1
743 -- Service and other unique instance (krbtgt)
744 nt-srv-inst NameType ::= 2
745 -- Service with host name as instance (telnet, rcommands)
746 nt-srv-hst NameType ::= 3
747 -- Service with host as remaining components
748 nt-srv-xhst NameType ::= 4
750 nt-uid NameType ::= 5
751 -- Encoded X.509 Distingished name [RFC 2253]
752 nt-x500-principal NameType ::= 6
753 -- Name in form of SMTP email name (e.g. user@foo.com)
754 nt-smtp-name NameType ::= 7
755 -- Enterprise name - may be mapped to principal name
756 nt-enterprise NameType ::= 10
760 7.2. Principal Type Definition
763 PrincipalName ::= SEQUENCE {
764 name-type [0] NameType,
765 -- May have zero elements, or individual elements may be
766 -- zero-length, but this is not recommended.
767 name-string [1] SEQUENCE OF KerberosString
774 Yu Expires: Jan 2005 [Page 12]
775 Internet-Draft yu-krb-extensions-01 19 Jul 2004
779 hint of the type of name that follows
783 The "name-string" encodes a sequence of components that form a
784 name, each component encoded as a KerberosString. Taken
785 together, a PrincipalName and a Realm form a principal
786 identifier. Most PrincipalNames will have only a few components
787 (typically one or two).
790 7.3. Principal Name Reuse
793 Realm administrators SHOULD use extreme caution when considering
794 reusing a principal name. A service administrator might explicitly
795 enter principal names into a local access control list (ACL) for the
796 service. If such local ACLs exist independently of a centrally
797 administered authorization infrastructure, realm administrators
798 SHOULD NOT reuse principal names until confirming that all extant ACL
799 entries referencing that principal name have been updated. Failure
800 to perform this check can result in a security vulnerability, as a
801 new principal can inadvertently inherit unauthorized privileges upon
802 receiving a reused principal name. An organization whose Kerberos-
803 authenticated services all use a centrally-adminstered authorization
804 infrastructure may not need to take these precautions regarding
805 principal name reuse.
811 Realm ::= KerberosString
815 RealmIA5 ::= Realm (KerberosStringIA5)
819 RealmExt ::= Realm (KerberosStringExt)
823 Kerberos realm names are KerberosStrings. Realms MUST NOT contain a
824 character with the code 0 (the US-ASCII NUL). Most realms will
825 usually consist of several components separated by periods (.), in
826 the style of Internet Domain Names, or separated by slashes (/) in
827 the style of X.500 names.
830 7.5. Printable Representations of Principal Names
833 [ perhaps non-normative? ]
836 The printable form of a principal name consists of the concatenation
837 of components of the PrincipalName value using the slash character
838 (/), followed by an at-sign (@), followed by the realm name.
842 Yu Expires: Jan 2005 [Page 13]
843 Internet-Draft yu-krb-extensions-01 19 Jul 2004
846 7.6. Ticket-Granting Service Principal
849 The PrincipalName value corresponding to a ticket-granting service
850 has two components: the first component is the string "krbtgt", and
851 the second component is the realm name of the TGS which will accept a
852 ticket-granting ticket having this service principal name. The realm
853 name of service always indicates which realm issued the ticket. A
854 ticket-granting ticket issued by "A.EXAMPLE.COM" which is valid for
855 obtaining tickets in the same realm would have the following ASN.1
856 values for its "realm" and "sname" components, respectively:
859 -- Example Realm and PrincipalName for a TGS
862 tgtRealm1 Realm ::= ia5 : "A.EXAMPLE.COM"
865 tgtPrinc1 PrincipalName ::= {
866 name-type nt-srv-inst,
867 name-string { ia5 : "krbtgt", ia5 : "A.EXAMPLE.COM" }
871 Its printable representation would be written as
872 "krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM".
875 7.6.1. Cross-Realm TGS Principals
878 It is possible for a principal in one realm to authenticate to a
879 service in another realm. A KDC can issue a cross-realm ticket-
880 granting ticket to allow one of its principals to authenticate to a
881 service in a foreign realm. For example, the TGS principal
882 "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" is a principal that permits a
883 client principal in the realm A.EXAMPLE.COM to authenticate to a
884 service in the realm B.EXAMPLE.COM. When the KDC for B.EXAMPLE.COM
885 issues a ticket to a client originating in A.EXAMPLE.COM, the
886 client's realm name remains "A.EXAMPLE.COM", even though the service
887 principal will have the realm "B.EXAMPLE.COM".
890 8. Types Relating to Encryption
893 Many Kerberos protocol messages contain encryptions of various data
894 types. Kerberos protocol messages also contain checksums
895 (signatures) of various types.
898 8.1. Assigned Numbers for Encryption
901 Encryption algorithm identifiers and key usages both have assigned
902 numbers, described in [KCRYPTO].
908 EType is the integer type for assigned numbers for encryption
909 algorithms. Defined in [KCRYPTO].
912 Yu Expires: Jan 2005 [Page 14]
913 Internet-Draft yu-krb-extensions-01 19 Jul 2004
916 -- Assigned numbers denoting encryption mechanisms.
920 -- assigned numbers for encryption schemes
921 et-des-cbc-crc EType ::= 1
922 et-des-cbc-md4 EType ::= 2
923 et-des-cbc-md5 EType ::= 3
925 et-des3-cbc-md5 EType ::= 5
927 et-des3-cbc-sha1 EType ::= 7
928 et-dsaWithSHA1-CmsOID EType ::= 9
929 et-md5WithRSAEncryption-CmsOID EType ::= 10
930 et-sha1WithRSAEncryption-CmsOID EType ::= 11
931 et-rc2CBC-EnvOID EType ::= 12
932 et-rsaEncryption-EnvOID EType ::= 13
933 et-rsaES-OAEP-ENV-OID EType ::= 14
934 et-des-ede3-cbc-Env-OID EType ::= 15
935 et-des3-cbc-sha1-kd EType ::= 16
937 et-aes128-cts-hmac-sha1-96 EType ::= 17
939 et-aes256-cts-hmac-sha1-96 EType ::= 18
941 et-rc4-hmac EType ::= 23
943 et-rc4-hmac-exp EType ::= 24
944 -- opaque; PacketCable
945 et-subkey-keymaterial EType ::= 65
952 KeyUsage is the integer type for assigned numbers for key usages.
953 Key usage values are inputs to the encryption and decryption
954 functions described in [KCRYPTO].
972 Yu Expires: Jan 2005 [Page 15]
973 Internet-Draft yu-krb-extensions-01 19 Jul 2004
976 -- Assigned numbers denoting key usages.
981 -- Actual identifier names are provisional and subject to
984 ku-pa-enc-ts KeyUsage ::= 1
985 ku-Ticket KeyUsage ::= 2
986 ku-EncASRepPart KeyUsage ::= 3
987 ku-TGSReqAuthData-sesskey KeyUsage ::= 4
988 ku-TGSReqAuthData-subkey KeyUsage ::= 5
989 ku-pa-TGSReq-cksum KeyUsage ::= 6
990 ku-pa-TGSReq-authenticator KeyUsage ::= 7
991 ku-EncTGSRepPart-sesskey KeyUsage ::= 8
992 ku-EncTGSRepPart-subkey KeyUsage ::= 9
993 ku-Authenticator-cksum KeyUsage ::= 10
994 ku-APReq-authenticator KeyUsage ::= 11
995 ku-EncAPRepPart KeyUsage ::= 12
996 ku-EncKrbPrivPart KeyUsage ::= 13
997 ku-EncKrbCredPart KeyUsage ::= 14
998 ku-KrbSafe-cksum KeyUsage ::= 15
999 ku-ad-KDCIssued-cksum KeyUsage ::= 19
1003 -- The following numbers are provisional...
1004 -- conflicts may exist elsewhere.
1005 ku-Ticket-cksum KeyUsage ::= 25
1006 ku-ASReq-cksum KeyUsage ::= 26
1007 ku-TGSReq-cksum KeyUsage ::= 27
1008 ku-ASRep-cksum KeyUsage ::= 28
1009 ku-TGSRep-cksum KeyUsage ::= 29
1010 ku-APReq-cksum KeyUsage ::= 30
1011 ku-APRep-cksum KeyUsage ::= 31
1012 ku-KrbCred-cksum KeyUsage ::= 32
1013 ku-KrbError-cksum KeyUsage ::= 33
1014 ku-KDCRep-cksum KeyUsage ::= 34
1018 8.2. Which Key to Use
1032 Yu Expires: Jan 2005 [Page 16]
1033 Internet-Draft yu-krb-extensions-01 19 Jul 2004
1036 -- KeyToUse identifies which key is to be used to encrypt or
1037 -- sign a given value.
1039 -- Values of KeyToUse are never actually transmitted over the
1040 -- wire, or even used directly by the implementation in any
1041 -- way, as key usages are; it exists primarily to identify
1042 -- which key gets used for what purpose. Thus, the specific
1043 -- numeric values associated with this type are irrelevant.
1044 KeyToUse ::= ENUMERATED {
1047 -- server long term key
1049 -- client long term key
1051 -- key selected by KDC for encryption of a KDC-REP
1053 -- session key from ticket
1055 -- subsession key negotiated via AP-REQ/AP-REP
1065 The "EncryptionKey" type holds an encryption key.
1068 EncryptionKey ::= SEQUENCE {
1070 keyvalue [1] OCTET STRING
1076 This "EType" identifies the encryption algorithm, described in
1081 Contains the actual key.
1087 The "EncryptedData" type contains the encryption of another data
1088 type. The recipient uses fields within EncryptedData to determine
1089 which key to use for decryption.
1096 Yu Expires: Jan 2005 [Page 17]
1097 Internet-Draft yu-krb-extensions-01 19 Jul 2004
1101 -- "Type" specifies which ASN.1 type is encrypted to the
1102 -- ciphertext in the EncryptedData. "Keys" specifies a set of
1103 -- keys of which one key may be used to encrypt the data.
1104 -- "KeyUsages" specifies a set of key usages, one of which may
1105 -- be used to encrypt.
1107 -- None of the parameters is transmitted over the wire.
1109 Type, KeyToUse:Keys, KeyUsage:KeyUsages
1112 kvno [1] UInt32 OPTIONAL,
1113 cipher [2] OCTET STRING (CONSTRAINED BY {
1114 -- must be encryption of --
1115 OCTET STRING (CONTAINING Type),
1116 -- with one of the keys -- KeyToUse:Keys,
1117 -- with key usage being one of --
1127 Advisory parameter indicating which key usage to use when
1128 encrypting the ciphertext. If "KeyUsages" indicate multiple
1129 "KeyUsage" values, the detailed description of the containing
1130 message will indicate which key to use under which conditions.
1134 Advisory parameter indicating the ASN.1 type whose DER encoding
1135 is the plaintext encrypted into the EncryptedData.
1139 Advisory parameter indicating which key to use to perform the
1140 encryption. If "Keys" indicate multiple "KeyToUse" values, the
1141 detailed description of the containing message will indicate
1142 which key to use under which conditions.
1146 Advisory parameter indicating which "KeyUsage" value is used to
1147 encrypt. If "KeyUsages" indicates multiple "KeyUsage" values,
1148 the detailed description of the containing message will indicate
1149 which key usage to use under which conditions.
1155 Several types contain checksums (actually signatures) of data.
1159 Yu Expires: Jan 2005 [Page 18]
1160 Internet-Draft yu-krb-extensions-01 19 Jul 2004
1166 -- The parameters specify which key to use to produce the
1167 -- signature, as well as which key usage to use. The
1168 -- parameters are not actually sent over the wire.
1170 KeyToUse:Keys, KeyUsage:KeyUsages
1172 cksumtype [0] CksumType,
1173 checksum [1] OCTET STRING (CONSTRAINED BY {
1174 -- signed using one of the keys --
1176 -- with key usage being one of --
1184 Integer type for assigned numbers for signature algorithms.
1185 Defined in [KCRYPTO]
1197 Signature algorithm used to produce the signature.
1201 The actual checksum.
1207 ChecksumOf is like "Checksum", but specifies which type is signed.
1210 -- a Checksum that must contain the checksum
1211 -- of a particular type
1213 Type, KeyToUse:Keys, KeyUsage:KeyUsages
1214 } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
1216 checksum (CONSTRAINED BY {
1217 -- must be checksum of --
1218 OCTET STRING (CONTAINING Type)
1225 Yu Expires: Jan 2005 [Page 19]
1226 Internet-Draft yu-krb-extensions-01 19 Jul 2004
1230 Indicates the ASN.1 type whose DER encoding is signed.
1236 Signed is like "ChecksumOf", but contains an actual instance of the
1237 type being signed in addition to the signature.
1240 -- parameterized type for wrapping authenticated plaintext
1242 InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
1244 cksum [0] ChecksumOf {
1245 InnerType, Keys, KeyUsages
1247 inner [1] InnerType,
1256 [ A large number of items described here are duplicated in the
1257 sections describing KDC-REQ processing. Should find a way to avoid
1261 A ticket binds a principal name to a session key. The important
1262 fields of a ticket are in the encrypted part. The components in
1263 common between the RFC 1510 and the extensible versions are
1266 EncTicketPartCommon ::= SEQUENCE {
1267 flags [0] TicketFlags,
1268 key [1] EncryptionKey,
1270 cname [3] PrincipalName,
1271 transited [4] TransitedEncoding,
1272 authtime [5] KerberosTime,
1273 starttime [6] KerberosTime OPTIONAL,
1274 endtime [7] KerberosTime,
1275 renew-till [8] KerberosTime OPTIONAL,
1276 caddr [9] HostAddresses OPTIONAL,
1277 authorization-data [10] AuthorizationData OPTIONAL,
1284 This field contains the client's realm.
1288 This field contains the client's name.
1291 Yu Expires: Jan 2005 [Page 20]
1292 Internet-Draft yu-krb-extensions-01 19 Jul 2004
1296 This field lists the network addresses (if absent, all addresses
1297 are permitted) from which the ticket is valid.
1300 Descriptions of the other fields appear in the following sections.
1306 Three of the ticket timestamps may be requested from the KDC. The
1307 timestamps may differ from those requested, depending on site policy.
1311 The time at which the client authenticated, as recorded by the
1316 The earliest time when the ticket is valid. If not present, the
1317 ticket is valid starting at the authtime. This is requested as
1318 the "from" field of KDC-REQ-BODY-COMMON.
1322 This time is requested in the "till" field of KDC-REQ-BODY-
1323 COMMON. Contains the time after which the ticket will not be
1324 honored (its expiration time). Note that individual services
1325 MAY place their own limits on the life of a ticket and MAY
1326 reject tickets which have not yet expired. As such, this is
1327 really an upper bound on the expiration time for the ticket.
1331 This time is requested in the "rtime" field of KDC-REQ-BODY-
1332 COMMON. It is only present in tickets that have the "renewable"
1333 flag set in the flags field. It indicates the maximum endtime
1334 that may be included in a renewal. It can be thought of as the
1335 absolute expiration time for the ticket, including all renewals.
1341 A number of flags may be set in the ticket, further defining some of
1342 its capabilities. Some of these flags map to flags in a KDC request.
1357 Yu Expires: Jan 2005 [Page 21]
1358 Internet-Draft yu-krb-extensions-01 19 Jul 2004
1361 TicketFlags ::= KerberosFlags { TicketFlagsBits }
1364 TicketFlagsBits ::= BIT STRING {
1377 transited-policy-checked (12),
1378 ok-as-delegate (13),
1380 cksummed-ticket (15)
1385 9.2.1. Flags Relating to Initial Ticket Acquisition
1388 [ adapted KCLAR 2.1. ]
1391 Several flags indicate the details of how the initial ticket was
1396 The "initial" flag indicates that a ticket was issued using the
1397 AS protocol, rather than issued based on a ticket-granting
1398 ticket. Application servers (e.g., a password-changing program)
1399 requiring a client's definite knowledge of its secret key can
1400 insist that this flag be set in any tickets they accept, thus
1401 being assured that the client's key was recently presented to
1402 the application client.
1406 The "pre-authent" flag indicates that some sort of pre-
1407 authentication was used during the AS exchange.
1411 The "hw-authent" flag indicates that some sort of hardware-based
1412 pre-authentication occurred during the AS exchange.
1415 Both the "pre-authent" and the "hw-authent" flags may be present with
1416 or without the "initial" flag; such tickets with the "initial" flag
1417 clear are ones which are derived from initial tickets with the "pre-
1418 authent" or "hw-authent" flags set.
1422 Yu Expires: Jan 2005 [Page 22]
1423 Internet-Draft yu-krb-extensions-01 19 Jul 2004
1426 9.2.2. Invalid Tickets
1432 The "invalid" flag indicates that a ticket is invalid. Application
1433 servers MUST reject tickets which have this flag set. A postdated
1434 ticket will be issued in this form. Invalid tickets MUST be
1435 validated by the KDC before use, by presenting them to the KDC in a
1436 TGS request with the "validate" option specified. The KDC will only
1437 validate tickets after their starttime has passed. The validation is
1438 required so that postdated tickets which have been stolen before
1439 their starttime can be rendered permanently invalid (through a hot-
1440 list mechanism -- see Section 10.3.2.4).
1443 9.2.3. OK as Delegate
1449 The "ok-as-delegate" flag provides a way for a KDC to communicate
1450 local realm policy to a client regarding whether the service for
1451 which the ticket is issued is trusted to accept delegated
1452 credentials. For some applications, a client may need to delegate
1453 credentials to a service to act on its behalf in contacting other
1454 services. The ability of a client to obtain a service ticket for a
1455 service conveys no information to the client about whether the
1456 service should be trusted to accept delegated credentials.
1459 The copy of the ticket flags visible to the client may have the "ok-
1460 as-delegate" flag set to indicate to the client that the service
1461 specified in the ticket has been determined by policy of the realm to
1462 be a suitable recipient of delegation. A client can use the presence
1463 of this flag to help it make a decision whether to delegate
1464 credentials (either grant a proxy or a forwarded ticket-granting
1465 ticket) to this service. It is acceptable to ignore the value of
1466 this flag. When setting this flag, an administrator should consider
1467 the security and placement of the server on which the service will
1468 run, as well as whether the service requires the use of delegated
1472 9.3. Renewable Tickets
1475 [ adapted KCLAR 2.3. ]
1478 The "renewable" flag indicates whether the ticket may be renewed.
1481 Renewable tickets can be used to mitigate the consequences of ticket
1482 theft. Applications may desire to hold credentials which can be
1483 valid for long periods of time. However, this can expose the
1484 credentials to potential theft for equally long periods, and those
1485 stolen credentials would be valid until the expiration time of the
1486 ticket(s). Simply using short-lived tickets and obtaining new ones
1489 Yu Expires: Jan 2005 [Page 23]
1490 Internet-Draft yu-krb-extensions-01 19 Jul 2004
1493 periodically would require the application to have long-term access
1494 to the client's secret key, which is an even greater risk.
1497 Renewable tickets have two "expiration times": the first is when the
1498 current instance of the ticket expires, and the second is the latest
1499 permissible value for an individual expiration time. An application
1500 client must periodically present an unexpired renewable ticket to the
1501 KDC, setting the "renew" option in the KDC request. The KDC will
1502 issue a new ticket with a new session key and a later expiration
1503 time. All other fields of the ticket are left unmodified by the
1504 renewal process. When the latest permissible expiration time
1505 arrives, the ticket expires permanently. At each renewal, the KDC
1506 MAY consult a hot-list to determine if the ticket had been reported
1507 stolen since its last renewal; it will refuse to renew such stolen
1508 tickets, and thus the usable lifetime of stolen tickets is reduced.
1511 The "renewable" flag in a ticket is normally only interpreted by the
1512 ticket-granting service. It can usually be ignored by application
1513 servers. However, some particularly careful application servers MAY
1514 disallow renewable tickets.
1517 If a renewable ticket is not renewed by its expiration time, the KDC
1518 will not renew the ticket. The "renewable" flag is clear by default,
1519 but a client can request it be set by setting the "renewable" option
1520 in the AS-REQ message. If it is set, then the "renew-till" field in
1521 the ticket contains the time after which the ticket may not be
1525 9.4. Postdated Tickets
1529 indicates a ticket which has been postdated
1533 indicates that postdated tickets may be issued based on this
1540 Applications may occasionally need to obtain tickets for use much
1541 later, e.g., a batch submission system would need tickets to be valid
1542 at the time the batch job is serviced. However, it is dangerous to
1543 hold valid tickets in a batch queue, since they will be on-line
1544 longer and more prone to theft. Postdated tickets provide a way to
1545 obtain these tickets from the KDC at job submission time, but to
1546 leave them "dormant" until they are activated and validated by a
1547 further request of the KDC. If a ticket theft were reported in the
1548 interim, the KDC would refuse to validate the ticket, and the thief
1554 Yu Expires: Jan 2005 [Page 24]
1555 Internet-Draft yu-krb-extensions-01 19 Jul 2004
1558 The "may-postdate" flag in a ticket is normally only interpreted by
1559 the TGS. It can be ignored by application servers. This flag MUST
1560 be set in a ticket-granting ticket in order for the KDC to issue a
1561 postdated ticket based on the presented ticket. It is reset by
1562 default; it MAY be requested by a client by setting the "allow-
1563 postdate" option in the AS-REQ [?also TGS-REQ?] message. This flag
1564 does not allow a client to obtain a postdated ticket-granting ticket;
1565 postdated ticket-granting tickets can only by obtained by requesting
1566 the postdating in the AS-REQ message. The life (endtime minus
1567 starttime) of a postdated ticket will be the remaining life of the
1568 ticket-granting ticket at the time of the request, unless the
1569 "renewable" option is also set, in which case it can be the full life
1570 (endtime minus starttime) of the ticket-granting ticket. The KDC MAY
1571 limit how far in the future a ticket may be postdated.
1574 The "postdated" flag indicates that a ticket has been postdated. The
1575 application server can check the authtime field in the ticket to see
1576 when the original authentication occurred. Some services MAY choose
1577 to reject postdated tickets, or they may only accept them within a
1578 certain period after the original authentication. When the KDC
1579 issues a "postdated" ticket, it will also be marked as "invalid", so
1580 that the application client MUST present the ticket to the KDC for
1581 validation before use.
1584 9.5. Proxiable and Proxy Tickets
1588 indicates a proxy ticket
1592 indicates that proxy tickets may be issued based on this ticket
1598 It may be necessary for a principal to allow a service to perform an
1599 operation on its behalf. The service must be able to take on the
1600 identity of the client, but only for a particular purpose. A
1601 principal can allow a service to take on the principal's identity for
1602 a particular purpose by granting it a proxy.
1605 The process of granting a proxy using the "proxy" and "proxiable"
1606 flags is used to provide credentials for use with specific services.
1607 Though conceptually also a proxy, users wishing to delegate their
1608 identity in a form usable for all purposes MUST use the ticket
1609 forwarding mechanism described in the next section to forward a
1610 ticket-granting ticket.
1613 The "proxiable" flag in a ticket is normally only interpreted by the
1614 ticket-granting service. It can be ignored by application servers.
1615 When set, this flag tells the ticket-granting server that it is OK to
1616 issue a new ticket (but not a ticket-granting ticket) with a
1619 Yu Expires: Jan 2005 [Page 25]
1620 Internet-Draft yu-krb-extensions-01 19 Jul 2004
1623 different network address based on this ticket. This flag is set if
1624 requested by the client on initial authentication. By default, the
1625 client will request that it be set when requesting a ticket-granting
1626 ticket, and reset when requesting any other ticket.
1629 This flag allows a client to pass a proxy to a server to perform a
1630 remote request on its behalf (e.g. a print service client can give
1631 the print server a proxy to access the client's files on a particular
1632 file server in order to satisfy a print request).
1635 In order to complicate the use of stolen credentials, Kerberos
1636 tickets may contain a set of network addresses from which they are
1637 valid. When granting a proxy, the client MUST specify the new
1638 network address from which the proxy is to be used, or indicate that
1639 the proxy is to be issued for use from any address.
1642 The "proxy" flag is set in a ticket by the TGS when it issues a proxy
1643 ticket. Application servers MAY check this flag and at their option
1644 they MAY require additional authentication from the agent presenting
1645 the proxy in order to provide an audit trail.
1648 9.6. Forwardable Tickets
1652 indicates a forwarded ticket
1656 indicates that forwarded tickets may be issued based on this
1663 Authentication forwarding is an instance of a proxy where the service
1664 that is granted is complete use of the client's identity. An example
1665 where it might be used is when a user logs in to a remote system and
1666 wants authentication to work from that system as if the login were
1670 The "forwardable" flag in a ticket is normally only interpreted by
1671 the ticket-granting service. It can be ignored by application
1672 servers. The "forwardable" flag has an interpretation similar to
1673 that of the "proxiable" flag, except ticket-granting tickets may also
1674 be issued with different network addresses. This flag is reset by
1675 default, but users MAY request that it be set by setting the
1676 "forwardable" option in the AS request when they request their
1677 initial ticket-granting ticket.
1680 This flag allows for authentication forwarding without requiring the
1681 user to enter a password again. If the flag is not set, then
1682 authentication forwarding is not permitted, but the same result can
1683 still be achieved if the user engages in the AS exchange specifying
1686 Yu Expires: Jan 2005 [Page 26]
1687 Internet-Draft yu-krb-extensions-01 19 Jul 2004
1690 the requested network addresses and supplies a password.
1693 The "forwarded" flag is set by the TGS when a client presents a
1694 ticket with the "forwardable" flag set and requests a forwarded
1695 ticket by specifying the "forwarded" KDC option and supplying a set
1696 of addresses for the new ticket. It is also set in all tickets
1697 issued based on tickets with the "forwarded" flag set. Application
1698 servers may choose to process "forwarded" tickets differently than
1699 non-forwarded tickets.
1702 If addressless tickets are forwarded from one system to another,
1703 clients SHOULD still use this option to obtain a new TGT in order to
1704 have different session keys on the different systems.
1707 9.7. Transited Realms
1710 [ KCLAR 2.7., plus new stuff ]
1713 9.8. Authorization Data
1716 9.9. Encrypted Part of Ticket
1719 The complete definition of the encrypted part is
1722 -- Encrypted part of ticket
1723 EncTicketPart ::= CHOICE {
1724 rfc1510 [APPLICATION 3] EncTicketPart1510,
1725 ext [APPLICATION 5] EncTicketPartExt
1730 EncTicketPart1510 ::= SEQUENCE {
1731 COMPONENTS OF EncTicketPartCommon
1732 } (WITH COMPONENTS {
1734 -- explicitly force IA5 in strings
1736 cname (PrincipalNameIA5)
1741 EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS {
1743 -- explicitly force UTF-8 in strings
1745 cname (PrincipalNameExt),
1746 -- explicitly constrain caddr to be non-empty if present
1747 caddr (SIZE (1..MAX)),
1748 -- forbid empty authorization-data encodings
1749 authorization-data (SIZE (1..MAX))
1753 Yu Expires: Jan 2005 [Page 27]
1754 Internet-Draft yu-krb-extensions-01 19 Jul 2004
1757 9.10. Cleartext Part of Ticket
1761 rfc1510 [APPLICATION 1] Ticket1510,
1762 ext [APPLICATION 4] Signed {
1763 TicketExt, { key-server }, { ku-Ticket-cksum }
1769 -- takes a parameter specifying which type gets encrypted
1770 TicketCommon { EncPart } ::= SEQUENCE {
1771 tkt-vno [0] INTEGER (5),
1773 sname [2] PrincipalName,
1774 enc-part [3] EncryptedData {
1775 EncPart, { key-server }, { ku-Ticket }
1778 extensions [4] TicketExtensions OPTIONAL,
1784 Ticket1510 ::= SEQUENCE {
1785 COMPONENTS OF TicketCommon { EncTicketPart1510 }
1786 } (WITH COMPONENTS {
1788 -- explicitly force IA5 in strings
1790 sname (PrincipalNameIA5)
1795 -- APPLICATION tag goes inside Signed{} as well as outside,
1796 -- to prevent possible substitution attacks.
1797 TicketExt ::= [APPLICATION 4] TicketCommon {
1799 } (WITH COMPONENTS {
1801 -- explicitly force UTF-8 in strings
1803 sname (PrincipalNameExt)
1808 10. Credential Acquisition
1811 There are two exchanges that can be used for acquiring credentials:
1812 the AS exchange and the TGS exchange. These exchanges have many
1813 similarities, and this document describes them in parallel, noting
1816 Yu Expires: Jan 2005 [Page 28]
1817 Internet-Draft yu-krb-extensions-01 19 Jul 2004
1820 which behaviors are specific to one type of exchange. The AS request
1821 (AS-REQ) and TGS request (TGS-REQ) are both forms of KDC requests
1822 (KDC-REQ). Likewise, the AS reply (AS-REP) and TGS reply (TGS-REP)
1823 are forms of KDC replies (KDC-REP).
1829 The KDC-REQ has a large number of fields in common between the RFC
1830 1510 and the extensible versions.
1833 KDC-REQ-COMMON ::= SEQUENCE {
1834 -- NOTE: first tag is [1], not [0]
1835 pvno [1] INTEGER (5),
1836 msg-type [2] INTEGER (10 -- AS-REQ.rfc1510 --
1837 | 12 -- TGS-REQ.rfc1510 --
1838 | 6 -- AS-REQ.ext --
1839 | 8 -- TGS-REQ.ext -- ),
1840 padata [3] SEQUENCE OF PA-DATA OPTIONAL
1876 Yu Expires: Jan 2005 [Page 29]
1877 Internet-Draft yu-krb-extensions-01 19 Jul 2004
1880 KDC-REQ-BODY-COMMON ::= SEQUENCE {
1881 kdc-options [0] KDCOptions,
1882 cname [1] PrincipalName OPTIONAL
1883 -- Used only in AS-REQ --,
1887 -- Server's realm; also client's in AS-REQ --,
1890 sname [3] PrincipalName OPTIONAL,
1891 from [4] KerberosTime OPTIONAL,
1892 till [5] KerberosTime OPTIONAL
1893 -- was required in rfc1510;
1894 -- still required for compat versions
1898 rtime [6] KerberosTime OPTIONAL,
1900 etype [8] SEQUENCE OF EType
1901 -- in preference order --,
1904 addresses [9] HostAddresses OPTIONAL,
1905 enc-authorization-data [10] EncryptedData {
1906 AuthorizationData, { key-session | key-subsession },
1907 { ku-TGSReqAuthData-subkey |
1908 ku-TGSReqAuthData-sesskey }
1912 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
1913 -- NOTE: not empty --,
1919 Many fields of KDC-REQ-BODY-COMMON correspond directly to fields of
1920 an EncTicketPartCommon. The KDC copies most of them unchanged,
1921 provided that their values meet site policy.
1925 These flags do not correspond directly to "flags" in
1926 EncTicketPartCommon.
1930 This field is copied to the "cname" field in
1931 EncTicketPartCommon. The "cname" field is required in an AS-
1932 REQ; the client places its own name here. In a TGS-REQ, the
1933 "cname" in the ticket in the AP-REQ takes precedence.
1937 This field is the server's realm, and also holds the client's
1942 Yu Expires: Jan 2005 [Page 30]
1943 Internet-Draft yu-krb-extensions-01 19 Jul 2004
1947 The "sname" field indicates the server's name. It may be absent
1948 in a TGS-REQ which requests user-to-user authentication, in
1949 which case the "sname" of the issued ticket will be taken from
1950 the included additional ticket.
1953 The "from", "till", and "rtime" fields correspond to the "starttime",
1954 "endtime", and "renew-till" fields of EncTicketPartCommon.
1958 This field corresponds to the "caddr" field of
1959 EncTicketPartCommon.
1962 enc-authorization-data
1963 For TGS-REQ, this field contains authorization data encrypted
1964 using either the TGT session key or the AP-REQ subsession key;
1965 the KDC may copy these into the "authorization-data" field of
1966 EncTicketPartCommon if policy permits.
1972 PA-DATA have multiple uses in the Kerberos protocol. They may pre-
1973 authenticate an AS-REQ; they may also modify several of the
1974 encryption keys used in a KDC-REP. PA-DATA may also provide "hints"
1975 to the client about which long-term key (usually password-derived) to
1976 use. PA-DATA may also include "hints" about which pre-authentication
1977 mechanisms to use, or include data for input into a pre-
1978 authentication mechanism.
1981 10.3. KDC-REQ Processing
1984 Processing of a KDC-REQ proceeds through several steps. An
1985 implementation need not perform these steps exactly as described, as
1986 long as it behaves as if the steps were performed as described. The
1987 KDC performs replay handling upon receiving the request; it then
1988 validates the request, adjusts timestamps, and selects the keys used
1989 in the reply. It copies data from the request into the issued
1990 ticket, adjusting the values to conform with its policies. The KDC
1991 then transmits the reply to the client.
1994 10.3.1. Handling Replays
1997 Because Kerberos can run over unreliable transports such as UDP, the
1998 KDC MUST be prepared to retransmit responses in case they are lost.
1999 If a KDC receives a request identical to one it has recently
2000 successfully processed, the KDC MUST respond with a KDC-REP message
2001 rather than a replay error. In order to reduce the amount of
2002 ciphertext given to a potential attacker, KDCs MAY send the same
2003 response generated when the request was first handled. KDCs MUST
2004 obey this replay behavior even if the actual transport in use is
2005 reliable. If the AP-REQ which authenticates a TGS-REQ is a replay,
2008 Yu Expires: Jan 2005 [Page 31]
2009 Internet-Draft yu-krb-extensions-01 19 Jul 2004
2012 and the entire request is not identical to a recently successfully
2013 processed request, the KDC SHOULD return "krb-ap-err-repeat", as is
2014 appropriate for AP-REQ processing.
2017 10.3.2. Request Validation
2020 10.3.2.1. AS-REQ Authentication
2023 Site policy determines whether a given client principal is required
2024 to provide some pre-authentication prior to receiving an AS-REP.
2025 Since the default reply key is typically the client's long-term
2026 password-based key, an attacker may easily request known plaintext
2027 (in the form of an AS-REP) upon which to mount a dictionary attack.
2028 Pre-authentication can limit the possibility of such an attack.
2031 If site policy requires pre-authentication for a client principal,
2032 and no pre-authentication is provided, the KDC returns the error
2033 "kdc-err-preauth-required". Accompanying this error are "e-data"
2034 which include hints telling the client which pre-authentication
2035 mechanisms to use, or data for input to pre-authentication mechanisms
2036 (e.g., input to challenge-response systems). If pre-authentication
2037 fails, the KDC returns the error "kdc-err-preauth-failed".
2040 [ may need additional changes based on Sam's preauth draft ]
2043 10.3.2.2. TGS-REQ Authentication
2046 A TGS-REQ has an accompanying AP-REQ, which is included in the "pa-
2047 tgs-req". The KDC MUST validate the checksum in the Authenticator of
2048 the AP-REQ, which is computed over the KDC-REQ-BODY-1510 or KDC-REQ-
2049 BODY-EXT (for TGS-REQ-1510 or TGS-REQ-EXT, respectively) of the
2050 request. [ padata not signed by authenticator! ] Any error from the
2051 AP-REQ validation process SHOULD be returned in a KRB-ERROR message.
2052 The service principal in the ticket of the AP-REQ may be a ticket-
2053 granting service principal, or a normal application service
2054 principal. A ticket which is not a ticket-granting ticket MUST NOT
2055 be used to issue a ticket for any service other than the one named in
2056 the ticket. In this case, the "renew", "validate", or "proxy" [?also
2057 forwarded?] option must be set in the request.
2060 10.3.2.3. Principal Validation
2063 If the client principal in an AS-REQ is unknown, the KDC returns the
2064 error "kdc-err-c-principal-unknown". If the server principal in a
2065 KDC-REQ is unknown, the KDC returns the error "kdc-err-s-principal-
2069 10.3.2.4. Checking For Revoked or Invalid Tickets
2076 Yu Expires: Jan 2005 [Page 32]
2077 Internet-Draft yu-krb-extensions-01 19 Jul 2004
2080 Whenever a request is made to the ticket-granting server, the
2081 presented ticket(s) is(are) checked against a hot-list of tickets
2082 which have been canceled. This hot-list might be implemented by
2083 storing a range of issue timestamps for "suspect tickets"; if a
2084 presented ticket had an authtime in that range, it would be rejected.
2085 In this way, a stolen ticket-granting ticket or renewable ticket
2086 cannot be used to gain additional tickets (renewals or otherwise)
2087 once the theft has been reported to the KDC for the realm in which
2088 the server resides. Any normal ticket obtained before it was
2089 reported stolen will still be valid (because they require no
2090 interaction with the KDC), but only until their normal expiration
2091 time. If TGTs have been issued for cross-realm authentication, use
2092 of the cross-realm TGT will not be affected unless the hot-list is
2093 propagated to the KDCs for the realms for which such cross-realm
2094 tickets were issued.
2097 If a TGS-REQ ticket has its "invalid" flag set, the KDC MUST NOT
2098 issue any ticket unless the TGS-REQ requests the "validate" option.
2101 10.3.3. Timestamp Handling
2104 [ some aspects of timestamp handling, especially regarding postdating
2105 and renewal, are difficult to read in KCLAR... needs closer
2109 Processing of "starttime" (requested in the "from" field) differs
2110 depending on whether the "postdated" option is set in the request.
2111 If the "postdated" option is not set, and the requested "starttime"
2112 is in the future beyond the window of acceptable clock skew, the KDC
2113 returns the error "kdc-err-cannot-postdate". If the "postdated"
2114 option is not set, and the requested "starttime" is absent or does
2115 not indicate a time in the future beyond the acceptable clock skew,
2116 the KDC sets the "starttime" to the KDC's current time. The
2117 "postdated" option MUST NOT be honored if the ticket is being
2118 requested by TGS-REQ and the "may-postdate" is not set in the TGT.
2119 Otherwise, if the "postdated" option is set, and site policy permits,
2120 the KDC sets the "starttime" as requested, and sets the "invalid"
2121 flag in the new ticket.
2124 The "till" field is required in the RFC 1510 version of the KDC-REQ.
2125 If the "till" field is equal to "19700101000000Z" (midnight, January
2126 1, 1970), the KDC SHOULD behave as if the "till" field were absent.
2129 The KDC MUST NOT issue a ticket whose "starttime", "endtime", or
2130 "renew-till" time is later than the "renew-till" time of the ticket
2131 from which it is derived.
2134 10.3.3.1. AS-REQ Timestamp Processing
2137 In the AS exchange, the "authtime" of a ticket is set to the local
2141 Yu Expires: Jan 2005 [Page 33]
2142 Internet-Draft yu-krb-extensions-01 19 Jul 2004
2145 The "endtime" of the ticket will be set to the earlier of the
2146 requested "till" time and a time determined by local policy, possibly
2147 determined using factors specific to the realm or principal. For
2148 example, the expiration time MAY be set to the earliest of the
2152 * the expiration time ("till" value) requested
2155 * the ticket's start time plus the maximum allowable lifetime
2156 associated with the client principal from the authentication
2160 * the ticket's start time plus the maximum allowable lifetime
2161 associated with the server principal
2164 * the ticket's start time plus the maximum lifetime set by the
2165 policy of the local realm
2168 If the requested expiration time minus the start time (as determined
2169 above) is less than a site-determined minimum lifetime, an error
2170 message with code "kdc-err-never-valid" is returned. If the
2171 requested expiration time for the ticket exceeds what was determined
2172 as above, and if the "renewable-ok" option was requested, then the
2173 "renewable" flag is set in the new ticket, and the "renew-till" value
2174 is set as if the "renewable" option were requested.
2177 If the "renewable" option has been requested or if the "renewable-ok"
2178 option has been set and a renewable ticket is to be issued, then the
2179 "renew-till" field MAY be set to the earliest of:
2182 * its requested value
2185 * the start time of the ticket plus the minimum of the two maximum
2186 renewable lifetimes associated with the principals' database
2190 * the start time of the ticket plus the maximum renewable lifetime
2191 set by the policy of the local realm
2194 10.3.3.2. TGS-REQ Timestamp Processing
2197 In the TGS exchange, the KDC sets the "authtime" to that of the
2198 ticket in the AP-REQ authenticating the TGS-REQ. [?application
2199 server can print a ticket for itself with a spoofed authtime.
2200 security issues for hot-list?] [ MIT implementation may change
2201 authtime of renewed tickets; needs check... ]
2204 If the TGS-REQ has a TGT as the ticket in its AP-REQ, and the TGS-REQ
2205 requests an "endtime" (in the "till" field), then the "endtime" of
2206 the new ticket is set to the minimum of
2210 Yu Expires: Jan 2005 [Page 34]
2211 Internet-Draft yu-krb-extensions-01 19 Jul 2004
2214 * the requested "endtime" value,
2217 * the "endtime" in the TGT, and
2220 * an "endtime" determined by site policy on ticket lifetimes.
2223 If the new ticket is a renewal, the "endtime" of the new ticket is
2224 bounded by the minimum of
2227 * the requested "endtime" value,
2230 * the value of the "renew-till" value of the old,
2233 * the "starttime" of the new ticket plus the lifetime (endtime
2234 minus starttime) of the old ticket, i.e., the lifetime of the
2235 new ticket may not exceed that of the ticket being renewed [
2236 adapted from KCLAR 3.3.3. ], and
2239 * an "endtime" determined by site policy on ticket lifetimes.
2242 When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with
2243 a "starttime", "endtime", or "renew-till" time later than the "renew-
2244 till" time of the TGT.
2247 10.3.4. Handling Transited Realms
2250 The KDC checks the ticket in a TGS-REQ against site policy, unless
2251 the "disable-transited-check" option is set in the TGS-REQ. If site
2252 policy permits the transit path in the TGS-REQ ticket, the KDC sets
2253 the "transited-policy-checked" flag in the issued ticket. If the
2254 "disable-transited-check" option is set, the issued ticket will have
2255 the "transited-policy-checked" flag cleared.
2258 10.3.5. Address Processing The requested "addresses" in the KDC-REQ are
2259 copied into the issued ticket. If the "addresses" field is absent or
2260 empty in a TGS-REQ, the KDC copies addresses from the ticket in the
2261 TGS-REQ into the issued ticket, unless the either "forwarded" or
2262 "proxy" option is set. If the "forwarded" option is set, and the
2263 ticket in the TGS-REQ has its "forwardable" flag set, the KDC copies
2264 the addresses from the TGS-REQ, not the from TGS-REQ ticket, into the
2265 issued ticket. The KDC behaves similarly if the "proxy" option is
2266 set in the TGS-REQ and the "proxiable" flag is set in the ticket.
2267 The "proxy" option will not be honored on requests for additional
2268 ticket-granting tickets.
2271 10.3.6. Ticket Flag Processing
2274 Many kdc-options request that the KDC set a corresponding flag in the
2275 issued ticket. kdc-options marked with an asterisk (*) in the
2276 following table do not directly request the corresponding ticket flag
2277 and therefore require special handling.
2280 Yu Expires: Jan 2005 [Page 35]
2281 Internet-Draft yu-krb-extensions-01 19 Jul 2004
2283 kdc-option | ticket flag affected
2284 -------------------------+--------------------------
2285 forwardable | forwardable
2286 forwarded | forwarded
2287 proxiable | proxiable
2289 allow-postdate | may-postdate
2290 postdated | postdated
2291 renewable | renewable
2292 requestanonymous | anonymous
2294 disable-transited-check* | transited-policy-checked
2295 renewable-ok* | renewable
2303 The KDC sets the "forwarded" flag in the issued ticket if the
2304 "forwarded" option is set in the TGS-REQ and the "forwardable"
2305 flag is set in the TGS-REQ ticket.
2309 The KDC sets the "proxy" flag in the issued ticket if the
2310 "proxy" option is set in the TGS-REQ and the "proxiable" flag is
2311 set in the TGS-REQ ticket.
2314 disable-transited-check
2315 The handling of the "disable-transited-check" kdc-option is
2316 described in Section 10.3.4.
2320 The handling of the "renewable-ok" kdc-option is described in
2325 If the "validate" kdc-option is set in a TGS-REQ, and the
2326 "starttime" has passed, the KDC will clear the "invalid" bit on
2327 the ticket before re-issuing it.
2330 10.3.7. Key Selection
2333 Three keys are involved in creating a KDC-REP. The reply key
2334 encrypts the encrypted part of the KDC-REP. The session key is
2335 stored in the encrypted part of the ticket, and is also present in
2336 the encrypted part of the KDC-REP so that the client can retrieve it.
2337 The ticket key is used to encrypt the ticket. These keys all have
2338 initial values for a given exchange; pre-authentication and other
2339 extension mechanisms may change the value used for any of these keys.
2343 Yu Expires: Jan 2005 [Page 36]
2344 Internet-Draft yu-krb-extensions-01 19 Jul 2004
2347 [ again, may need changes based on Sam's preauth draft ]
2350 10.3.7.1. Reply Key and Session Key Selection
2353 The set of encryption types which the client will understand appears
2354 in the "etype" field of KDC-REQ-BODY-COMMON. The KDC limits the set
2355 of possible reply keys and the set of session key encryption types
2356 based on the "etype" field.
2359 For the AS exchange, the reply key is initially a long-term key of
2360 the client, limited to those encryption types listed in the "etype"
2361 field. The KDC SHOULD use the first valid strong "etype" for which
2362 an encryption key is available. For the TGS exchange, the reply key
2363 is initially the subsession key of the Authenticator. If the
2364 Authenticator subsesion key is absent, the reply key is initially the
2365 session key of the ticket used to authenticate the TGS-REQ.
2368 The session key is initially randomly generated, and has an
2369 encryption type which both the client and the server will understand.
2370 Typically, the KDC has prior knowledge of which encryption types the
2371 server will understand. It selects the first valid strong "etype"
2372 listed the request which the server also will understand.
2375 10.3.7.2. Ticket Key Selection
2378 The ticket key is initially the long-term key of the service. The
2379 "enc-tkt-in-skey" option requests user-to-user authentication, where
2380 the ticket encryption key of the issued ticket is set equal to the
2381 session key of the additional ticket in the request.
2384 10.4. Reply Validation
2387 11. Session Key Exchange
2390 Session key exchange consists of the AP-REQ and AP-REP messages. The
2391 client sends the AP-REQ message, and the service responds with an AP-
2392 REP message if mutual authentication is desired. Following session
2393 key exchange, the client and service share a secret session key, or
2394 possibly a subsesion key, which can be used to protect further
2395 communications. Additionally, the session key exchange process can
2396 establish initial sequence numbers which the client and service can
2397 use to detect replayed messages.
2403 An AP-REQ message contains a ticket and a authenticator. The
2404 authenticator is ciphertext encrypted with the session key contained
2405 in the ticket. The plaintext contents of the authenticator are:
2411 Yu Expires: Jan 2005 [Page 37]
2412 Internet-Draft yu-krb-extensions-01 19 Jul 2004
2415 -- plaintext of authenticator
2416 Authenticator ::= [APPLICATION 2] SEQUENCE {
2417 authenticator-vno [0] INTEGER (5),
2419 cname [2] PrincipalName,
2420 cksum [3] Checksum {{ key-session },
2421 { ku-Authenticator-cksum |
2422 ku-pa-TGSReq-cksum }} OPTIONAL,
2423 cusec [4] Microseconds,
2424 ctime [5] KerberosTime,
2425 subkey [6] EncryptionKey OPTIONAL,
2426 seq-number [7] SeqNum OPTIONAL,
2427 authorization-data [8] AuthorizationData OPTIONAL
2431 The common parts between the RFC 1510 and the extensible versions of
2435 AP-REQ-COMMON ::= SEQUENCE {
2436 pvno [0] INTEGER (5),
2437 msg-type [1] INTEGER (14 | 18),
2438 ap-options [2] APOptions,
2440 authenticator [4] EncryptedData {
2443 { ku-APReq-authenticator |
2444 ku-pa-TGSReq-authenticator }
2447 extensions [5] ApReqExtensions OPTIONAL,
2452 The complete definition of AP-REQ is:
2456 rfc1510 [APPLICATION 14] AP-REQ-1510,
2457 ext [APPLICATION 18] Signed {
2458 AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
2472 Yu Expires: Jan 2005 [Page 38]
2473 Internet-Draft yu-krb-extensions-01 19 Jul 2004
2476 AP-REQ-COMMON ::= SEQUENCE {
2477 pvno [0] INTEGER (5),
2478 msg-type [1] INTEGER (14 | 18),
2479 ap-options [2] APOptions,
2481 authenticator [4] EncryptedData {
2484 { ku-APReq-authenticator |
2485 ku-pa-TGSReq-authenticator }
2488 extensions [5] ApReqExtensions OPTIONAL,
2494 AP-REQ-1510 ::= SEQUENCE {
2495 COMPONENTS OF AP-REQ-COMMON
2496 } (WITH COMPONENTS {
2499 authenticator (EncryptedData {
2500 Authenticator (WITH COMPONENTS {
2503 cname (PrincipalNameIA5),
2505 }), { key-session }, { ku-APReq-authenticator }})
2510 AP-REQ-EXT ::= AP-REQ-COMMON
2514 -- The following constraints on Authenticator assume that
2515 -- we want to restrict the use of AP-REQ-EXT with TicketExt
2516 -- only, since that is the only way we can enforce UTF-8.
2517 authenticator (EncryptedData {
2518 Authenticator (WITH COMPONENTS {
2521 cname (PrincipalNameExt),
2522 authorization-data (SIZE (1..MAX))
2523 }), { key-session }, { ku-APReq-authenticator }})
2531 Yu Expires: Jan 2005 [Page 39]
2532 Internet-Draft yu-krb-extensions-01 19 Jul 2004
2535 APOptions ::= KerberosFlags { APOptionsBits }
2538 APOptionsBits ::= BIT STRING {
2540 use-session-key (1),
2549 EncAPRepPart ::= CHOICE {
2550 rfc1510 [APPLICATION 27] EncAPRepPart1510,
2551 ext [APPLICATION 31] EncAPRepPartExt
2556 EncAPRepPartCom ::= SEQUENCE {
2557 ctime [0] KerberosTime,
2558 cusec [1] Microseconds,
2559 subkey [2] EncryptionKey OPTIONAL,
2560 seq-number [3] SeqNum OPTIONAL,
2562 authorization-data [4] AuthorizationData OPTIONAL,
2568 EncAPRepPart1510 ::= SEQUENCE {
2569 COMPONENTS OF ENCAPRepPartCom
2570 } (WITH COMPONENTS {
2572 seq-number (UInt32),
2573 authorization-data ABSENT
2578 EncAPRepPartExt ::= EncAPRepPartCom
2583 rfc1510 [APPLICATION 15] AP-REP-1510,
2584 ext [APPLICATION 19] Signed {
2586 { key-session | key-subsession }, { ku-APRep-cksum }}
2595 Yu Expires: Jan 2005 [Page 40]
2596 Internet-Draft yu-krb-extensions-01 19 Jul 2004
2599 AP-REP-COMMON { EncPart } ::= SEQUENCE {
2600 pvno [0] INTEGER (5),
2601 msg-type [1] INTEGER (15 | 19),
2602 enc-part [2] EncryptedData {
2604 { key-session | key-subsession }, { ku-EncAPRepPart }},
2606 extensions [3] ApRepExtensions OPTIONAL,
2612 AP-REP-1510 ::= SEQUENCE {
2613 COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
2614 } (WITH COMPONENTS {
2621 AP-REP-EXT ::= [APPLICATION 19] AP-REP-COMMON {
2623 } (WITH COMPONENTS { ..., msg-type (19) })
2633 -- Do we chew up another tag for KRB-SAFE-EXT? That would
2634 -- allow us to make safe-body optional, allowing for a GSS-MIC
2636 KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
2637 pvno [0] INTEGER (5),
2638 msg-type [1] INTEGER (20),
2639 safe-body [2] KRB-SAFE-BODY,
2640 cksum [3] ChecksumOf {
2642 { key-session | key-subsession }, { ku-KrbSafe-cksum }},
2643 ... -- ASN.1 extensions must be excluded
2644 -- when sending to rfc1510 implementations
2657 Yu Expires: Jan 2005 [Page 41]
2658 Internet-Draft yu-krb-extensions-01 19 Jul 2004
2661 KRB-SAFE-BODY ::= SEQUENCE {
2662 user-data [0] OCTET STRING,
2663 timestamp [1] KerberosTime OPTIONAL,
2664 usec [2] Microseconds OPTIONAL,
2665 seq-number [3] SeqNum OPTIONAL,
2666 s-address [4] HostAddress,
2667 r-address [5] HostAddress OPTIONAL,
2668 ... -- ASN.1 extensions must be excluded
2669 -- when sending to rfc1510 implementations
2677 KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
2678 pvno [0] INTEGER (5),
2679 msg-type [1] INTEGER (21),
2680 enc-part [3] EncryptedData {
2682 { key-session | key-subsession }, { ku-EncKrbPrivPart }},
2688 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
2689 user-data [0] OCTET STRING,
2690 timestamp [1] KerberosTime OPTIONAL,
2691 usec [2] Microseconds OPTIONAL,
2692 seq-number [3] SeqNum OPTIONAL,
2693 s-address [4] HostAddress -- sender's addr --,
2694 r-address [5] HostAddress OPTIONAL -- recip's addr --,
2695 ... -- ASN.1 extensions must be excluded
2696 -- when sending to rfc1510 implementations
2704 KRB-CRED ::= CHOICE {
2705 rfc1510 [APPLICATION 22] KRB-CRED-1510,
2706 ext [APPLICATION 24] Signed {
2708 { key-session | key-subsession }, { ku-KrbCred-cksum }}
2719 Yu Expires: Jan 2005 [Page 42]
2720 Internet-Draft yu-krb-extensions-01 19 Jul 2004
2723 KRB-CRED-COMMON ::= SEQUENCE {
2724 pvno [0] INTEGER (5),
2725 msg-type [1] INTEGER (22 | 24),
2726 tickets [2] SEQUENCE OF Ticket,
2727 enc-part [3] EncryptedData {
2729 { key-session | key-subsession }, { ku-EncKrbCredPart }},
2735 KRB-CRED-1510 ::= SEQUENCE {
2736 COMPONENTS OF KRB-CRED-COMMON
2737 } (WITH COMPONENTS { ..., msg-type (22) })
2741 KRB-CRED-EXT ::= [APPLICATION 24] KRB-CRED-COMMON
2742 (WITH COMPONENTS { ..., msg-type (24) })
2746 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
2747 ticket-info [0] SEQUENCE OF KrbCredInfo,
2748 nonce [1] Nonce OPTIONAL,
2749 timestamp [2] KerberosTime OPTIONAL,
2750 usec [3] Microseconds OPTIONAL,
2751 s-address [4] HostAddress OPTIONAL,
2752 r-address [5] HostAddress OPTIONAL
2757 KrbCredInfo ::= SEQUENCE {
2758 key [0] EncryptionKey,
2759 prealm [1] Realm OPTIONAL,
2760 pname [2] PrincipalName OPTIONAL,
2761 flags [3] TicketFlags OPTIONAL,
2762 authtime [4] KerberosTime OPTIONAL,
2763 starttime [5] KerberosTime OPTIONAL,
2764 endtime [6] KerberosTime OPTIONAL,
2765 renew-till [7] KerberosTime OPTIONAL,
2766 srealm [8] Realm OPTIONAL,
2767 sname [9] PrincipalName OPTIONAL,
2768 caddr [10] HostAddresses OPTIONAL
2773 13. Security Considerations
2776 13.1. Time Synchronization
2779 Time synchronization between the KDC and application servers is
2780 necessary to prevent acceptance of expired tickets.
2783 Yu Expires: Jan 2005 [Page 43]
2784 Internet-Draft yu-krb-extensions-01 19 Jul 2004
2787 Time synchronization is needed between application servers and
2788 clients to prevent replay attacks if a replay cache is being used.
2789 If negotiated subsession keys are used to encrypt application data,
2790 replay caches may not be necessary.
2796 13.3. Principal Name Reuse
2802 13.4. Password Guessing
2805 13.5. Forward Secrecy
2808 [from KCLAR 10.; needs some rewriting]
2811 The Kerberos protocol in its basic form does not provide perfect
2812 forward secrecy for communications. If traffic has been recorded by
2813 an eavesdropper, then messages encrypted using the KRB-PRIV message,
2814 or messages encrypted using application-specific encryption under
2815 keys exchanged using Kerberos can be decrypted if any of the user's,
2816 application server's, or KDC's key is subsequently discovered. This
2817 is because the session key used to encrypt such messages is
2818 transmitted over the network encrypted in the key of the application
2819 server, and also encrypted under the session key from the user's
2820 ticket-granting ticket when returned to the user in the TGS-REP
2821 message. The session key from the ticket-granting ticket was sent to
2822 the user in the AS-REP message encrypted in the user's secret key,
2823 and embedded in the ticket-granting ticket, which was encrypted in
2824 the key of the KDC. Application requiring perfect forward secrecy
2825 must exchange keys through mechanisms that provide such assurance,
2826 but may use Kerberos for authentication of the encrypted channel
2827 established through such other means.
2833 As an authentication service, Kerberos provides a means of verifying
2834 the identity of principals on a network. Kerberos does not, by
2835 itself, provide authorization. Applications SHOULD NOT accept the
2836 mere issuance of a service ticket by the Kerberos server as granting
2837 authority to use the service.
2840 13.7. Login Authentication
2843 Some applications, particularly those which provide login access when
2844 provided with a password, SHOULD NOT treat successful acquisition of
2845 credentials as sufficient proof of the user's identity. An attacker
2846 posing as a user could generate an illegitimate KDC-REP message which
2847 decrypts properly. To authenticate a user logging on to a local
2848 system, the credentials obtained SHOULD be used in a TGS exchange to
2851 Yu Expires: Jan 2005 [Page 44]
2852 Internet-Draft yu-krb-extensions-01 19 Jul 2004
2855 obtain credentials for a local service. Successful use of those
2856 credentials to authenticate to the local service assures that the
2857 initially obtained credentials are from a valid KDC.
2863 Some stuff lifted from draft-ietf-krb-wg-kerberos-clarifications-06.
2869 A. ASN.1 Module (Normative)
2873 iso(1) identified-organization(3) dod(6) internet(1)
2874 security(5) kerberosV5(2) modules(4) krb5spec3(4)
2875 } DEFINITIONS EXPLICIT TAGS ::= BEGIN
2879 -- OID arc for KerberosV5
2881 -- This OID may be used to identify Kerberos protocol messages
2882 -- encapsulated in other protocols.
2884 -- This OID also designates the OID arc for KerberosV5-related
2887 -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its
2889 id-krb5 OBJECT IDENTIFIER ::= {
2890 iso(1) identified-organization(3) dod(6) internet(1)
2891 security(5) kerberosV5(2)
2914 Yu Expires: Jan 2005 [Page 45]
2915 Internet-Draft yu-krb-extensions-01 19 Jul 2004
2920 -- Applications should not directly reference any types
2921 -- other than KRB-PDU and its component types.
2923 KRB-PDU ::= CHOICE {
2935 krb-error KRB-ERROR,
2947 -- signed values representable in 32 bits
2949 -- These are often used as assigned numbers for various things.
2950 Int32 ::= INTEGER (-2147483648..2147483647)
2953 -- unsigned 32 bit values
2954 UInt32 ::= INTEGER (0..4294967295)
2958 -- unsigned 64 bit values
2959 UInt64 ::= INTEGER (0..18446744073709551615)
2964 Microseconds ::= INTEGER (0..999999)
2978 Yu Expires: Jan 2005 [Page 46]
2979 Internet-Draft yu-krb-extensions-01 19 Jul 2004
2982 -- must not have fractional seconds
2983 KerberosTime ::= GeneralizedTime
2987 -- used for names and for error messages
2988 KerberosString ::= CHOICE {
2989 ia5 GeneralString (IA5String),
2991 ... -- no extension may be sent
2992 -- to an rfc1510 implementation --
2997 -- IA5 choice only; useful for constraints
2998 KerberosStringIA5 ::= KerberosString
2999 (WITH COMPONENTS { ia5 PRESENT })
3002 -- IA5 excluded; useful for constraints
3003 KerberosStringExt ::= KerberosString
3004 (WITH COMPONENTS { ia5 ABSENT })
3008 -- used for language tags
3009 LangTag ::= PrintableString
3010 (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
3014 -- assigned numbers for name types (used in principal names)
3018 -- Name type not known
3019 nt-unknown NameType ::= 0
3020 -- Just the name of the principal as in DCE, or for users
3021 nt-principal NameType ::= 1
3022 -- Service and other unique instance (krbtgt)
3023 nt-srv-inst NameType ::= 2
3024 -- Service with host name as instance (telnet, rcommands)
3025 nt-srv-hst NameType ::= 3
3026 -- Service with host as remaining components
3027 nt-srv-xhst NameType ::= 4
3029 nt-uid NameType ::= 5
3030 -- Encoded X.509 Distingished name [RFC 2253]
3031 nt-x500-principal NameType ::= 6
3032 -- Name in form of SMTP email name (e.g. user@foo.com)
3033 nt-smtp-name NameType ::= 7
3034 -- Enterprise name - may be mapped to principal name
3035 nt-enterprise NameType ::= 10
3041 Yu Expires: Jan 2005 [Page 47]
3042 Internet-Draft yu-krb-extensions-01 19 Jul 2004
3045 PrincipalName ::= SEQUENCE {
3046 name-type [0] NameType,
3047 -- May have zero elements, or individual elements may be
3048 -- zero-length, but this is not recommended.
3049 name-string [1] SEQUENCE OF KerberosString
3055 PrincipalNameIA5 ::= PrincipalName (WITH COMPONENTS {
3057 name-string (WITH COMPONENT (KerberosStringIA5))
3062 PrincipalNameExt ::= PrincpalName (WITH COMPONENTS {
3064 name-string (WITH COMPONENT (KerberosStringExt))
3069 Realm ::= KerberosString
3073 RealmIA5 ::= Realm (KerberosStringIA5)
3077 RealmExt ::= Realm (KerberosStringExt)
3081 -- Yet another refinement to kludge around historical
3082 -- implementation bugs... we still send at least 32 bits, but
3083 -- this parameterized type allows us to actually use named bit
3084 -- string syntax to define flags, sort of.
3085 KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
3087 -- must be a valid value of -- NamedBits
3088 -- but if the value to be sent would otherwise be shorter
3089 -- than 32 bits, it must be padded with trailing zero bits
3090 -- to 32 bits. Otherwise, no trailing zero bits may be
3104 Yu Expires: Jan 2005 [Page 48]
3105 Internet-Draft yu-krb-extensions-01 19 Jul 2004
3111 HostAddress ::= SEQUENCE {
3112 addr-type [0] AddrType,
3113 address [1] OCTET STRING
3117 -- NOTE: HostAddresses is always used as an OPTIONAL field and
3118 -- should not be a zero-length SEQUENCE OF.
3120 -- The extensible messages explicitly constrain this to be
3122 HostAddresses ::= SEQUENCE OF HostAddress
3127 -- *** crypto-related types and assignments
3132 -- Assigned numbers denoting encryption mechanisms.
3136 -- assigned numbers for encryption schemes
3137 et-des-cbc-crc EType ::= 1
3138 et-des-cbc-md4 EType ::= 2
3139 et-des-cbc-md5 EType ::= 3
3141 et-des3-cbc-md5 EType ::= 5
3143 et-des3-cbc-sha1 EType ::= 7
3144 et-dsaWithSHA1-CmsOID EType ::= 9
3145 et-md5WithRSAEncryption-CmsOID EType ::= 10
3146 et-sha1WithRSAEncryption-CmsOID EType ::= 11
3147 et-rc2CBC-EnvOID EType ::= 12
3148 et-rsaEncryption-EnvOID EType ::= 13
3149 et-rsaES-OAEP-ENV-OID EType ::= 14
3150 et-des-ede3-cbc-Env-OID EType ::= 15
3151 et-des3-cbc-sha1-kd EType ::= 16
3153 et-aes128-cts-hmac-sha1-96 EType ::= 17
3155 et-aes256-cts-hmac-sha1-96 EType ::= 18
3157 et-rc4-hmac EType ::= 23
3159 et-rc4-hmac-exp EType ::= 24
3160 -- opaque; PacketCable
3161 et-subkey-keymaterial EType ::= 65
3166 Yu Expires: Jan 2005 [Page 49]
3167 Internet-Draft yu-krb-extensions-01 19 Jul 2004
3170 -- Assigned numbers denoting key usages.
3175 -- Actual identifier names are provisional and subject to
3178 ku-pa-enc-ts KeyUsage ::= 1
3179 ku-Ticket KeyUsage ::= 2
3180 ku-EncASRepPart KeyUsage ::= 3
3181 ku-TGSReqAuthData-sesskey KeyUsage ::= 4
3182 ku-TGSReqAuthData-subkey KeyUsage ::= 5
3183 ku-pa-TGSReq-cksum KeyUsage ::= 6
3184 ku-pa-TGSReq-authenticator KeyUsage ::= 7
3185 ku-EncTGSRepPart-sesskey KeyUsage ::= 8
3186 ku-EncTGSRepPart-subkey KeyUsage ::= 9
3187 ku-Authenticator-cksum KeyUsage ::= 10
3188 ku-APReq-authenticator KeyUsage ::= 11
3189 ku-EncAPRepPart KeyUsage ::= 12
3190 ku-EncKrbPrivPart KeyUsage ::= 13
3191 ku-EncKrbCredPart KeyUsage ::= 14
3192 ku-KrbSafe-cksum KeyUsage ::= 15
3193 ku-ad-KDCIssued-cksum KeyUsage ::= 19
3197 -- The following numbers are provisional...
3198 -- conflicts may exist elsewhere.
3199 ku-Ticket-cksum KeyUsage ::= 25
3200 ku-ASReq-cksum KeyUsage ::= 26
3201 ku-TGSReq-cksum KeyUsage ::= 27
3202 ku-ASRep-cksum KeyUsage ::= 28
3203 ku-TGSRep-cksum KeyUsage ::= 29
3204 ku-APReq-cksum KeyUsage ::= 30
3205 ku-APRep-cksum KeyUsage ::= 31
3206 ku-KrbCred-cksum KeyUsage ::= 32
3207 ku-KrbError-cksum KeyUsage ::= 33
3208 ku-KDCRep-cksum KeyUsage ::= 34
3225 Yu Expires: Jan 2005 [Page 50]
3226 Internet-Draft yu-krb-extensions-01 19 Jul 2004
3229 -- KeyToUse identifies which key is to be used to encrypt or
3230 -- sign a given value.
3232 -- Values of KeyToUse are never actually transmitted over the
3233 -- wire, or even used directly by the implementation in any
3234 -- way, as key usages are; it exists primarily to identify
3235 -- which key gets used for what purpose. Thus, the specific
3236 -- numeric values associated with this type are irrelevant.
3237 KeyToUse ::= ENUMERATED {
3240 -- server long term key
3242 -- client long term key
3244 -- key selected by KDC for encryption of a KDC-REP
3246 -- session key from ticket
3248 -- subsession key negotiated via AP-REQ/AP-REP
3255 EncryptionKey ::= SEQUENCE {
3257 keyvalue [1] OCTET STRING
3283 Yu Expires: Jan 2005 [Page 51]
3284 Internet-Draft yu-krb-extensions-01 19 Jul 2004
3288 -- "Type" specifies which ASN.1 type is encrypted to the
3289 -- ciphertext in the EncryptedData. "Keys" specifies a set of
3290 -- keys of which one key may be used to encrypt the data.
3291 -- "KeyUsages" specifies a set of key usages, one of which may
3292 -- be used to encrypt.
3294 -- None of the parameters is transmitted over the wire.
3296 Type, KeyToUse:Keys, KeyUsage:KeyUsages
3299 kvno [1] UInt32 OPTIONAL,
3300 cipher [2] OCTET STRING (CONSTRAINED BY {
3301 -- must be encryption of --
3302 OCTET STRING (CONTAINING Type),
3303 -- with one of the keys -- KeyToUse:Keys,
3304 -- with key usage being one of --
3316 -- The parameters specify which key to use to produce the
3317 -- signature, as well as which key usage to use. The
3318 -- parameters are not actually sent over the wire.
3320 KeyToUse:Keys, KeyUsage:KeyUsages
3322 cksumtype [0] CksumType,
3323 checksum [1] OCTET STRING (CONSTRAINED BY {
3324 -- signed using one of the keys --
3326 -- with key usage being one of --
3342 Yu Expires: Jan 2005 [Page 52]
3343 Internet-Draft yu-krb-extensions-01 19 Jul 2004
3346 -- a Checksum that must contain the checksum
3347 -- of a particular type
3349 Type, KeyToUse:Keys, KeyUsage:KeyUsages
3350 } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
3352 checksum (CONSTRAINED BY {
3353 -- must be checksum of --
3354 OCTET STRING (CONTAINING Type)
3360 -- parameterized type for wrapping authenticated plaintext
3362 InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
3364 cksum [0] ChecksumOf {
3365 InnerType, Keys, KeyUsages
3367 inner [1] InnerType,
3380 rfc1510 [APPLICATION 1] Ticket1510,
3381 ext [APPLICATION 4] Signed {
3382 TicketExt, { key-server }, { ku-Ticket-cksum }
3388 -- takes a parameter specifying which type gets encrypted
3389 TicketCommon { EncPart } ::= SEQUENCE {
3390 tkt-vno [0] INTEGER (5),
3392 sname [2] PrincipalName,
3393 enc-part [3] EncryptedData {
3394 EncPart, { key-server }, { ku-Ticket }
3397 extensions [4] TicketExtensions OPTIONAL,
3403 Yu Expires: Jan 2005 [Page 53]
3404 Internet-Draft yu-krb-extensions-01 19 Jul 2004
3407 Ticket1510 ::= SEQUENCE {
3408 COMPONENTS OF TicketCommon { EncTicketPart1510 }
3409 } (WITH COMPONENTS {
3411 -- explicitly force IA5 in strings
3413 sname (PrincipalNameIA5)
3418 -- APPLICATION tag goes inside Signed{} as well as outside,
3419 -- to prevent possible substitution attacks.
3420 TicketExt ::= [APPLICATION 4] TicketCommon {
3422 } (WITH COMPONENTS {
3424 -- explicitly force UTF-8 in strings
3426 sname (PrincipalNameExt)
3431 -- Encrypted part of ticket
3432 EncTicketPart ::= CHOICE {
3433 rfc1510 [APPLICATION 3] EncTicketPart1510,
3434 ext [APPLICATION 5] EncTicketPartExt
3439 EncTicketPartCommon ::= SEQUENCE {
3440 flags [0] TicketFlags,
3441 key [1] EncryptionKey,
3443 cname [3] PrincipalName,
3444 transited [4] TransitedEncoding,
3445 authtime [5] KerberosTime,
3446 starttime [6] KerberosTime OPTIONAL,
3447 endtime [7] KerberosTime,
3448 renew-till [8] KerberosTime OPTIONAL,
3449 caddr [9] HostAddresses OPTIONAL,
3450 authorization-data [10] AuthorizationData OPTIONAL,
3463 Yu Expires: Jan 2005 [Page 54]
3464 Internet-Draft yu-krb-extensions-01 19 Jul 2004
3467 EncTicketPart1510 ::= SEQUENCE {
3468 COMPONENTS OF EncTicketPartCommon
3469 } (WITH COMPONENTS {
3471 -- explicitly force IA5 in strings
3473 cname (PrincipalNameIA5)
3478 EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS {
3480 -- explicitly force UTF-8 in strings
3482 cname (PrincipalNameExt),
3483 -- explicitly constrain caddr to be non-empty if present
3484 caddr (SIZE (1..MAX)),
3485 -- forbid empty authorization-data encodings
3486 authorization-data (SIZE (1..MAX))
3492 -- *** Authorization Data
3500 AuthorizationData ::= SEQUENCE OF SEQUENCE {
3502 ad-data [1] OCTET STRING
3507 ad-if-relevant ADType ::= 1
3510 -- Encapsulates another AuthorizationData.
3511 -- Intended for application servers; receiving application servers
3513 AD-IF-RELEVANT ::= AuthorizationData
3526 Yu Expires: Jan 2005 [Page 55]
3527 Internet-Draft yu-krb-extensions-01 19 Jul 2004
3530 -- KDC-issued privilege attributes
3531 ad-kdcissued ADType ::= 4
3534 AD-KDCIssued ::= SEQUENCE {
3535 ad-checksum [0] ChecksumOf {
3536 AuthorizationData, { key-session },
3537 { ku-ad-KDCIssued-cksum }},
3538 i-realm [1] Realm OPTIONAL,
3539 i-sname [2] PrincipalName OPTIONAL,
3540 elements [3] AuthorizationData
3545 ad-and-or ADType ::= 5
3548 AD-AND-OR ::= SEQUENCE {
3549 condition-count [0] INTEGER,
3550 elements [1] AuthorizationData
3555 -- KDCs MUST interpret any AuthorizationData wrapped in this.
3556 ad-mandatory-for-kdc ADType ::= 8
3557 AD-MANDATORY-FOR-KDC ::= AuthorizationData
3561 TrType ::= Int32 -- must be registered
3564 -- encoded Transited field
3565 TransitedEncoding ::= SEQUENCE {
3567 contents [1] OCTET STRING
3575 -- ticket extensions: for TicketExt only
3576 TicketExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
3578 te-data [1] OCTET STRING
3591 Yu Expires: Jan 2005 [Page 56]
3592 Internet-Draft yu-krb-extensions-01 19 Jul 2004
3595 TicketFlags ::= KerberosFlags { TicketFlagsBits }
3598 TicketFlagsBits ::= BIT STRING {
3611 transited-policy-checked (12),
3612 ok-as-delegate (13),
3614 cksummed-ticket (15)
3626 rfc1510 [APPLICATION 10] KDC-REQ-1510
3630 -- AS-REQ must include client name
3631 req-body (WITH COMPONENTS { ..., cname PRESENT })
3633 ext [APPLICATION 6] Signed {
3634 -- APPLICATION tag goes inside Signed{} as well as
3635 -- outside, to prevent possible substitution attacks.
3636 [APPLICATION 6] KDC-REQ-EXT,
3637 -- not sure this is correct key to use; do we even want
3645 -- AS-REQ must include client name
3646 req-body (WITH COMPONENTS { ..., cname PRESENT })
3651 Yu Expires: Jan 2005 [Page 57]
3652 Internet-Draft yu-krb-extensions-01 19 Jul 2004
3655 TGS-REQ ::= CHOICE {
3656 rfc1510 [APPLICATION 12] KDC-REQ-1510
3660 -- client name optional in TGS-REQ
3661 req-body (WITH COMPONENTS { ..., cname ABSENT })
3663 ext [APPLICATION 8] Signed {
3664 -- APPLICATION tag goes inside Signed{} as well as
3665 -- outside, to prevent possible substitution attacks.
3666 [APPLICATION 8] KDC-REQ-EXT,
3667 { key-session }, { ku-TGSReq-cksum }
3672 -- client name optional in TGS-REQ
3673 req-body (WITH COMPONENTS { ..., cname ABSENT })
3679 KDC-REQ-COMMON ::= SEQUENCE {
3680 -- NOTE: first tag is [1], not [0]
3681 pvno [1] INTEGER (5),
3682 msg-type [2] INTEGER (10 -- AS-REQ.rfc1510 --
3683 | 12 -- TGS-REQ.rfc1510 --
3684 | 6 -- AS-REQ.ext --
3685 | 8 -- TGS-REQ.ext -- ),
3686 padata [3] SEQUENCE OF PA-DATA OPTIONAL
3692 KDC-REQ-1510 ::= SEQUENCE {
3693 COMPONENTS OF KDC-REQ-COMMON,
3694 req-body [4] KDC-REQ-BODY-1510
3695 } (WITH COMPONENTS { ..., msg-type (10 | 12) })
3710 Yu Expires: Jan 2005 [Page 58]
3711 Internet-Draft yu-krb-extensions-01 19 Jul 2004
3714 -- APPLICATION tag goes inside Signed{} as well as outside,
3715 -- to prevent possible substitution attacks.
3716 KDC-REQ-EXT ::= SEQUENCE {
3717 COMPONENTS OF KDC-REQ-COMMON,
3718 req-body [4] KDC-REQ-BODY-EXT,
3719 lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF
3722 } (WITH COMPONENTS {
3725 padata (SIZE (1..MAX))
3730 KDC-REQ-BODY-COMMON ::= SEQUENCE {
3731 kdc-options [0] KDCOptions,
3732 cname [1] PrincipalName OPTIONAL
3733 -- Used only in AS-REQ --,
3737 -- Server's realm; also client's in AS-REQ --,
3740 sname [3] PrincipalName OPTIONAL,
3741 from [4] KerberosTime OPTIONAL,
3742 till [5] KerberosTime OPTIONAL
3743 -- was required in rfc1510;
3744 -- still required for compat versions
3748 rtime [6] KerberosTime OPTIONAL,
3750 etype [8] SEQUENCE OF EType
3751 -- in preference order --,
3754 addresses [9] HostAddresses OPTIONAL,
3755 enc-authorization-data [10] EncryptedData {
3756 AuthorizationData, { key-session | key-subsession },
3757 { ku-TGSReqAuthData-subkey |
3758 ku-TGSReqAuthData-sesskey }
3762 additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
3763 -- NOTE: not empty --,
3773 Yu Expires: Jan 2005 [Page 59]
3774 Internet-Draft yu-krb-extensions-01 19 Jul 2004
3777 KDC-REQ-BODY-1510 ::= SEQUENCE {
3778 COMPONENTS OF KDC-REQ-BODY-COMMON
3779 } (WITH COMPONENTS {
3781 cname (PrincipalNameIA5),
3783 sname (PrincipalNameIA5),
3790 KDC-REQ-BODY-EXT ::= KDC-REQ-BODY-COMMON
3793 cname (PrincipalNameExt),
3795 sname (PrincipalNameExt),
3796 addresses (SIZE (1..MAX)),
3797 enc-authorization-data (EncryptedData {
3798 AuthorizationData (SIZE (1..MAX)),
3799 { key-session | key-subsession },
3800 { ku-TGSReqAuthData-subkey |
3801 ku-TGSReqAuthData-sesskey }
3803 additional-tickets (SIZE (1..MAX))
3831 Yu Expires: Jan 2005 [Page 60]
3832 Internet-Draft yu-krb-extensions-01 19 Jul 2004
3835 KDCOptions ::= KerberosFlags { KDCOptionsBits }
3836 KDCOptionsBits ::= BIT STRING {
3851 requestanonymous (14),
3853 disable-transited-check (26),
3855 enc-tkt-in-skey (28),
3858 -- XXX need "need ticket1" flag?
3864 rfc1510 [APPLICATION 11] KDC-REP-1510 {
3866 } (WITH COMPONENTS { ..., msg-type (11) }),
3867 ext [APPLICATION 7] Signed {
3868 [APPLICATION 7] KDC-REP-EXT { EncASRepPartExt },
3869 { key-reply }, { ku-ASRep-cksum }
3870 } (WITH COMPONENTS { ..., msg-type (7) })
3875 TGS-REP ::= CHOICE {
3876 rfc1510 [APPLICATION 13] KDC-REP-1510 {
3878 } (WITH COMPONENTS { ..., msg-type (13) }),
3879 ext [APPLICATION 9] Signed {
3880 [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
3881 { key-reply }, { ku-TGSRep-cksum }
3882 } (WITH COMPONENTS { ..., msg-type (9) })
3890 Yu Expires: Jan 2005 [Page 61]
3891 Internet-Draft yu-krb-extensions-01 19 Jul 2004
3894 KDC-REP-COMMON { EncPart } ::= SEQUENCE {
3895 pvno [0] INTEGER (5),
3896 msg-type [1] INTEGER (11 -- AS-REP.rfc1510 -- |
3897 13 -- TGS.rfc1510 -- |
3898 7 -- AS-REP.ext -- |
3899 9 -- TGS-REP.ext -- ),
3900 padata [2] SEQUENCE OF PA-DATA OPTIONAL,
3902 cname [4] PrincipalName,
3904 enc-part [6] EncryptedData {
3907 -- maybe reach into EncryptedData in AS-REP/TGS-REP
3908 -- definitions to apply constraints on key usages?
3909 { ku-EncASRepPart -- if AS-REP -- |
3910 ku-EncTGSRepPart-subkey -- if TGS-REP and
3911 -- using Authenticator
3913 ku-EncTGSRepPart-sesskey -- if TGS-REP and using
3914 -- subsession key -- }
3917 -- In extensible version, KDC signs original request
3918 -- to avoid replay attacks agaginst client.
3919 req-cksum [7] ChecksumOf { CHOICE {
3922 }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
3923 lang-tag [8] LangTag OPTIONAL,
3929 KDC-REP-1510 { EncPart } ::= SEQUENCE {
3930 COMPONENTS OF KDC-REP-COMMON { EncPart }
3931 } (WITH COMPONENTS {
3935 cname (PrincipalNameIA5)
3940 KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart }
3945 cname (PrincipalNameExt)
3949 Yu Expires: Jan 2005 [Page 62]
3950 Internet-Draft yu-krb-extensions-01 19 Jul 2004
3953 EncASRepPart1510 ::= [APPLICATION 25] EncKDCRepPart1510
3954 EncTGSRepPart1510 ::= [APPLICATION 26] EncKDCRepPart1510
3957 EncASRepPartExt ::= [APPLICATION 32] EncKDCRepPartExt
3958 EncTGSRepPartExt ::= [APPLICATION 33] EncKDCRepPartExt
3961 EncKDCRepPartCom ::= SEQUENCE {
3962 key [0] EncryptionKey,
3963 last-req [1] LastReq,
3965 key-expiration [3] KerberosTime OPTIONAL,
3966 flags [4] TicketFlags,
3967 authtime [5] KerberosTime,
3968 starttime [6] KerberosTime OPTIONAL,
3969 endtime [7] KerberosTime,
3970 renew-till [8] KerberosTime OPTIONAL,
3972 sname [10] PrincipalName,
3973 caddr [11] HostAddresses OPTIONAL,
3978 EncKDCRepPart1510 ::= SEQUENCE {
3979 COMPONENTS OF EncKDCRepPartCom
3980 } (WITH COMPONENTS {
3983 sname (PrincipalNameIA5),
3987 EncKdcRepPartExt ::= EncKDCRepPartCom (WITH COMPONENTS {
3990 sname (PrincipalNameExt)
3996 LastReq ::= SEQUENCE OF SEQUENCE {
3998 lr-value [1] KerberosTime
4012 Yu Expires: Jan 2005 [Page 63]
4013 Internet-Draft yu-krb-extensions-01 19 Jul 2004
4016 PaDataType ::= Int32
4017 PaDataOID ::= RELATIVE-OID
4020 PA-DATA ::= SEQUENCE {
4021 -- NOTE: first tag is [1], not [0]
4022 padata-type [1] CHOICE {
4024 -- example of possible use
4028 padata-value [2] OCTET STRING
4033 PaDataSet PADATA-OBJ ::= {
4045 -- AP-REQ authenticating a TGS-REQ
4046 pa-tgs-req PaDataType ::= 1
4047 PA-TGS-REQ ::= AP-REQ
4051 -- Encrypted timestamp preauth
4052 -- Encryption key used is client's long-term key.
4053 pa-enc-timestamp PaDataType ::= 2
4056 PA-ENC-TIMESTAMP ::= EncryptedData {
4057 PA-ENC-TS-ENC, { key-client }, { ku-pa-enc-ts }
4061 PA-ENC-TS-ENC ::= SEQUENCE {
4062 patimestamp [0] KerberosTime -- client's time --,
4063 pausec [1] Microseconds OPTIONAL
4075 Yu Expires: Jan 2005 [Page 64]
4076 Internet-Draft yu-krb-extensions-01 19 Jul 2004
4079 -- Hints returned in AS-REP or KRB-ERROR to help client
4080 -- choose a password-derived key, either for preauthentication
4081 -- or for decryption of the reply.
4082 pa-etype-info PaDataType ::= 11
4085 ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY
4088 ETYPE-INFO-ENTRY ::= SEQUENCE {
4090 salt [1] OCTET STRING OPTIONAL
4095 -- Similar to etype-info, but with parameters provided for
4096 -- the string-to-key function.
4097 pa-etype-info2 PaDataType ::= 19
4100 ETYPE-INFO2 ::= SEQUENCE (SIZE (1..MAX))
4104 ETYPE-INFO2-ENTRY ::= SEQUENCE {
4106 salt [1] KerberosString OPTIONAL,
4107 s2kparams [2] OCTET STRING OPTIONAL
4112 -- Obsolescent. Salt for client's long-term key.
4113 -- Its character encoding is unspecified.
4114 pa-pw-salt PaDataType ::= 3
4115 -- The "padata-value" does not encode an ASN.1 type.
4116 -- Instead, "padata-value" must consist of the salt string to
4117 -- be used by the client, in an unspecified character
4123 -- An extensible AS-REQ may be sent as a padata in a
4124 -- non-extensible AS-REQ to allow for backwards compatibility.
4125 pa-as-req PaDataType ::= 42 -- provisional
4126 PA-AS-REQ ::= AS-REQ (WITH COMPONENTS ext)
4131 -- *** Session key exchange
4140 Yu Expires: Jan 2005 [Page 65]
4141 Internet-Draft yu-krb-extensions-01 19 Jul 2004
4145 rfc1510 [APPLICATION 14] AP-REQ-1510,
4146 ext [APPLICATION 18] Signed {
4147 AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
4153 AP-REQ-COMMON ::= SEQUENCE {
4154 pvno [0] INTEGER (5),
4155 msg-type [1] INTEGER (14 | 18),
4156 ap-options [2] APOptions,
4158 authenticator [4] EncryptedData {
4161 { ku-APReq-authenticator |
4162 ku-pa-TGSReq-authenticator }
4165 extensions [5] ApReqExtensions OPTIONAL,
4171 AP-REQ-1510 ::= SEQUENCE {
4172 COMPONENTS OF AP-REQ-COMMON
4173 } (WITH COMPONENTS {
4176 authenticator (EncryptedData {
4177 Authenticator (WITH COMPONENTS {
4180 cname (PrincipalNameIA5),
4182 }), { key-session }, { ku-APReq-authenticator }})
4199 Yu Expires: Jan 2005 [Page 66]
4200 Internet-Draft yu-krb-extensions-01 19 Jul 2004
4203 AP-REQ-EXT ::= AP-REQ-COMMON
4207 -- The following constraints on Authenticator assume that
4208 -- we want to restrict the use of AP-REQ-EXT with TicketExt
4209 -- only, since that is the only way we can enforce UTF-8.
4210 authenticator (EncryptedData {
4211 Authenticator (WITH COMPONENTS {
4214 cname (PrincipalNameExt),
4215 authorization-data (SIZE (1..MAX))
4216 }), { key-session }, { ku-APReq-authenticator }})
4221 ApReqExtType ::= Int32
4224 ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
4225 apReqExt-Type [0] ApReqExtType,
4226 apReqExt-Data [1] OCTET STRING
4231 APOptions ::= KerberosFlags { APOptionsBits }
4234 APOptionsBits ::= BIT STRING {
4236 use-session-key (1),
4242 -- plaintext of authenticator
4243 Authenticator ::= [APPLICATION 2] SEQUENCE {
4244 authenticator-vno [0] INTEGER (5),
4246 cname [2] PrincipalName,
4247 cksum [3] Checksum {{ key-session },
4248 { ku-Authenticator-cksum |
4249 ku-pa-TGSReq-cksum }} OPTIONAL,
4250 cusec [4] Microseconds,
4251 ctime [5] KerberosTime,
4252 subkey [6] EncryptionKey OPTIONAL,
4253 seq-number [7] SeqNum OPTIONAL,
4254 authorization-data [8] AuthorizationData OPTIONAL
4261 Yu Expires: Jan 2005 [Page 67]
4262 Internet-Draft yu-krb-extensions-01 19 Jul 2004
4266 rfc1510 [APPLICATION 15] AP-REP-1510,
4267 ext [APPLICATION 19] Signed {
4269 { key-session | key-subsession }, { ku-APRep-cksum }}
4274 AP-REP-COMMON { EncPart } ::= SEQUENCE {
4275 pvno [0] INTEGER (5),
4276 msg-type [1] INTEGER (15 | 19),
4277 enc-part [2] EncryptedData {
4279 { key-session | key-subsession }, { ku-EncAPRepPart }},
4281 extensions [3] ApRepExtensions OPTIONAL,
4287 AP-REP-1510 ::= SEQUENCE {
4288 COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
4289 } (WITH COMPONENTS {
4296 AP-REP-EXT ::= [APPLICATION 19] AP-REP-COMMON {
4298 } (WITH COMPONENTS { ..., msg-type (19) })
4302 ApRepExtType ::= Int32
4305 ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
4306 apRepExt-Type [0] ApRepExtType,
4307 apRepExt-Data [1] OCTET STRING
4312 EncAPRepPart ::= CHOICE {
4313 rfc1510 [APPLICATION 27] EncAPRepPart1510,
4314 ext [APPLICATION 31] EncAPRepPartExt
4324 Yu Expires: Jan 2005 [Page 68]
4325 Internet-Draft yu-krb-extensions-01 19 Jul 2004
4328 EncAPRepPart1510 ::= SEQUENCE {
4329 COMPONENTS OF ENCAPRepPartCom
4330 } (WITH COMPONENTS {
4332 seq-number (UInt32),
4333 authorization-data ABSENT
4338 EncAPRepPartExt ::= EncAPRepPartCom
4342 EncAPRepPartCom ::= SEQUENCE {
4343 ctime [0] KerberosTime,
4344 cusec [1] Microseconds,
4345 subkey [2] EncryptionKey OPTIONAL,
4346 seq-number [3] SeqNum OPTIONAL,
4348 authorization-data [4] AuthorizationData OPTIONAL,
4355 -- *** Application messages
4360 -- Do we chew up another tag for KRB-SAFE-EXT? That would
4361 -- allow us to make safe-body optional, allowing for a GSS-MIC
4363 KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
4364 pvno [0] INTEGER (5),
4365 msg-type [1] INTEGER (20),
4366 safe-body [2] KRB-SAFE-BODY,
4367 cksum [3] ChecksumOf {
4369 { key-session | key-subsession }, { ku-KrbSafe-cksum }},
4370 ... -- ASN.1 extensions must be excluded
4371 -- when sending to rfc1510 implementations
4385 Yu Expires: Jan 2005 [Page 69]
4386 Internet-Draft yu-krb-extensions-01 19 Jul 2004
4389 KRB-SAFE-BODY ::= SEQUENCE {
4390 user-data [0] OCTET STRING,
4391 timestamp [1] KerberosTime OPTIONAL,
4392 usec [2] Microseconds OPTIONAL,
4393 seq-number [3] SeqNum OPTIONAL,
4394 s-address [4] HostAddress,
4395 r-address [5] HostAddress OPTIONAL,
4396 ... -- ASN.1 extensions must be excluded
4397 -- when sending to rfc1510 implementations
4402 KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
4403 pvno [0] INTEGER (5),
4404 msg-type [1] INTEGER (21),
4405 enc-part [3] EncryptedData {
4407 { key-session | key-subsession }, { ku-EncKrbPrivPart }},
4413 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
4414 user-data [0] OCTET STRING,
4415 timestamp [1] KerberosTime OPTIONAL,
4416 usec [2] Microseconds OPTIONAL,
4417 seq-number [3] SeqNum OPTIONAL,
4418 s-address [4] HostAddress -- sender's addr --,
4419 r-address [5] HostAddress OPTIONAL -- recip's addr --,
4420 ... -- ASN.1 extensions must be excluded
4421 -- when sending to rfc1510 implementations
4426 KRB-CRED ::= CHOICE {
4427 rfc1510 [APPLICATION 22] KRB-CRED-1510,
4428 ext [APPLICATION 24] Signed {
4430 { key-session | key-subsession }, { ku-KrbCred-cksum }}
4435 KRB-CRED-COMMON ::= SEQUENCE {
4436 pvno [0] INTEGER (5),
4437 msg-type [1] INTEGER (22 | 24),
4438 tickets [2] SEQUENCE OF Ticket,
4439 enc-part [3] EncryptedData {
4441 { key-session | key-subsession }, { ku-EncKrbCredPart }},
4446 Yu Expires: Jan 2005 [Page 70]
4447 Internet-Draft yu-krb-extensions-01 19 Jul 2004
4450 KRB-CRED-1510 ::= SEQUENCE {
4451 COMPONENTS OF KRB-CRED-COMMON
4452 } (WITH COMPONENTS { ..., msg-type (22) })
4456 KRB-CRED-EXT ::= [APPLICATION 24] KRB-CRED-COMMON
4457 (WITH COMPONENTS { ..., msg-type (24) })
4461 EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
4462 ticket-info [0] SEQUENCE OF KrbCredInfo,
4463 nonce [1] Nonce OPTIONAL,
4464 timestamp [2] KerberosTime OPTIONAL,
4465 usec [3] Microseconds OPTIONAL,
4466 s-address [4] HostAddress OPTIONAL,
4467 r-address [5] HostAddress OPTIONAL
4472 KrbCredInfo ::= SEQUENCE {
4473 key [0] EncryptionKey,
4474 prealm [1] Realm OPTIONAL,
4475 pname [2] PrincipalName OPTIONAL,
4476 flags [3] TicketFlags OPTIONAL,
4477 authtime [4] KerberosTime OPTIONAL,
4478 starttime [5] KerberosTime OPTIONAL,
4479 endtime [6] KerberosTime OPTIONAL,
4480 renew-till [7] KerberosTime OPTIONAL,
4481 srealm [8] Realm OPTIONAL,
4482 sname [9] PrincipalName OPTIONAL,
4483 caddr [10] HostAddresses OPTIONAL
4488 TGT-REQ ::= [APPLICATION 16] SEQUENCE {
4489 pvno [0] INTEGER (5),
4490 msg-type [1] INTEGER (16),
4491 sname [2] PrincipalName OPTIONAL,
4492 srealm [3] Realm OPTIONAL,
4499 -- *** Error messages
4508 Yu Expires: Jan 2005 [Page 71]
4509 Internet-Draft yu-krb-extensions-01 19 Jul 2004
4515 KRB-ERROR ::= CHOICE {
4516 rfc1510 [APPLICATION 30] KRB-ERROR-1510,
4517 ext [APPLICATION 23] Signed {
4518 KRB-ERROR-EXT, { ku-KrbError-cksum } }
4523 KRB-ERROR-COMMON ::= SEQUENCE {
4524 pvno [0] INTEGER (5),
4525 msg-type [1] INTEGER (30 | 23),
4526 ctime [2] KerberosTime OPTIONAL,
4527 cusec [3] Microseconds OPTIONAL,
4528 stime [4] KerberosTime,
4529 susec [5] Microseconds,
4530 error-code [6] ErrCode,
4531 crealm [7] Realm OPTIONAL,
4532 cname [8] PrincipalName OPTIONAL,
4533 realm [9] Realm -- Correct realm --,
4534 sname [10] PrincipalName -- Correct name --,
4535 e-text [11] KerberosString OPTIONAL,
4536 e-data [12] OCTET STRING OPTIONAL,
4538 typed-data [13] TYPED-DATA OPTIONAL,
4539 nonce [14] Nonce OPTIONAL,
4540 lang-tag [15] LangTag OPTIONAL,
4546 KRB-ERROR-1510 ::= SEQUENCE {
4547 COMPONENTS OF KRB-ERROR-COMMON
4548 } (WITH COMPONENTS {
4555 KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON
4556 (WITH COMPONENTS { ..., msg-type (23) })
4563 TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
4564 data-type [0] TDType,
4565 data-value [1] OCTET STRING OPTIONAL
4571 Yu Expires: Jan 2005 [Page 72]
4572 Internet-Draft yu-krb-extensions-01 19 Jul 2004
4581 kdc-err-none ErrCode ::= 0
4582 -- Client's entry in database has expired
4583 kdc-err-name-exp ErrCode ::= 1
4584 -- Server's entry in database has expired
4585 kdc-err-service-exp ErrCode ::= 2
4586 -- Requested protocol version number not supported
4587 kdc-err-bad-pvno ErrCode ::= 3
4588 -- Client's key encrypted in old master key
4589 kdc-err-c-old-mast-kvno ErrCode ::= 4
4590 -- Server's key encrypted in old master key
4591 kdc-err-s-old-mast-kvno ErrCode ::= 5
4592 -- Client not found in Kerberos database
4593 kdc-err-c-principal-unknown ErrCode ::= 6
4594 -- Server not found in Kerberos database
4595 kdc-err-s-principal-unknown ErrCode ::= 7
4596 -- Multiple principal entries in database
4597 kdc-err-principal-not-unique ErrCode ::= 8
4598 -- The client or server has a null key
4599 kdc-err-null-key ErrCode ::= 9
4600 -- Ticket not eligible for postdating
4601 kdc-err-cannot-postdate ErrCode ::= 10
4602 -- Requested start time is later than end time
4603 kdc-err-never-valid ErrCode ::= 11
4604 -- KDC policy rejects request
4605 kdc-err-policy ErrCode ::= 12
4606 -- KDC cannot accommodate requested option
4607 kdc-err-badoption ErrCode ::= 13
4608 -- KDC has no support for encryption type
4609 kdc-err-etype-nosupp ErrCode ::= 14
4610 -- KDC has no support for checksum type
4611 kdc-err-sumtype-nosupp ErrCode ::= 15
4612 -- KDC has no support for padata type
4613 kdc-err-padata-type-nosupp ErrCode ::= 16
4614 -- KDC has no support for transited type
4615 kdc-err-trtype-nosupp ErrCode ::= 17
4616 -- Clients credentials have been revoked
4617 kdc-err-client-revoked ErrCode ::= 18
4618 -- Credentials for server have been revoked
4619 kdc-err-service-revoked ErrCode ::= 19
4620 -- TGT has been revoked
4621 kdc-err-tgt-revoked ErrCode ::= 20
4629 Yu Expires: Jan 2005 [Page 73]
4630 Internet-Draft yu-krb-extensions-01 19 Jul 2004
4633 -- Client not yet valid - try again later
4634 kdc-err-client-notyet ErrCode ::= 21
4635 -- Server not yet valid - try again later
4636 kdc-err-service-notyet ErrCode ::= 22
4637 -- Password has expired - change password to reset
4638 kdc-err-key-expired ErrCode ::= 23
4639 -- Pre-authentication information was invalid
4640 kdc-err-preauth-failed ErrCode ::= 24
4641 -- Additional pre-authenticationrequired
4642 kdc-err-preauth-required ErrCode ::= 25
4643 -- Requested server and ticket don't match
4644 kdc-err-server-nomatch ErrCode ::= 26
4645 -- Server principal valid for user2user only
4646 kdc-err-must-use-user2user ErrCode ::= 27
4647 -- KDC Policy rejects transited path
4648 kdc-err-path-not-accpeted ErrCode ::= 28
4649 -- A service is not available
4650 kdc-err-svc-unavailable ErrCode ::= 29
4651 -- Integrity check on decrypted field failed
4652 krb-ap-err-bad-integrity ErrCode ::= 31
4654 krb-ap-err-tkt-expired ErrCode ::= 32
4655 -- Ticket not yet valid
4656 krb-ap-err-tkt-nyv ErrCode ::= 33
4657 -- Request is a replay
4658 krb-ap-err-repeat ErrCode ::= 34
4659 -- The ticket isn't for us
4660 krb-ap-err-not-us ErrCode ::= 35
4661 -- Ticket and authenticator don't match
4662 krb-ap-err-badmatch ErrCode ::= 36
4663 -- Clock skew too great
4664 krb-ap-err-skew ErrCode ::= 37
4665 -- Incorrect net address
4666 krb-ap-err-badaddr ErrCode ::= 38
4667 -- Protocol version mismatch
4668 krb-ap-err-badversion ErrCode ::= 39
4670 krb-ap-err-msg-type ErrCode ::= 40
4686 Yu Expires: Jan 2005 [Page 74]
4687 Internet-Draft yu-krb-extensions-01 19 Jul 2004
4690 -- Message stream modified
4691 krb-ap-err-modified ErrCode ::= 41
4692 -- Message out of order
4693 krb-ap-err-badorder ErrCode ::= 42
4694 -- Specified version of key is not available
4695 krb-ap-err-badkeyver ErrCode ::= 44
4696 -- Service key not available
4697 krb-ap-err-nokey ErrCode ::= 45
4698 -- Mutual authentication failed
4699 krb-ap-err-mut-fail ErrCode ::= 46
4700 -- Incorrect message direction
4701 krb-ap-err-baddirection ErrCode ::= 47
4702 -- Alternative authentication method required
4703 krb-ap-err-method ErrCode ::= 48
4704 -- Incorrect sequence number in message
4705 krb-ap-err-badseq ErrCode ::= 49
4706 -- Inappropriate type of checksum in message
4707 krb-ap-err-inapp-cksum ErrCode ::= 50
4708 -- Policy rejects transited path
4709 krb-ap-path-not-accepted ErrCode ::= 51
4710 -- Response too big for UDP, retry with TCP
4711 krb-err-response-too-big ErrCode ::= 52
4712 -- Generic error (description in e-text)
4713 krb-err-generic ErrCode ::= 60
4743 Yu Expires: Jan 2005 [Page 75]
4744 Internet-Draft yu-krb-extensions-01 19 Jul 2004
4747 -- Field is too long for this implementation
4748 krb-err-field-toolong ErrCode ::= 61
4749 -- Reserved for PKINIT
4750 kdc-error-client-not-trusted ErrCode ::= 62
4751 -- Reserved for PKINIT
4752 kdc-error-kdc-not-trusted ErrCode ::= 63
4753 -- Reserved for PKINIT
4754 kdc-error-invalid-sig ErrCode ::= 64
4755 -- Reserved for PKINIT
4756 kdc-err-key-too-weak ErrCode ::= 65
4757 -- Reserved for PKINIT
4758 kdc-err-certificate-mismatch ErrCode ::= 66
4759 -- No TGT available to validate USER-TO-USER
4760 krb-ap-err-no-tgt ErrCode ::= 67
4761 -- USER-TO-USER TGT issued different KDC
4762 kdc-err-wrong-realm ErrCode ::= 68
4763 -- Ticket must be for USER-TO-USER
4764 krb-ap-err-user-to-user-required ErrCode ::= 69
4765 -- Reserved for PKINIT
4766 kdc-err-cant-verify-certificate ErrCode ::= 70
4767 -- Reserved for PKINIT
4768 kdc-err-invalid-certificate ErrCode ::= 71
4769 -- Reserved for PKINIT
4770 kdc-err-revoked-certificate ErrCode ::= 72
4771 -- Reserved for PKINIT
4772 kdc-err-revocation-status-unknown ErrCode ::= 73
4773 -- Reserved for PKINIT
4774 kdc-err-revocation-status-unavailable ErrCode ::= 74
4782 B. Kerberos and Character Encodings (Informative)
4785 [adapted from KCLAR 5.2.1]
4788 The original specification of the Kerberos protocol in RFC 1510 uses
4789 GeneralString in numerous places for human-readable string data.
4790 Historical implementations of Kerberos cannot utilize the full power
4791 of GeneralString. This ASN.1 type requires the use of designation
4792 and invocation escape sequences as specified in ISO 2022 | ECMA-35
4793 [ISO2022] to switch character sets, and the default character set
4794 that is designated as G0 is the ISO 646 | ECMA-6 [ISO646]
4795 International Reference Version (IRV) (aka U.S. ASCII), which mostly
4799 ISO 2022 | ECMA-35 defines four character-set code elements (G0..G3)
4800 and two Control-function code elements (C0..C1). DER previously
4801 [X690-1997] prohibited the designation of character sets as any but
4802 the G0 and C0 sets. This had the side effect of prohibiting the use
4805 Yu Expires: Jan 2005 [Page 76]
4806 Internet-Draft yu-krb-extensions-01 19 Jul 2004
4809 of (ISO Latin) character-sets such as ISO 8859-1 [ISO8859-1] or any
4810 other character-sets that utilize a 96-character set, since it is
4811 prohibited by ISO 2022 | ECMA-35 to designate them as the G0 code
4812 element. Recent revisions to the ASN.1 standards resolve this
4816 In practice, many implementations treat RFC 1510 GeneralStrings as if
4817 they were 8-bit strings of whichever character set the implementation
4818 defaults to, without regard for correct usage of character-set
4819 designation escape sequences. The default character set is often
4820 determined by the current user's operating system dependent locale.
4821 At least one major implementation places unescaped UTF-8 encoded
4822 Unicode characters in the GeneralString. This failure to conform to
4823 the GeneralString specifications results in interoperability issues
4824 when conflicting character encodings are utilized by the Kerberos
4825 clients, services, and KDC.
4828 This unfortunate situation is the result of improper documentation of
4829 the restrictions of the ASN.1 GeneralString type in prior Kerberos
4833 [the following should probably be rewritten and moved into the
4834 principal name section]
4837 For compatibility, implementations MAY choose to accept GeneralString
4838 values that contain characters other than those permitted by
4839 IA5String, but they should be aware that character set designation
4840 codes will likely be absent, and that the encoding should probably be
4841 treated as locale-specific in almost every way. Implementations MAY
4842 also choose to emit GeneralString values that are beyond those
4843 permitted by IA5String, but should be aware that doing so is
4844 extraordinarily risky from an interoperability perspective.
4847 Some existing implementations use GeneralString to encode unescaped
4848 locale-specific characters. This is a violation of the ASN.1
4849 standard. Most of these implementations encode US-ASCII in the left-
4850 hand half, so as long the implementation transmits only US-ASCII, the
4851 ASN.1 standard is not violated in this regard. As soon as such an
4852 implementation encodes unescaped locale-specific characters with the
4853 high bit set, it violates the ASN.1 standard.
4856 Other implementations have been known to use GeneralString to contain
4857 a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8
4858 is a different encoding, not a 94 or 96 character "G" set as defined
4859 by ISO 2022. It is believed that these implementations do not even
4860 use the ISO 2022 escape sequence to change the character encoding.
4861 Even if implementations were to announce the change of encoding by
4862 using that escape sequence, the ASN.1 standard prohibits the use of
4863 any escape sequences other than those used to designate/invoke "G" or
4864 "C" sets allowed by GeneralString.
4868 Yu Expires: Jan 2005 [Page 77]
4869 Internet-Draft yu-krb-extensions-01 19 Jul 2004
4872 C. Kerberos History (Informative)
4875 [Adapted from KCLAR "BACKGROUND"]
4878 The Kerberos model is based in part on Needham and Schroeder's
4879 trusted third-party authentication protocol [NS78] and on
4880 modifications suggested by Denning and Sacco [DS81]. The original
4881 design and implementation of Kerberos Versions 1 through 4 was the
4882 work of two former Project Athena staff members, Steve Miller of
4883 Digital Equipment Corporation and Clifford Neuman (now at the
4884 Information Sciences Institute of the University of Southern
4885 California), along with Jerome Saltzer, Technical Director of Project
4886 Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other
4887 members of Project Athena have also contributed to the work on
4891 Version 5 of the Kerberos protocol (described in this document) has
4892 evolved from Version 4 based on new requirements and desires for
4893 features not available in Version 4. The design of Version 5 of the
4894 Kerberos protocol was led by Clifford Neuman and John Kohl with much
4895 input from the community. The development of the MIT reference
4896 implementation was led at MIT by John Kohl and Theodore Ts'o, with
4897 help and contributed code from many others. Since RFC1510 was
4898 issued, extensions and revisions to the protocol have been proposed
4899 by many individuals. Some of these proposals are reflected in this
4900 document. Where such changes involved significant effort, the
4901 document cites the contribution of the proposer.
4904 Reference implementations of both version 4 and version 5 of Kerberos
4905 are publicly available and commercial implementations have been
4906 developed and are widely used. Details on the differences between
4907 Kerberos Versions 4 and 5 can be found in [KNT94].
4910 D. Notational Differences from [KCLAR]
4913 [ possible point for discussion ]
4916 [KCLAR] uses notational conventions slightly different from this
4917 document. As a derivative of RFC 1510, the text of [KCLAR] uses C-
4918 language style identifier names for defined values. In ASN.1
4919 notation, identifiers referencing defined values must begin with a
4920 lowercase letter and contain hyphen (-) characters rather than
4921 underscore (_) characters, while identifiers referencing types begin
4922 with an uppercase letter. [KCLAR] and RFC 1510 use all-uppercase
4923 identifiers with underscores to identify defined values. This has
4924 the potential to create confusion, but neither document defines
4925 values using actual ASN.1 value-assignment notation.
4928 It is debatable whether it is advantageous to write all identifier
4929 names (regardless of their ASN.1 token type) in all-uppercase letters
4930 for the purpose of emphasis in running text. The alternative is to
4933 Yu Expires: Jan 2005 [Page 78]
4934 Internet-Draft yu-krb-extensions-01 19 Jul 2004
4937 use double-quote characters (") when ambiguity is possible.
4940 Normative References
4944 "7-bit coded character set", ISO/IEC 646:1991 | ECMA-6:1991.
4948 "Information technology -- Character code structure and
4949 extension techniques", ISO/IEC 2022:1994 | ECMA-35:1994.
4953 draft-ietf-krb-wg-crypto-07.txt
4957 S. Bradner, RFC2119: "Key words for use in RFC's to Indicate
4958 Requirement Levels", March 1997.
4962 "Information technology -- Abstract Syntax Notation One (ASN.1):
4963 Specification of basic notation", ITU-T Recommendation X.680
4964 (2002) | ISO/IEC 8824-1:2002.
4968 "Information technology -- Abstract Syntax Notation One (ASN.1):
4969 Constraint specification", ITU-T Recommendation X.682 (2002) |
4970 ISO/IEC 8824-3:2002.
4974 "Information technology -- Abstract Syntax Notation One (ASN.1):
4975 Parameterization of ASN.1 specifications", ITU-T Recommendation
4976 X.683 (2002) | ISO/IEC 8824-4:2002.
4980 "Information technology -- ASN.1 encoding Rules: Specification
4981 of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
4982 and Distinguished Encoding Rules (DER)", ITU-T Recommendation
4983 X.690 (2002) | ISO/IEC 8825-1:2002.
4986 Informative References
4990 Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key
4991 Distribution Protocols," Communications of the ACM, Vol. 24(8),
4992 pp. 533-536 (August 1981).
4996 Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous
4997 Systems", Elsevier-Morgan Kaufmann, 2000.
4998 <http://www.oss.com/asn1/dubuisson.html>
5002 Yu Expires: Jan 2005 [Page 79]
5003 Internet-Draft yu-krb-extensions-01 19 Jul 2004
5007 "Information technology -- 8-bit single-byte coded graphic
5008 character sets -- Part 1: Latin alphabet No. 1", ISO/IEC
5013 draft-ietf-krb-wg-kerberos-clarifications-06.txt
5017 John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
5018 Evolution of the Kerberos Authentication System". In
5019 Distributed Open Systems, pages 78-94. IEEE Computer Society
5024 John Larmouth, "Understanding OSI", International Thomson
5025 Computer Press, 1996.
5026 <http://www.isi.salford.ac.uk/books/osi.html>
5030 John Larmouth, "ASN.1 Complete", Elsevier-Morgan Kaufmann,
5031 1999. <http://www.oss.com/asn1/larmouth.html>
5035 Roger M. Needham and Michael D. Schroeder, "Using Encryption for
5036 Authentication in Large Networks of Computers", Communications
5037 of the ACM, Vol. 21(12), pp. 993-999 (December, 1978).
5041 J. Kohl and B. C. Neuman, "The Kerberos Network Authentication
5042 Service (v5)", RFC1510, September 1993, Status: Proposed
5047 J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
5048 June 1996, Status: Proposed Standard.
5052 "Information technology -- ASN.1 encoding rules: Specification
5053 of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
5054 and Distinguished Encoding Rules (DER)", ITU-T Recommendation
5055 X.690 (1997) | ISO/IEC 8825-1:1998.
5062 77 Massachusetts Ave
5069 Yu Expires: Jan 2005 [Page 80]
5070 Internet-Draft yu-krb-extensions-01 19 Jul 2004
5073 Full Copyright Statement
5076 Copyright (C) The Internet Society (2004). This document is subject
5077 to the rights, licenses and restrictions contained in BCP 78, and
5078 except as set forth therein, the authors retain all their rights.
5081 This document and the information contained herein are provided on an
5082 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
5083 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
5084 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
5085 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
5086 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
5087 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
5127 Yu Expires: Jan 2005 [Page 81]
git.samba.org / samba.git / blob