oysteikt/heimdal
0
0
Fork 0
Code Issues 5 Pull Requests Releases Activity
Files
a41439d52bac720cdf71a0e473f14be894fb4c29
heimdal/doc/standardisation/draft-yu-krb-wg-kerberos-extensions-01.txt
Love Hörnquist Åstrand d8b99337de x 
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@14346 ec53bebd-3082-4978-b11e-865c3cabbd6b
2004-11-10 20:50:35 +00:00

5127 lines
156 KiB
Plaintext
Raw Blame History

INTERNET-DRAFT Tom Yu
draft-yu-krb-wg-kerberos-extensions-01.txt MIT
Expires: 19 Jan 2005 19 July 2004
The Kerberos Network Authentication Service (Version 5)
Status of This Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes version 5 of the Kerberos network
authentication protocol. It describes changes to the protocol which
allow for extensions to be made to the protocol without creating
interoperability problems.
Key Words for Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
to be interpreted as described in RFC 2119.
Yu Expires: Jan 2005 [Page 1]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
Table of Contents
Status of This Memo ....................................... 1
Copyright Notice .......................................... 1
Abstract .................................................. 1
Key Words for Requirements ................................ 1
Table of Contents ......................................... 2
1. Introduction .......................................... 4
1.1. Kerberos Protocol Overview .......................... 4
1.2. Overview of Document ................................ 5
2. Extensibility ......................................... 5
3. Backwards Compatibility ............................... 6
4. Criticality ........................................... 6
5. Use of ASN.1 in Kerberos .............................. 6
5.1. Module Header ....................................... 7
5.2. Top-Level Type ...................................... 7
5.3. Previously Unused ASN.1 Notation .................... 8
5.3.1. Parameterized Types ............................... 8
5.3.2. COMPONENTS OF Notation ............................ 8
5.3.3. Constraints ....................................... 8
5.4. New Types ........................................... 9
6. Basic Types ........................................... 10
6.1. Constrained Integer Types ........................... 10
6.2. KerberosTime ........................................ 11
6.3. KerberosString ...................................... 11
7. Principals ............................................ 11
7.1. Name Types .......................................... 12
7.2. Principal Type Definition ........................... 12
7.3. Principal Name Reuse ................................ 13
7.4. Realm Names ......................................... 13
7.5. Printable Representations of Principal Names ........ 13
7.6. Ticket-Granting Service Principal ................... 13
7.6.1. Cross-Realm TGS Principals ........................ 14
8. Types Relating to Encryption .......................... 14
8.1. Assigned Numbers for Encryption ..................... 14
8.1.1. EType ............................................. 14
8.1.2. Key Usages ........................................ 15
8.2. Which Key to Use .................................... 16
8.3. EncryptionKey ....................................... 17
8.4. EncryptedData ....................................... 17
8.5. Checksums ........................................... 18
8.5.1. ChecksumOf ........................................ 19
8.5.2. Signed ............................................ 20
9. Tickets ............................................... 20
9.1. Timestamps .......................................... 21
9.2. Ticket Flags ........................................ 21
9.2.1. Flags Relating to Initial Ticket Acquisition ...... 22
9.2.2. Invalid Tickets ................................... 22
9.2.3. OK as Delegate .................................... 23
9.3. Renewable Tickets ................................... 23
9.4. Postdated Tickets ................................... 24
Yu Expires: Jan 2005 [Page 2]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
9.5. Proxiable and Proxy Tickets ......................... 25
9.6. Forwardable Tickets ................................. 26
9.7. Transited Realms .................................... 27
9.8. Authorization Data .................................. 27
9.9. Encrypted Part of Ticket ............................ 27
9.10. Cleartext Part of Ticket ........................... 28
10. Credential Acquisition ............................... 28
10.1. KDC-REQ ............................................ 29
10.2. PA-DATA ............................................ 31
10.3. KDC-REQ Processing ................................. 31
10.3.1. Handling Replays ................................. 31
10.3.2. Request Validation ............................... 32
10.3.2.1. AS-REQ Authentication .......................... 32
10.3.2.2. TGS-REQ Authentication ......................... 32
10.3.2.3. Principal Validation ........................... 32
10.3.2.4. Checking For Revoked or Invalid Tickets ........ 32
10.3.3. Timestamp Handling ............................... 33
10.3.3.1. AS-REQ Timestamp Processing .................... 33
10.3.3.2. TGS-REQ Timestamp Processing ................... 34
10.3.4. Handling Transited Realms ........................ 35
10.3.5. Address Processing ............................... 35
10.3.6. Ticket Flag Processing ........................... 35
10.3.7. Key Selection .................................... 36
10.3.7.1. Reply Key and Session Key Selection ............ 37
10.3.7.2. Ticket Key Selection ........................... 37
10.4. Reply Validation ................................... 37
11. Session Key Exchange ................................. 37
11.1. AP-REQ ............................................. 37
11.2. AP-REP ............................................. 40
12. Session Key Use ...................................... 41
12.1. KRB-SAFE ........................................... 41
12.2. KRB-PRIV ........................................... 42
12.3. KRB-CRED ........................................... 42
13. Security Considerations .............................. 43
13.1. Time Synchronization ............................... 43
13.2. Replays ............................................ 44
13.3. Principal Name Reuse ............................... 44
13.4. Password Guessing .................................. 44
13.5. Forward Secrecy .................................... 44
13.6. Authorization ...................................... 44
13.7. Login Authentication ............................... 44
14. Acknowledgments ...................................... 45
Appendices ................................................ 45
A. ASN.1 Module (Normative) .............................. 45
B. Kerberos and Character Encodings (Informative) ........ 76
C. Kerberos History (Informative) ........................ 77
D. Notational Differences from [KCLAR] ................... 78
Normative References ...................................... 79
Informative References .................................... 79
Author's Address .......................................... 80
Full Copyright Statement .................................. 80
Yu Expires: Jan 2005 [Page 3]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
1. Introduction
The Kerberos network authentication protocol is a trusted third-party
protocol utilizing symmetric-key cryptography. It assumes that all
communications between parties in the protocol may be arbitrarily
tampered with or monitored, and that the security of the overall
system depends only on the effectiveness of the cryptographic
techniques and the secrecy of the keys used. The protocol
authenticates an application client's identity to an application
server, and likewise authenticates the application server's identity
to the application client. These assurances are made possible by the
client and the server sharing secrets with the trusted third party:
the Kerberos server, also known as the Key Distribution Center (KDC).
In addition, the protocol establishes an ephemeral shared secret (the
session key) between the client and the server, allowing the
protection of further communications between them.
1.1. Kerberos Protocol Overview
Kerberos comprises three main sub-protocols: credentials acquisition,
session key exchange, and session key usage. A client acquires
credentials by asking the KDC for a credential for a service; the KDC
issues the credential, which contains a ticket and a session key.
The ticket, containing the client's identity, timestamps, expiration
time, and a session key, is a encrypted in a key known to the
application server. The KDC encrypts the credential using a key
known to the client, and transmits the credential to the client.
There are two means of requesting credentials: the Authentication
Service (AS) exchange, and the Ticket-Granting Service (TGS)
exchange. In the typical AS exchange, a client uses a password-
derived key to decrypt the response. In the TGS exchange, the KDC
behaves as an application, which the client authenticates to using a
Ticket-Granting Ticket (TGT). The client usually obtains the TGT by
using the AS exchange.
Session key exchange consists of the client transmitting the ticket
to the application server, accompanied by an authenticator. The
authenticator contains a timestamp and additional data encrypted
using the ticket's session key. The application server decrypts the
ticket, extracting the session key. The application server then uses
the session key to decrypt the authenticator. Upon successful
decryption of the authenticator, the application server knows that
the data in the authenticator were sent by the client named in the
associated ticket. Additionally, since authenticators expire more
quickly than tickets, the application server has some assurance that
the transaction is not a replay. The application server may send an
encrypted acknowledgment to the client, verifying its identity to the
client.
Yu Expires: Jan 2005 [Page 4]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
Once session key exchange has occurred, the client and server may use
the established session key to protect further traffic. This
protection may consist of protection of integrity only, or of
protection of confidentiality and integrity. Additional measures
exist for a client to securely forward credentials to a server.
The entire scheme depends on loosely synchronized clocks.
Synchronization of the clock on the KDC with the application server
clock allows the application server to accurately determine whether a
credential is expired. Likewise, synchronization of the clock on the
client with the application server clock prevents replay attacks
utilizing the same credential. Careful design of the application
protocol may allow replay prevention without requiring client-server
clock synchronization.
After establishing a session key, application client and the
application server can exchange Kerberos protocol messages that use
the session key to protect the integrity or confidentiality of
communications between the client and the server. Additionally, the
client may forward credentials to the application server.
The credentials acquisition protocol takes place over specific,
defined transports (UDP and TCP). Application protocols define which
transport to use for the session key establishment protocol and for
messages using the session key; the application may choose to perform
its own encapsulation of the Kerberos messages, for example.
1.2. Overview of Document
The remainder of this document begins by describing the general
frameworks for protocol extensibility, including whether to interpret
unknown extensions as critical. It then defines the protocol
messages and exchanges.
The definition of the Kerberos protocol uses Abstract Syntax Notation
One (ASN.1) [X680], which specifies notation for describing the
abstract content of protocol messages. This document defines a
number of base types using ASN.1; these base types subsequently
appear in multiple types which define actual protocol messages.
Definitions of principal names and of tickets, which are central to
the protocol, also appear preceding the protocol message definitions.
2. Extensibility
As originally defined in RFC 1510, the Kerberos protocol does not
readily allow for backwards-compatible extensions to the protocol.
Various proposals to extend the Kerberos protocol have appeared since
RFC 1510, many of them creating problems for backwards compatibility.
This document adopts the technique of creating new extensible types
which encode to messages which are very similar to RFC 1510 messages
on the wire. This similarity allows implementors to use shared code
Yu Expires: Jan 2005 [Page 5]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
paths for encoding and decoding both new and old messages.
The protocol defined in RFC 1510 already contains some elements
allowing for limited backwards-compatible extensions to the protocol.
Most of these elements consist of "typed holes"; these are octet
strings having associated assigned numbers indicating the intended
interpretation of the octet string. This document typed holes to
some types which have previously lacked typed holes. This document
also describes procedures for the IETF to use the extensibility model
of ASN.1 to make further backwards-compatible extensions of the
Kerberos protocol, if typed holes prove inadequate for some desired
extension.
3. Backwards Compatibility
This document describes two sets (for the most part) of ASN.1 types.
The first set of types is wire-encoding compatible with RFC 1510 and
[KCLAR]. The second set of types is the set of types enabling
extensibility. This second set may be referred to as "extensibility-
enabled types". [ need to make this consistent throughout? ]
A major difference between the new extensibility-enabled types and
the types for RFC 1510 compatibility is that the extensibility-
enabled types allow for the use of UTF-8 encodings in various
character strings in the protocol. Each party in the protocol must
have some knowledge of the capabilities of the other parties in the
protocol. There are methods for establishing this knowledge without
necessarily requiring explicit configuration.
An extensibility-enabled client can detect whether a KDC supports the
extensibility-enabled types by requesting an extensibility-enabled
reply. If the KDC replies with an extensibility-enabled reply, the
client knows that the KDC supports extensibility. If the KDC issues
an extensibility-enabled ticket, the client knows that the service
named in the ticket is extensibility-enabled.
4. Criticality
In general, implementations SHOULD treat unknown extension, flags,
etc. as non-critical; i.e., they should ignore them when they do not
understand them. Exceptions are clearly marked. An implementation
SHOULD NOT reject a request merely because it does not understand
some element of the request. As a related consequence,
implementations SHOULD handle talking to other implementations which
do not implement some requested options. This may require designers
of extensions or options to provide means to detect whether
extensions or options are rejected, or whether such extensions or
options are merely not understood, or whether such extensions or
options are (perhaps maliciously) deleted or modified in transit.
Yu Expires: Jan 2005 [Page 6]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
5. Use of ASN.1 in Kerberos
Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690].
Even though ASN.1 theoretically allows the description of protocol
messages to be independent of the encoding rules used to encode the
messages, Kerberos messages MUST be encoded with DER. Subtleties in
the semantics of the notation, such as whether tags carry any
semantic content to the application, may cause the use of other ASN.1
encoding rules to be problematic.
Implementors not using existing ASN.1 tools (e.g., compilers or
support libraries) are cautioned to thoroughly read and understand
the actual ASN.1 specification to ensure correct implementation
behavior. There is more complexity in the notation than is
immediately obvious, and some tutorials and guides to ASN.1 are
misleading or erroneous. Recommended tutorials and guides include
[Dub00], [Lar99], though there is still no substitute for reading the
actual ASN.1 specification.
5.1. Module Header
The type definitions in this document assume an ASN.1 module
definition of the following form:
KerberosV5Spec3 {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) krb5spec3(4)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
-- Rest of definitions here
END
This specifies that the tagging context for the module will be
explicit and that automatic tagging is not done.
Some other publications [RFC1510] [RFC1964] erroneously specify an
object identifier (OID) having an incorrect value of "5" for the
"dod" component of the OID. In the case of RFC 1964, use of the
"correct" OID value would result in a change in the wire protocol;
therefore, the RFC 1964 OID remains unchanged for now.
5.2. Top-Level Type
The ASN.1 type "KRB-PDU" is a CHOICE over all the types (Protocol
Data Units or PDUs) which an application may directly reference.
Applications SHOULD NOT transmit any types other than those which are
alternatives of the KRB-PDU CHOICE.
Yu Expires: Jan 2005 [Page 7]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
-- top-level type
--
-- Applications should not directly reference any types
-- other than KRB-PDU and its component types.
--
KRB-PDU ::= CHOICE {
ticket Ticket,
as-req AS-REQ,
as-rep AS-REP,
tgs-req TGS-REQ,
tgs-rep TGS-REP,
ap-req AP-REQ,
ap-rep AP-REP,
krb-safe KRB-SAFE,
krb-priv KRB-PRIV,
krb-cred KRB-CRED,
tgt-req TGT-REQ,
krb-error KRB-ERROR,
...
}
5.3. Previously Unused ASN.1 Notation
Some aspects of ASN.1 notation used in this document were not used in
[KCLAR], and may be unfamiliar to some readers.
5.3.1. Parameterized Types
This document uses ASN.1 parameterized types [X683] to make
definitions of types more readable. For some types, some or all of
the parameters are advisory, i.e., they are not encoded in any form
for transmission in a protocol message. These advisory parameters
can describe implementation behavior associated with the type.
5.3.2. COMPONENTS OF Notation
The "COMPONENTS OF" notation, used to define the RFC 1510
compatibility types, extracts all of the component types of an ASN.1
SEQUENCE type. The extension marker (the "..." notation) and any
extension components are not extracted by "COMPONENTS OF". The
"COMPONENTS OF" notation permits concise definition of multiple types
which have many components in common with each other.
5.3.3. Constraints
This document uses ASN.1 constraints, including the
"UserDefinedConstraint" syntax [X682]. Some constraints can be
handled automatically by tools that can parse them. Uses of the
"UserDefinedConstraint" syntax (the "CONSTRAINED BY" syntax) will
typically need to have behavior manually coded; these uses provide a
Yu Expires: Jan 2005 [Page 8]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
formalized way of conveying intended implementation behavior.
The "WITH COMPONENTS" constraint notation allows constraints to apply
to component types of a SEQUENCE type. This constraint notation
effectively allows constraints to "reach into" a type to constrain
its component types.
5.4. New Types
This document defines a number of ASN.1 types which are new since
RFC 1510. The names of these types will typically have a suffix like
"Ext", indicating that the types are intended to support
extensibility. Types original to RFC 1510 have been renamed to have
a suffix like "1510". The "Ext" and "1510" types often contain a
number of common elements; these common elements have a suffix like
"Common". The "1510" types have various ASN.1 constraints applied to
them; the constraints limit the possible values of the "1510" types
to those permitted by RFC 1510 or by [KCLAR]. The "Ext" types may
have different constraints, typically to force string values to be
sent as UTF-8.
For example, consider
-- example "common" type
Foo-Common ::= SEQUENCE {
a [0] INTEGER,
b [1] OCTET STRING,
...,
c [2] INTEGER,
...
}
-- example "RFC 1510 compatibility" type
Foo-1510 ::= SEQUENCE {
-- the COMPONENTS OF notation drops the extension marker
-- and all extension additions.
COMPONENTS OF Foo-Common
}
-- example "extensibility-enabled" type
Foo-Ext ::= Foo-Common
where "Foo-Common" is a common type used to define both the "1510"
and "Ext" versions of a type. "Foo-1510" is the RFC 1510 version of
the type, while "Foo-Ext" is the extensible version. "Foo-1510" does
not contain the extension marker, nor does it contain the extension
component "c". The type "Foo-1510" is equivalent to
"Foo-1510-Equiv", shown below.
Yu Expires: Jan 2005 [Page 9]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
-- example type equivalent to Foo-1510
Foo-1510-Equiv ::= SEQUENCE {
a [0] INTEGER,
b [1] OCTET STRING
}
6. Basic Types
Certain ASN.1 types in Kerberos appear repeatedly in other Kerberos
types.
6.1. Constrained Integer Types
In RFC 1510, many types contained references to the unconstrained
INTEGER type. Since an unconstrained INTEGER may contain any
possible abstract integer value, most of the unconstrained references
to INTEGER in RFC 1510 have been constrained to 32 bits or smaller.
-- signed values representable in 32 bits
--
-- These are often used as assigned numbers for various things.
Int32 ::= INTEGER (-2147483648..2147483647)
-- unsigned 32 bit values
UInt32 ::= INTEGER (0..4294967295)
The "Int32" type often contains an assigned number identifying the
type of a protocol element. Unless otherwise stated, non-negative
values are registered, and negative values are available for local
use.
-- unsigned 64 bit values
UInt64 ::= INTEGER (0..18446744073709551615)
The "UInt64" type is used in places where 32 bits of precision may
provide inadequate security.
-- microseconds
Microseconds ::= INTEGER (0..999999)
-- sequence numbers
SeqNum ::= UInt64
-- nonces
Nonce ::= UInt64
While these types have different abstract types from their
equivalents in RFC 1510, their DER encodings remain identical.
Yu Expires: Jan 2005 [Page 10]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
Nonces and sequence numbers are constrained to 32 bits in the
RFC 1510 backwards-compatibility types.
6.2. KerberosTime
-- must not have fractional seconds
KerberosTime ::= GeneralizedTime
The timestamps used in Kerberos are encoded as GeneralizedTimes. A
KerberosTime value MUST NOT include any fractional portions of the
seconds. As required by the DER, it further MUST NOT include any
separators, and it specifies the UTC time zone (Z). Example: The
only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
November 1985 is "19851106210627Z".
6.3. KerberosString
-- used for names and for error messages
KerberosString ::= CHOICE {
ia5 GeneralString (IA5String),
utf8 UTF8String,
... -- no extension may be sent
-- to an rfc1510 implementation --
}
The KerberosString type is used for strings in various places in the
Kerberos protocol. For compatibility with RFC 1510, GeneralString
values constrained to IA5String (US-ASCII) are permitted in messages
exchanged with RFC 1510 implementations. The new protocol messages
contain strings encoded as UTF-8. KerberosString values are present
in principal names and in error messages. Control characters SHOULD
NOT be used in principal names, and used with caution in error
messages.
-- IA5 choice only; useful for constraints
KerberosStringIA5 ::= KerberosString
(WITH COMPONENTS { ia5 PRESENT })
-- IA5 excluded; useful for constraints
KerberosStringExt ::= KerberosString
(WITH COMPONENTS { ia5 ABSENT })
KerberosStringIA5 and KerberosStringExt respectively force and forbid
the use of the "ia5" alternative. These types are used as
constraints on other types for backwards compatibility purposes.
For detailed background regarding the history of character string use
in Kerberos, as well as discussion of some compatibility issues, see
Appendix B.
Yu Expires: Jan 2005 [Page 11]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
7. Principals
Principals are participants in the Kerberos protocol. A "realm"
consists of principals in one administrative domain, served by one
KDC (or one replicated set of KDCs). Each principal name has an
arbitrary number of components, though typical principal names will
only have one or two components. A principal name is meant to be
readable by and meaningful to humans, especially in a realm lacking a
centrally adminstered authorization infrastructure.
7.1. Name Types
Each Principal has NameType indicating what sort of name it is. The
name-type SHOULD be treated as a hint. Ignoring the name type, no
two names can be the same (i.e., at least one of the components, or
the realm, must be different).
-- assigned numbers for name types (used in principal names)
NameType ::= Int32
-- Name type not known
nt-unknown NameType ::= 0
-- Just the name of the principal as in DCE, or for users
nt-principal NameType ::= 1
-- Service and other unique instance (krbtgt)
nt-srv-inst NameType ::= 2
-- Service with host name as instance (telnet, rcommands)
nt-srv-hst NameType ::= 3
-- Service with host as remaining components
nt-srv-xhst NameType ::= 4
-- Unique ID
nt-uid NameType ::= 5
-- Encoded X.509 Distingished name [RFC 2253]
nt-x500-principal NameType ::= 6
-- Name in form of SMTP email name (e.g. user@foo.com)
nt-smtp-name NameType ::= 7
-- Enterprise name - may be mapped to principal name
nt-enterprise NameType ::= 10
7.2. Principal Type Definition
PrincipalName ::= SEQUENCE {
name-type [0] NameType,
-- May have zero elements, or individual elements may be
-- zero-length, but this is not recommended.
name-string [1] SEQUENCE OF KerberosString
}
Yu Expires: Jan 2005 [Page 12]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
name-type
hint of the type of name that follows
name-string
The "name-string" encodes a sequence of components that form a
name, each component encoded as a KerberosString. Taken
together, a PrincipalName and a Realm form a principal
identifier. Most PrincipalNames will have only a few components
(typically one or two).
7.3. Principal Name Reuse
Realm administrators SHOULD use extreme caution when considering
reusing a principal name. A service administrator might explicitly
enter principal names into a local access control list (ACL) for the
service. If such local ACLs exist independently of a centrally
administered authorization infrastructure, realm administrators
SHOULD NOT reuse principal names until confirming that all extant ACL
entries referencing that principal name have been updated. Failure
to perform this check can result in a security vulnerability, as a
new principal can inadvertently inherit unauthorized privileges upon
receiving a reused principal name. An organization whose Kerberos-
authenticated services all use a centrally-adminstered authorization
infrastructure may not need to take these precautions regarding
principal name reuse.
7.4. Realm Names
Realm ::= KerberosString
-- IA5 only
RealmIA5 ::= Realm (KerberosStringIA5)
-- IA5 excluded
RealmExt ::= Realm (KerberosStringExt)
Kerberos realm names are KerberosStrings. Realms MUST NOT contain a
character with the code 0 (the US-ASCII NUL). Most realms will
usually consist of several components separated by periods (.), in
the style of Internet Domain Names, or separated by slashes (/) in
the style of X.500 names.
7.5. Printable Representations of Principal Names
[ perhaps non-normative? ]
The printable form of a principal name consists of the concatenation
of components of the PrincipalName value using the slash character
(/), followed by an at-sign (@), followed by the realm name.
Yu Expires: Jan 2005 [Page 13]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
7.6. Ticket-Granting Service Principal
The PrincipalName value corresponding to a ticket-granting service
has two components: the first component is the string "krbtgt", and
the second component is the realm name of the TGS which will accept a
ticket-granting ticket having this service principal name. The realm
name of service always indicates which realm issued the ticket. A
ticket-granting ticket issued by "A.EXAMPLE.COM" which is valid for
obtaining tickets in the same realm would have the following ASN.1
values for its "realm" and "sname" components, respectively:
-- Example Realm and PrincipalName for a TGS
tgtRealm1 Realm ::= ia5 : "A.EXAMPLE.COM"
tgtPrinc1 PrincipalName ::= {
name-type nt-srv-inst,
name-string { ia5 : "krbtgt", ia5 : "A.EXAMPLE.COM" }
}
Its printable representation would be written as
"krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM".
7.6.1. Cross-Realm TGS Principals
It is possible for a principal in one realm to authenticate to a
service in another realm. A KDC can issue a cross-realm ticket-
granting ticket to allow one of its principals to authenticate to a
service in a foreign realm. For example, the TGS principal
"krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" is a principal that permits a
client principal in the realm A.EXAMPLE.COM to authenticate to a
service in the realm B.EXAMPLE.COM. When the KDC for B.EXAMPLE.COM
issues a ticket to a client originating in A.EXAMPLE.COM, the
client's realm name remains "A.EXAMPLE.COM", even though the service
principal will have the realm "B.EXAMPLE.COM".
8. Types Relating to Encryption
Many Kerberos protocol messages contain encryptions of various data
types. Kerberos protocol messages also contain checksums
(signatures) of various types.
8.1. Assigned Numbers for Encryption
Encryption algorithm identifiers and key usages both have assigned
numbers, described in [KCRYPTO].
8.1.1. EType
EType is the integer type for assigned numbers for encryption
algorithms. Defined in [KCRYPTO].
Yu Expires: Jan 2005 [Page 14]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
-- Assigned numbers denoting encryption mechanisms.
EType ::= Int32
-- assigned numbers for encryption schemes
et-des-cbc-crc EType ::= 1
et-des-cbc-md4 EType ::= 2
et-des-cbc-md5 EType ::= 3
-- [reserved] 4
et-des3-cbc-md5 EType ::= 5
-- [reserved] 6
et-des3-cbc-sha1 EType ::= 7
et-dsaWithSHA1-CmsOID EType ::= 9
et-md5WithRSAEncryption-CmsOID EType ::= 10
et-sha1WithRSAEncryption-CmsOID EType ::= 11
et-rc2CBC-EnvOID EType ::= 12
et-rsaEncryption-EnvOID EType ::= 13
et-rsaES-OAEP-ENV-OID EType ::= 14
et-des-ede3-cbc-Env-OID EType ::= 15
et-des3-cbc-sha1-kd EType ::= 16
-- AES
et-aes128-cts-hmac-sha1-96 EType ::= 17
-- AES
et-aes256-cts-hmac-sha1-96 EType ::= 18
-- Microsoft
et-rc4-hmac EType ::= 23
-- Microsoft
et-rc4-hmac-exp EType ::= 24
-- opaque; PacketCable
et-subkey-keymaterial EType ::= 65
8.1.2. Key Usages
KeyUsage is the integer type for assigned numbers for key usages.
Key usage values are inputs to the encryption and decryption
functions described in [KCRYPTO].
Yu Expires: Jan 2005 [Page 15]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
-- Assigned numbers denoting key usages.
KeyUsage ::= UInt32
--
-- Actual identifier names are provisional and subject to
-- change.
--
ku-pa-enc-ts KeyUsage ::= 1
ku-Ticket KeyUsage ::= 2
ku-EncASRepPart KeyUsage ::= 3
ku-TGSReqAuthData-sesskey KeyUsage ::= 4
ku-TGSReqAuthData-subkey KeyUsage ::= 5
ku-pa-TGSReq-cksum KeyUsage ::= 6
ku-pa-TGSReq-authenticator KeyUsage ::= 7
ku-EncTGSRepPart-sesskey KeyUsage ::= 8
ku-EncTGSRepPart-subkey KeyUsage ::= 9
ku-Authenticator-cksum KeyUsage ::= 10
ku-APReq-authenticator KeyUsage ::= 11
ku-EncAPRepPart KeyUsage ::= 12
ku-EncKrbPrivPart KeyUsage ::= 13
ku-EncKrbCredPart KeyUsage ::= 14
ku-KrbSafe-cksum KeyUsage ::= 15
ku-ad-KDCIssued-cksum KeyUsage ::= 19
-- The following numbers are provisional...
-- conflicts may exist elsewhere.
ku-Ticket-cksum KeyUsage ::= 25
ku-ASReq-cksum KeyUsage ::= 26
ku-TGSReq-cksum KeyUsage ::= 27
ku-ASRep-cksum KeyUsage ::= 28
ku-TGSRep-cksum KeyUsage ::= 29
ku-APReq-cksum KeyUsage ::= 30
ku-APRep-cksum KeyUsage ::= 31
ku-KrbCred-cksum KeyUsage ::= 32
ku-KrbError-cksum KeyUsage ::= 33
ku-KDCRep-cksum KeyUsage ::= 34
8.2. Which Key to Use
Yu Expires: Jan 2005 [Page 16]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
-- KeyToUse identifies which key is to be used to encrypt or
-- sign a given value.
--
-- Values of KeyToUse are never actually transmitted over the
-- wire, or even used directly by the implementation in any
-- way, as key usages are; it exists primarily to identify
-- which key gets used for what purpose. Thus, the specific
-- numeric values associated with this type are irrelevant.
KeyToUse ::= ENUMERATED {
-- unspecified
key-unspecified,
-- server long term key
key-server,
-- client long term key
key-client,
-- key selected by KDC for encryption of a KDC-REP
key-kdc-rep,
-- session key from ticket
key-session,
-- subsession key negotiated via AP-REQ/AP-REP
key-subsession,
...
}
8.3. EncryptionKey
The "EncryptionKey" type holds an encryption key.
EncryptionKey ::= SEQUENCE {
keytype [0] EType,
keyvalue [1] OCTET STRING
}
keytype
This "EType" identifies the encryption algorithm, described in
[KCRYPTO].
keyvalue
Contains the actual key.
8.4. EncryptedData
The "EncryptedData" type contains the encryption of another data
type. The recipient uses fields within EncryptedData to determine
which key to use for decryption.
Yu Expires: Jan 2005 [Page 17]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
-- "Type" specifies which ASN.1 type is encrypted to the
-- ciphertext in the EncryptedData. "Keys" specifies a set of
-- keys of which one key may be used to encrypt the data.
-- "KeyUsages" specifies a set of key usages, one of which may
-- be used to encrypt.
--
-- None of the parameters is transmitted over the wire.
EncryptedData {
Type, KeyToUse:Keys, KeyUsage:KeyUsages
} ::= SEQUENCE {
etype [0] EType,
kvno [1] UInt32 OPTIONAL,
cipher [2] OCTET STRING (CONSTRAINED BY {
-- must be encryption of --
OCTET STRING (CONTAINING Type),
-- with one of the keys -- KeyToUse:Keys,
-- with key usage being one of --
KeyUsage:KeyUsages
}),
...
}
KeyUsages
Advisory parameter indicating which key usage to use when
encrypting the ciphertext. If "KeyUsages" indicate multiple
"KeyUsage" values, the detailed description of the containing
message will indicate which key to use under which conditions.
Type
Advisory parameter indicating the ASN.1 type whose DER encoding
is the plaintext encrypted into the EncryptedData.
Keys
Advisory parameter indicating which key to use to perform the
encryption. If "Keys" indicate multiple "KeyToUse" values, the
detailed description of the containing message will indicate
which key to use under which conditions.
KeyUsages
Advisory parameter indicating which "KeyUsage" value is used to
encrypt. If "KeyUsages" indicates multiple "KeyUsage" values,
the detailed description of the containing message will indicate
which key usage to use under which conditions.
8.5. Checksums
Several types contain checksums (actually signatures) of data.
Yu Expires: Jan 2005 [Page 18]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
CksumType ::= Int32
-- The parameters specify which key to use to produce the
-- signature, as well as which key usage to use. The
-- parameters are not actually sent over the wire.
Checksum {
KeyToUse:Keys, KeyUsage:KeyUsages
} ::= SEQUENCE {
cksumtype [0] CksumType,
checksum [1] OCTET STRING (CONSTRAINED BY {
-- signed using one of the keys --
KeyToUse:Keys,
-- with key usage being one of --
KeyUsage:KeyUsages
})
}
CksumType
Integer type for assigned numbers for signature algorithms.
Defined in [KCRYPTO]
Keys
As in EncryptedData
KeyUsages
As in EncryptedData
cksumtype
Signature algorithm used to produce the signature.
checksum
The actual checksum.
8.5.1. ChecksumOf
ChecksumOf is like "Checksum", but specifies which type is signed.
-- a Checksum that must contain the checksum
-- of a particular type
ChecksumOf {
Type, KeyToUse:Keys, KeyUsage:KeyUsages
} ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
...,
checksum (CONSTRAINED BY {
-- must be checksum of --
OCTET STRING (CONTAINING Type)
})
})
Yu Expires: Jan 2005 [Page 19]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
Type
Indicates the ASN.1 type whose DER encoding is signed.
8.5.2. Signed
Signed is like "ChecksumOf", but contains an actual instance of the
type being signed in addition to the signature.
-- parameterized type for wrapping authenticated plaintext
Signed {
InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
} ::= SEQUENCE {
cksum [0] ChecksumOf {
InnerType, Keys, KeyUsages
} OPTIONAL,
inner [1] InnerType,
...
}
9. Tickets
[ A large number of items described here are duplicated in the
sections describing KDC-REQ processing. Should find a way to avoid
this duplication. ]
A ticket binds a principal name to a session key. The important
fields of a ticket are in the encrypted part. The components in
common between the RFC 1510 and the extensible versions are
EncTicketPartCommon ::= SEQUENCE {
flags [0] TicketFlags,
key [1] EncryptionKey,
crealm [2] Realm,
cname [3] PrincipalName,
transited [4] TransitedEncoding,
authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL,
caddr [9] HostAddresses OPTIONAL,
authorization-data [10] AuthorizationData OPTIONAL,
...
}
crealm
This field contains the client's realm.
cname
This field contains the client's name.
Yu Expires: Jan 2005 [Page 20]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
caddr
This field lists the network addresses (if absent, all addresses
are permitted) from which the ticket is valid.
Descriptions of the other fields appear in the following sections.
9.1. Timestamps
Three of the ticket timestamps may be requested from the KDC. The
timestamps may differ from those requested, depending on site policy.
authtime
The time at which the client authenticated, as recorded by the
KDC.
starttime
The earliest time when the ticket is valid. If not present, the
ticket is valid starting at the authtime. This is requested as
the "from" field of KDC-REQ-BODY-COMMON.
endtime
This time is requested in the "till" field of KDC-REQ-BODY-
COMMON. Contains the time after which the ticket will not be
honored (its expiration time). Note that individual services
MAY place their own limits on the life of a ticket and MAY
reject tickets which have not yet expired. As such, this is
really an upper bound on the expiration time for the ticket.
renew-till
This time is requested in the "rtime" field of KDC-REQ-BODY-
COMMON. It is only present in tickets that have the "renewable"
flag set in the flags field. It indicates the maximum endtime
that may be included in a renewal. It can be thought of as the
absolute expiration time for the ticket, including all renewals.
9.2. Ticket Flags
A number of flags may be set in the ticket, further defining some of
its capabilities. Some of these flags map to flags in a KDC request.
Yu Expires: Jan 2005 [Page 21]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
TicketFlags ::= KerberosFlags { TicketFlagsBits }
TicketFlagsBits ::= BIT STRING {
reserved (0),
forwardable (1),
forwarded (2),
proxiable (3),
proxy (4),
may-postdate (5),
postdated (6),
invalid (7),
renewable (8),
initial (9),
pre-authent (10),
hw-authent (11),
transited-policy-checked (12),
ok-as-delegate (13),
anonymous (14),
cksummed-ticket (15)
}
9.2.1. Flags Relating to Initial Ticket Acquisition
[ adapted KCLAR 2.1. ]
Several flags indicate the details of how the initial ticket was
acquired.
initial
The "initial" flag indicates that a ticket was issued using the
AS protocol, rather than issued based on a ticket-granting
ticket. Application servers (e.g., a password-changing program)
requiring a client's definite knowledge of its secret key can
insist that this flag be set in any tickets they accept, thus
being assured that the client's key was recently presented to
the application client.
pre-authent
The "pre-authent" flag indicates that some sort of pre-
authentication was used during the AS exchange.
hw-authent
The "hw-authent" flag indicates that some sort of hardware-based
pre-authentication occurred during the AS exchange.
Both the "pre-authent" and the "hw-authent" flags may be present with
or without the "initial" flag; such tickets with the "initial" flag
clear are ones which are derived from initial tickets with the "pre-
authent" or "hw-authent" flags set.
Yu Expires: Jan 2005 [Page 22]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
9.2.2. Invalid Tickets
[ KCLAR 2.2. ]
The "invalid" flag indicates that a ticket is invalid. Application
servers MUST reject tickets which have this flag set. A postdated
ticket will be issued in this form. Invalid tickets MUST be
validated by the KDC before use, by presenting them to the KDC in a
TGS request with the "validate" option specified. The KDC will only
validate tickets after their starttime has passed. The validation is
required so that postdated tickets which have been stolen before
their starttime can be rendered permanently invalid (through a hot-
list mechanism -- see Section 10.3.2.4).
9.2.3. OK as Delegate
[ KCLAR 2.8. ]
The "ok-as-delegate" flag provides a way for a KDC to communicate
local realm policy to a client regarding whether the service for
which the ticket is issued is trusted to accept delegated
credentials. For some applications, a client may need to delegate
credentials to a service to act on its behalf in contacting other
services. The ability of a client to obtain a service ticket for a
service conveys no information to the client about whether the
service should be trusted to accept delegated credentials.
The copy of the ticket flags visible to the client may have the "ok-
as-delegate" flag set to indicate to the client that the service
specified in the ticket has been determined by policy of the realm to
be a suitable recipient of delegation. A client can use the presence
of this flag to help it make a decision whether to delegate
credentials (either grant a proxy or a forwarded ticket-granting
ticket) to this service. It is acceptable to ignore the value of
this flag. When setting this flag, an administrator should consider
the security and placement of the server on which the service will
run, as well as whether the service requires the use of delegated
credentials.
9.3. Renewable Tickets
[ adapted KCLAR 2.3. ]
The "renewable" flag indicates whether the ticket may be renewed.
Renewable tickets can be used to mitigate the consequences of ticket
theft. Applications may desire to hold credentials which can be
valid for long periods of time. However, this can expose the
credentials to potential theft for equally long periods, and those
stolen credentials would be valid until the expiration time of the
ticket(s). Simply using short-lived tickets and obtaining new ones
Yu Expires: Jan 2005 [Page 23]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
periodically would require the application to have long-term access
to the client's secret key, which is an even greater risk.
Renewable tickets have two "expiration times": the first is when the
current instance of the ticket expires, and the second is the latest
permissible value for an individual expiration time. An application
client must periodically present an unexpired renewable ticket to the
KDC, setting the "renew" option in the KDC request. The KDC will
issue a new ticket with a new session key and a later expiration
time. All other fields of the ticket are left unmodified by the
renewal process. When the latest permissible expiration time
arrives, the ticket expires permanently. At each renewal, the KDC
MAY consult a hot-list to determine if the ticket had been reported
stolen since its last renewal; it will refuse to renew such stolen
tickets, and thus the usable lifetime of stolen tickets is reduced.
The "renewable" flag in a ticket is normally only interpreted by the
ticket-granting service. It can usually be ignored by application
servers. However, some particularly careful application servers MAY
disallow renewable tickets.
If a renewable ticket is not renewed by its expiration time, the KDC
will not renew the ticket. The "renewable" flag is clear by default,
but a client can request it be set by setting the "renewable" option
in the AS-REQ message. If it is set, then the "renew-till" field in
the ticket contains the time after which the ticket may not be
renewed.
9.4. Postdated Tickets
postdated
indicates a ticket which has been postdated
may-postdate
indicates that postdated tickets may be issued based on this
ticket
[ KCLAR 2.4. ]
Applications may occasionally need to obtain tickets for use much
later, e.g., a batch submission system would need tickets to be valid
at the time the batch job is serviced. However, it is dangerous to
hold valid tickets in a batch queue, since they will be on-line
longer and more prone to theft. Postdated tickets provide a way to
obtain these tickets from the KDC at job submission time, but to
leave them "dormant" until they are activated and validated by a
further request of the KDC. If a ticket theft were reported in the
interim, the KDC would refuse to validate the ticket, and the thief
would be foiled.
Yu Expires: Jan 2005 [Page 24]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
The "may-postdate" flag in a ticket is normally only interpreted by
the TGS. It can be ignored by application servers. This flag MUST
be set in a ticket-granting ticket in order for the KDC to issue a
postdated ticket based on the presented ticket. It is reset by
default; it MAY be requested by a client by setting the "allow-
postdate" option in the AS-REQ [?also TGS-REQ?] message. This flag
does not allow a client to obtain a postdated ticket-granting ticket;
postdated ticket-granting tickets can only by obtained by requesting
the postdating in the AS-REQ message. The life (endtime minus
starttime) of a postdated ticket will be the remaining life of the
ticket-granting ticket at the time of the request, unless the
"renewable" option is also set, in which case it can be the full life
(endtime minus starttime) of the ticket-granting ticket. The KDC MAY
limit how far in the future a ticket may be postdated.
The "postdated" flag indicates that a ticket has been postdated. The
application server can check the authtime field in the ticket to see
when the original authentication occurred. Some services MAY choose
to reject postdated tickets, or they may only accept them within a
certain period after the original authentication. When the KDC
issues a "postdated" ticket, it will also be marked as "invalid", so
that the application client MUST present the ticket to the KDC for
validation before use.
9.5. Proxiable and Proxy Tickets
proxy
indicates a proxy ticket
proxiable
indicates that proxy tickets may be issued based on this ticket
[ KCLAR 2.5. ]
It may be necessary for a principal to allow a service to perform an
operation on its behalf. The service must be able to take on the
identity of the client, but only for a particular purpose. A
principal can allow a service to take on the principal's identity for
a particular purpose by granting it a proxy.
The process of granting a proxy using the "proxy" and "proxiable"
flags is used to provide credentials for use with specific services.
Though conceptually also a proxy, users wishing to delegate their
identity in a form usable for all purposes MUST use the ticket
forwarding mechanism described in the next section to forward a
ticket-granting ticket.
The "proxiable" flag in a ticket is normally only interpreted by the
ticket-granting service. It can be ignored by application servers.
When set, this flag tells the ticket-granting server that it is OK to
issue a new ticket (but not a ticket-granting ticket) with a
Yu Expires: Jan 2005 [Page 25]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
different network address based on this ticket. This flag is set if
requested by the client on initial authentication. By default, the
client will request that it be set when requesting a ticket-granting
ticket, and reset when requesting any other ticket.
This flag allows a client to pass a proxy to a server to perform a
remote request on its behalf (e.g. a print service client can give
the print server a proxy to access the client's files on a particular
file server in order to satisfy a print request).
In order to complicate the use of stolen credentials, Kerberos
tickets may contain a set of network addresses from which they are
valid. When granting a proxy, the client MUST specify the new
network address from which the proxy is to be used, or indicate that
the proxy is to be issued for use from any address.
The "proxy" flag is set in a ticket by the TGS when it issues a proxy
ticket. Application servers MAY check this flag and at their option
they MAY require additional authentication from the agent presenting
the proxy in order to provide an audit trail.
9.6. Forwardable Tickets
forwarded
indicates a forwarded ticket
forwardable
indicates that forwarded tickets may be issued based on this
ticket
[ KCLAR 2.6. ]
Authentication forwarding is an instance of a proxy where the service
that is granted is complete use of the client's identity. An example
where it might be used is when a user logs in to a remote system and
wants authentication to work from that system as if the login were
local.
The "forwardable" flag in a ticket is normally only interpreted by
the ticket-granting service. It can be ignored by application
servers. The "forwardable" flag has an interpretation similar to
that of the "proxiable" flag, except ticket-granting tickets may also
be issued with different network addresses. This flag is reset by
default, but users MAY request that it be set by setting the
"forwardable" option in the AS request when they request their
initial ticket-granting ticket.
This flag allows for authentication forwarding without requiring the
user to enter a password again. If the flag is not set, then
authentication forwarding is not permitted, but the same result can
still be achieved if the user engages in the AS exchange specifying
Yu Expires: Jan 2005 [Page 26]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
the requested network addresses and supplies a password.
The "forwarded" flag is set by the TGS when a client presents a
ticket with the "forwardable" flag set and requests a forwarded
ticket by specifying the "forwarded" KDC option and supplying a set
of addresses for the new ticket. It is also set in all tickets
issued based on tickets with the "forwarded" flag set. Application
servers may choose to process "forwarded" tickets differently than
non-forwarded tickets.
If addressless tickets are forwarded from one system to another,
clients SHOULD still use this option to obtain a new TGT in order to
have different session keys on the different systems.
9.7. Transited Realms
[ KCLAR 2.7., plus new stuff ]
9.8. Authorization Data
9.9. Encrypted Part of Ticket
The complete definition of the encrypted part is
-- Encrypted part of ticket
EncTicketPart ::= CHOICE {
rfc1510 [APPLICATION 3] EncTicketPart1510,
ext [APPLICATION 5] EncTicketPartExt
}
EncTicketPart1510 ::= SEQUENCE {
COMPONENTS OF EncTicketPartCommon
} (WITH COMPONENTS {
...,
-- explicitly force IA5 in strings
crealm (RealmIA5),
cname (PrincipalNameIA5)
})
EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS {
...,
-- explicitly force UTF-8 in strings
crealm (RealmExt),
cname (PrincipalNameExt),
-- explicitly constrain caddr to be non-empty if present
caddr (SIZE (1..MAX)),
-- forbid empty authorization-data encodings
authorization-data (SIZE (1..MAX))
})
Yu Expires: Jan 2005 [Page 27]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
9.10. Cleartext Part of Ticket
Ticket ::= CHOICE {
rfc1510 [APPLICATION 1] Ticket1510,
ext [APPLICATION 4] Signed {
TicketExt, { key-server }, { ku-Ticket-cksum }
}
}
-- takes a parameter specifying which type gets encrypted
TicketCommon { EncPart } ::= SEQUENCE {
tkt-vno [0] INTEGER (5),
realm [1] Realm,
sname [2] PrincipalName,
enc-part [3] EncryptedData {
EncPart, { key-server }, { ku-Ticket }
},
...,
extensions [4] TicketExtensions OPTIONAL,
...
}
Ticket1510 ::= SEQUENCE {
COMPONENTS OF TicketCommon { EncTicketPart1510 }
} (WITH COMPONENTS {
...,
-- explicitly force IA5 in strings
realm (RealmIA5),
sname (PrincipalNameIA5)
})
-- APPLICATION tag goes inside Signed{} as well as outside,
-- to prevent possible substitution attacks.
TicketExt ::= [APPLICATION 4] TicketCommon {
EncTicketPartExt
} (WITH COMPONENTS {
...,
-- explicitly force UTF-8 in strings
realm (RealmExt),
sname (PrincipalNameExt)
})
10. Credential Acquisition
There are two exchanges that can be used for acquiring credentials:
the AS exchange and the TGS exchange. These exchanges have many
similarities, and this document describes them in parallel, noting
Yu Expires: Jan 2005 [Page 28]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
which behaviors are specific to one type of exchange. The AS request
(AS-REQ) and TGS request (TGS-REQ) are both forms of KDC requests
(KDC-REQ). Likewise, the AS reply (AS-REP) and TGS reply (TGS-REP)
are forms of KDC replies (KDC-REP).
10.1. KDC-REQ
The KDC-REQ has a large number of fields in common between the RFC
1510 and the extensible versions.
KDC-REQ-COMMON ::= SEQUENCE {
-- NOTE: first tag is [1], not [0]
pvno [1] INTEGER (5),
msg-type [2] INTEGER (10 -- AS-REQ.rfc1510 --
| 12 -- TGS-REQ.rfc1510 --
| 6 -- AS-REQ.ext --
| 8 -- TGS-REQ.ext -- ),
padata [3] SEQUENCE OF PA-DATA OPTIONAL
-- NOTE: not empty
}
Yu Expires: Jan 2005 [Page 29]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
KDC-REQ-BODY-COMMON ::= SEQUENCE {
kdc-options [0] KDCOptions,
cname [1] PrincipalName OPTIONAL
-- Used only in AS-REQ --,
realm [2] Realm
-- Server's realm; also client's in AS-REQ --,
sname [3] PrincipalName OPTIONAL,
from [4] KerberosTime OPTIONAL,
till [5] KerberosTime OPTIONAL
-- was required in rfc1510;
-- still required for compat versions
-- of messages --,
rtime [6] KerberosTime OPTIONAL,
nonce [7] Nonce,
etype [8] SEQUENCE OF EType
-- in preference order --,
addresses [9] HostAddresses OPTIONAL,
enc-authorization-data [10] EncryptedData {
AuthorizationData, { key-session | key-subsession },
{ ku-TGSReqAuthData-subkey |
ku-TGSReqAuthData-sesskey }
} OPTIONAL,
additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
-- NOTE: not empty --,
...
}
Many fields of KDC-REQ-BODY-COMMON correspond directly to fields of
an EncTicketPartCommon. The KDC copies most of them unchanged,
provided that their values meet site policy.
kdc-options
These flags do not correspond directly to "flags" in
EncTicketPartCommon.
cname
This field is copied to the "cname" field in
EncTicketPartCommon. The "cname" field is required in an AS-
REQ; the client places its own name here. In a TGS-REQ, the
"cname" in the ticket in the AP-REQ takes precedence.
realm
This field is the server's realm, and also holds the client's
realm in an AS-REQ.
Yu Expires: Jan 2005 [Page 30]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
sname
The "sname" field indicates the server's name. It may be absent
in a TGS-REQ which requests user-to-user authentication, in
which case the "sname" of the issued ticket will be taken from
the included additional ticket.
The "from", "till", and "rtime" fields correspond to the "starttime",
"endtime", and "renew-till" fields of EncTicketPartCommon.
addresses
This field corresponds to the "caddr" field of
EncTicketPartCommon.
enc-authorization-data
For TGS-REQ, this field contains authorization data encrypted
using either the TGT session key or the AP-REQ subsession key;
the KDC may copy these into the "authorization-data" field of
EncTicketPartCommon if policy permits.
10.2. PA-DATA
PA-DATA have multiple uses in the Kerberos protocol. They may pre-
authenticate an AS-REQ; they may also modify several of the
encryption keys used in a KDC-REP. PA-DATA may also provide "hints"
to the client about which long-term key (usually password-derived) to
use. PA-DATA may also include "hints" about which pre-authentication
mechanisms to use, or include data for input into a pre-
authentication mechanism.
10.3. KDC-REQ Processing
Processing of a KDC-REQ proceeds through several steps. An
implementation need not perform these steps exactly as described, as
long as it behaves as if the steps were performed as described. The
KDC performs replay handling upon receiving the request; it then
validates the request, adjusts timestamps, and selects the keys used
in the reply. It copies data from the request into the issued
ticket, adjusting the values to conform with its policies. The KDC
then transmits the reply to the client.
10.3.1. Handling Replays
Because Kerberos can run over unreliable transports such as UDP, the
KDC MUST be prepared to retransmit responses in case they are lost.
If a KDC receives a request identical to one it has recently
successfully processed, the KDC MUST respond with a KDC-REP message
rather than a replay error. In order to reduce the amount of
ciphertext given to a potential attacker, KDCs MAY send the same
response generated when the request was first handled. KDCs MUST
obey this replay behavior even if the actual transport in use is
reliable. If the AP-REQ which authenticates a TGS-REQ is a replay,
Yu Expires: Jan 2005 [Page 31]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
and the entire request is not identical to a recently successfully
processed request, the KDC SHOULD return "krb-ap-err-repeat", as is
appropriate for AP-REQ processing.
10.3.2. Request Validation
10.3.2.1. AS-REQ Authentication
Site policy determines whether a given client principal is required
to provide some pre-authentication prior to receiving an AS-REP.
Since the default reply key is typically the client's long-term
password-based key, an attacker may easily request known plaintext
(in the form of an AS-REP) upon which to mount a dictionary attack.
Pre-authentication can limit the possibility of such an attack.
If site policy requires pre-authentication for a client principal,
and no pre-authentication is provided, the KDC returns the error
"kdc-err-preauth-required". Accompanying this error are "e-data"
which include hints telling the client which pre-authentication
mechanisms to use, or data for input to pre-authentication mechanisms
(e.g., input to challenge-response systems). If pre-authentication
fails, the KDC returns the error "kdc-err-preauth-failed".
[ may need additional changes based on Sam's preauth draft ]
10.3.2.2. TGS-REQ Authentication
A TGS-REQ has an accompanying AP-REQ, which is included in the "pa-
tgs-req". The KDC MUST validate the checksum in the Authenticator of
the AP-REQ, which is computed over the KDC-REQ-BODY-1510 or KDC-REQ-
BODY-EXT (for TGS-REQ-1510 or TGS-REQ-EXT, respectively) of the
request. [ padata not signed by authenticator! ] Any error from the
AP-REQ validation process SHOULD be returned in a KRB-ERROR message.
The service principal in the ticket of the AP-REQ may be a ticket-
granting service principal, or a normal application service
principal. A ticket which is not a ticket-granting ticket MUST NOT
be used to issue a ticket for any service other than the one named in
the ticket. In this case, the "renew", "validate", or "proxy" [?also
forwarded?] option must be set in the request.
10.3.2.3. Principal Validation
If the client principal in an AS-REQ is unknown, the KDC returns the
error "kdc-err-c-principal-unknown". If the server principal in a
KDC-REQ is unknown, the KDC returns the error "kdc-err-s-principal-
unknown".
10.3.2.4. Checking For Revoked or Invalid Tickets
[ KCLAR 3.3.3.1 ]
Yu Expires: Jan 2005 [Page 32]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
Whenever a request is made to the ticket-granting server, the
presented ticket(s) is(are) checked against a hot-list of tickets
which have been canceled. This hot-list might be implemented by
storing a range of issue timestamps for "suspect tickets"; if a
presented ticket had an authtime in that range, it would be rejected.
In this way, a stolen ticket-granting ticket or renewable ticket
cannot be used to gain additional tickets (renewals or otherwise)
once the theft has been reported to the KDC for the realm in which
the server resides. Any normal ticket obtained before it was
reported stolen will still be valid (because they require no
interaction with the KDC), but only until their normal expiration
time. If TGTs have been issued for cross-realm authentication, use
of the cross-realm TGT will not be affected unless the hot-list is
propagated to the KDCs for the realms for which such cross-realm
tickets were issued.
If a TGS-REQ ticket has its "invalid" flag set, the KDC MUST NOT
issue any ticket unless the TGS-REQ requests the "validate" option.
10.3.3. Timestamp Handling
[ some aspects of timestamp handling, especially regarding postdating
and renewal, are difficult to read in KCLAR... needs closer
examination here ]
Processing of "starttime" (requested in the "from" field) differs
depending on whether the "postdated" option is set in the request.
If the "postdated" option is not set, and the requested "starttime"
is in the future beyond the window of acceptable clock skew, the KDC
returns the error "kdc-err-cannot-postdate". If the "postdated"
option is not set, and the requested "starttime" is absent or does
not indicate a time in the future beyond the acceptable clock skew,
the KDC sets the "starttime" to the KDC's current time. The
"postdated" option MUST NOT be honored if the ticket is being
requested by TGS-REQ and the "may-postdate" is not set in the TGT.
Otherwise, if the "postdated" option is set, and site policy permits,
the KDC sets the "starttime" as requested, and sets the "invalid"
flag in the new ticket.
The "till" field is required in the RFC 1510 version of the KDC-REQ.
If the "till" field is equal to "19700101000000Z" (midnight, January
1, 1970), the KDC SHOULD behave as if the "till" field were absent.
The KDC MUST NOT issue a ticket whose "starttime", "endtime", or
"renew-till" time is later than the "renew-till" time of the ticket
from which it is derived.
10.3.3.1. AS-REQ Timestamp Processing
In the AS exchange, the "authtime" of a ticket is set to the local
time at the KDC.
Yu Expires: Jan 2005 [Page 33]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
The "endtime" of the ticket will be set to the earlier of the
requested "till" time and a time determined by local policy, possibly
determined using factors specific to the realm or principal. For
example, the expiration time MAY be set to the earliest of the
following:
* the expiration time ("till" value) requested
* the ticket's start time plus the maximum allowable lifetime
associated with the client principal from the authentication
server's database
* the ticket's start time plus the maximum allowable lifetime
associated with the server principal
* the ticket's start time plus the maximum lifetime set by the
policy of the local realm
If the requested expiration time minus the start time (as determined
above) is less than a site-determined minimum lifetime, an error
message with code "kdc-err-never-valid" is returned. If the
requested expiration time for the ticket exceeds what was determined
as above, and if the "renewable-ok" option was requested, then the
"renewable" flag is set in the new ticket, and the "renew-till" value
is set as if the "renewable" option were requested.
If the "renewable" option has been requested or if the "renewable-ok"
option has been set and a renewable ticket is to be issued, then the
"renew-till" field MAY be set to the earliest of:
* its requested value
* the start time of the ticket plus the minimum of the two maximum
renewable lifetimes associated with the principals' database
entries
* the start time of the ticket plus the maximum renewable lifetime
set by the policy of the local realm
10.3.3.2. TGS-REQ Timestamp Processing
In the TGS exchange, the KDC sets the "authtime" to that of the
ticket in the AP-REQ authenticating the TGS-REQ. [?application
server can print a ticket for itself with a spoofed authtime.
security issues for hot-list?] [ MIT implementation may change
authtime of renewed tickets; needs check... ]
If the TGS-REQ has a TGT as the ticket in its AP-REQ, and the TGS-REQ
requests an "endtime" (in the "till" field), then the "endtime" of
the new ticket is set to the minimum of
Yu Expires: Jan 2005 [Page 34]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
* the requested "endtime" value,
* the "endtime" in the TGT, and
* an "endtime" determined by site policy on ticket lifetimes.
If the new ticket is a renewal, the "endtime" of the new ticket is
bounded by the minimum of
* the requested "endtime" value,
* the value of the "renew-till" value of the old,
* the "starttime" of the new ticket plus the lifetime (endtime
minus starttime) of the old ticket, i.e., the lifetime of the
new ticket may not exceed that of the ticket being renewed [
adapted from KCLAR 3.3.3. ], and
* an "endtime" determined by site policy on ticket lifetimes.
When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with
a "starttime", "endtime", or "renew-till" time later than the "renew-
till" time of the TGT.
10.3.4. Handling Transited Realms
The KDC checks the ticket in a TGS-REQ against site policy, unless
the "disable-transited-check" option is set in the TGS-REQ. If site
policy permits the transit path in the TGS-REQ ticket, the KDC sets
the "transited-policy-checked" flag in the issued ticket. If the
"disable-transited-check" option is set, the issued ticket will have
the "transited-policy-checked" flag cleared.
10.3.5. Address Processing The requested "addresses" in the KDC-REQ are
copied into the issued ticket. If the "addresses" field is absent or
empty in a TGS-REQ, the KDC copies addresses from the ticket in the
TGS-REQ into the issued ticket, unless the either "forwarded" or
"proxy" option is set. If the "forwarded" option is set, and the
ticket in the TGS-REQ has its "forwardable" flag set, the KDC copies
the addresses from the TGS-REQ, not the from TGS-REQ ticket, into the
issued ticket. The KDC behaves similarly if the "proxy" option is
set in the TGS-REQ and the "proxiable" flag is set in the ticket.
The "proxy" option will not be honored on requests for additional
ticket-granting tickets.
10.3.6. Ticket Flag Processing
Many kdc-options request that the KDC set a corresponding flag in the
issued ticket. kdc-options marked with an asterisk (*) in the
following table do not directly request the corresponding ticket flag
and therefore require special handling.
Yu Expires: Jan 2005 [Page 35]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
|
kdc-option | ticket flag affected
-------------------------+--------------------------
forwardable | forwardable
forwarded | forwarded
proxiable | proxiable
proxy | proxy
allow-postdate | may-postdate
postdated | postdated
renewable | renewable
requestanonymous | anonymous
canonicalize | -
disable-transited-check* | transited-policy-checked
renewable-ok* | renewable
enc-tkt-in-skey | -
renew | -
validate* | invalid
forwarded
The KDC sets the "forwarded" flag in the issued ticket if the
"forwarded" option is set in the TGS-REQ and the "forwardable"
flag is set in the TGS-REQ ticket.
proxy
The KDC sets the "proxy" flag in the issued ticket if the
"proxy" option is set in the TGS-REQ and the "proxiable" flag is
set in the TGS-REQ ticket.
disable-transited-check
The handling of the "disable-transited-check" kdc-option is
described in Section 10.3.4.
renewable-ok
The handling of the "renewable-ok" kdc-option is described in
Section 10.3.3.1.
validate
If the "validate" kdc-option is set in a TGS-REQ, and the
"starttime" has passed, the KDC will clear the "invalid" bit on
the ticket before re-issuing it.
10.3.7. Key Selection
Three keys are involved in creating a KDC-REP. The reply key
encrypts the encrypted part of the KDC-REP. The session key is
stored in the encrypted part of the ticket, and is also present in
the encrypted part of the KDC-REP so that the client can retrieve it.
The ticket key is used to encrypt the ticket. These keys all have
initial values for a given exchange; pre-authentication and other
extension mechanisms may change the value used for any of these keys.
Yu Expires: Jan 2005 [Page 36]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
[ again, may need changes based on Sam's preauth draft ]
10.3.7.1. Reply Key and Session Key Selection
The set of encryption types which the client will understand appears
in the "etype" field of KDC-REQ-BODY-COMMON. The KDC limits the set
of possible reply keys and the set of session key encryption types
based on the "etype" field.
For the AS exchange, the reply key is initially a long-term key of
the client, limited to those encryption types listed in the "etype"
field. The KDC SHOULD use the first valid strong "etype" for which
an encryption key is available. For the TGS exchange, the reply key
is initially the subsession key of the Authenticator. If the
Authenticator subsesion key is absent, the reply key is initially the
session key of the ticket used to authenticate the TGS-REQ.
The session key is initially randomly generated, and has an
encryption type which both the client and the server will understand.
Typically, the KDC has prior knowledge of which encryption types the
server will understand. It selects the first valid strong "etype"
listed the request which the server also will understand.
10.3.7.2. Ticket Key Selection
The ticket key is initially the long-term key of the service. The
"enc-tkt-in-skey" option requests user-to-user authentication, where
the ticket encryption key of the issued ticket is set equal to the
session key of the additional ticket in the request.
10.4. Reply Validation
11. Session Key Exchange
Session key exchange consists of the AP-REQ and AP-REP messages. The
client sends the AP-REQ message, and the service responds with an AP-
REP message if mutual authentication is desired. Following session
key exchange, the client and service share a secret session key, or
possibly a subsesion key, which can be used to protect further
communications. Additionally, the session key exchange process can
establish initial sequence numbers which the client and service can
use to detect replayed messages.
11.1. AP-REQ
An AP-REQ message contains a ticket and a authenticator. The
authenticator is ciphertext encrypted with the session key contained
in the ticket. The plaintext contents of the authenticator are:
Yu Expires: Jan 2005 [Page 37]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
-- plaintext of authenticator
Authenticator ::= [APPLICATION 2] SEQUENCE {
authenticator-vno [0] INTEGER (5),
crealm [1] Realm,
cname [2] PrincipalName,
cksum [3] Checksum {{ key-session },
{ ku-Authenticator-cksum |
ku-pa-TGSReq-cksum }} OPTIONAL,
cusec [4] Microseconds,
ctime [5] KerberosTime,
subkey [6] EncryptionKey OPTIONAL,
seq-number [7] SeqNum OPTIONAL,
authorization-data [8] AuthorizationData OPTIONAL
}
The common parts between the RFC 1510 and the extensible versions of
the AP-REQ are:
AP-REQ-COMMON ::= SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (14 | 18),
ap-options [2] APOptions,
ticket [3] Ticket,
authenticator [4] EncryptedData {
Authenticator,
{ key-session },
{ ku-APReq-authenticator |
ku-pa-TGSReq-authenticator }
},
...,
extensions [5] ApReqExtensions OPTIONAL,
...
}
The complete definition of AP-REQ is:
AP-REQ ::= CHOICE {
rfc1510 [APPLICATION 14] AP-REQ-1510,
ext [APPLICATION 18] Signed {
AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
}
}
Yu Expires: Jan 2005 [Page 38]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
AP-REQ-COMMON ::= SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (14 | 18),
ap-options [2] APOptions,
ticket [3] Ticket,
authenticator [4] EncryptedData {
Authenticator,
{ key-session },
{ ku-APReq-authenticator |
ku-pa-TGSReq-authenticator }
},
...,
extensions [5] ApReqExtensions OPTIONAL,
...
}
AP-REQ-1510 ::= SEQUENCE {
COMPONENTS OF AP-REQ-COMMON
} (WITH COMPONENTS {
...,
msg-type (14),
authenticator (EncryptedData {
Authenticator (WITH COMPONENTS {
...,
crealm (RealmIA5),
cname (PrincipalNameIA5),
seqnum (UInt32)
}), { key-session }, { ku-APReq-authenticator }})
})
AP-REQ-EXT ::= AP-REQ-COMMON
(WITH COMPONENTS {
...,
msg-type (18),
-- The following constraints on Authenticator assume that
-- we want to restrict the use of AP-REQ-EXT with TicketExt
-- only, since that is the only way we can enforce UTF-8.
authenticator (EncryptedData {
Authenticator (WITH COMPONENTS {
...,
crealm (RealmExt),
cname (PrincipalNameExt),
authorization-data (SIZE (1..MAX))
}), { key-session }, { ku-APReq-authenticator }})
})
Yu Expires: Jan 2005 [Page 39]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
APOptions ::= KerberosFlags { APOptionsBits }
APOptionsBits ::= BIT STRING {
reserved (0),
use-session-key (1),
mutual-required (2)
}
11.2. AP-REP
EncAPRepPart ::= CHOICE {
rfc1510 [APPLICATION 27] EncAPRepPart1510,
ext [APPLICATION 31] EncAPRepPartExt
}
EncAPRepPartCom ::= SEQUENCE {
ctime [0] KerberosTime,
cusec [1] Microseconds,
subkey [2] EncryptionKey OPTIONAL,
seq-number [3] SeqNum OPTIONAL,
...,
authorization-data [4] AuthorizationData OPTIONAL,
...
}
EncAPRepPart1510 ::= SEQUENCE {
COMPONENTS OF ENCAPRepPartCom
} (WITH COMPONENTS {
...,
seq-number (UInt32),
authorization-data ABSENT
})
EncAPRepPartExt ::= EncAPRepPartCom
AP-REP ::= CHOICE {
rfc1510 [APPLICATION 15] AP-REP-1510,
ext [APPLICATION 19] Signed {
AP-REP-EXT,
{ key-session | key-subsession }, { ku-APRep-cksum }}
}
Yu Expires: Jan 2005 [Page 40]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
AP-REP-COMMON { EncPart } ::= SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (15 | 19),
enc-part [2] EncryptedData {
EncPart,
{ key-session | key-subsession }, { ku-EncAPRepPart }},
...,
extensions [3] ApRepExtensions OPTIONAL,
...
}
AP-REP-1510 ::= SEQUENCE {
COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
} (WITH COMPONENTS {
...,
msg-type (15)
})
AP-REP-EXT ::= [APPLICATION 19] AP-REP-COMMON {
EncAPRepPartExt
} (WITH COMPONENTS { ..., msg-type (19) })
12. Session Key Use
12.1. KRB-SAFE
-- Do we chew up another tag for KRB-SAFE-EXT? That would
-- allow us to make safe-body optional, allowing for a GSS-MIC
-- sort of message.
KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (20),
safe-body [2] KRB-SAFE-BODY,
cksum [3] ChecksumOf {
KRB-SAFE-BODY,
{ key-session | key-subsession }, { ku-KrbSafe-cksum }},
... -- ASN.1 extensions must be excluded
-- when sending to rfc1510 implementations
}
Yu Expires: Jan 2005 [Page 41]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
KRB-SAFE-BODY ::= SEQUENCE {
user-data [0] OCTET STRING,
timestamp [1] KerberosTime OPTIONAL,
usec [2] Microseconds OPTIONAL,
seq-number [3] SeqNum OPTIONAL,
s-address [4] HostAddress,
r-address [5] HostAddress OPTIONAL,
... -- ASN.1 extensions must be excluded
-- when sending to rfc1510 implementations
}
12.2. KRB-PRIV
KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (21),
enc-part [3] EncryptedData {
EncKrbPrivPart,
{ key-session | key-subsession }, { ku-EncKrbPrivPart }},
...
}
EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
user-data [0] OCTET STRING,
timestamp [1] KerberosTime OPTIONAL,
usec [2] Microseconds OPTIONAL,
seq-number [3] SeqNum OPTIONAL,
s-address [4] HostAddress -- sender's addr --,
r-address [5] HostAddress OPTIONAL -- recip's addr --,
... -- ASN.1 extensions must be excluded
-- when sending to rfc1510 implementations
}
12.3. KRB-CRED
KRB-CRED ::= CHOICE {
rfc1510 [APPLICATION 22] KRB-CRED-1510,
ext [APPLICATION 24] Signed {
KRB-CRED-EXT,
{ key-session | key-subsession }, { ku-KrbCred-cksum }}
}
Yu Expires: Jan 2005 [Page 42]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
KRB-CRED-COMMON ::= SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (22 | 24),
tickets [2] SEQUENCE OF Ticket,
enc-part [3] EncryptedData {
EncKrbCredPart,
{ key-session | key-subsession }, { ku-EncKrbCredPart }},
...
}
KRB-CRED-1510 ::= SEQUENCE {
COMPONENTS OF KRB-CRED-COMMON
} (WITH COMPONENTS { ..., msg-type (22) })
KRB-CRED-EXT ::= [APPLICATION 24] KRB-CRED-COMMON
(WITH COMPONENTS { ..., msg-type (24) })
EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
ticket-info [0] SEQUENCE OF KrbCredInfo,
nonce [1] Nonce OPTIONAL,
timestamp [2] KerberosTime OPTIONAL,
usec [3] Microseconds OPTIONAL,
s-address [4] HostAddress OPTIONAL,
r-address [5] HostAddress OPTIONAL
}
KrbCredInfo ::= SEQUENCE {
key [0] EncryptionKey,
prealm [1] Realm OPTIONAL,
pname [2] PrincipalName OPTIONAL,
flags [3] TicketFlags OPTIONAL,
authtime [4] KerberosTime OPTIONAL,
starttime [5] KerberosTime OPTIONAL,
endtime [6] KerberosTime OPTIONAL,
renew-till [7] KerberosTime OPTIONAL,
srealm [8] Realm OPTIONAL,
sname [9] PrincipalName OPTIONAL,
caddr [10] HostAddresses OPTIONAL
}
13. Security Considerations
13.1. Time Synchronization
Time synchronization between the KDC and application servers is
necessary to prevent acceptance of expired tickets.
Yu Expires: Jan 2005 [Page 43]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
Time synchronization is needed between application servers and
clients to prevent replay attacks if a replay cache is being used.
If negotiated subsession keys are used to encrypt application data,
replay caches may not be necessary.
13.2. Replays
13.3. Principal Name Reuse
See Section 7.3.
13.4. Password Guessing
13.5. Forward Secrecy
[from KCLAR 10.; needs some rewriting]
The Kerberos protocol in its basic form does not provide perfect
forward secrecy for communications. If traffic has been recorded by
an eavesdropper, then messages encrypted using the KRB-PRIV message,
or messages encrypted using application-specific encryption under
keys exchanged using Kerberos can be decrypted if any of the user's,
application server's, or KDC's key is subsequently discovered. This
is because the session key used to encrypt such messages is
transmitted over the network encrypted in the key of the application
server, and also encrypted under the session key from the user's
ticket-granting ticket when returned to the user in the TGS-REP
message. The session key from the ticket-granting ticket was sent to
the user in the AS-REP message encrypted in the user's secret key,
and embedded in the ticket-granting ticket, which was encrypted in
the key of the KDC. Application requiring perfect forward secrecy
must exchange keys through mechanisms that provide such assurance,
but may use Kerberos for authentication of the encrypted channel
established through such other means.
13.6. Authorization
As an authentication service, Kerberos provides a means of verifying
the identity of principals on a network. Kerberos does not, by
itself, provide authorization. Applications SHOULD NOT accept the
mere issuance of a service ticket by the Kerberos server as granting
authority to use the service.
13.7. Login Authentication
Some applications, particularly those which provide login access when
provided with a password, SHOULD NOT treat successful acquisition of
credentials as sufficient proof of the user's identity. An attacker
posing as a user could generate an illegitimate KDC-REP message which
decrypts properly. To authenticate a user logging on to a local
system, the credentials obtained SHOULD be used in a TGS exchange to
Yu Expires: Jan 2005 [Page 44]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
obtain credentials for a local service. Successful use of those
credentials to authenticate to the local service assures that the
initially obtained credentials are from a valid KDC.
14. Acknowledgments
Some stuff lifted from draft-ietf-krb-wg-kerberos-clarifications-06.
Appendices
A. ASN.1 Module (Normative)
KerberosV5Spec3 {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) krb5spec3(4)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
-- OID arc for KerberosV5
--
-- This OID may be used to identify Kerberos protocol messages
-- encapsulated in other protocols.
--
-- This OID also designates the OID arc for KerberosV5-related
-- OIDs.
--
-- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its
-- OID.
id-krb5 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2)
}
Yu Expires: Jan 2005 [Page 45]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
-- top-level type
--
-- Applications should not directly reference any types
-- other than KRB-PDU and its component types.
--
KRB-PDU ::= CHOICE {
ticket Ticket,
as-req AS-REQ,
as-rep AS-REP,
tgs-req TGS-REQ,
tgs-rep TGS-REP,
ap-req AP-REQ,
ap-rep AP-REP,
krb-safe KRB-SAFE,
krb-priv KRB-PRIV,
krb-cred KRB-CRED,
tgt-req TGT-REQ,
krb-error KRB-ERROR,
...
}
--
-- *** basic types
--
-- signed values representable in 32 bits
--
-- These are often used as assigned numbers for various things.
Int32 ::= INTEGER (-2147483648..2147483647)
-- unsigned 32 bit values
UInt32 ::= INTEGER (0..4294967295)
-- unsigned 64 bit values
UInt64 ::= INTEGER (0..18446744073709551615)
-- microseconds
Microseconds ::= INTEGER (0..999999)
-- sequence numbers
SeqNum ::= UInt64
-- nonces
Nonce ::= UInt64
Yu Expires: Jan 2005 [Page 46]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
-- must not have fractional seconds
KerberosTime ::= GeneralizedTime
-- used for names and for error messages
KerberosString ::= CHOICE {
ia5 GeneralString (IA5String),
utf8 UTF8String,
... -- no extension may be sent
-- to an rfc1510 implementation --
}
-- IA5 choice only; useful for constraints
KerberosStringIA5 ::= KerberosString
(WITH COMPONENTS { ia5 PRESENT })
-- IA5 excluded; useful for constraints
KerberosStringExt ::= KerberosString
(WITH COMPONENTS { ia5 ABSENT })
-- used for language tags
LangTag ::= PrintableString
(FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
-- assigned numbers for name types (used in principal names)
NameType ::= Int32
-- Name type not known
nt-unknown NameType ::= 0
-- Just the name of the principal as in DCE, or for users
nt-principal NameType ::= 1
-- Service and other unique instance (krbtgt)
nt-srv-inst NameType ::= 2
-- Service with host name as instance (telnet, rcommands)
nt-srv-hst NameType ::= 3
-- Service with host as remaining components
nt-srv-xhst NameType ::= 4
-- Unique ID
nt-uid NameType ::= 5
-- Encoded X.509 Distingished name [RFC 2253]
nt-x500-principal NameType ::= 6
-- Name in form of SMTP email name (e.g. user@foo.com)
nt-smtp-name NameType ::= 7
-- Enterprise name - may be mapped to principal name
nt-enterprise NameType ::= 10
Yu Expires: Jan 2005 [Page 47]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
PrincipalName ::= SEQUENCE {
name-type [0] NameType,
-- May have zero elements, or individual elements may be
-- zero-length, but this is not recommended.
name-string [1] SEQUENCE OF KerberosString
}
-- IA5 only
PrincipalNameIA5 ::= PrincipalName (WITH COMPONENTS {
...,
name-string (WITH COMPONENT (KerberosStringIA5))
})
-- IA5 excluded
PrincipalNameExt ::= PrincpalName (WITH COMPONENTS {
...,
name-string (WITH COMPONENT (KerberosStringExt))
})
Realm ::= KerberosString
-- IA5 only
RealmIA5 ::= Realm (KerberosStringIA5)
-- IA5 excluded
RealmExt ::= Realm (KerberosStringExt)
-- Yet another refinement to kludge around historical
-- implementation bugs... we still send at least 32 bits, but
-- this parameterized type allows us to actually use named bit
-- string syntax to define flags, sort of.
KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
(CONSTRAINED BY {
-- must be a valid value of -- NamedBits
-- but if the value to be sent would otherwise be shorter
-- than 32 bits, it must be padded with trailing zero bits
-- to 32 bits. Otherwise, no trailing zero bits may be
-- present.
})
Yu Expires: Jan 2005 [Page 48]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
AddrType ::= Int32
HostAddress ::= SEQUENCE {
addr-type [0] AddrType,
address [1] OCTET STRING
}
-- NOTE: HostAddresses is always used as an OPTIONAL field and
-- should not be a zero-length SEQUENCE OF.
--
-- The extensible messages explicitly constrain this to be
-- non-empty.
HostAddresses ::= SEQUENCE OF HostAddress
--
-- *** crypto-related types and assignments
--
-- Assigned numbers denoting encryption mechanisms.
EType ::= Int32
-- assigned numbers for encryption schemes
et-des-cbc-crc EType ::= 1
et-des-cbc-md4 EType ::= 2
et-des-cbc-md5 EType ::= 3
-- [reserved] 4
et-des3-cbc-md5 EType ::= 5
-- [reserved] 6
et-des3-cbc-sha1 EType ::= 7
et-dsaWithSHA1-CmsOID EType ::= 9
et-md5WithRSAEncryption-CmsOID EType ::= 10
et-sha1WithRSAEncryption-CmsOID EType ::= 11
et-rc2CBC-EnvOID EType ::= 12
et-rsaEncryption-EnvOID EType ::= 13
et-rsaES-OAEP-ENV-OID EType ::= 14
et-des-ede3-cbc-Env-OID EType ::= 15
et-des3-cbc-sha1-kd EType ::= 16
-- AES
et-aes128-cts-hmac-sha1-96 EType ::= 17
-- AES
et-aes256-cts-hmac-sha1-96 EType ::= 18
-- Microsoft
et-rc4-hmac EType ::= 23
-- Microsoft
et-rc4-hmac-exp EType ::= 24
-- opaque; PacketCable
et-subkey-keymaterial EType ::= 65
Yu Expires: Jan 2005 [Page 49]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
-- Assigned numbers denoting key usages.
KeyUsage ::= UInt32
--
-- Actual identifier names are provisional and subject to
-- change.
--
ku-pa-enc-ts KeyUsage ::= 1
ku-Ticket KeyUsage ::= 2
ku-EncASRepPart KeyUsage ::= 3
ku-TGSReqAuthData-sesskey KeyUsage ::= 4
ku-TGSReqAuthData-subkey KeyUsage ::= 5
ku-pa-TGSReq-cksum KeyUsage ::= 6
ku-pa-TGSReq-authenticator KeyUsage ::= 7
ku-EncTGSRepPart-sesskey KeyUsage ::= 8
ku-EncTGSRepPart-subkey KeyUsage ::= 9
ku-Authenticator-cksum KeyUsage ::= 10
ku-APReq-authenticator KeyUsage ::= 11
ku-EncAPRepPart KeyUsage ::= 12
ku-EncKrbPrivPart KeyUsage ::= 13
ku-EncKrbCredPart KeyUsage ::= 14
ku-KrbSafe-cksum KeyUsage ::= 15
ku-ad-KDCIssued-cksum KeyUsage ::= 19
-- The following numbers are provisional...
-- conflicts may exist elsewhere.
ku-Ticket-cksum KeyUsage ::= 25
ku-ASReq-cksum KeyUsage ::= 26
ku-TGSReq-cksum KeyUsage ::= 27
ku-ASRep-cksum KeyUsage ::= 28
ku-TGSRep-cksum KeyUsage ::= 29
ku-APReq-cksum KeyUsage ::= 30
ku-APRep-cksum KeyUsage ::= 31
ku-KrbCred-cksum KeyUsage ::= 32
ku-KrbError-cksum KeyUsage ::= 33
ku-KDCRep-cksum KeyUsage ::= 34
Yu Expires: Jan 2005 [Page 50]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
-- KeyToUse identifies which key is to be used to encrypt or
-- sign a given value.
--
-- Values of KeyToUse are never actually transmitted over the
-- wire, or even used directly by the implementation in any
-- way, as key usages are; it exists primarily to identify
-- which key gets used for what purpose. Thus, the specific
-- numeric values associated with this type are irrelevant.
KeyToUse ::= ENUMERATED {
-- unspecified
key-unspecified,
-- server long term key
key-server,
-- client long term key
key-client,
-- key selected by KDC for encryption of a KDC-REP
key-kdc-rep,
-- session key from ticket
key-session,
-- subsession key negotiated via AP-REQ/AP-REP
key-subsession,
...
}
EncryptionKey ::= SEQUENCE {
keytype [0] EType,
keyvalue [1] OCTET STRING
}
Yu Expires: Jan 2005 [Page 51]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
-- "Type" specifies which ASN.1 type is encrypted to the
-- ciphertext in the EncryptedData. "Keys" specifies a set of
-- keys of which one key may be used to encrypt the data.
-- "KeyUsages" specifies a set of key usages, one of which may
-- be used to encrypt.
--
-- None of the parameters is transmitted over the wire.
EncryptedData {
Type, KeyToUse:Keys, KeyUsage:KeyUsages
} ::= SEQUENCE {
etype [0] EType,
kvno [1] UInt32 OPTIONAL,
cipher [2] OCTET STRING (CONSTRAINED BY {
-- must be encryption of --
OCTET STRING (CONTAINING Type),
-- with one of the keys -- KeyToUse:Keys,
-- with key usage being one of --
KeyUsage:KeyUsages
}),
...
}
CksumType ::= Int32
-- The parameters specify which key to use to produce the
-- signature, as well as which key usage to use. The
-- parameters are not actually sent over the wire.
Checksum {
KeyToUse:Keys, KeyUsage:KeyUsages
} ::= SEQUENCE {
cksumtype [0] CksumType,
checksum [1] OCTET STRING (CONSTRAINED BY {
-- signed using one of the keys --
KeyToUse:Keys,
-- with key usage being one of --
KeyUsage:KeyUsages
})
}
Yu Expires: Jan 2005 [Page 52]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
-- a Checksum that must contain the checksum
-- of a particular type
ChecksumOf {
Type, KeyToUse:Keys, KeyUsage:KeyUsages
} ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
...,
checksum (CONSTRAINED BY {
-- must be checksum of --
OCTET STRING (CONTAINING Type)
})
})
-- parameterized type for wrapping authenticated plaintext
Signed {
InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
} ::= SEQUENCE {
cksum [0] ChecksumOf {
InnerType, Keys, KeyUsages
} OPTIONAL,
inner [1] InnerType,
...
}
--
-- *** Tickets
--
Ticket ::= CHOICE {
rfc1510 [APPLICATION 1] Ticket1510,
ext [APPLICATION 4] Signed {
TicketExt, { key-server }, { ku-Ticket-cksum }
}
}
-- takes a parameter specifying which type gets encrypted
TicketCommon { EncPart } ::= SEQUENCE {
tkt-vno [0] INTEGER (5),
realm [1] Realm,
sname [2] PrincipalName,
enc-part [3] EncryptedData {
EncPart, { key-server }, { ku-Ticket }
},
...,
extensions [4] TicketExtensions OPTIONAL,
...
}
Yu Expires: Jan 2005 [Page 53]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
Ticket1510 ::= SEQUENCE {
COMPONENTS OF TicketCommon { EncTicketPart1510 }
} (WITH COMPONENTS {
...,
-- explicitly force IA5 in strings
realm (RealmIA5),
sname (PrincipalNameIA5)
})
-- APPLICATION tag goes inside Signed{} as well as outside,
-- to prevent possible substitution attacks.
TicketExt ::= [APPLICATION 4] TicketCommon {
EncTicketPartExt
} (WITH COMPONENTS {
...,
-- explicitly force UTF-8 in strings
realm (RealmExt),
sname (PrincipalNameExt)
})
-- Encrypted part of ticket
EncTicketPart ::= CHOICE {
rfc1510 [APPLICATION 3] EncTicketPart1510,
ext [APPLICATION 5] EncTicketPartExt
}
EncTicketPartCommon ::= SEQUENCE {
flags [0] TicketFlags,
key [1] EncryptionKey,
crealm [2] Realm,
cname [3] PrincipalName,
transited [4] TransitedEncoding,
authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL,
caddr [9] HostAddresses OPTIONAL,
authorization-data [10] AuthorizationData OPTIONAL,
...
}
Yu Expires: Jan 2005 [Page 54]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
EncTicketPart1510 ::= SEQUENCE {
COMPONENTS OF EncTicketPartCommon
} (WITH COMPONENTS {
...,
-- explicitly force IA5 in strings
crealm (RealmIA5),
cname (PrincipalNameIA5)
})
EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS {
...,
-- explicitly force UTF-8 in strings
crealm (RealmExt),
cname (PrincipalNameExt),
-- explicitly constrain caddr to be non-empty if present
caddr (SIZE (1..MAX)),
-- forbid empty authorization-data encodings
authorization-data (SIZE (1..MAX))
})
--
-- *** Authorization Data
--
ADType ::= Int32
AuthorizationData ::= SEQUENCE OF SEQUENCE {
ad-type [0] ADType,
ad-data [1] OCTET STRING
}
ad-if-relevant ADType ::= 1
-- Encapsulates another AuthorizationData.
-- Intended for application servers; receiving application servers
-- MAY ignore.
AD-IF-RELEVANT ::= AuthorizationData
}
Yu Expires: Jan 2005 [Page 55]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
-- KDC-issued privilege attributes
ad-kdcissued ADType ::= 4
AD-KDCIssued ::= SEQUENCE {
ad-checksum [0] ChecksumOf {
AuthorizationData, { key-session },
{ ku-ad-KDCIssued-cksum }},
i-realm [1] Realm OPTIONAL,
i-sname [2] PrincipalName OPTIONAL,
elements [3] AuthorizationData
}
ad-and-or ADType ::= 5
AD-AND-OR ::= SEQUENCE {
condition-count [0] INTEGER,
elements [1] AuthorizationData
}
-- KDCs MUST interpret any AuthorizationData wrapped in this.
ad-mandatory-for-kdc ADType ::= 8
AD-MANDATORY-FOR-KDC ::= AuthorizationData
TrType ::= Int32 -- must be registered
-- encoded Transited field
TransitedEncoding ::= SEQUENCE {
tr-type [0] TrType,
contents [1] OCTET STRING
}
TEType ::= Int32
-- ticket extensions: for TicketExt only
TicketExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
te-type [0] TEType,
te-data [1] OCTET STRING
}
Yu Expires: Jan 2005 [Page 56]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
TicketFlags ::= KerberosFlags { TicketFlagsBits }
TicketFlagsBits ::= BIT STRING {
reserved (0),
forwardable (1),
forwarded (2),
proxiable (3),
proxy (4),
may-postdate (5),
postdated (6),
invalid (7),
renewable (8),
initial (9),
pre-authent (10),
hw-authent (11),
transited-policy-checked (12),
ok-as-delegate (13),
anonymous (14),
cksummed-ticket (15)
}
--
-- *** KDC protocol
--
AS-REQ ::= CHOICE {
rfc1510 [APPLICATION 10] KDC-REQ-1510
(WITH COMPONENTS {
...,
msg-type (10),
-- AS-REQ must include client name
req-body (WITH COMPONENTS { ..., cname PRESENT })
}),
ext [APPLICATION 6] Signed {
-- APPLICATION tag goes inside Signed{} as well as
-- outside, to prevent possible substitution attacks.
[APPLICATION 6] KDC-REQ-EXT,
-- not sure this is correct key to use; do we even want
-- to sign AS-REQ?
{ key-client },
{ ku-ASReq-cksum }
}
(WITH COMPONENTS {
...,
msg-type (6),
-- AS-REQ must include client name
req-body (WITH COMPONENTS { ..., cname PRESENT })
})
}
Yu Expires: Jan 2005 [Page 57]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
TGS-REQ ::= CHOICE {
rfc1510 [APPLICATION 12] KDC-REQ-1510
(WITH COMPONENTS {
...,
msg-type (12),
-- client name optional in TGS-REQ
req-body (WITH COMPONENTS { ..., cname ABSENT })
}),
ext [APPLICATION 8] Signed {
-- APPLICATION tag goes inside Signed{} as well as
-- outside, to prevent possible substitution attacks.
[APPLICATION 8] KDC-REQ-EXT,
{ key-session }, { ku-TGSReq-cksum }
}
(WITH COMPONENTS {
...,
msg-type (8),
-- client name optional in TGS-REQ
req-body (WITH COMPONENTS { ..., cname ABSENT })
})
}
KDC-REQ-COMMON ::= SEQUENCE {
-- NOTE: first tag is [1], not [0]
pvno [1] INTEGER (5),
msg-type [2] INTEGER (10 -- AS-REQ.rfc1510 --
| 12 -- TGS-REQ.rfc1510 --
| 6 -- AS-REQ.ext --
| 8 -- TGS-REQ.ext -- ),
padata [3] SEQUENCE OF PA-DATA OPTIONAL
-- NOTE: not empty
}
KDC-REQ-1510 ::= SEQUENCE {
COMPONENTS OF KDC-REQ-COMMON,
req-body [4] KDC-REQ-BODY-1510
} (WITH COMPONENTS { ..., msg-type (10 | 12) })
Yu Expires: Jan 2005 [Page 58]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
-- APPLICATION tag goes inside Signed{} as well as outside,
-- to prevent possible substitution attacks.
KDC-REQ-EXT ::= SEQUENCE {
COMPONENTS OF KDC-REQ-COMMON,
req-body [4] KDC-REQ-BODY-EXT,
lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF
LangTag OPTIONAL,
...
} (WITH COMPONENTS {
...,
msg-type (6 | 8),
padata (SIZE (1..MAX))
})
KDC-REQ-BODY-COMMON ::= SEQUENCE {
kdc-options [0] KDCOptions,
cname [1] PrincipalName OPTIONAL
-- Used only in AS-REQ --,
realm [2] Realm
-- Server's realm; also client's in AS-REQ --,
sname [3] PrincipalName OPTIONAL,
from [4] KerberosTime OPTIONAL,
till [5] KerberosTime OPTIONAL
-- was required in rfc1510;
-- still required for compat versions
-- of messages --,
rtime [6] KerberosTime OPTIONAL,
nonce [7] Nonce,
etype [8] SEQUENCE OF EType
-- in preference order --,
addresses [9] HostAddresses OPTIONAL,
enc-authorization-data [10] EncryptedData {
AuthorizationData, { key-session | key-subsession },
{ ku-TGSReqAuthData-subkey |
ku-TGSReqAuthData-sesskey }
} OPTIONAL,
additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
-- NOTE: not empty --,
...
}
Yu Expires: Jan 2005 [Page 59]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
KDC-REQ-BODY-1510 ::= SEQUENCE {
COMPONENTS OF KDC-REQ-BODY-COMMON
} (WITH COMPONENTS {
...,
cname (PrincipalNameIA5),
realm (RealmIA5),
sname (PrincipalNameIA5),
till PRESENT,
nonce (UInt32)
})
KDC-REQ-BODY-EXT ::= KDC-REQ-BODY-COMMON
(WITH COMPONENTS {
...,
cname (PrincipalNameExt),
realm (RealmExt),
sname (PrincipalNameExt),
addresses (SIZE (1..MAX)),
enc-authorization-data (EncryptedData {
AuthorizationData (SIZE (1..MAX)),
{ key-session | key-subsession },
{ ku-TGSReqAuthData-subkey |
ku-TGSReqAuthData-sesskey }
}),
additional-tickets (SIZE (1..MAX))
})
Yu Expires: Jan 2005 [Page 60]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
KDCOptions ::= KerberosFlags { KDCOptionsBits }
KDCOptionsBits ::= BIT STRING {
reserved (0),
forwardable (1),
forwarded (2),
proxiable (3),
proxy (4),
allow-postdate (5),
postdated (6),
unused7 (7),
renewable (8),
unused9 (9),
unused10 (10),
unused11 (11),
unused12 (12),
unused13 (13),
requestanonymous (14),
canonicalize (15),
disable-transited-check (26),
renewable-ok (27),
enc-tkt-in-skey (28),
renew (30),
validate (31)
-- XXX need "need ticket1" flag?
}
AS-REP ::= CHOICE {
rfc1510 [APPLICATION 11] KDC-REP-1510 {
EncASRepPart1510
} (WITH COMPONENTS { ..., msg-type (11) }),
ext [APPLICATION 7] Signed {
[APPLICATION 7] KDC-REP-EXT { EncASRepPartExt },
{ key-reply }, { ku-ASRep-cksum }
} (WITH COMPONENTS { ..., msg-type (7) })
}
TGS-REP ::= CHOICE {
rfc1510 [APPLICATION 13] KDC-REP-1510 {
EncTGSRepPart1510
} (WITH COMPONENTS { ..., msg-type (13) }),
ext [APPLICATION 9] Signed {
[APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
{ key-reply }, { ku-TGSRep-cksum }
} (WITH COMPONENTS { ..., msg-type (9) })
}
Yu Expires: Jan 2005 [Page 61]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
KDC-REP-COMMON { EncPart } ::= SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (11 -- AS-REP.rfc1510 -- |
13 -- TGS.rfc1510 -- |
7 -- AS-REP.ext -- |
9 -- TGS-REP.ext -- ),
padata [2] SEQUENCE OF PA-DATA OPTIONAL,
crealm [3] Realm,
cname [4] PrincipalName,
ticket [5] Ticket,
enc-part [6] EncryptedData {
EncPart,
{ key-reply },
-- maybe reach into EncryptedData in AS-REP/TGS-REP
-- definitions to apply constraints on key usages?
{ ku-EncASRepPart -- if AS-REP -- |
ku-EncTGSRepPart-subkey -- if TGS-REP and
-- using Authenticator
-- session key -- |
ku-EncTGSRepPart-sesskey -- if TGS-REP and using
-- subsession key -- }
},
...,
-- In extensible version, KDC signs original request
-- to avoid replay attacks agaginst client.
req-cksum [7] ChecksumOf { CHOICE {
as-req AS-REQ,
tgs-req TGS-REQ
}, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
lang-tag [8] LangTag OPTIONAL,
...
}
KDC-REP-1510 { EncPart } ::= SEQUENCE {
COMPONENTS OF KDC-REP-COMMON { EncPart }
} (WITH COMPONENTS {
...,
msg-type (11 | 13),
crealm (RealmIA5),
cname (PrincipalNameIA5)
})
KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart }
(WITH COMPONENTS {
...,
msg-type (7 | 9),
crealm (RealmExt),
cname (PrincipalNameExt)
})
Yu Expires: Jan 2005 [Page 62]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
EncASRepPart1510 ::= [APPLICATION 25] EncKDCRepPart1510
EncTGSRepPart1510 ::= [APPLICATION 26] EncKDCRepPart1510
EncASRepPartExt ::= [APPLICATION 32] EncKDCRepPartExt
EncTGSRepPartExt ::= [APPLICATION 33] EncKDCRepPartExt
EncKDCRepPartCom ::= SEQUENCE {
key [0] EncryptionKey,
last-req [1] LastReq,
nonce [2] Nonce,
key-expiration [3] KerberosTime OPTIONAL,
flags [4] TicketFlags,
authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL,
srealm [9] Realm,
sname [10] PrincipalName,
caddr [11] HostAddresses OPTIONAL,
...
}
EncKDCRepPart1510 ::= SEQUENCE {
COMPONENTS OF EncKDCRepPartCom
} (WITH COMPONENTS {
...,
srealm (RealmIA5),
sname (PrincipalNameIA5),
nonce UInt32 })
EncKdcRepPartExt ::= EncKDCRepPartCom (WITH COMPONENTS {
...,
srealm (RealmExt),
sname (PrincipalNameExt)
})
LRType ::= Int32
LastReq ::= SEQUENCE OF SEQUENCE {
lr-type [0] LRType,
lr-value [1] KerberosTime
}
--
-- *** preauth
--
Yu Expires: Jan 2005 [Page 63]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
PaDataType ::= Int32
PaDataOID ::= RELATIVE-OID
PA-DATA ::= SEQUENCE {
-- NOTE: first tag is [1], not [0]
padata-type [1] CHOICE {
int PaDataType,
-- example of possible use
-- of RELATIVE-OIDs
oid PaDataOID
},
padata-value [2] OCTET STRING
}
PaDataSet PADATA-OBJ ::= {
pa-tgs-req |
pa-enc-timestamp |
pa-etype-info |
pa-etype-info2 |
pa-pw-salt |
pa-as-req ,
...
}
-- AP-REQ authenticating a TGS-REQ
pa-tgs-req PaDataType ::= 1
PA-TGS-REQ ::= AP-REQ
-- Encrypted timestamp preauth
-- Encryption key used is client's long-term key.
pa-enc-timestamp PaDataType ::= 2
PA-ENC-TIMESTAMP ::= EncryptedData {
PA-ENC-TS-ENC, { key-client }, { ku-pa-enc-ts }
}
PA-ENC-TS-ENC ::= SEQUENCE {
patimestamp [0] KerberosTime -- client's time --,
pausec [1] Microseconds OPTIONAL
}
Yu Expires: Jan 2005 [Page 64]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
-- Hints returned in AS-REP or KRB-ERROR to help client
-- choose a password-derived key, either for preauthentication
-- or for decryption of the reply.
pa-etype-info PaDataType ::= 11
ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY
ETYPE-INFO-ENTRY ::= SEQUENCE {
etype [0] EType,
salt [1] OCTET STRING OPTIONAL
}
-- Similar to etype-info, but with parameters provided for
-- the string-to-key function.
pa-etype-info2 PaDataType ::= 19
ETYPE-INFO2 ::= SEQUENCE (SIZE (1..MAX))
OF ETYPE-INFO-ENTRY
ETYPE-INFO2-ENTRY ::= SEQUENCE {
etype [0] EType,
salt [1] KerberosString OPTIONAL,
s2kparams [2] OCTET STRING OPTIONAL
}
-- Obsolescent. Salt for client's long-term key.
-- Its character encoding is unspecified.
pa-pw-salt PaDataType ::= 3
-- The "padata-value" does not encode an ASN.1 type.
-- Instead, "padata-value" must consist of the salt string to
-- be used by the client, in an unspecified character
-- encoding.
}
-- An extensible AS-REQ may be sent as a padata in a
-- non-extensible AS-REQ to allow for backwards compatibility.
pa-as-req PaDataType ::= 42 -- provisional
PA-AS-REQ ::= AS-REQ (WITH COMPONENTS ext)
--
-- *** Session key exchange
--
Yu Expires: Jan 2005 [Page 65]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
AP-REQ ::= CHOICE {
rfc1510 [APPLICATION 14] AP-REQ-1510,
ext [APPLICATION 18] Signed {
AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
}
}
AP-REQ-COMMON ::= SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (14 | 18),
ap-options [2] APOptions,
ticket [3] Ticket,
authenticator [4] EncryptedData {
Authenticator,
{ key-session },
{ ku-APReq-authenticator |
ku-pa-TGSReq-authenticator }
},
...,
extensions [5] ApReqExtensions OPTIONAL,
...
}
AP-REQ-1510 ::= SEQUENCE {
COMPONENTS OF AP-REQ-COMMON
} (WITH COMPONENTS {
...,
msg-type (14),
authenticator (EncryptedData {
Authenticator (WITH COMPONENTS {
...,
crealm (RealmIA5),
cname (PrincipalNameIA5),
seqnum (UInt32)
}), { key-session }, { ku-APReq-authenticator }})
})
Yu Expires: Jan 2005 [Page 66]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
AP-REQ-EXT ::= AP-REQ-COMMON
(WITH COMPONENTS {
...,
msg-type (18),
-- The following constraints on Authenticator assume that
-- we want to restrict the use of AP-REQ-EXT with TicketExt
-- only, since that is the only way we can enforce UTF-8.
authenticator (EncryptedData {
Authenticator (WITH COMPONENTS {
...,
crealm (RealmExt),
cname (PrincipalNameExt),
authorization-data (SIZE (1..MAX))
}), { key-session }, { ku-APReq-authenticator }})
})
ApReqExtType ::= Int32
ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
apReqExt-Type [0] ApReqExtType,
apReqExt-Data [1] OCTET STRING
}
APOptions ::= KerberosFlags { APOptionsBits }
APOptionsBits ::= BIT STRING {
reserved (0),
use-session-key (1),
mutual-required (2)
}
-- plaintext of authenticator
Authenticator ::= [APPLICATION 2] SEQUENCE {
authenticator-vno [0] INTEGER (5),
crealm [1] Realm,
cname [2] PrincipalName,
cksum [3] Checksum {{ key-session },
{ ku-Authenticator-cksum |
ku-pa-TGSReq-cksum }} OPTIONAL,
cusec [4] Microseconds,
ctime [5] KerberosTime,
subkey [6] EncryptionKey OPTIONAL,
seq-number [7] SeqNum OPTIONAL,
authorization-data [8] AuthorizationData OPTIONAL
}
Yu Expires: Jan 2005 [Page 67]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
AP-REP ::= CHOICE {
rfc1510 [APPLICATION 15] AP-REP-1510,
ext [APPLICATION 19] Signed {
AP-REP-EXT,
{ key-session | key-subsession }, { ku-APRep-cksum }}
}
AP-REP-COMMON { EncPart } ::= SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (15 | 19),
enc-part [2] EncryptedData {
EncPart,
{ key-session | key-subsession }, { ku-EncAPRepPart }},
...,
extensions [3] ApRepExtensions OPTIONAL,
...
}
AP-REP-1510 ::= SEQUENCE {
COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
} (WITH COMPONENTS {
...,
msg-type (15)
})
AP-REP-EXT ::= [APPLICATION 19] AP-REP-COMMON {
EncAPRepPartExt
} (WITH COMPONENTS { ..., msg-type (19) })
ApRepExtType ::= Int32
ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
apRepExt-Type [0] ApRepExtType,
apRepExt-Data [1] OCTET STRING
}
EncAPRepPart ::= CHOICE {
rfc1510 [APPLICATION 27] EncAPRepPart1510,
ext [APPLICATION 31] EncAPRepPartExt
}
Yu Expires: Jan 2005 [Page 68]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
EncAPRepPart1510 ::= SEQUENCE {
COMPONENTS OF ENCAPRepPartCom
} (WITH COMPONENTS {
...,
seq-number (UInt32),
authorization-data ABSENT
})
EncAPRepPartExt ::= EncAPRepPartCom
EncAPRepPartCom ::= SEQUENCE {
ctime [0] KerberosTime,
cusec [1] Microseconds,
subkey [2] EncryptionKey OPTIONAL,
seq-number [3] SeqNum OPTIONAL,
...,
authorization-data [4] AuthorizationData OPTIONAL,
...
}
--
-- *** Application messages
--
-- Do we chew up another tag for KRB-SAFE-EXT? That would
-- allow us to make safe-body optional, allowing for a GSS-MIC
-- sort of message.
KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (20),
safe-body [2] KRB-SAFE-BODY,
cksum [3] ChecksumOf {
KRB-SAFE-BODY,
{ key-session | key-subsession }, { ku-KrbSafe-cksum }},
... -- ASN.1 extensions must be excluded
-- when sending to rfc1510 implementations
}
Yu Expires: Jan 2005 [Page 69]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
KRB-SAFE-BODY ::= SEQUENCE {
user-data [0] OCTET STRING,
timestamp [1] KerberosTime OPTIONAL,
usec [2] Microseconds OPTIONAL,
seq-number [3] SeqNum OPTIONAL,
s-address [4] HostAddress,
r-address [5] HostAddress OPTIONAL,
... -- ASN.1 extensions must be excluded
-- when sending to rfc1510 implementations
}
KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (21),
enc-part [3] EncryptedData {
EncKrbPrivPart,
{ key-session | key-subsession }, { ku-EncKrbPrivPart }},
...
}
EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
user-data [0] OCTET STRING,
timestamp [1] KerberosTime OPTIONAL,
usec [2] Microseconds OPTIONAL,
seq-number [3] SeqNum OPTIONAL,
s-address [4] HostAddress -- sender's addr --,
r-address [5] HostAddress OPTIONAL -- recip's addr --,
... -- ASN.1 extensions must be excluded
-- when sending to rfc1510 implementations
}
KRB-CRED ::= CHOICE {
rfc1510 [APPLICATION 22] KRB-CRED-1510,
ext [APPLICATION 24] Signed {
KRB-CRED-EXT,
{ key-session | key-subsession }, { ku-KrbCred-cksum }}
}
KRB-CRED-COMMON ::= SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (22 | 24),
tickets [2] SEQUENCE OF Ticket,
enc-part [3] EncryptedData {
EncKrbCredPart,
{ key-session | key-subsession }, { ku-EncKrbCredPart }},
...
}
Yu Expires: Jan 2005 [Page 70]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
KRB-CRED-1510 ::= SEQUENCE {
COMPONENTS OF KRB-CRED-COMMON
} (WITH COMPONENTS { ..., msg-type (22) })
KRB-CRED-EXT ::= [APPLICATION 24] KRB-CRED-COMMON
(WITH COMPONENTS { ..., msg-type (24) })
EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
ticket-info [0] SEQUENCE OF KrbCredInfo,
nonce [1] Nonce OPTIONAL,
timestamp [2] KerberosTime OPTIONAL,
usec [3] Microseconds OPTIONAL,
s-address [4] HostAddress OPTIONAL,
r-address [5] HostAddress OPTIONAL
}
KrbCredInfo ::= SEQUENCE {
key [0] EncryptionKey,
prealm [1] Realm OPTIONAL,
pname [2] PrincipalName OPTIONAL,
flags [3] TicketFlags OPTIONAL,
authtime [4] KerberosTime OPTIONAL,
starttime [5] KerberosTime OPTIONAL,
endtime [6] KerberosTime OPTIONAL,
renew-till [7] KerberosTime OPTIONAL,
srealm [8] Realm OPTIONAL,
sname [9] PrincipalName OPTIONAL,
caddr [10] HostAddresses OPTIONAL
}
TGT-REQ ::= [APPLICATION 16] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (16),
sname [2] PrincipalName OPTIONAL,
srealm [3] Realm OPTIONAL,
...
}
--
-- *** Error messages
--
Yu Expires: Jan 2005 [Page 71]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
ErrCode ::= Int32
KRB-ERROR ::= CHOICE {
rfc1510 [APPLICATION 30] KRB-ERROR-1510,
ext [APPLICATION 23] Signed {
KRB-ERROR-EXT, { ku-KrbError-cksum } }
}
KRB-ERROR-COMMON ::= SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (30 | 23),
ctime [2] KerberosTime OPTIONAL,
cusec [3] Microseconds OPTIONAL,
stime [4] KerberosTime,
susec [5] Microseconds,
error-code [6] ErrCode,
crealm [7] Realm OPTIONAL,
cname [8] PrincipalName OPTIONAL,
realm [9] Realm -- Correct realm --,
sname [10] PrincipalName -- Correct name --,
e-text [11] KerberosString OPTIONAL,
e-data [12] OCTET STRING OPTIONAL,
...,
typed-data [13] TYPED-DATA OPTIONAL,
nonce [14] Nonce OPTIONAL,
lang-tag [15] LangTag OPTIONAL,
...
}
KRB-ERROR-1510 ::= SEQUENCE {
COMPONENTS OF KRB-ERROR-COMMON
} (WITH COMPONENTS {
...,
msg-type (30)
})
KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON
(WITH COMPONENTS { ..., msg-type (23) })
TDType ::= Int32
TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
data-type [0] TDType,
data-value [1] OCTET STRING OPTIONAL
}
Yu Expires: Jan 2005 [Page 72]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
--
-- *** Error codes
--
-- No error
kdc-err-none ErrCode ::= 0
-- Client's entry in database has expired
kdc-err-name-exp ErrCode ::= 1
-- Server's entry in database has expired
kdc-err-service-exp ErrCode ::= 2
-- Requested protocol version number not supported
kdc-err-bad-pvno ErrCode ::= 3
-- Client's key encrypted in old master key
kdc-err-c-old-mast-kvno ErrCode ::= 4
-- Server's key encrypted in old master key
kdc-err-s-old-mast-kvno ErrCode ::= 5
-- Client not found in Kerberos database
kdc-err-c-principal-unknown ErrCode ::= 6
-- Server not found in Kerberos database
kdc-err-s-principal-unknown ErrCode ::= 7
-- Multiple principal entries in database
kdc-err-principal-not-unique ErrCode ::= 8
-- The client or server has a null key
kdc-err-null-key ErrCode ::= 9
-- Ticket not eligible for postdating
kdc-err-cannot-postdate ErrCode ::= 10
-- Requested start time is later than end time
kdc-err-never-valid ErrCode ::= 11
-- KDC policy rejects request
kdc-err-policy ErrCode ::= 12
-- KDC cannot accommodate requested option
kdc-err-badoption ErrCode ::= 13
-- KDC has no support for encryption type
kdc-err-etype-nosupp ErrCode ::= 14
-- KDC has no support for checksum type
kdc-err-sumtype-nosupp ErrCode ::= 15
-- KDC has no support for padata type
kdc-err-padata-type-nosupp ErrCode ::= 16
-- KDC has no support for transited type
kdc-err-trtype-nosupp ErrCode ::= 17
-- Clients credentials have been revoked
kdc-err-client-revoked ErrCode ::= 18
-- Credentials for server have been revoked
kdc-err-service-revoked ErrCode ::= 19
-- TGT has been revoked
kdc-err-tgt-revoked ErrCode ::= 20
Yu Expires: Jan 2005 [Page 73]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
-- Client not yet valid - try again later
kdc-err-client-notyet ErrCode ::= 21
-- Server not yet valid - try again later
kdc-err-service-notyet ErrCode ::= 22
-- Password has expired - change password to reset
kdc-err-key-expired ErrCode ::= 23
-- Pre-authentication information was invalid
kdc-err-preauth-failed ErrCode ::= 24
-- Additional pre-authenticationrequired
kdc-err-preauth-required ErrCode ::= 25
-- Requested server and ticket don't match
kdc-err-server-nomatch ErrCode ::= 26
-- Server principal valid for user2user only
kdc-err-must-use-user2user ErrCode ::= 27
-- KDC Policy rejects transited path
kdc-err-path-not-accpeted ErrCode ::= 28
-- A service is not available
kdc-err-svc-unavailable ErrCode ::= 29
-- Integrity check on decrypted field failed
krb-ap-err-bad-integrity ErrCode ::= 31
-- Ticket expired
krb-ap-err-tkt-expired ErrCode ::= 32
-- Ticket not yet valid
krb-ap-err-tkt-nyv ErrCode ::= 33
-- Request is a replay
krb-ap-err-repeat ErrCode ::= 34
-- The ticket isn't for us
krb-ap-err-not-us ErrCode ::= 35
-- Ticket and authenticator don't match
krb-ap-err-badmatch ErrCode ::= 36
-- Clock skew too great
krb-ap-err-skew ErrCode ::= 37
-- Incorrect net address
krb-ap-err-badaddr ErrCode ::= 38
-- Protocol version mismatch
krb-ap-err-badversion ErrCode ::= 39
-- Invalid msg type
krb-ap-err-msg-type ErrCode ::= 40
Yu Expires: Jan 2005 [Page 74]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
-- Message stream modified
krb-ap-err-modified ErrCode ::= 41
-- Message out of order
krb-ap-err-badorder ErrCode ::= 42
-- Specified version of key is not available
krb-ap-err-badkeyver ErrCode ::= 44
-- Service key not available
krb-ap-err-nokey ErrCode ::= 45
-- Mutual authentication failed
krb-ap-err-mut-fail ErrCode ::= 46
-- Incorrect message direction
krb-ap-err-baddirection ErrCode ::= 47
-- Alternative authentication method required
krb-ap-err-method ErrCode ::= 48
-- Incorrect sequence number in message
krb-ap-err-badseq ErrCode ::= 49
-- Inappropriate type of checksum in message
krb-ap-err-inapp-cksum ErrCode ::= 50
-- Policy rejects transited path
krb-ap-path-not-accepted ErrCode ::= 51
-- Response too big for UDP, retry with TCP
krb-err-response-too-big ErrCode ::= 52
-- Generic error (description in e-text)
krb-err-generic ErrCode ::= 60
Yu Expires: Jan 2005 [Page 75]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
-- Field is too long for this implementation
krb-err-field-toolong ErrCode ::= 61
-- Reserved for PKINIT
kdc-error-client-not-trusted ErrCode ::= 62
-- Reserved for PKINIT
kdc-error-kdc-not-trusted ErrCode ::= 63
-- Reserved for PKINIT
kdc-error-invalid-sig ErrCode ::= 64
-- Reserved for PKINIT
kdc-err-key-too-weak ErrCode ::= 65
-- Reserved for PKINIT
kdc-err-certificate-mismatch ErrCode ::= 66
-- No TGT available to validate USER-TO-USER
krb-ap-err-no-tgt ErrCode ::= 67
-- USER-TO-USER TGT issued different KDC
kdc-err-wrong-realm ErrCode ::= 68
-- Ticket must be for USER-TO-USER
krb-ap-err-user-to-user-required ErrCode ::= 69
-- Reserved for PKINIT
kdc-err-cant-verify-certificate ErrCode ::= 70
-- Reserved for PKINIT
kdc-err-invalid-certificate ErrCode ::= 71
-- Reserved for PKINIT
kdc-err-revoked-certificate ErrCode ::= 72
-- Reserved for PKINIT
kdc-err-revocation-status-unknown ErrCode ::= 73
-- Reserved for PKINIT
kdc-err-revocation-status-unavailable ErrCode ::= 74
END
B. Kerberos and Character Encodings (Informative)
[adapted from KCLAR 5.2.1]
The original specification of the Kerberos protocol in RFC 1510 uses
GeneralString in numerous places for human-readable string data.
Historical implementations of Kerberos cannot utilize the full power
of GeneralString. This ASN.1 type requires the use of designation
and invocation escape sequences as specified in ISO 2022 | ECMA-35
[ISO2022] to switch character sets, and the default character set
that is designated as G0 is the ISO 646 | ECMA-6 [ISO646]
International Reference Version (IRV) (aka U.S. ASCII), which mostly
works.
ISO 2022 | ECMA-35 defines four character-set code elements (G0..G3)
and two Control-function code elements (C0..C1). DER previously
[X690-1997] prohibited the designation of character sets as any but
the G0 and C0 sets. This had the side effect of prohibiting the use
Yu Expires: Jan 2005 [Page 76]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
of (ISO Latin) character-sets such as ISO 8859-1 [ISO8859-1] or any
other character-sets that utilize a 96-character set, since it is
prohibited by ISO 2022 | ECMA-35 to designate them as the G0 code
element. Recent revisions to the ASN.1 standards resolve this
contradiction.
In practice, many implementations treat RFC 1510 GeneralStrings as if
they were 8-bit strings of whichever character set the implementation
defaults to, without regard for correct usage of character-set
designation escape sequences. The default character set is often
determined by the current user's operating system dependent locale.
At least one major implementation places unescaped UTF-8 encoded
Unicode characters in the GeneralString. This failure to conform to
the GeneralString specifications results in interoperability issues
when conflicting character encodings are utilized by the Kerberos
clients, services, and KDC.
This unfortunate situation is the result of improper documentation of
the restrictions of the ASN.1 GeneralString type in prior Kerberos
specifications.
[the following should probably be rewritten and moved into the
principal name section]
For compatibility, implementations MAY choose to accept GeneralString
values that contain characters other than those permitted by
IA5String, but they should be aware that character set designation
codes will likely be absent, and that the encoding should probably be
treated as locale-specific in almost every way. Implementations MAY
also choose to emit GeneralString values that are beyond those
permitted by IA5String, but should be aware that doing so is
extraordinarily risky from an interoperability perspective.
Some existing implementations use GeneralString to encode unescaped
locale-specific characters. This is a violation of the ASN.1
standard. Most of these implementations encode US-ASCII in the left-
hand half, so as long the implementation transmits only US-ASCII, the
ASN.1 standard is not violated in this regard. As soon as such an
implementation encodes unescaped locale-specific characters with the
high bit set, it violates the ASN.1 standard.
Other implementations have been known to use GeneralString to contain
a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8
is a different encoding, not a 94 or 96 character "G" set as defined
by ISO 2022. It is believed that these implementations do not even
use the ISO 2022 escape sequence to change the character encoding.
Even if implementations were to announce the change of encoding by
using that escape sequence, the ASN.1 standard prohibits the use of
any escape sequences other than those used to designate/invoke "G" or
"C" sets allowed by GeneralString.
Yu Expires: Jan 2005 [Page 77]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
C. Kerberos History (Informative)
[Adapted from KCLAR "BACKGROUND"]
The Kerberos model is based in part on Needham and Schroeder's
trusted third-party authentication protocol [NS78] and on
modifications suggested by Denning and Sacco [DS81]. The original
design and implementation of Kerberos Versions 1 through 4 was the
work of two former Project Athena staff members, Steve Miller of
Digital Equipment Corporation and Clifford Neuman (now at the
Information Sciences Institute of the University of Southern
California), along with Jerome Saltzer, Technical Director of Project
Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other
members of Project Athena have also contributed to the work on
Kerberos.
Version 5 of the Kerberos protocol (described in this document) has
evolved from Version 4 based on new requirements and desires for
features not available in Version 4. The design of Version 5 of the
Kerberos protocol was led by Clifford Neuman and John Kohl with much
input from the community. The development of the MIT reference
implementation was led at MIT by John Kohl and Theodore Ts'o, with
help and contributed code from many others. Since RFC1510 was
issued, extensions and revisions to the protocol have been proposed
by many individuals. Some of these proposals are reflected in this
document. Where such changes involved significant effort, the
document cites the contribution of the proposer.
Reference implementations of both version 4 and version 5 of Kerberos
are publicly available and commercial implementations have been
developed and are widely used. Details on the differences between
Kerberos Versions 4 and 5 can be found in [KNT94].
D. Notational Differences from [KCLAR]
[ possible point for discussion ]
[KCLAR] uses notational conventions slightly different from this
document. As a derivative of RFC 1510, the text of [KCLAR] uses C-
language style identifier names for defined values. In ASN.1
notation, identifiers referencing defined values must begin with a
lowercase letter and contain hyphen (-) characters rather than
underscore (_) characters, while identifiers referencing types begin
with an uppercase letter. [KCLAR] and RFC 1510 use all-uppercase
identifiers with underscores to identify defined values. This has
the potential to create confusion, but neither document defines
values using actual ASN.1 value-assignment notation.
It is debatable whether it is advantageous to write all identifier
names (regardless of their ASN.1 token type) in all-uppercase letters
for the purpose of emphasis in running text. The alternative is to
Yu Expires: Jan 2005 [Page 78]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
use double-quote characters (") when ambiguity is possible.
Normative References
[ISO646]
"7-bit coded character set", ISO/IEC 646:1991 | ECMA-6:1991.
[ISO2022]
"Information technology -- Character code structure and
extension techniques", ISO/IEC 2022:1994 | ECMA-35:1994.
[KCRYPTO]
draft-ietf-krb-wg-crypto-07.txt
[RFC2119]
S. Bradner, RFC2119: "Key words for use in RFC's to Indicate
Requirement Levels", March 1997.
[X680]
"Information technology -- Abstract Syntax Notation One (ASN.1):
Specification of basic notation", ITU-T Recommendation X.680
(2002) | ISO/IEC 8824-1:2002.
[X682]
"Information technology -- Abstract Syntax Notation One (ASN.1):
Constraint specification", ITU-T Recommendation X.682 (2002) |
ISO/IEC 8824-3:2002.
[X683]
"Information technology -- Abstract Syntax Notation One (ASN.1):
Parameterization of ASN.1 specifications", ITU-T Recommendation
X.683 (2002) | ISO/IEC 8824-4:2002.
[X690]
"Information technology -- ASN.1 encoding Rules: Specification
of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
and Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690 (2002) | ISO/IEC 8825-1:2002.
Informative References
[DS81]
Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key
Distribution Protocols," Communications of the ACM, Vol. 24(8),
pp. 533-536 (August 1981).
[Dub00]
Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous
Systems", Elsevier-Morgan Kaufmann, 2000.
<http://www.oss.com/asn1/dubuisson.html>
Yu Expires: Jan 2005 [Page 79]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
[ISO8859-1]
"Information technology -- 8-bit single-byte coded graphic
character sets -- Part 1: Latin alphabet No. 1", ISO/IEC
8859-1:1998.
[KCLAR]
draft-ietf-krb-wg-kerberos-clarifications-06.txt
[KNT94]
John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
Evolution of the Kerberos Authentication System". In
Distributed Open Systems, pages 78-94. IEEE Computer Society
Press, 1994.
[Lar96]
John Larmouth, "Understanding OSI", International Thomson
Computer Press, 1996.
<http://www.isi.salford.ac.uk/books/osi.html>
[Lar99]
John Larmouth, "ASN.1 Complete", Elsevier-Morgan Kaufmann,
1999. <http://www.oss.com/asn1/larmouth.html>
[NS78]
Roger M. Needham and Michael D. Schroeder, "Using Encryption for
Authentication in Large Networks of Computers", Communications
of the ACM, Vol. 21(12), pp. 993-999 (December, 1978).
[RFC1510]
J. Kohl and B. C. Neuman, "The Kerberos Network Authentication
Service (v5)", RFC1510, September 1993, Status: Proposed
Standard.
[RFC1964]
J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
June 1996, Status: Proposed Standard.
[X690-1997]
"Information technology -- ASN.1 encoding rules: Specification
of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
and Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690 (1997) | ISO/IEC 8825-1:1998.
Author's Address
Tom Yu
77 Massachusetts Ave
Cambridge, MA 02139
USA
tlyu@mit.edu
Yu Expires: Jan 2005 [Page 80]
Internet-Draft yu-krb-extensions-01 19 Jul 2004
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Yu Expires: Jan 2005 [Page 81]
Reference in New Issue View Git Blame Copy Permalink