+++ /dev/null
-
-INTERNET-DRAFT Clifford Neuman
- John Kohl
- Theodore Ts'o
- 21 November 1997
-
-The Kerberos Network Authentication Service (V5)
-
-STATUS OF THIS MEMO
-
-This document is an Internet-Draft. 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.'
-
-To learn the current status of any Internet-Draft, please check the
-'1id-abstracts.txt' listing contained in the Internet-Drafts Shadow
-Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
-ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
-
-The distribution of this memo is unlimited. It is filed as
-draft-ietf-cat-kerberos-r-01.txt, and expires 21 May 1998. Please send
-comments to: krb-protocol@MIT.EDU
-
-ABSTRACT
-
-This document provides an overview and specification of Version 5 of the
-Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol
-and its intended use that require more detailed or clearer explanation than
-was provided in RFC1510. This document is intended to provide a detailed
-description of the protocol, suitable for implementation, together with
-descriptions of the appropriate use of protocol messages and fields within
-those messages.
-
-This document is not intended to describe Kerberos to the end user, system
-administrator, or application developer. Higher level papers describing
-Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88],
-are available elsewhere.
-
-OVERVIEW
-
-This INTERNET-DRAFT describes the concepts and model upon which the Kerberos
-network authentication system is based. It also specifies Version 5 of the
-Kerberos protocol.
-
-The motivations, goals, assumptions, and rationale behind most design
-decisions are treated cursorily; they are more fully described in a paper
-available in IEEE communications [NT94] and earlier in the Kerberos portion
-of the Athena Technical Plan [MNSS87]. The protocols have been a proposed
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-standard and are being considered for advancement for draft standard through
-the IETF standard process. Comments are encouraged on the presentation, but
-only minor refinements to the protocol as implemented or extensions that fit
-within current protocol framework will be considered at this time.
-
-Requests for addition to an electronic mailing list for discussion of
-Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-request@MIT.EDU.
-This mailing list is gatewayed onto the Usenet as the group
-comp.protocols.kerberos. Requests for further information, including
-documents and code availability, may be sent to info-kerberos@MIT.EDU.
-
-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 T'so, with help and contributed code from many others.
-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
-[KNT92].
-
-1. Introduction
-
-Kerberos provides a means of verifying the identities of principals, (e.g. a
-workstation user or a network server) on an open (unprotected) network. This
-is accomplished without relying on assertions by the host operating system,
-without basing trust on host addresses, without requiring physical security
-of all the hosts on the network, and under the assumption that packets
-traveling along the network can be read, modified, and inserted at will[1].
-Kerberos performs authentication under these conditions as a trusted
-third-party authentication service by using conventional (shared secret key
-[2] cryptography. Kerberos extensions have been proposed and implemented
-that provide for the use of public key cryptography during certain phases of
-the authentication protocol. These extensions provide for authentication of
-users registered with public key certification authorities, and allow the
-system to provide certain benefits of public key cryptography in situations
-where they are needed.
-
-The basic Kerberos authentication process proceeds as follows: A client
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-sends a request to the authentication server (AS) requesting 'credentials'
-for a given server. The AS responds with these credentials, encrypted in the
-client's key. The credentials consist of 1) a 'ticket' for the server and 2)
-a temporary encryption key (often called a "session key"). The client
-transmits the ticket (which contains the client's identity and a copy of the
-session key, all encrypted in the server's key) to the server. The session
-key (now shared by the client and server) is used to authenticate the
-client, and may optionally be used to authenticate the server. It may also
-be used to encrypt further communication between the two parties or to
-exchange a separate sub-session key to be used to encrypt further
-communication.
-
-Implementation of the basic protocol consists of one or more authentication
-servers running on physically secure hosts. The authentication servers
-maintain a database of principals (i.e., users and servers) and their secret
-keys. Code libraries provide encryption and implement the Kerberos protocol.
-In order to add authentication to its transactions, a typical network
-application adds one or two calls to the Kerberos library directly or
-through the Generic Security Services Application Programming Interface,
-GSSAPI, described in separate document. These calls result in the
-transmission of the necessary messages to achieve authentication.
-
-The Kerberos protocol consists of several sub-protocols (or exchanges).
-There are two basic methods by which a client can ask a Kerberos server for
-credentials. In the first approach, the client sends a cleartext request for
-a ticket for the desired server to the AS. The reply is sent encrypted in
-the client's secret key. Usually this request is for a ticket-granting
-ticket (TGT) which can later be used with the ticket-granting server (TGS).
-In the second method, the client sends a request to the TGS. The client uses
-the TGT to authenticate itself to the TGS in the same manner as if it were
-contacting any other application server that requires Kerberos
-authentication. The reply is encrypted in the session key from the TGT.
-Though the protocol specification describes the AS and the TGS as separate
-servers, they are implemented in practice as different protocol entry points
-within a single Kerberos server.
-
-Once obtained, credentials may be used to verify the identity of the
-principals in a transaction, to ensure the integrity of messages exchanged
-between them, or to preserve privacy of the messages. The application is
-free to choose whatever protection may be necessary.
-
-To verify the identities of the principals in a transaction, the client
-transmits the ticket to the application server. Since the ticket is sent "in
-the clear" (parts of it are encrypted, but this encryption doesn't thwart
-replay) and might be intercepted and reused by an attacker, additional
-information is sent to prove that the message originated with the principal
-to whom the ticket was issued. This information (called the authenticator)
-is encrypted in the session key, and includes a timestamp. The timestamp
-proves that the message was recently generated and is not a replay.
-Encrypting the authenticator in the session key proves that it was generated
-by a party possessing the session key. Since no one except the requesting
-principal and the server know the session key (it is never sent over the
-network in the clear) this guarantees the identity of the client.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-The integrity of the messages exchanged between principals can also be
-guaranteed using the session key (passed in the ticket and contained in the
-credentials). This approach provides detection of both replay attacks and
-message stream modification attacks. It is accomplished by generating and
-transmitting a collision-proof checksum (elsewhere called a hash or digest
-function) of the client's message, keyed with the session key. Privacy and
-integrity of the messages exchanged between principals can be secured by
-encrypting the data to be passed using the session key contained in the
-ticket or the subsession key found in the authenticator.
-
-The authentication exchanges mentioned above require read-only access to the
-Kerberos database. Sometimes, however, the entries in the database must be
-modified, such as when adding new principals or changing a principal's key.
-This is done using a protocol between a client and a third Kerberos server,
-the Kerberos Administration Server (KADM). There is also a protocol for
-maintaining multiple copies of the Kerberos database. Neither of these
-protocols are described in this document.
-
-1.1. Cross-Realm Operation
-
-The Kerberos protocol is designed to operate across organizational
-boundaries. A client in one organization can be authenticated to a server in
-another. Each organization wishing to run a Kerberos server establishes its
-own 'realm'. The name of the realm in which a client is registered is part
-of the client's name, and can be used by the end-service to decide whether
-to honor a request.
-
-By establishing 'inter-realm' keys, the administrators of two realms can
-allow a client authenticated in the local realm to prove its identity to
-servers in other realms[3]. The exchange of inter-realm keys (a separate key
-may be used for each direction) registers the ticket-granting service of
-each realm as a principal in the other realm. A client is then able to
-obtain a ticket-granting ticket for the remote realm's ticket-granting
-service from its local realm. When that ticket-granting ticket is used, the
-remote ticket-granting service uses the inter-realm key (which usually
-differs from its own normal TGS key) to decrypt the ticket-granting ticket,
-and is thus certain that it was issued by the client's own TGS. Tickets
-issued by the remote ticket-granting service will indicate to the
-end-service that the client was authenticated from another realm.
-
-A realm is said to communicate with another realm if the two realms share an
-inter-realm key, or if the local realm shares an inter-realm key with an
-intermediate realm that communicates with the remote realm. An
-authentication path is the sequence of intermediate realms that are
-transited in communicating from one realm to another.
-
-Realms are typically organized hierarchically. Each realm shares a key with
-its parent and a different key with each child. If an inter-realm key is not
-directly shared by two realms, the hierarchical organization allows an
-authentication path to be easily constructed. If a hierarchical organization
-is not used, it may be necessary to consult a database in order to construct
-an authentication path between realms.
-
-Although realms are typically hierarchical, intermediate realms may be
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-bypassed to achieve cross-realm authentication through alternate
-authentication paths (these might be established to make communication
-between two realms more efficient). It is important for the end-service to
-know which realms were transited when deciding how much faith to place in
-the authentication process. To facilitate this decision, a field in each
-ticket contains the names of the realms that were involved in authenticating
-the client.
-
-The application server is ultimately responsible for accepting or rejecting
-authentication and should check the transited field. The application server
-may choose to rely on the KDC for the application server's realm to check
-the transited field. The application server's KDC will set the
-TRANSITED-POLICY-CHECKED flag in this case. The KDC's for intermediate
-realms may also check the transited field as they issue
-ticket-granting-tickets for other realms, but they are encouraged not to do
-so. A client may request that the KDC's not check the transited field by
-setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but not
-required to honor this flag.
-
-1.2. Authorization
-
-As an authentication service, Kerberos provides a means of verifying the
-identity of principals on a network. Authentication is usually useful
-primarily as a first step in the process of authorization, determining
-whether a client may use a service, which objects the client is allowed to
-access, and the type of access allowed for each. Kerberos does not, by
-itself, provide authorization. Possession of a client ticket for a service
-provides only for authentication of the client to that service, and in the
-absence of a separate authorization procedure, it should not be considered
-by an application as authorizing the use of that service.
-
-Such separate authorization methods may be implemented as application
-specific access control functions and may be based on files such as the
-application server, or on separately issued authorization credentials such
-as those based on proxies [Neu93] , or on other authorization services.
-
-Applications should not be modified to accept the issuance of a service
-ticket by the Kerberos server (even by an modified Kerberos server) as
-granting authority to use the service, since such applications may become
-vulnerable to the bypass of this authorization check in an environment if
-they interoperate with other KDCs or where other options for application
-authentication (e.g. the PKTAPP proposal) are provided.
-
-1.3. Environmental assumptions
-
-Kerberos imposes a few assumptions on the environment in which it can
-properly function:
-
- * 'Denial of service' attacks are not solved with Kerberos. There are
- places in these protocols where an intruder can prevent an application
- from participating in the proper authentication steps. Detection and
- solution of such attacks (some of which can appear to be nnot-uncommon
- 'normal' failure modes for the system) is usually best left to the
- human administrators and users.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- * Principals must keep their secret keys secret. If an intruder somehow
- steals a principal's key, it will be able to masquerade as that
- principal or impersonate any server to the legitimate principal.
- * 'Password guessing' attacks are not solved by Kerberos. If a user
- chooses a poor password, it is possible for an attacker to successfully
- mount an offline dictionary attack by repeatedly attempting to decrypt,
- with successive entries from a dictionary, messages obtained which are
- encrypted under a key derived from the user's password.
- * Each host on the network must have a clock which is 'loosely
- synchronized' to the time of the other hosts; this synchronization is
- used to reduce the bookkeeping needs of application servers when they
- do replay detection. The degree of "looseness" can be configured on a
- per-server basis, but is typically on the order of 5 minutes. If the
- clocks are synchronized over the network, the clock synchronization
- protocol must itself be secured from network attackers.
- * Principal identifiers are not recycled on a short-term basis. A typical
- mode of access control will use access control lists (ACLs) to grant
- permissions to particular principals. If a stale ACL entry remains for
- a deleted principal and the principal identifier is reused, the new
- principal will inherit rights specified in the stale ACL entry. By not
- re-using principal identifiers, the danger of inadvertent access is
- removed.
-
-1.4. Glossary of terms
-
-Below is a list of terms used throughout this document.
-
-Authentication
- Verifying the claimed identity of a principal.
-Authentication header
- A record containing a Ticket and an Authenticator to be presented to a
- server as part of the authentication process.
-Authentication path
- A sequence of intermediate realms transited in the authentication
- process when communicating from one realm to another.
-Authenticator
- A record containing information that can be shown to have been recently
- generated using the session key known only by the client and server.
-Authorization
- The process of determining whether a client may use a service, which
- objects the client is allowed to access, and the type of access allowed
- for each.
-Capability
- A token that grants the bearer permission to access an object or
- service. In Kerberos, this might be a ticket whose use is restricted by
- the contents of the authorization data field, but which lists no
- network addresses, together with the session key necessary to use the
- ticket.
-Ciphertext
- The output of an encryption function. Encryption transforms plaintext
- into ciphertext.
-Client
- A process that makes use of a network service on behalf of a user. Note
- that in some cases a Server may itself be a client of some other server
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- (e.g. a print server may be a client of a file server).
-Credentials
- A ticket plus the secret session key necessary to successfully use that
- ticket in an authentication exchange.
-KDC
- Key Distribution Center, a network service that supplies tickets and
- temporary session keys; or an instance of that service or the host on
- which it runs. The KDC services both initial ticket and ticket-granting
- ticket requests. The initial ticket portion is sometimes referred to as
- the Authentication Server (or service). The ticket-granting ticket
- portion is sometimes referred to as the ticket-granting server (or
- service).
-Kerberos
- Aside from the 3-headed dog guarding Hades, the name given to Project
- Athena's authentication service, the protocol used by that service, or
- the code used to implement the authentication service.
-Plaintext
- The input to an encryption function or the output of a decryption
- function. Decryption transforms ciphertext into plaintext.
-Principal
- A uniquely named client or server instance that participates in a
- network communication.
-Principal identifier
- The name used to uniquely identify each different principal.
-Seal
- To encipher a record containing several fields in such a way that the
- fields cannot be individually replaced without either knowledge of the
- encryption key or leaving evidence of tampering.
-Secret key
- An encryption key shared by a principal and the KDC, distributed
- outside the bounds of the system, with a long lifetime. In the case of
- a human user's principal, the secret key is derived from a password.
-Server
- A particular Principal which provides a resource to network clients.
- The server is sometimes refered to as the Application Server.
-Service
- A resource provided to network clients; often provided by more than one
- server (for example, remote file service).
-Session key
- A temporary encryption key used between two principals, with a lifetime
- limited to the duration of a single login "session".
-Sub-session key
- A temporary encryption key used between two principals, selected and
- exchanged by the principals using the session key, and with a lifetime
- limited to the duration of a single association.
-Ticket
- A record that helps a client authenticate itself to a server; it
- contains the client's identity, a session key, a timestamp, and other
- information, all sealed using the server's secret key. It only serves
- to authenticate a client when presented along with a fresh
- Authenticator.
-
-2. Ticket flag uses and requests
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-Each Kerberos ticket contains a set of flags which are used to indicate
-various attributes of that ticket. Most flags may be requested by a client
-when the ticket is obtained; some are automatically turned on and off by a
-Kerberos server as required. The following sections explain what the various
-flags mean, and gives examples of reasons to use such a flag.
-
-2.1. Initial and pre-authenticated tickets
-
-The INITIAL flag indicates that a ticket was issued using the AS protocol
-and not issued based on a ticket-granting ticket. Application servers that
-want to require the demonstrated knowledge of a client's secret key (e.g. a
-password-changing program) can insist that this flag be set in any tickets
-they accept, and thus be assured that the client's key was recently
-presented to the application client.
-
-The PRE-AUTHENT and HW-AUTHENT flags provide addition information about the
-initial authentication, regardless of whether the current ticket was issued
-directly (in which case INITIAL will also be set) or issued on the basis of
-a ticket-granting ticket (in which case the INITIAL flag is clear, but the
-PRE-AUTHENT and HW-AUTHENT flags are carried forward from the
-ticket-granting ticket).
-
-2.2. Invalid tickets
-
-The INVALID flag indicates that a ticket is invalid. Application servers
-must reject tickets which have this flag set. A postdated ticket will
-usually 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 3.3.3.1).
-
-2.3. Renewable tickets
-
-Applications may desire to hold tickets which can be valid for long periods
-of time. However, this can expose their 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 periodically would require the client to have long-term
-access to its secret key, an even greater risk. Renewable tickets can be
-used to mitigate the consequences of theft. 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 (i.e. before it
-expires) present a renewable ticket to the KDC, with the RENEW option set 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.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-The RENEWABLE flag in a ticket is normally only interpreted by the
-ticket-granting service (discussed below in section 3.3). It can usually be
-ignored by application servers. However, some particularly careful
-application servers may wish to 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 reset by default, but a client
-may request it be set by setting the RENEWABLE option in the KRB_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.
-
-2.4. Postdated tickets
-
-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.
-
-The MAY-POSTDATE flag in a ticket is normally only interpreted by the
-ticket-granting service. It can be ignored by application servers. This flag
-must be set in a ticket-granting ticket in order 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 KRB_AS_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 KRB_AS_REQ message. The life (endtime-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-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 to be validated before use.
-
-2.5. Proxiable and proxy tickets
-
-At times 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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-also a proxy, user's wishing to delegate their identity for ANY purpose 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 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 are
-usually valid from only those network addresses specifically included in the
-ticket[4]. 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.
-
-2.6. Forwardable tickets
-
-Authentication forwarding is an instance of a proxy where the service is
-granted 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 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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-set. Application servers may choose to process FORWARDED tickets differently
-than non-FORWARDED tickets.
-
-2.7. Other KDC options
-
-There are two additional options which may be set in a client's request of
-the KDC. The RENEWABLE-OK option indicates that the client will accept a
-renewable ticket if a ticket with the requested life cannot otherwise be
-provided. If a ticket with the requested life cannot be provided, then the
-KDC may issue a renewable ticket with a renew-till equal to the the
-requested endtime. The value of the renew-till field may still be adjusted
-by site-determined limits or limits imposed by the individual principal or
-server.
-
-The ENC-TKT-IN-SKEY option is honored only by the ticket-granting service.
-It indicates that the ticket to be issued for the end server is to be
-encrypted in the session key from the a additional second ticket-granting
-ticket provided with the request. See section 3.3.3 for specific details.
-
-3. Message Exchanges
-
-The following sections describe the interactions between network clients and
-servers and the messages involved in those exchanges.
-
-3.1. The Authentication Service Exchange
-
- Summary
- Message direction Message type Section
- 1. Client to Kerberos KRB_AS_REQ 5.4.1
- 2. Kerberos to client KRB_AS_REP or 5.4.2
- KRB_ERROR 5.9.1
-
-The Authentication Service (AS) Exchange between the client and the Kerberos
-Authentication Server is initiated by a client when it wishes to obtain
-authentication credentials for a given server but currently holds no
-credentials. In its basic form, the client's secret key is used for
-encryption and decryption. This exchange is typically used at the initiation
-of a login session to obtain credentials for a Ticket-Granting Server which
-will subsequently be used to obtain credentials for other servers (see
-section 3.3) without requiring further use of the client's secret key. This
-exchange is also used to request credentials for services which must not be
-mediated through the Ticket-Granting Service, but rather require a
-principal's secret key, such as the password-changing service[5]. This
-exchange does not by itself provide any assurance of the the identity of the
-user[6].
-
-The exchange consists of two messages: KRB_AS_REQ from the client to
-Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these
-messages are described in sections 5.4.1, 5.4.2, and 5.9.1.
-
-In the request, the client sends (in cleartext) its own identity and the
-identity of the server for which it is requesting credentials. The response,
-KRB_AS_REP, contains a ticket for the client to present to the server, and a
-session key that will be shared by the client and the server. The session
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-key and additional information are encrypted in the client's secret key. The
-KRB_AS_REP message contains information which can be used to detect replays,
-and to associate it with the message to which it replies. Various errors can
-occur; these are indicated by an error response (KRB_ERROR) instead of the
-KRB_AS_REP response. The error message is not encrypted. The KRB_ERROR
-message contains information which can be used to associate it with the
-message to which it replies. The lack of encryption in the KRB_ERROR message
-precludes the ability to detect replays, fabrications, or modifications of
-such messages.
-
-Without preautentication, the authentication server does not know whether
-the client is actually the principal named in the request. It simply sends a
-reply without knowing or caring whether they are the same. This is
-acceptable because nobody but the principal whose identity was given in the
-request will be able to use the reply. Its critical information is encrypted
-in that principal's key. The initial request supports an optional field that
-can be used to pass additional information that might be needed for the
-initial exchange. This field may be used for preauthentication as described
-in section [hl<>].
-
-3.1.1. Generation of KRB_AS_REQ message
-
-The client may specify a number of options in the initial request. Among
-these options are whether pre-authentication is to be performed; whether the
-requested ticket is to be renewable, proxiable, or forwardable; whether it
-should be postdated or allow postdating of derivative tickets; and whether a
-renewable ticket will be accepted in lieu of a non-renewable ticket if the
-requested ticket expiration date cannot be satisfied by a non-renewable
-ticket (due to configuration constraints; see section 4). See section A.1
-for pseudocode.
-
-The client prepares the KRB_AS_REQ message and sends it to the KDC.
-
-3.1.2. Receipt of KRB_AS_REQ message
-
-If all goes well, processing the KRB_AS_REQ message will result in the
-creation of a ticket for the client to present to the server. The format for
-the ticket is described in section 5.3.1. The contents of the ticket are
-determined as follows.
-
-3.1.3. Generation of KRB_AS_REP message
-
-The authentication server looks up the client and server principals named in
-the KRB_AS_REQ in its database, extracting their respective keys. If
-required, the server pre-authenticates the request, and if the
-pre-authentication check fails, an error message with the code
-KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate the
-requested encryption type, an error message with code KDC_ERR_ETYPE_NOSUPP
-is returned. Otherwise it generates a 'random' session key[7].
-
-If there are multiple encryption keys registered for a client in the
-Kerberos database (or if the key registered supports multiple encryption
-types; e.g. DES-CBC-CRC and DES-CBC-MD5), then the etype field from the AS
-request is used by the KDC to select the encryption method to be used for
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-encrypting the response to the client. If there is more than one supported,
-strong encryption type in the etype list, the first valid etype for which an
-encryption key is available is used. The encryption method used to respond
-to a TGS request is taken from the keytype of the session key found in the
-ticket granting ticket.
-
-When the etype field is present in a KDC request, whether an AS or TGS
-request, the KDC will attempt to assign the type of the random session key
-from the list of methods in the etype field. The KDC will select the
-appropriate type using the list of methods provided together with
-information from the Kerberos database indicating acceptable encryption
-methods for the application server. The KDC will not issue tickets with a
-weak session key encryption type.
-
-If the requested start time is absent, indicates a time in the past, or is
-within the window of acceptable clock skew for the KDC and the POSTDATE
-option has not been specified, then the start time of the ticket is set to
-the authentication server's current time. If it indicates a time in the
-future beyond the acceptable clock skew, but the POSTDATED option has not
-been specified then the error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise
-the requested start time is checked against the policy of the local realm
-(the administrator might decide to prohibit certain types or ranges of
-postdated tickets), and if acceptable, the ticket's start time is set as
-requested and the INVALID flag is set in the new ticket. The postdated
-ticket must be validated before use by presenting it to the KDC after the
-start time has been reached.
-
-The expiration time of the ticket will be set to the minimum of the
-following:
-
- * The expiration time (endtime) requested in the KRB_AS_REQ message.
- * The ticket's start time plus the maximum allowable lifetime associated
- with the client principal (the authentication server's database
- includes a maximum ticket lifetime field in each principal's record;
- see section 4).
- * 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
-(the field and option names are described fully in section 5.4.1).
-
-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
-is set to the minimum of:
-
- * Its requested value.
- * The start time of the ticket plus the minimum of the two maximum
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- 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.
-
-The flags field of the new ticket will have the following options set if
-they have been requested and if the policy of the local realm allows:
-FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. If the new
-ticket is post-dated (the start time is in the future), its INVALID flag
-will also be set.
-
-If all of the above succeed, the server formats a KRB_AS_REP message (see
-section 5.4.2), copying the addresses in the request into the caddr of the
-response, placing any required pre-authentication data into the padata of
-the response, and encrypts the ciphertext part in the client's key using the
-requested encryption method, and sends it to the client. See section A.2 for
-pseudocode.
-
-3.1.4. Generation of KRB_ERROR message
-
-Several errors can occur, and the Authentication Server responds by
-returning an error message, KRB_ERROR, to the client, with the error-code
-and e-text fields set to appropriate values. The error message contents and
-details are described in Section 5.9.1.
-
-3.1.5. Receipt of KRB_AS_REP message
-
-If the reply message type is KRB_AS_REP, then the client verifies that the
-cname and crealm fields in the cleartext portion of the reply match what it
-requested. If any padata fields are present, they may be used to derive the
-proper secret key to decrypt the message. The client decrypts the encrypted
-part of the response using its secret key, verifies that the nonce in the
-encrypted part matches the nonce it supplied in its request (to detect
-replays). It also verifies that the sname and srealm in the response match
-those in the request (or are otherwise expected values), and that the host
-address field is also correct. It then stores the ticket, session key, start
-and expiration times, and other information for later use. The
-key-expiration field from the encrypted part of the response may be checked
-to notify the user of impending key expiration (the client program could
-then suggest remedial action, such as a password change). See section A.3
-for pseudocode.
-
-Proper decryption of the KRB_AS_REP message is not sufficient to verify the
-identity of the user; the user and an attacker could cooperate to generate a
-KRB_AS_REP format message which decrypts properly but is not from the proper
-KDC. If the host wishes to verify the identity of the user, it must require
-the user to present application credentials which can be verified using a
-securely-stored secret key for the host. If those credentials can be
-verified, then the identity of the user can be assured.
-
-3.1.6. Receipt of KRB_ERROR message
-
-If the reply message type is KRB_ERROR, then the client interprets it as an
-error and performs whatever application-specific tasks are necessary to
-recover.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
-3.2. The Client/Server Authentication Exchange
-
- Summary
-Message direction Message type Section
-Client to Application server KRB_AP_REQ 5.5.1
-[optional] Application server to client KRB_AP_REP or 5.5.2
- KRB_ERROR 5.9.1
-
-The client/server authentication (CS) exchange is used by network
-applications to authenticate the client to the server and vice versa. The
-client must have already acquired credentials for the server using the AS or
-TGS exchange.
-
-3.2.1. The KRB_AP_REQ message
-
-The KRB_AP_REQ contains authentication information which should be part of
-the first message in an authenticated transaction. It contains a ticket, an
-authenticator, and some additional bookkeeping information (see section
-5.5.1 for the exact format). The ticket by itself is insufficient to
-authenticate a client, since tickets are passed across the network in
-cleartext[DS90], so the authenticator is used to prevent invalid replay of
-tickets by proving to the server that the client knows the session key of
-the ticket and thus is entitled to use the ticket. The KRB_AP_REQ message is
-referred to elsewhere as the 'authentication header.'
-
-3.2.2. Generation of a KRB_AP_REQ message
-
-When a client wishes to initiate authentication to a server, it obtains
-(either through a credentials cache, the AS exchange, or the TGS exchange) a
-ticket and session key for the desired service. The client may re-use any
-tickets it holds until they expire. To use a ticket the client constructs a
-new Authenticator from the the system time, its name, and optionally an
-application specific checksum, an initial sequence number to be used in
-KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in
-negotiations for a session key unique to this particular session.
-Authenticators may not be re-used and will be rejected if replayed to a
-server[LGDSR87]. If a sequence number is to be included, it should be
-randomly chosen so that even after many messages have been exchanged it is
-not likely to collide with other sequence numbers in use.
-
-The client may indicate a requirement of mutual authentication or the use of
-a session-key based ticket by setting the appropriate flag(s) in the
-ap-options field of the message.
-
-The Authenticator is encrypted in the session key and combined with the
-ticket to form the KRB_AP_REQ message which is then sent to the end server
-along with any additional application-specific information. See section A.9
-for pseudocode.
-
-3.2.3. Receipt of KRB_AP_REQ message
-
-Authentication is based on the server's current time of day (clocks must be
-loosely synchronized), the authenticator, and the ticket. Several errors are
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-possible. If an error occurs, the server is expected to reply to the client
-with a KRB_ERROR message. This message may be encapsulated in the
-application protocol if its 'raw' form is not acceptable to the protocol.
-The format of error messages is described in section 5.9.1.
-
-The algorithm for verifying authentication information is as follows. If the
-message type is not KRB_AP_REQ, the server returns the KRB_AP_ERR_MSG_TYPE
-error. If the key version indicated by the Ticket in the KRB_AP_REQ is not
-one the server can use (e.g., it indicates an old key, and the server no
-longer possesses a copy of the old key), the KRB_AP_ERR_BADKEYVER error is
-returned. If the USE-SESSION-KEY flag is set in the ap-options field, it
-indicates to the server that the ticket is encrypted in the session key from
-the server's ticket-granting ticket rather than its secret key[10]. Since it
-is possible for the server to be registered in multiple realms, with
-different keys in each, the srealm field in the unencrypted portion of the
-ticket in the KRB_AP_REQ is used to specify which secret key the server
-should use to decrypt that ticket. The KRB_AP_ERR_NOKEY error code is
-returned if the server doesn't have the proper key to decipher the ticket.
-
-The ticket is decrypted using the version of the server's key specified by
-the ticket. If the decryption routines detect a modification of the ticket
-(each encryption system must provide safeguards to detect modified
-ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY error is returned
-(chances are good that different keys were used to encrypt and decrypt).
-
-The authenticator is decrypted using the session key extracted from the
-decrypted ticket. If decryption shows it to have been modified, the
-KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the client
-from the ticket are compared against the same fields in the authenticator.
-If they don't match, the KRB_AP_ERR_BADMATCH error is returned (they might
-not match, for example, if the wrong session key was used to encrypt the
-authenticator). The addresses in the ticket (if any) are then searched for
-an address matching the operating-system reported address of the client. If
-no match is found or the server insists on ticket addresses but none are
-present in the ticket, the KRB_AP_ERR_BADADDR error is returned.
-
-If the local (server) time and the client time in the authenticator differ
-by more than the allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW
-error is returned. If the server name, along with the client name, time and
-microsecond fields from the Authenticator match any recently-seen such
-tuples, the KRB_AP_ERR_REPEAT error is returned[11]. The server must
-remember any authenticator presented within the allowable clock skew, so
-that a replay attempt is guaranteed to fail. If a server loses track of any
-authenticator presented within the allowable clock skew, it must reject all
-requests until the clock skew interval has passed. This assures that any
-lost or re-played authenticators will fall outside the allowable clock skew
-and can no longer be successfully replayed (If this is not done, an attacker
-could conceivably record the ticket and authenticator sent over the network
-to a server, then disable the client's host, pose as the disabled host, and
-replay the ticket and authenticator to subvert the authentication.). If a
-sequence number is provided in the authenticator, the server saves it for
-later use in processing KRB_SAFE and/or KRB_PRIV messages. If a subkey is
-present, the server either saves it for later use or uses it to help
-generate its own choice for a subkey to be returned in a KRB_AP_REP message.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
-The server computes the age of the ticket: local (server) time minus the
-start time inside the Ticket. If the start time is later than the current
-time by more than the allowable clock skew or if the INVALID flag is set in
-the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Otherwise, if the
-current time is later than end time by more than the allowable clock skew,
-the KRB_AP_ERR_TKT_EXPIRED error is returned.
-
-If all these checks succeed without an error, the server is assured that the
-client possesses the credentials of the principal named in the ticket and
-thus, the client has been authenticated to the server. See section A.10 for
-pseudocode.
-
-Passing these checks provides only authentication of the named principal; it
-does not imply authorization to use the named service. Applications must
-make a separate authorization decisions based upon the authenticated name of
-the user, the requested operation, local acces control information such as
-that contained in a .k5login or .k5users file, and possibly a separate
-distributed authorization service.
-
-3.2.4. Generation of a KRB_AP_REP message
-
-Typically, a client's request will include both the authentication
-information and its initial request in the same message, and the server need
-not explicitly reply to the KRB_AP_REQ. However, if mutual authentication
-(not only authenticating the client to the server, but also the server to
-the client) is being performed, the KRB_AP_REQ message will have
-MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message is
-required in response. As with the error message, this message may be
-encapsulated in the application protocol if its "raw" form is not acceptable
-to the application's protocol. The timestamp and microsecond field used in
-the reply must be the client's timestamp and microsecond field (as provided
-in the authenticator)[12]. If a sequence number is to be included, it should
-be randomly chosen as described above for the authenticator. A subkey may be
-included if the server desires to negotiate a different subkey. The
-KRB_AP_REP message is encrypted in the session key extracted from the
-ticket. See section A.11 for pseudocode.
-
-3.2.5. Receipt of KRB_AP_REP message
-
-If a KRB_AP_REP message is returned, the client uses the session key from
-the credentials obtained for the server[13] to decrypt the message, and
-verifies that the timestamp and microsecond fields match those in the
-Authenticator it sent to the server. If they match, then the client is
-assured that the server is genuine. The sequence number and subkey (if
-present) are retained for later use. See section A.12 for pseudocode.
-
-3.2.6. Using the encryption key
-
-After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and server
-share an encryption key which can be used by the application. The 'true
-session key' to be used for KRB_PRIV, KRB_SAFE, or other
-application-specific uses may be chosen by the application based on the
-subkeys in the KRB_AP_REP message and the authenticator[14]. In some cases,
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-the use of this session key will be implicit in the protocol; in others the
-method of use must be chosen from several alternatives. We leave the
-protocol negotiations of how to use the key (e.g. selecting an encryption or
-checksum type) to the application programmer; the Kerberos protocol does not
-constrain the implementation options, but an example of how this might be
-done follows.
-
-One way that an application may choose to negotiate a key to be used for
-subequent integrity and privacy protection is for the client to propose a
-key in the subkey field of the authenticator. The server can then choose a
-key using the proposed key from the client as input, returning the new
-subkey in the subkey field of the application reply. This key could then be
-used for subsequent communication. To make this example more concrete, if
-the encryption method in use required a 56 bit key, and for whatever reason,
-one of the parties was prevented from using a key with more than 40 unknown
-bits, this method would allow the the party which is prevented from using
-more than 40 bits to either propose (if the client) an initial key with a
-known quantity for 16 of those bits, or to mask 16 of the bits (if the
-server) with the known quantity. The application implementor is warned,
-however, that this is only an example, and that an analysis of the
-particular crytosystem to be used, and the reasons for limiting the key
-length, must be made before deciding whether it is acceptable to mask bits
-of the key.
-
-With both the one-way and mutual authentication exchanges, the peers should
-take care not to send sensitive information to each other without proper
-assurances. In particular, applications that require privacy or integrity
-should use the KRB_AP_REP response from the server to client to assure both
-client and server of their peer's identity. If an application protocol
-requires privacy of its messages, it can use the KRB_PRIV message (section
-3.5). The KRB_SAFE message (section 3.4) can be used to assure integrity.
-
-3.3. The Ticket-Granting Service (TGS) Exchange
-
- Summary
- Message direction Message type Section
- 1. Client to Kerberos KRB_TGS_REQ 5.4.1
- 2. Kerberos to client KRB_TGS_REP or 5.4.2
- KRB_ERROR 5.9.1
-
-The TGS exchange between a client and the Kerberos Ticket-Granting Server is
-initiated by a client when it wishes to obtain authentication credentials
-for a given server (which might be registered in a remote realm), when it
-wishes to renew or validate an existing ticket, or when it wishes to obtain
-a proxy ticket. In the first case, the client must already have acquired a
-ticket for the Ticket-Granting Service using the AS exchange (the
-ticket-granting ticket is usually obtained when a client initially
-authenticates to the system, such as when a user logs in). The message
-format for the TGS exchange is almost identical to that for the AS exchange.
-The primary difference is that encryption and decryption in the TGS exchange
-does not take place under the client's key. Instead, the session key from
-the ticket-granting ticket or renewable ticket, or sub-session key from an
-Authenticator is used. As is the case for all application servers, expired
-tickets are not accepted by the TGS, so once a renewable or ticket-granting
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-ticket expires, the client must use a separate exchange to obtain valid
-tickets.
-
-The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from the
-client to the Kerberos Ticket-Granting Server, and a reply (KRB_TGS_REP or
-KRB_ERROR). The KRB_TGS_REQ message includes information authenticating the
-client plus a request for credentials. The authentication information
-consists of the authentication header (KRB_AP_REQ) which includes the
-client's previously obtained ticket-granting, renewable, or invalid ticket.
-In the ticket-granting ticket and proxy cases, the request may include one
-or more of: a list of network addresses, a collection of typed authorization
-data to be sealed in the ticket for authorization use by the application
-server, or additional tickets (the use of which are described later). The
-TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted in the
-session key from the ticket-granting ticket or renewable ticket, or if
-present, in the sub-session key from the Authenticator (part of the
-authentication header). The KRB_ERROR message contains an error code and
-text explaining what went wrong. The KRB_ERROR message is not encrypted. The
-KRB_TGS_REP message contains information which can be used to detect
-replays, and to associate it with the message to which it replies. The
-KRB_ERROR message also contains information which can be used to associate
-it with the message to which it replies, but the lack of encryption in the
-KRB_ERROR message precludes the ability to detect replays or fabrications of
-such messages.
-
-3.3.1. Generation of KRB_TGS_REQ message
-
-Before sending a request to the ticket-granting service, the client must
-determine in which realm the application server is registered[15]. If the
-client does not already possess a ticket-granting ticket for the appropriate
-realm, then one must be obtained. This is first attempted by requesting a
-ticket-granting ticket for the destination realm from a Kerberos server for
-which the client does posess a ticket-granting ticket (using the KRB_TGS_REQ
-message recursively). The Kerberos server may return a TGT for the desired
-realm in which case one can proceed. Alternatively, the Kerberos server may
-return a TGT for a realm which is 'closer' to the desired realm (further
-along the standard hierarchical path), in which case this step must be
-repeated with a Kerberos server in the realm specified in the returned TGT.
-If neither are returned, then the request must be retried with a Kerberos
-server for a realm higher in the hierarchy. This request will itself require
-a ticket-granting ticket for the higher realm which must be obtained by
-recursively applying these directions.
-
-Once the client obtains a ticket-granting ticket for the appropriate realm,
-it determines which Kerberos servers serve that realm, and contacts one. The
-list might be obtained through a configuration file or network service or it
-may be generated from the name of the realm; as long as the secret keys
-exchanged by realms are kept secret, only denial of service results from
-using a false Kerberos server.
-
-As in the AS exchange, the client may specify a number of options in the
-KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ message, providing
-an authentication header as an element of the padata field, and including
-the same fields as used in the KRB_AS_REQ message along with several
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-optional fields: the enc-authorization-data field for application server use
-and additional tickets required by some options.
-
-In preparing the authentication header, the client can select a sub-session
-key under which the response from the Kerberos server will be encrypted[16].
-If the sub-session key is not specified, the session key from the
-ticket-granting ticket will be used. If the enc-authorization-data is
-present, it must be encrypted in the sub-session key, if present, from the
-authenticator portion of the authentication header, or if not present, using
-the session key from the ticket-granting ticket.
-
-Once prepared, the message is sent to a Kerberos server for the destination
-realm. See section A.5 for pseudocode.
-
-3.3.2. Receipt of KRB_TGS_REQ message
-
-The KRB_TGS_REQ message is processed in a manner similar to the KRB_AS_REQ
-message, but there are many additional checks to be performed. First, the
-Kerberos server must determine which server the accompanying ticket is for
-and it must select the appropriate key to decrypt it. For a normal
-KRB_TGS_REQ message, it will be for the ticket granting service, and the
-TGS's key will be used. If the TGT was issued by another realm, then the
-appropriate inter-realm key must be used. If the accompanying ticket is not
-a ticket granting ticket for the current realm, but is for an application
-server in the current realm, the RENEW, VALIDATE, or PROXY options are
-specified in the request, and the server for which a ticket is requested is
-the server named in the accompanying ticket, then the KDC will decrypt the
-ticket in the authentication header using the key of the server for which it
-was issued. If no ticket can be found in the padata field, the
-KDC_ERR_PADATA_TYPE_NOSUPP error is returned.
-
-Once the accompanying ticket has been decrypted, the user-supplied checksum
-in the Authenticator must be verified against the contents of the request,
-and the message rejected if the checksums do not match (with an error code
-of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or not
-collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM). If the
-checksum type is not supported, the KDC_ERR_SUMTYPE_NOSUPP error is
-returned. If the authorization-data are present, they are decrypted using
-the sub-session key from the Authenticator.
-
-If any of the decryptions indicate failed integrity checks, the
-KRB_AP_ERR_BAD_INTEGRITY error is returned.
-
-3.3.3. Generation of KRB_TGS_REP message
-
-The KRB_TGS_REP message shares its format with the KRB_AS_REP (KRB_KDC_REP),
-but with its type field set to KRB_TGS_REP. The detailed specification is in
-section 5.4.2.
-
-The response will include a ticket for the requested server. The Kerberos
-database is queried to retrieve the record for the requested server
-(including the key with which the ticket will be encrypted). If the request
-is for a ticket granting ticket for a remote realm, and if no key is shared
-with the requested realm, then the Kerberos server will select the realm
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-"closest" to the requested realm with which it does share a key, and use
-that realm instead. This is the only case where the response from the KDC
-will be for a different server than that requested by the client.
-
-By default, the address field, the client's name and realm, the list of
-transited realms, the time of initial authentication, the expiration time,
-and the authorization data of the newly-issued ticket will be copied from
-the ticket-granting ticket (TGT) or renewable ticket. If the transited field
-needs to be updated, but the transited type is not supported, the
-KDC_ERR_TRTYPE_NOSUPP error is returned.
-
-If the request specifies an endtime, then the endtime of the new ticket is
-set to the minimum of (a) that request, (b) the endtime from the TGT, and
-(c) the starttime of the TGT plus the minimum of the maximum life for the
-application server and the maximum life for the local realm (the maximum
-life for the requesting principal was already applied when the TGT was
-issued). If the new ticket is to be a renewal, then the endtime above is
-replaced by the minimum of (a) the value of the renew_till field of the
-ticket and (b) the starttime for the new ticket plus the life
-(endtime-starttime) of the old ticket.
-
-If the FORWARDED option has been requested, then the resulting ticket will
-contain the addresses specified by the client. This option will only be
-honored if the FORWARDABLE flag is set in the TGT. The PROXY option is
-similar; the resulting ticket will contain the addresses specified by the
-client. It will be honored only if the PROXIABLE flag in the TGT is set. The
-PROXY option will not be honored on requests for additional ticket-granting
-tickets.
-
-If the requested start time is absent, indicates a time in the past, or is
-within the window of acceptable clock skew for the KDC and the POSTDATE
-option has not been specified, then the start time of the ticket is set to
-the authentication server's current time. If it indicates a time in the
-future beyond the acceptable clock skew, but the POSTDATED option has not
-been specified or the MAY-POSTDATE flag is not set in the TGT, then the
-error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the ticket-granting
-ticket has the MAY-POSTDATE flag set, then the resulting ticket will be
-postdated and the requested starttime is checked against the policy of the
-local realm. If acceptable, the ticket's start time is set as requested, and
-the INVALID flag is set. The postdated ticket must be validated before use
-by presenting it to the KDC after the starttime has been reached. However,
-in no case may the starttime, endtime, or renew-till time of a newly-issued
-postdated ticket extend beyond the renew-till time of the ticket-granting
-ticket.
-
-If the ENC-TKT-IN-SKEY option has been specified and an additional ticket
-has been included in the request, the KDC will decrypt the additional ticket
-using the key for the server to which the additional ticket was issued and
-verify that it is a ticket-granting ticket. If the name of the requested
-server is missing from the request, the name of the client in the additional
-ticket will be used. Otherwise the name of the requested server will be
-compared to the name of the client in the additional ticket and if
-different, the request will be rejected. If the request succeeds, the
-session key from the additional ticket will be used to encrypt the new
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-ticket that is issued instead of using the key of the server for which the
-new ticket will be used[17].
-
-If the name of the server in the ticket that is presented to the KDC as part
-of the authentication header is not that of the ticket-granting server
-itself, the server is registered in the realm of the KDC, and the RENEW
-option is requested, then the KDC will verify that the RENEWABLE flag is set
-in the ticket, that the INVALID flag is not set in the ticket, and that the
-renew_till time is still in the future. If the VALIDATE option is rqeuested,
-the KDC will check that the starttime has passed and the INVALID flag is
-set. If the PROXY option is requested, then the KDC will check that the
-PROXIABLE flag is set in the ticket. If the tests succeed, and the ticket
-passes the hotlist check described in the next paragraph, the KDC will issue
-the appropriate new ticket.
-
-3.3.3.1. Checking for revoked tickets
-
-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. 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.
-
-The ciphertext part of the response in the KRB_TGS_REP message is encrypted
-in the sub-session key from the Authenticator, if present, or the session
-key key from the ticket-granting ticket. It is not encrypted using the
-client's secret key. Furthermore, the client's key's expiration date and the
-key version number fields are left out since these values are stored along
-with the client's database record, and that record is not needed to satisfy
-a request based on a ticket-granting ticket. See section A.6 for pseudocode.
-
-3.3.3.2. Encoding the transited field
-
-If the identity of the server in the TGT that is presented to the KDC as
-part of the authentication header is that of the ticket-granting service,
-but the TGT was issued from another realm, the KDC will look up the
-inter-realm key shared with that realm and use that key to decrypt the
-ticket. If the ticket is valid, then the KDC will honor the request, subject
-to the constraints outlined above in the section describing the AS exchange.
-The realm part of the client's identity will be taken from the
-ticket-granting ticket. The name of the realm that issued the
-ticket-granting ticket will be added to the transited field of the ticket to
-be issued. This is accomplished by reading the transited field from the
-ticket-granting ticket (which is treated as an unordered set of realm
-names), adding the new realm to the set, then constructing and writing out
-its encoded (shorthand) form (this may involve a rearrangement of the
-existing encoding).
-
-Note that the ticket-granting service does not add the name of its own
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-realm. Instead, its responsibility is to add the name of the previous realm.
-This prevents a malicious Kerberos server from intentionally leaving out its
-own name (it could, however, omit other realms' names).
-
-The names of neither the local realm nor the principal's realm are to be
-included in the transited field. They appear elsewhere in the ticket and
-both are known to have taken part in authenticating the principal. Since the
-endpoints are not included, both local and single-hop inter-realm
-authentication result in a transited field that is empty.
-
-Because the name of each realm transited is added to this field, it might
-potentially be very long. To decrease the length of this field, its contents
-are encoded. The initially supported encoding is optimized for the normal
-case of inter-realm communication: a hierarchical arrangement of realms
-using either domain or X.500 style realm names. This encoding (called
-DOMAIN-X500-COMPRESS) is now described.
-
-Realm names in the transited field are separated by a ",". The ",", "\",
-trailing "."s, and leading spaces (" ") are special characters, and if they
-are part of a realm name, they must be quoted in the transited field by
-preced- ing them with a "\".
-
-A realm name ending with a "." is interpreted as being prepended to the
-previous realm. For example, we can encode traversal of EDU, MIT.EDU,
-ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as:
-
- "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
-
-Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, that they
-would not be included in this field, and we would have:
-
- "EDU,MIT.,WASHINGTON.EDU"
-
-A realm name beginning with a "/" is interpreted as being appended to the
-previous realm[18]. If it is to stand by itself, then it should be preceded
-by a space (" "). For example, we can encode traversal of /COM/HP/APOLLO,
-/COM/HP, /COM, and /COM/DEC as:
-
- "/COM,/HP,/APOLLO, /COM/DEC".
-
-Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they
-they would not be included in this field, and we would have:
-
- "/COM,/HP"
-
-A null subfield preceding or following a "," indicates that all realms
-between the previous realm and the next realm have been traversed[19]. Thus,
-"," means that all realms along the path between the client and the server
-have been traversed. ",EDU, /COM," means that that all realms from the
-client's realm up to EDU (in a domain style hierarchy) have been traversed,
-and that everything from /COM down to the server's realm in an X.500 style
-has also been traversed. This could occur if the EDU realm in one hierarchy
-shares an inter-realm key directly with the /COM realm in another hierarchy.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-3.3.4. Receipt of KRB_TGS_REP message
-
-When the KRB_TGS_REP is received by the client, it is processed in the same
-manner as the KRB_AS_REP processing described above. The primary difference
-is that the ciphertext part of the response must be decrypted using the
-session key from the ticket-granting ticket rather than the client's secret
-key. See section A.7 for pseudocode.
-
-3.4. The KRB_SAFE Exchange
-
-The KRB_SAFE message may be used by clients requiring the ability to detect
-modifications of messages they exchange. It achieves this by including a
-keyed collision-proof checksum of the user data and some control
-information. The checksum is keyed with an encryption key (usually the last
-key negotiated via subkeys, or the session key if no negotiation has
-occured).
-
-3.4.1. Generation of a KRB_SAFE message
-
-When an application wishes to send a KRB_SAFE message, it collects its data
-and the appropriate control information and computes a checksum over them.
-The checksum algorithm should be a keyed one-way hash function (such as the
-RSA- MD5-DES checksum algorithm specified in section 6.4.5, or the DES MAC),
-generated using the sub-session key if present, or the session key.
-Different algorithms may be selected by changing the checksum type in the
-message. Unkeyed or non-collision-proof checksums are not suitable for this
-use.
-
-The control information for the KRB_SAFE message includes both a timestamp
-and a sequence number. The designer of an application using the KRB_SAFE
-message must choose at least one of the two mechanisms. This choice should
-be based on the needs of the application protocol.
-
-Sequence numbers are useful when all messages sent will be received by one's
-peer. Connection state is presently required to maintain the session key, so
-maintaining the next sequence number should not present an additional
-problem.
-
-If the application protocol is expected to tolerate lost messages without
-them being resent, the use of the timestamp is the appropriate replay
-detection mechanism. Using timestamps is also the appropriate mechanism for
-multi-cast protocols where all of one's peers share a common sub-session
-key, but some messages will be sent to a subset of one's peers.
-
-After computing the checksum, the client then transmits the information and
-checksum to the recipient in the message format specified in section 5.6.1.
-
-3.4.2. Receipt of KRB_SAFE message
-
-When an application receives a KRB_SAFE message, it verifies it as follows.
-If any error occurs, an error code is reported for use by the application.
-
-The message is first checked by verifying that the protocol version and type
-fields match the current version and KRB_SAFE, respectively. A mismatch
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The
-application verifies that the checksum used is a collision-proof keyed
-checksum, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. The
-recipient verifies that the operating system's report of the sender's
-address matches the sender's address in the message, and (if a recipient
-address is specified or the recipient requires an address) that one of the
-recipient's addresses appears as the recipient's address in the message. A
-failed match for either case generates a KRB_AP_ERR_BADADDR error. Then the
-timestamp and usec and/or the sequence number fields are checked. If
-timestamp and usec are expected and not present, or they are present but not
-current, the KRB_AP_ERR_SKEW error is generated. If the server name, along
-with the client name, time and microsecond fields from the Authenticator
-match any recently-seen (sent or received[20] ) such tuples, the
-KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence number is
-included, or a sequence number is expected but not present, the
-KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and usec or
-a sequence number is present, a KRB_AP_ERR_MODIFIED error is generated.
-Finally, the checksum is computed over the data and control information, and
-if it doesn't match the received checksum, a KRB_AP_ERR_MODIFIED error is
-generated.
-
-If all the checks succeed, the application is assured that the message was
-generated by its peer and was not modi- fied in transit.
-
-3.5. The KRB_PRIV Exchange
-
-The KRB_PRIV message may be used by clients requiring confidentiality and
-the ability to detect modifications of exchanged messages. It achieves this
-by encrypting the messages and adding control information.
-
-3.5.1. Generation of a KRB_PRIV message
-
-When an application wishes to send a KRB_PRIV message, it collects its data
-and the appropriate control information (specified in section 5.7.1) and
-encrypts them under an encryption key (usually the last key negotiated via
-subkeys, or the session key if no negotiation has occured). As part of the
-control information, the client must choose to use either a timestamp or a
-sequence number (or both); see the discussion in section 3.4.1 for
-guidelines on which to use. After the user data and control information are
-encrypted, the client transmits the ciphertext and some 'envelope'
-information to the recipient.
-
-3.5.2. Receipt of KRB_PRIV message
-
-When an application receives a KRB_PRIV message, it verifies it as follows.
-If any error occurs, an error code is reported for use by the application.
-
-The message is first checked by verifying that the protocol version and type
-fields match the current version and KRB_PRIV, respectively. A mismatch
-generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The
-application then decrypts the ciphertext and processes the resultant
-plaintext. If decryption shows the data to have been modified, a
-KRB_AP_ERR_BAD_INTEGRITY error is generated. The recipient verifies that the
-operating system's report of the sender's address matches the sender's
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-address in the message, and (if a recipient address is specified or the
-recipient requires an address) that one of the recipient's addresses appears
-as the recipient's address in the message. A failed match for either case
-generates a KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the
-sequence number fields are checked. If timestamp and usec are expected and
-not present, or they are present but not current, the KRB_AP_ERR_SKEW error
-is generated. If the server name, along with the client name, time and
-microsecond fields from the Authenticator match any recently-seen such
-tuples, the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence
-number is included, or a sequence number is expected but not present, the
-KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and usec or
-a sequence number is present, a KRB_AP_ERR_MODIFIED error is generated.
-
-If all the checks succeed, the application can assume the message was
-generated by its peer, and was securely transmitted (without intruders able
-to see the unencrypted contents).
-
-3.6. The KRB_CRED Exchange
-
-The KRB_CRED message may be used by clients requiring the ability to send
-Kerberos credentials from one host to another. It achieves this by sending
-the tickets together with encrypted data containing the session keys and
-other information associated with the tickets.
-
-3.6.1. Generation of a KRB_CRED message
-
-When an application wishes to send a KRB_CRED message it first (using the
-KRB_TGS exchange) obtains credentials to be sent to the remote host. It then
-constructs a KRB_CRED message using the ticket or tickets so obtained,
-placing the session key needed to use each ticket in the key field of the
-corresponding KrbCredInfo sequence of the encrypted part of the the KRB_CRED
-message.
-
-Other information associated with each ticket and obtained during the
-KRB_TGS exchange is also placed in the corresponding KrbCredInfo sequence in
-the encrypted part of the KRB_CRED message. The current time and, if
-specifically required by the application the nonce, s-address, and r-address
-fields, are placed in the encrypted part of the KRB_CRED message which is
-then encrypted under an encryption key previosuly exchanged in the KRB_AP
-exchange (usually the last key negotiated via subkeys, or the session key if
-no negotiation has occured).
-
-3.6.2. Receipt of KRB_CRED message
-
-When an application receives a KRB_CRED message, it verifies it. If any
-error occurs, an error code is reported for use by the application. The
-message is verified by checking that the protocol version and type fields
-match the current version and KRB_CRED, respectively. A mismatch generates a
-KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then
-decrypts the ciphertext and processes the resultant plaintext. If decryption
-shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is
-generated.
-
-If present or required, the recipient verifies that the operating system's
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-report of the sender's address matches the sender's address in the message,
-and that one of the recipient's addresses appears as the recipient's address
-in the message. A failed match for either case generates a
-KRB_AP_ERR_BADADDR error. The timestamp and usec fields (and the nonce field
-if required) are checked next. If the timestamp and usec are not present, or
-they are present but not current, the KRB_AP_ERR_SKEW error is generated.
-
-If all the checks succeed, the application stores each of the new tickets in
-its ticket cache together with the session key and other information in the
-corresponding KrbCredInfo sequence from the encrypted part of the KRB_CRED
-message.
-
-4. The Kerberos Database
-
-The Kerberos server must have access to a database contain- ing the
-principal identifiers and secret keys of principals to be authenticated[21].
-
-4.1. Database contents
-
-A database entry should contain at least the following fields:
-
-Field Value
-
-name Principal's identifier
-key Principal's secret key
-p_kvno Principal's key version
-max_life Maximum lifetime for Tickets
-max_renewable_life Maximum total lifetime for renewable Tickets
-
-The name field is an encoding of the principal's identifier. The key field
-contains an encryption key. This key is the principal's secret key. (The key
-can be encrypted before storage under a Kerberos "master key" to protect it
-in case the database is compromised but the master key is not. In that case,
-an extra field must be added to indicate the master key version used, see
-below.) The p_kvno field is the key version number of the principal's secret
-key. The max_life field contains the maximum allowable lifetime (endtime -
-starttime) for any Ticket issued for this principal. The max_renewable_life
-field contains the maximum allowable total lifetime for any renewable Ticket
-issued for this principal. (See section 3.1 for a description of how these
-lifetimes are used in determining the lifetime of a given Ticket.)
-
-A server may provide KDC service to several realms, as long as the database
-representation provides a mechanism to distinguish between principal records
-with identifiers which differ only in the realm name.
-
-When an application server's key changes, if the change is routine (i.e. not
-the result of disclosure of the old key), the old key should be retained by
-the server until all tickets that had been issued using that key have
-expired. Because of this, it is possible for several keys to be active for a
-single principal. Ciphertext encrypted in a principal's key is always tagged
-with the version of the key that was used for encryption, to help the
-recipient find the proper key for decryption.
-
-When more than one key is active for a particular principal, the principal
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-will have more than one record in the Kerberos database. The keys and key
-version numbers will differ between the records (the rest of the fields may
-or may not be the same). Whenever Kerberos issues a ticket, or responds to a
-request for initial authentication, the most recent key (known by the
-Kerberos server) will be used for encryption. This is the key with the
-highest key version number.
-
-4.2. Additional fields
-
-Project Athena's KDC implementation uses additional fields in its database:
-
-Field Value
-
-K_kvno Kerberos' key version
-expiration Expiration date for entry
-attributes Bit field of attributes
-mod_date Timestamp of last modification
-mod_name Modifying principal's identifier
-
-The K_kvno field indicates the key version of the Kerberos master key under
-which the principal's secret key is encrypted.
-
-After an entry's expiration date has passed, the KDC will return an error to
-any client attempting to gain tickets as or for the principal. (A database
-may want to maintain two expiration dates: one for the principal, and one
-for the principal's current key. This allows password aging to work
-independently of the principal's expiration date. However, due to the
-limited space in the responses, the KDC must combine the key expiration and
-principal expiration date into a single value called 'key_exp', which is
-used as a hint to the user to take administrative action.)
-
-The attributes field is a bitfield used to govern the operations involving
-the principal. This field might be useful in conjunction with user
-registration procedures, for site-specific policy implementations (Project
-Athena currently uses it for their user registration process controlled by
-the system-wide database service, Moira [LGDSR87]), to identify whether a
-principal can play the role of a client or server or both, to note whether a
-server is appropriate trusted to recieve credentials delegated by a client,
-or to identify the 'string to key' conversion algorithm used for a
-principal's key[22]. Other bits are used to indicate that certain ticket
-options should not be allowed in tickets encrypted under a principal's key
-(one bit each): Disallow issuing postdated tickets, disallow issuing
-forwardable tickets, disallow issuing tickets based on TGT authentication,
-disallow issuing renewable tickets, disallow issuing proxiable tickets, and
-disallow issuing tickets for which the principal is the server.
-
-The mod_date field contains the time of last modification of the entry, and
-the mod_name field contains the name of the principal which last modified
-the entry.
-
-4.3. Frequently Changing Fields
-
-Some KDC implementations may wish to maintain the last time that a request
-was made by a particular principal. Information that might be maintained
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-includes the time of the last request, the time of the last request for a
-ticket-granting ticket, the time of the last use of a ticket-granting
-ticket, or other times. This information can then be returned to the user in
-the last-req field (see section 5.2).
-
-Other frequently changing information that can be maintained is the latest
-expiration time for any tickets that have been issued using each key. This
-field would be used to indicate how long old keys must remain valid to allow
-the continued use of outstanding tickets.
-
-4.4. Site Constants
-
-The KDC implementation should have the following configurable constants or
-options, to allow an administrator to make and enforce policy decisions:
-
- * The minimum supported lifetime (used to determine whether the
- KDC_ERR_NEVER_VALID error should be returned). This constant should
- reflect reasonable expectations of round-trip time to the KDC,
- encryption/decryption time, and processing time by the client and
- target server, and it should allow for a minimum 'useful' lifetime.
- * The maximum allowable total (renewable) lifetime of a ticket
- (renew_till - starttime).
- * The maximum allowable lifetime of a ticket (endtime - starttime).
- * Whether to allow the issue of tickets with empty address fields
- (including the ability to specify that such tickets may only be issued
- if the request specifies some authorization_data).
- * Whether proxiable, forwardable, renewable or post-datable tickets are
- to be issued.
-
-5. Message Specifications
-
-The following sections describe the exact contents and encoding of protocol
-messages and objects. The ASN.1 base definitions are presented in the first
-subsection. The remaining subsections specify the protocol objects (tickets
-and authenticators) and messages. Specification of encryption and checksum
-techniques, and the fields related to them, appear in section 6.
-
-5.1. ASN.1 Distinguished Encoding Representation
-
-All uses of ASN.1 in Kerberos shall use the Distinguished Encoding
-Representation of the data elements as described in the X.509 specification,
-section 8.7 [X509-88].
-
-5.2. ASN.1 Base Definitions
-
-The following ASN.1 base definitions are used in the rest of this section.
-Note that since the underscore character (_) is not permitted in ASN.1
-names, the hyphen (-) is used in its place for the purposes of ASN.1 names.
-
-Realm ::= GeneralString
-PrincipalName ::= SEQUENCE {
- name-type[0] INTEGER,
- name-string[1] SEQUENCE OF GeneralString
-}
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
-Kerberos realms are encoded as GeneralStrings. Realms shall not contain a
-character with the code 0 (the 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.
-Acceptable forms for realm names are specified in section 7. A PrincipalName
-is a typed sequence of components consisting of the following sub-fields:
-
-name-type
- This field specifies the type of name that follows. Pre-defined values
- for this field are specified in section 7.2. 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).
- This constraint may be eliminated in the future.
-name-string
- This field encodes a sequence of components that form a name, each
- component encoded as a GeneralString. Taken together, a PrincipalName
- and a Realm form a principal identifier. Most PrincipalNames will have
- only a few components (typically one or two).
-
-KerberosTime ::= GeneralizedTime
- -- Specifying UTC time zone (Z)
-
-The timestamps used in Kerberos are encoded as GeneralizedTimes. An encoding
-shall specify the UTC time zone (Z) and shall not include any fractional
-portions of the seconds. It further shall not include any separators.
-Example: The only valid format for UTC time 6 minutes, 27 seconds after 9 pm
-on 6 November 1985 is 19851106210627Z.
-
-HostAddress ::= SEQUENCE {
- addr-type[0] INTEGER,
- address[1] OCTET STRING
-}
-
-HostAddresses ::= SEQUENCE OF HostAddress
-
-The host adddress encodings consists of two fields:
-
-addr-type
- This field specifies the type of address that follows. Pre-defined
- values for this field are specified in section 8.1.
-address
- This field encodes a single address of type addr-type.
-
-The two forms differ slightly. HostAddress contains exactly one address;
-HostAddresses contains a sequence of possibly many addresses.
-
-AuthorizationData ::= SEQUENCE OF SEQUENCE {
- ad-type[0] INTEGER,
- ad-data[1] OCTET STRING
-}
-
-ad-data
- This field contains authorization data to be interpreted according to
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- the value of the corresponding ad-type field.
-ad-type
- This field specifies the format for the ad-data subfield. All negative
- values are reserved for local use. Non-negative values are reserved for
- registered use.
-
-Each sequence of type and data is refered to as an authorization element.
-Elements may be application specific, however, there is a common set of
-recursive elements that should be understood by all implementations. These
-elements contain other elements embedded within them, and the interpretation
-of the encapsulating element determines which of the embedded elements must
-be interpreted, and which may be ignored. Definitions for these common
-elements may be found in Appendix B.
-
-TicketExtensions ::= SEQUENCE OF SEQUENCE {
- te-type[0] INTEGER,
- te-data[1] OCTET STRING
-}
-
-
-
-te-data
- This field contains opaque data that must be caried with the ticket to
- support extensions to the Kerberos protocol including but not limited
- to some forms of inter-realm key exchange and plaintext authorization
- data. See appendix C for some common uses of this field.
-te-type
- This field specifies the format for the te-data subfield. All negative
- values are reserved for local use. Non-negative values are reserved for
- registered use.
-
-APOptions ::= BIT STRING {
- reserved(0),
- use-session-key(1),
- mutual-required(2)
-}
-
-TicketFlags ::= 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)
-}
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-KDCOptions ::= 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),
- disable-transited-check(26),
- renewable-ok(27),
- enc-tkt-in-skey(28),
- renew(30),
- validate(31)
-}
-
-ASN.1 Bit strings have a length and a value. When used in Kerberos for the
-APOptions, TicketFlags, and KDCOptions, the length of the bit string on
-generated values should be the smallest multiple of 32 bits needed to
-include the highest order bit that is set (1), but in no case less than 32
-bits. Implementations should accept values of bit strings of any length and
-treat the value of flags cooresponding to bits beyond the end of the bit
-string as if the bit were reset (0). Comparisonof bit strings of different
-length should treat the smaller string as if it were padded with zeros
-beyond the high order bits to the length of the longer string[23].
-
-LastReq ::= SEQUENCE OF SEQUENCE {
- lr-type[0] INTEGER,
- lr-value[1] KerberosTime
-}
-
-lr-type
- This field indicates how the following lr-value field is to be
- interpreted. Negative values indicate that the information pertains
- only to the responding server. Non-negative values pertain to all
- servers for the realm. If the lr-type field is zero (0), then no
- information is conveyed by the lr-value subfield. If the absolute value
- of the lr-type field is one (1), then the lr-value subfield is the time
- of last initial request for a TGT. If it is two (2), then the lr-value
- subfield is the time of last initial request. If it is three (3), then
- the lr-value subfield is the time of issue for the newest
- ticket-granting ticket used. If it is four (4), then the lr-value
- subfield is the time of the last renewal. If it is five (5), then the
- lr-value subfield is the time of last request (of any type).
-lr-value
- This field contains the time of the last request. the time must be
- interpreted according to the contents of the accompanying lr-type
- subfield.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
-See section 6 for the definitions of Checksum, ChecksumType, EncryptedData,
-EncryptionKey, EncryptionType, and KeyType.
-
-5.3. Tickets and Authenticators
-
-This section describes the format and encryption parameters for tickets and
-authenticators. When a ticket or authenticator is included in a protocol
-message it is treated as an opaque object.
-
-5.3.1. Tickets
-
-A ticket is a record that helps a client authenticate to a service. A Ticket
-contains the following information:
-
-Ticket ::= [APPLICATION 1] SEQUENCE {
- tkt-vno[0] INTEGER,
- realm[1] Realm,
- sname[2] PrincipalName,
- enc-part[3] EncryptedData,
- extensions[4] TicketExtensions OPTIONAL
-}
-
--- Encrypted part of ticket
-EncTicketPart ::= [APPLICATION 3] 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
-}
--- encoded Transited field
-TransitedEncoding ::= SEQUENCE {
- tr-type[0] INTEGER, -- must be registered
- contents[1] OCTET STRING
-}
-
-The encoding of EncTicketPart is encrypted in the key shared by Kerberos and
-the end server (the server's secret key). See section 6 for the format of
-the ciphertext.
-
-tkt-vno
- This field specifies the version number for the ticket format. This
- document describes version number 5.
-realm
- This field specifies the realm that issued a ticket. It also serves to
- identify the realm part of the server's principal identifier. Since a
- Kerberos server can only issue tickets for servers within its realm,
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- the two will always be identical.
-sname
- This field specifies the name part of the server's identity.
-enc-part
- This field holds the encrypted encoding of the EncTicketPart sequence.
-extensions
- This optional field contains a sequence of extentions that may be used
- to carry information that must be carried with the ticket to support
- several extensions, including but not limited to plaintext
- authorization data, tokens for exchanging inter-realm keys, and other
- information that must be associated with a ticket for use by the
- application server. See Appendix C for definitions of some common
- extensions.
-
- Note that some older versions of Kerberos did not support this field.
- Because this is an optional field it will not break older clients, but
- older clients might strip this field from the ticket before sending it
- to the application server. This limits the usefulness of this ticket
- field to environments where the ticket will not be parsed and
- reconstructed by these older Kerberos clients.
-
- If it is known that the client will strip this field from the ticket,
- as an interim measure the KDC may append this field to the end of the
- enc-part of the ticket and append a traler indicating the lenght of the
- appended extensions field. (this paragraph is open for discussion,
- including the form of the traler).
-flags
- This field indicates which of various options were used or requested
- when the ticket was issued. It is a bit-field, where the selected
- options are indicated by the bit being set (1), and the unselected
- options and reserved fields being reset (0). Bit 0 is the most
- significant bit. The encoding of the bits is specified in section 5.2.
- The flags are described in more detail above in section 2. The meanings
- of the flags are:
-
- Bit(s) Name Description
-
- 0 RESERVED
- Reserved for future expansion of this
- field.
-
- 1 FORWARDABLE
- The FORWARDABLE flag is normally only
- interpreted by the TGS, and can be
- ignored by end servers. When set, this
- flag tells the ticket-granting server
- that it is OK to issue a new ticket-
- granting ticket with a different network
- address based on the presented ticket.
-
- 2 FORWARDED
- When set, this flag indicates that the
- ticket has either been forwarded or was
- issued based on authentication involving
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- a forwarded ticket-granting ticket.
-
- 3 PROXIABLE
- The PROXIABLE flag is normally only
- interpreted by the TGS, and can be
- ignored by end servers. The PROXIABLE
- flag has an interpretation identical to
- that of the FORWARDABLE flag, except
- that the PROXIABLE flag tells the
- ticket-granting server that only non-
- ticket-granting tickets may be issued
- with different network addresses.
-
- 4 PROXY
- When set, this flag indicates that a
- ticket is a proxy.
-
- 5 MAY-POSTDATE
- The MAY-POSTDATE flag is normally only
- interpreted by the TGS, and can be
- ignored by end servers. This flag tells
- the ticket-granting server that a post-
- dated ticket may be issued based on this
- ticket-granting ticket.
-
- 6 POSTDATED
- This flag indicates that this ticket has
- been postdated. The end-service can
- check the authtime field to see when the
- original authentication occurred.
-
- 7 INVALID
- This flag indicates that a ticket is
- invalid, and it must be validated by the
- KDC before use. Application servers
- must reject tickets which have this flag
- set.
-
- 8 RENEWABLE
- The RENEWABLE flag is normally only
- interpreted by the TGS, and can usually
- be ignored by end servers (some particu-
- larly careful servers may wish to disal-
- low renewable tickets). A renewable
- ticket can be used to obtain a replace-
- ment ticket that expires at a later
- date.
-
- 9 INITIAL
- This flag indicates that this ticket was
- issued using the AS protocol, and not
- issued based on a ticket-granting
- ticket.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- 10 PRE-AUTHENT
- This flag indicates that during initial
- authentication, the client was authenti-
- cated by the KDC before a ticket was
- issued. The strength of the pre-
- authentication method is not indicated,
- but is acceptable to the KDC.
-
- 11 HW-AUTHENT
- This flag indicates that the protocol
- employed for initial authentication
- required the use of hardware expected to
- be possessed solely by the named client.
- The hardware authentication method is
- selected by the KDC and the strength of
- the method is not indicated.
-
- 12 TRANSITED This flag indicates that the KDC for the
- POLICY-CHECKED realm has checked the transited field
- against a realm defined policy for
- trusted certifiers. If this flag is
- reset (0), then the application server
- must check the transited field itself,
- and if unable to do so it must reject
- the authentication. If the flag is set
- (1) then the application server may skip
- its own validation of the transited
- field, relying on the validation
- performed by the KDC. At its option the
- application server may still apply its
- own validation based on a separate
- policy for acceptance.
-
- 13 OK-AS-DELEGATE This flag indicates that the server (not
- the client) 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 server.
- The client is free 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.
-
- 14 ANONYMOUS
- This flag indicates that the principal
- named in the ticket is a generic princi-
- pal for the realm and does not identify
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- the individual using the ticket. The
- purpose of the ticket is only to
- securely distribute a session key, and
- not to identify the user. Subsequent
- requests using the same ticket and ses-
- sion may be considered as originating
- from the same user, but requests with
- the same username but a different ticket
- are likely to originate from different
- users.
-
- 15-31 RESERVED
- Reserved for future use.
-
-key
- This field exists in the ticket and the KDC response and is used to
- pass the session key from Kerberos to the application server and the
- client. The field's encoding is described in section 6.2.
-crealm
- This field contains the name of the realm in which the client is
- registered and in which initial authentication took place.
-cname
- This field contains the name part of the client's principal identifier.
-transited
- This field lists the names of the Kerberos realms that took part in
- authenticating the user to whom this ticket was issued. It does not
- specify the order in which the realms were transited. See section
- 3.3.3.2 for details on how this field encodes the traversed realms.
-authtime
- This field indicates the time of initial authentication for the named
- principal. It is the time of issue for the original ticket on which
- this ticket is based. It is included in the ticket to provide
- additional information to the end service, and to provide the necessary
- information for implementation of a `hot list' service at the KDC. An
- end service that is particularly paranoid could refuse to accept
- tickets for which the initial authentication occurred "too far" in the
- past. This field is also returned as part of the response from the KDC.
- When returned as part of the response to initial authentication
- (KRB_AS_REP), this is the current time on the Ker- beros server[24].
-starttime
- This field in the ticket specifies the time after which the ticket is
- valid. Together with endtime, this field specifies the life of the
- ticket. If it is absent from the ticket, its value should be treated as
- that of the authtime field.
-endtime
- This field 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 field 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
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- time for the ticket, including all renewals.
-caddr
- This field in a ticket contains zero (if omitted) or more (if present)
- host addresses. These are the addresses from which the ticket can be
- used. If there are no addresses, the ticket can be used from any
- location. The decision by the KDC to issue or by the end server to
- accept zero-address tickets is a policy decision and is left to the
- Kerberos and end-service administrators; they may refuse to issue or
- accept such tickets. The suggested and default policy, however, is that
- such tickets will only be issued or accepted when additional
- information that can be used to restrict the use of the ticket is
- included in the authorization_data field. Such a ticket is a
- capability.
-
- Network addresses are included in the ticket to make it harder for an
- attacker to use stolen credentials. Because the session key is not sent
- over the network in cleartext, credentials can't be stolen simply by
- listening to the network; an attacker has to gain access to the session
- key (perhaps through operating system security breaches or a careless
- user's unattended session) to make use of stolen tickets.
-
- It is important to note that the network address from which a
- connection is received cannot be reliably determined. Even if it could
- be, an attacker who has compromised the client's worksta- tion could
- use the credentials from there. Including the network addresses only
- makes it more difficult, not impossible, for an attacker to walk off
- with stolen credentials and then use them from a "safe" location.
-authorization-data
- The authorization-data field is used to pass authorization data from
- the principal on whose behalf a ticket was issued to the application
- service. If no authorization data is included, this field will be left
- out. Experience has shown that the name of this field is confusing, and
- that a better name for this field would be restrictions. Unfortunately,
- it is not possible to change the name of this field at this time.
-
- This field contains restrictions on any authority obtained on the basis
- of authentication using the ticket. It is possible for any principal in
- posession of credentials to add entries to the authorization data field
- since these entries further restrict what can be done with the ticket.
- Such additions can be made by specifying the additional entries when a
- new ticket is obtained during the TGS exchange, or they may be added
- during chained delegation using the authorization data field of the
- authenticator.
-
- Because entries may be added to this field by the holder of
- credentials, it is not allowable for the presence of an entry in the
- authorization data field of a ticket to amplify the priveleges one
- would obtain from using a ticket.
-
- The data in this field may be specific to the end service; the field
- will contain the names of service specific objects, and the rights to
- those objects. The format for this field is described in section 5.2.
- Although Kerberos is not concerned with the format of the contents of
- the sub-fields, it does carry type information (ad-type).
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
- By using the authorization_data field, a principal is able to issue a
- proxy that is valid for a specific purpose. For example, a client
- wishing to print a file can obtain a file server proxy to be passed to
- the print server. By specifying the name of the file in the
- authorization_data field, the file server knows that the print server
- can only use the client's rights when accessing the particular file to
- be printed.
-
- A separate service providing authorization or certifying group
- membership may be built using the authorization-data field. In this
- case, the entity granting authorization (not the authorized entity),
- obtains a ticket in its own name (e.g. the ticket is issued in the name
- of a privelege server), and this entity adds restrictions on its own
- authority and delegates the restricted authority through a proxy to the
- client. The client would then present this authorization credential to
- the application server separately from the authentication exchange.
-
- Similarly, if one specifies the authorization-data field of a proxy and
- leaves the host addresses blank, the resulting ticket and session key
- can be treated as a capability. See [Neu93] for some suggested uses of
- this field.
-
- The authorization-data field is optional and does not have to be
- included in a ticket.
-
-5.3.2. Authenticators
-
-An authenticator is a record sent with a ticket to a server to certify the
-client's knowledge of the encryption key in the ticket, to help the server
-detect replays, and to help choose a "true session key" to use with the
-particular session. The encoding is encrypted in the ticket's session key
-shared by the client and the server:
-
--- Unencrypted authenticator
-Authenticator ::= [APPLICATION 2] SEQUENCE {
- authenticator-vno[0] INTEGER,
- crealm[1] Realm,
- cname[2] PrincipalName,
- cksum[3] Checksum OPTIONAL,
- cusec[4] INTEGER,
- ctime[5] KerberosTime,
- subkey[6] EncryptionKey OPTIONAL,
- seq-number[7] INTEGER OPTIONAL,
- authorization-data[8] AuthorizationData OPTIONAL
-}
-
-
-authenticator-vno
- This field specifies the version number for the format of the
- authenticator. This document specifies version 5.
-crealm and cname
- These fields are the same as those described for the ticket in section
- 5.3.1.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-cksum
- This field contains a checksum of the the applica- tion data that
- accompanies the KRB_AP_REQ.
-cusec
- This field contains the microsecond part of the client's timestamp. Its
- value (before encryption) ranges from 0 to 999999. It often appears
- along with ctime. The two fields are used together to specify a
- reasonably accurate timestamp.
-ctime
- This field contains the current time on the client's host.
-subkey
- This field contains the client's choice for an encryption key which is
- to be used to protect this specific application session. Unless an
- application specifies otherwise, if this field is left out the session
- key from the ticket will be used.
-seq-number
- This optional field includes the initial sequence number to be used by
- the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to
- detect replays (It may also be used by application specific messages).
- When included in the authenticator this field specifies the initial
- sequence number for messages from the client to the server. When
- included in the AP-REP message, the initial sequence number is that for
- messages from the server to the client. When used in KRB_PRIV or
- KRB_SAFE messages, it is incremented by one after each message is sent.
-
- For sequence numbers to adequately support the detection of replays
- they should be non-repeating, even across connection boundaries. The
- initial sequence number should be random and uniformly distributed
- across the full space of possible sequence numbers, so that it cannot
- be guessed by an attacker and so that it and the successive sequence
- numbers do not repeat other sequences.
-authorization-data
- This field is the same as described for the ticket in section 5.3.1. It
- is optional and will only appear when additional restrictions are to be
- placed on the use of a ticket, beyond those carried in the ticket
- itself.
-
-5.4. Specifications for the AS and TGS exchanges
-
-This section specifies the format of the messages used in the exchange
-between the client and the Kerberos server. The format of possible error
-messages appears in section 5.9.1.
-
-5.4.1. KRB_KDC_REQ definition
-
-The KRB_KDC_REQ message has no type of its own. Instead, its type is one of
-KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is for an initial
-ticket or an additional ticket. In either case, the message is sent from the
-client to the Authentication Server to request credentials for a service.
-
-The message fields are:
-
-AS-REQ ::= [APPLICATION 10] KDC-REQ
-TGS-REQ ::= [APPLICATION 12] KDC-REQ
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
-KDC-REQ ::= SEQUENCE {
- pvno[1] INTEGER,
- msg-type[2] INTEGER,
- padata[3] SEQUENCE OF PA-DATA OPTIONAL,
- req-body[4] KDC-REQ-BODY
-}
-
-PA-DATA ::= SEQUENCE {
- padata-type[1] INTEGER,
- padata-value[2] OCTET STRING,
- -- might be encoded AP-REQ
-}
-
-KDC-REQ-BODY ::= 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,
- rtime[6] KerberosTime OPTIONAL,
- nonce[7] INTEGER,
- etype[8] SEQUENCE OF INTEGER,
- -- EncryptionType,
- -- in preference order
- addresses[9] HostAddresses OPTIONAL,
- enc-authorization-data[10] EncryptedData OPTIONAL,
- -- Encrypted AuthorizationData
- -- encoding
- additional-tickets[11] SEQUENCE OF Ticket OPTIONAL
-}
-
-The fields in this message are:
-
-pvno
- This field is included in each message, and specifies the protocol
- version number. This document specifies protocol version 5.
-msg-type
- This field indicates the type of a protocol message. It will almost
- always be the same as the application identifier associated with a
- message. It is included to make the identifier more readily accessible
- to the application. For the KDC-REQ message, this type will be
- KRB_AS_REQ or KRB_TGS_REQ.
-padata
- The padata (pre-authentication data) field contains a sequence of
- authentication information which may be needed before credentials can
- be issued or decrypted. In the case of requests for additional tickets
- (KRB_TGS_REQ), this field will include an element with padata-type of
- PA-TGS-REQ and data of an authentication header (ticket-granting ticket
- and authenticator). The checksum in the authenticator (which must be
- collision-proof) is to be computed over the KDC-REQ-BODY encoding. In
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- most requests for initial authentication (KRB_AS_REQ) and most replies
- (KDC-REP), the padata field will be left out.
-
- This field may also contain information needed by certain extensions to
- the Kerberos protocol. For example, it might be used to initially
- verify the identity of a client before any response is returned. This
- is accomplished with a padata field with padata-type equal to
- PA-ENC-TIMESTAMP and padata-value defined as follows:
-
- padata-type ::= PA-ENC-TIMESTAMP
- padata-value ::= EncryptedData -- PA-ENC-TS-ENC
-
- PA-ENC-TS-ENC ::= SEQUENCE {
- patimestamp[0] KerberosTime, -- client's time
- pausec[1] INTEGER OPTIONAL
- }
-
- with patimestamp containing the client's time and pausec containing the
- microseconds which may be omitted if a client will not generate more
- than one request per second. The ciphertext (padata-value) consists of
- the PA-ENC-TS-ENC sequence, encrypted using the client's secret key.
-
- [use-specified-kvno item is here for discussion and may be removed] It
- may also be used by the client to specify the version of a key that is
- being used for accompanying preauthentication, and/or which should be
- used to encrypt the reply from the KDC.
-
- PA-USE-SPECIFIED-KVNO ::= Integer
-
- The KDC should only accept and abide by the value of the
- use-specified-kvno preauthentication data field when the specified key
- is still valid and until use of a new key is confirmed. This situation
- is likely to occur primarily during the period during which an updated
- key is propagating to other KDC's in a realm.
-
- The padata field can also contain information needed to help the KDC or
- the client select the key needed for generating or decrypting the
- response. This form of the padata is useful for supporting the use of
- certain token cards with Kerberos. The details of such extensions are
- specified in separate documents. See [Pat92] for additional uses of
- this field.
-padata-type
- The padata-type element of the padata field indicates the way that the
- padata-value element is to be interpreted. Negative values of
- padata-type are reserved for unregistered use; non-negative values are
- used for a registered interpretation of the element type.
-req-body
- This field is a placeholder delimiting the extent of the remaining
- fields. If a checksum is to be calculated over the request, it is
- calculated over an encoding of the KDC-REQ-BODY sequence which is
- enclosed within the req-body field.
-kdc-options
- This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the
- KDC and indicates the flags that the client wants set on the tickets as
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- well as other information that is to modify the behavior of the KDC.
- Where appropriate, the name of an option may be the same as the flag
- that is set by that option. Although in most case, the bit in the
- options field will be the same as that in the flags field, this is not
- guaranteed, so it is not acceptable to simply copy the options field to
- the flags field. There are various checks that must be made before
- honoring an option anyway.
-
- The kdc_options field is a bit-field, where the selected options are
- indicated by the bit being set (1), and the unselected options and
- reserved fields being reset (0). The encoding of the bits is specified
- in section 5.2. The options are described in more detail above in
- section 2. The meanings of the options are:
-
- Bit(s) Name Description
- 0 RESERVED
- Reserved for future expansion of this
- field.
-
- 1 FORWARDABLE
- The FORWARDABLE option indicates that
- the ticket to be issued is to have its
- forwardable flag set. It may only be
- set on the initial request, or in a sub-
- sequent request if the ticket-granting
- ticket on which it is based is also for-
- wardable.
-
- 2 FORWARDED
- The FORWARDED option is only specified
- in a request to the ticket-granting
- server and will only be honored if the
- ticket-granting ticket in the request
- has its FORWARDABLE bit set. This
- option indicates that this is a request
- for forwarding. The address(es) of the
- host from which the resulting ticket is
- to be valid are included in the
- addresses field of the request.
-
- 3 PROXIABLE
- The PROXIABLE option indicates that the
- ticket to be issued is to have its prox-
- iable flag set. It may only be set on
- the initial request, or in a subsequent
- request if the ticket-granting ticket on
- which it is based is also proxiable.
-
- 4 PROXY
- The PROXY option indicates that this is
- a request for a proxy. This option will
- only be honored if the ticket-granting
- ticket in the request has its PROXIABLE
- bit set. The address(es) of the host
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- from which the resulting ticket is to be
- valid are included in the addresses
- field of the request.
-
- 5 ALLOW-POSTDATE
- The ALLOW-POSTDATE option indicates that
- the ticket to be issued is to have its
- MAY-POSTDATE flag set. It may only be
- set on the initial request, or in a sub-
- sequent request if the ticket-granting
- ticket on which it is based also has its
- MAY-POSTDATE flag set.
-
- 6 POSTDATED
- The POSTDATED option indicates that this
- is a request for a postdated ticket.
- This option will only be honored if the
- ticket-granting ticket on which it is
- based has its MAY-POSTDATE flag set.
- The resulting ticket will also have its
- INVALID flag set, and that flag may be
- reset by a subsequent request to the KDC
- after the starttime in the ticket has
- been reached.
-
- 7 UNUSED
- This option is presently unused.
-
- 8 RENEWABLE
- The RENEWABLE option indicates that the
- ticket to be issued is to have its
- RENEWABLE flag set. It may only be set
- on the initial request, or when the
- ticket-granting ticket on which the
- request is based is also renewable. If
- this option is requested, then the rtime
- field in the request contains the
- desired absolute expiration time for the
- ticket.
-
- 9-13 UNUSED
- These options are presently unused.
-
- 14 REQUEST-ANONYMOUS
- The REQUEST-ANONYMOUS option indicates
- that the ticket to be issued is not to
- identify the user to which it was
- issued. Instead, the principal identif-
- ier is to be generic, as specified by
- the policy of the realm (e.g. usually
- anonymous@realm). The purpose of the
- ticket is only to securely distribute a
- session key, and not to identify the
- user. The ANONYMOUS flag on the ticket
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- to be returned should be set. If the
- local realms policy does not permit
- anonymous credentials, the request is to
- be rejected.
-
- 15-25 RESERVED
- Reserved for future use.
-
- 26 DISABLE-TRANSITED-CHECK
- By default the KDC will check the
- transited field of a ticket-granting-
- ticket against the policy of the local
- realm before it will issue derivative
- tickets based on the ticket granting
- ticket. If this flag is set in the
- request, checking of the transited field
- is disabled. Tickets issued without the
- performance of this check will be noted
- by the reset (0) value of the
- TRANSITED-POLICY-CHECKED flag,
- indicating to the application server
- that the tranisted field must be checked
- locally. KDC's are encouraged but not
- required to honor the
- DISABLE-TRANSITED-CHECK option.
-
- 27 RENEWABLE-OK
- The RENEWABLE-OK option indicates that a
- renewable ticket will be acceptable if a
- ticket with the requested life cannot
- otherwise be provided. If a ticket with
- the requested life cannot be provided,
- then a renewable ticket may be issued
- with a renew-till equal to the the
- requested endtime. The value of the
- renew-till field may still be limited by
- local limits, or limits selected by the
- individual principal or server.
-
- 28 ENC-TKT-IN-SKEY
- This option is used only by the ticket-
- granting service. The ENC-TKT-IN-SKEY
- option indicates that the ticket for the
- end server is to be encrypted in the
- session key from the additional ticket-
- granting ticket provided.
-
- 29 RESERVED
- Reserved for future use.
-
- 30 RENEW
- This option is used only by the ticket-
- granting service. The RENEW option
- indicates that the present request is
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- for a renewal. The ticket provided is
- encrypted in the secret key for the
- server on which it is valid. This
- option will only be honored if the
- ticket to be renewed has its RENEWABLE
- flag set and if the time in its renew-
- till field has not passed. The ticket
- to be renewed is passed in the padata
- field as part of the authentication
- header.
-
- 31 VALIDATE
- This option is used only by the ticket-
- granting service. The VALIDATE option
- indicates that the request is to vali-
- date a postdated ticket. It will only
- be honored if the ticket presented is
- postdated, presently has its INVALID
- flag set, and would be otherwise usable
- at this time. A ticket cannot be vali-
- dated before its starttime. The ticket
- presented for validation is encrypted in
- the key of the server for which it is
- valid and is passed in the padata field
- as part of the authentication header.
-
-cname and sname
- These fields are the same as those described for the ticket in section
- 5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY option is
- specified. If absent, the name of the server is taken from the name of
- the client in the ticket passed as additional-tickets.
-enc-authorization-data
- The enc-authorization-data, if present (and it can only be present in
- the TGS_REQ form), is an encoding of the desired authorization-data
- encrypted under the sub-session key if present in the Authenticator, or
- alternatively from the session key in the ticket-granting ticket, both
- from the padata field in the KRB_AP_REQ.
-realm
- This field specifies the realm part of the server's principal
- identifier. In the AS exchange, this is also the realm part of the
- client's principal identifier.
-from
- This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket
- requests when the requested ticket is to be postdated. It specifies the
- desired start time for the requested ticket. If this field is omitted
- then the KDC should use the current time instead.
-till
- This field contains the expiration date requested by the client in a
- ticket request. It is optional and if omitted the requested ticket is
- to have the maximum endtime permitted according to KDC policy for the
- parties to the authentication exchange as limited by expiration date of
- the ticket granting ticket or other preauthentication credentials.
-rtime
- This field is the requested renew-till time sent from a client to the
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- KDC in a ticket request. It is optional.
-nonce
- This field is part of the KDC request and response. It it intended to
- hold a random number generated by the client. If the same number is
- included in the encrypted response from the KDC, it provides evidence
- that the response is fresh and has not been replayed by an attacker.
- Nonces must never be re-used. Ideally, it should be generated randomly,
- but if the correct time is known, it may suffice[25].
-etype
- This field specifies the desired encryption algorithm to be used in the
- response.
-addresses
- This field is included in the initial request for tickets, and
- optionally included in requests for additional tickets from the
- ticket-granting server. It specifies the addresses from which the
- requested ticket is to be valid. Normally it includes the addresses for
- the client's host. If a proxy is requested, this field will contain
- other addresses. The contents of this field are usually copied by the
- KDC into the caddr field of the resulting ticket.
-additional-tickets
- Additional tickets may be optionally included in a request to the
- ticket-granting server. If the ENC-TKT-IN-SKEY option has been
- specified, then the session key from the additional ticket will be used
- in place of the server's key to encrypt the new ticket. If more than
- one option which requires additional tickets has been specified, then
- the additional tickets are used in the order specified by the ordering
- of the options bits (see kdc-options, above).
-
-The application code will be either ten (10) or twelve (12) depending on
-whether the request is for an initial ticket (AS-REQ) or for an additional
-ticket (TGS-REQ).
-
-The optional fields (addresses, authorization-data and additional-tickets)
-are only included if necessary to perform the operation specified in the
-kdc-options field.
-
-It should be noted that in KRB_TGS_REQ, the protocol version number appears
-twice and two different message types appear: the KRB_TGS_REQ message
-contains these fields as does the authentication header (KRB_AP_REQ) that is
-passed in the padata field.
-
-5.4.2. KRB_KDC_REP definition
-
-The KRB_KDC_REP message format is used for the reply from the KDC for either
-an initial (AS) request or a subsequent (TGS) request. There is no message
-type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or
-KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply
-depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in
-the client's secret key, and the client's key version number is included in
-the key version number for the encrypted data. For KRB_TGS_REP, the
-ciphertext is encrypted in the sub-session key from the Authenticator, or if
-absent, the session key from the ticket-granting ticket used in the request.
-In that case, no version number will be present in the EncryptedData
-sequence.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
-The KRB_KDC_REP message contains the following fields:
-
-AS-REP ::= [APPLICATION 11] KDC-REP
-TGS-REP ::= [APPLICATION 13] KDC-REP
-
-KDC-REP ::= SEQUENCE {
- pvno[0] INTEGER,
- msg-type[1] INTEGER,
- padata[2] SEQUENCE OF PA-DATA OPTIONAL,
- crealm[3] Realm,
- cname[4] PrincipalName,
- ticket[5] Ticket,
- enc-part[6] EncryptedData
-}
-
-EncASRepPart ::= [APPLICATION 25[27]] EncKDCRepPart
-EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart
-
-EncKDCRepPart ::= SEQUENCE {
- key[0] EncryptionKey,
- last-req[1] LastReq,
- nonce[2] INTEGER,
- 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
-}
-
-pvno and msg-type
- These fields are described above in section 5.4.1. msg-type is either
- KRB_AS_REP or KRB_TGS_REP.
-padata
- This field is described in detail in section 5.4.1. One possible use
- for this field is to encode an alternate "mix-in" string to be used
- with a string-to-key algorithm (such as is described in section 6.3.2).
- This ability is useful to ease transitions if a realm name needs to
- change (e.g. when a company is acquired); in such a case all existing
- password-derived entries in the KDC database would be flagged as
- needing a special mix-in string until the next password change.
-crealm, cname, srealm and sname
- These fields are the same as those described for the ticket in section
- 5.3.1.
-ticket
- The newly-issued ticket, from section 5.3.1.
-enc-part
- This field is a place holder for the ciphertext and related information
- that forms the encrypted part of a message. The description of the
- encrypted part of the message follows each appearance of this field.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- The encrypted part is encoded as described in section 6.1.
-key
- This field is the same as described for the ticket in section 5.3.1.
-last-req
- This field is returned by the KDC and specifies the time(s) of the last
- request by a principal. Depending on what information is available,
- this might be the last time that a request for a ticket-granting ticket
- was made, or the last time that a request based on a ticket-granting
- ticket was successful. It also might cover all servers for a realm, or
- just the particular server. Some implementations may display this
- information to the user to aid in discovering unauthorized use of one's
- identity. It is similar in spirit to the last login time displayed when
- logging into timesharing systems.
-nonce
- This field is described above in section 5.4.1.
-key-expiration
- The key-expiration field is part of the response from the KDC and
- specifies the time that the client's secret key is due to expire. The
- expiration might be the result of password aging or an account
- expiration. This field will usually be left out of the TGS reply since
- the response to the TGS request is encrypted in a session key and no
- client information need be retrieved from the KDC database. It is up to
- the application client (usually the login program) to take appropriate
- action (such as notifying the user) if the expiration time is imminent.
-flags, authtime, starttime, endtime, renew-till and caddr
- These fields are duplicates of those found in the encrypted portion of
- the attached ticket (see section 5.3.1), provided so the client may
- verify they match the intended request and to assist in proper ticket
- caching. If the message is of type KRB_TGS_REP, the caddr field will
- only be filled in if the request was for a proxy or forwarded ticket,
- or if the user is substituting a subset of the addresses from the
- ticket granting ticket. If the client-requested addresses are not
- present or not used, then the addresses contained in the ticket will be
- the same as those included in the ticket-granting ticket.
-
-5.5. Client/Server (CS) message specifications
-
-This section specifies the format of the messages used for the
-authentication of the client to the application server.
-
-5.5.1. KRB_AP_REQ definition
-
-The KRB_AP_REQ message contains the Kerberos protocol version number, the
-message type KRB_AP_REQ, an options field to indicate any options in use,
-and the ticket and authenticator themselves. The KRB_AP_REQ message is often
-referred to as the 'authentication header'.
-
-AP-REQ ::= [APPLICATION 14] SEQUENCE {
- pvno[0] INTEGER,
- msg-type[1] INTEGER,
- ap-options[2] APOptions,
- ticket[3] Ticket,
- authenticator[4] EncryptedData
-}
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
-APOptions ::= BIT STRING {
- reserved(0),
- use-session-key(1),
- mutual-required(2)
-}
-
-
-
-pvno and msg-type
- These fields are described above in section 5.4.1. msg-type is
- KRB_AP_REQ.
-ap-options
- This field appears in the application request (KRB_AP_REQ) and affects
- the way the request is processed. It is a bit-field, where the selected
- options are indicated by the bit being set (1), and the unselected
- options and reserved fields being reset (0). The encoding of the bits
- is specified in section 5.2. The meanings of the options are:
-
- Bit(s) Name Description
- 0 RESERVED
- Reserved for future expansion of this
- field.
-
- 1 USE-SESSION-KEY
- The USE-SESSION-KEY option indicates
- that the ticket the client is presenting
- to a server is encrypted in the session
- key from the server's ticket-granting
- ticket. When this option is not speci-
- fied, the ticket is encrypted in the
- server's secret key.
-
- 2 MUTUAL-REQUIRED
- The MUTUAL-REQUIRED option tells the
- server that the client requires mutual
- authentication, and that it must respond
- with a KRB_AP_REP message.
-
- 3-31 RESERVED
- Reserved for future use.
-ticket
- This field is a ticket authenticating the client to the server.
-authenticator
- This contains the authenticator, which includes the client's choice of
- a subkey. Its encoding is described in section 5.3.2.
-
-5.5.2. KRB_AP_REP definition
-
-The KRB_AP_REP message contains the Kerberos protocol version number, the
-message type, and an encrypted time- stamp. The message is sent in in
-response to an application request (KRB_AP_REQ) where the mutual
-authentication option has been selected in the ap-options field.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-AP-REP ::= [APPLICATION 15] SEQUENCE {
- pvno[0] INTEGER,
- msg-type[1] INTEGER,
- enc-part[2] EncryptedData
-}
-
-EncAPRepPart ::= [APPLICATION 27[29]] SEQUENCE {
- ctime[0] KerberosTime,
- cusec[1] INTEGER,
- subkey[2] EncryptionKey OPTIONAL,
- seq-number[3] INTEGER OPTIONAL
-}
-
-The encoded EncAPRepPart is encrypted in the shared session key of the
-ticket. The optional subkey field can be used in an application-arranged
-negotiation to choose a per association session key.
-
-pvno and msg-type
- These fields are described above in section 5.4.1. msg-type is
- KRB_AP_REP.
-enc-part
- This field is described above in section 5.4.2.
-ctime
- This field contains the current time on the client's host.
-cusec
- This field contains the microsecond part of the client's timestamp.
-subkey
- This field contains an encryption key which is to be used to protect
- this specific application session. See section 3.2.6 for specifics on
- how this field is used to negotiate a key. Unless an application
- specifies otherwise, if this field is left out, the sub-session key
- from the authenticator, or if also left out, the session key from the
- ticket will be used.
-
-5.5.3. Error message reply
-
-If an error occurs while processing the application request, the KRB_ERROR
-message will be sent in response. See section 5.9.1 for the format of the
-error message. The cname and crealm fields may be left out if the server
-cannot determine their appropriate values from the corresponding KRB_AP_REQ
-message. If the authenticator was decipherable, the ctime and cusec fields
-will contain the values from it.
-
-5.6. KRB_SAFE message specification
-
-This section specifies the format of a message that can be used by either
-side (client or server) of an application to send a tamper-proof message to
-its peer. It presumes that a session key has previously been exchanged (for
-example, by using the KRB_AP_REQ/KRB_AP_REP messages).
-
-5.6.1. KRB_SAFE definition
-
-The KRB_SAFE message contains user data along with a collision-proof
-checksum keyed with the last encryption key negotiated via subkeys, or the
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-session key if no negotiation has occured. The message fields are:
-
-KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
- pvno[0] INTEGER,
- msg-type[1] INTEGER,
- safe-body[2] KRB-SAFE-BODY,
- cksum[3] Checksum
-}
-
-KRB-SAFE-BODY ::= SEQUENCE {
- user-data[0] OCTET STRING,
- timestamp[1] KerberosTime OPTIONAL,
- usec[2] INTEGER OPTIONAL,
- seq-number[3] INTEGER OPTIONAL,
- s-address[4] HostAddress OPTIONAL,
- r-address[5] HostAddress OPTIONAL
-}
-
-pvno and msg-type
- These fields are described above in section 5.4.1. msg-type is
- KRB_SAFE.
-safe-body
- This field is a placeholder for the body of the KRB-SAFE message. It is
- to be encoded separately and then have the checksum computed over it,
- for use in the cksum field.
-cksum
- This field contains the checksum of the application data. Checksum
- details are described in section 6.4. The checksum is computed over the
- encoding of the KRB-SAFE-BODY sequence.
-user-data
- This field is part of the KRB_SAFE and KRB_PRIV messages and contain
- the application specific data that is being passed from the sender to
- the recipient.
-timestamp
- This field is part of the KRB_SAFE and KRB_PRIV messages. Its contents
- are the current time as known by the sender of the message. By checking
- the timestamp, the recipient of the message is able to make sure that
- it was recently generated, and is not a replay.
-usec
- This field is part of the KRB_SAFE and KRB_PRIV headers. It contains
- the microsecond part of the timestamp.
-seq-number
- This field is described above in section 5.3.2.
-s-address
- This field specifies the address in use by the sender of the message.
-r-address
- This field specifies the address in use by the recipient of the
- message. It may be omitted for some uses (such as broadcast protocols),
- but the recipient may arbitrarily reject such messages. This field
- along with s-address can be used to help detect messages which have
- been incorrectly or maliciously delivered to the wrong recipient.
-
-5.7. KRB_PRIV message specification
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-This section specifies the format of a message that can be used by either
-side (client or server) of an application to securely and privately send a
-message to its peer. It presumes that a session key has previously been
-exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages).
-
-5.7.1. KRB_PRIV definition
-
-The KRB_PRIV message contains user data encrypted in the Session Key. The
-message fields are:
-
-KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
- pvno[0] INTEGER,
- msg-type[1] INTEGER,
- enc-part[3] EncryptedData
-}
-
-EncKrbPrivPart ::= [APPLICATION 28[31]] SEQUENCE {
- user-data[0] OCTET STRING,
- timestamp[1] KerberosTime OPTIONAL,
- usec[2] INTEGER OPTIONAL,
- seq-number[3] INTEGER OPTIONAL,
- s-address[4] HostAddress OPTIONAL, -- sender's addr
- r-address[5] HostAddress OPTIONAL -- recip's addr
-}
-
-pvno and msg-type
- These fields are described above in section 5.4.1. msg-type is
- KRB_PRIV.
-enc-part
- This field holds an encoding of the EncKrbPrivPart sequence encrypted
- under the session key[32]. This encrypted encoding is used for the
- enc-part field of the KRB-PRIV message. See section 6 for the format of
- the ciphertext.
-user-data, timestamp, usec, s-address and r-address
- These fields are described above in section 5.6.1.
-seq-number
- This field is described above in section 5.3.2.
-
-5.8. KRB_CRED message specification
-
-This section specifies the format of a message that can be used to send
-Kerberos credentials from one principal to another. It is presented here to
-encourage a common mechanism to be used by applications when forwarding
-tickets or providing proxies to subordinate servers. It presumes that a
-session key has already been exchanged perhaps by using the
-KRB_AP_REQ/KRB_AP_REP messages.
-
-5.8.1. KRB_CRED definition
-
-The KRB_CRED message contains a sequence of tickets to be sent and
-information needed to use the tickets, including the session key from each.
-The information needed to use the tickets is encrypted under an encryption
-key previously exchanged or transferred alongside the KRB_CRED message. The
-message fields are:
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
-KRB-CRED ::= [APPLICATION 22] SEQUENCE {
- pvno[0] INTEGER,
- msg-type[1] INTEGER, -- KRB_CRED
- tickets[2] SEQUENCE OF Ticket,
- enc-part[3] EncryptedData
-}
-
-EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
- ticket-info[0] SEQUENCE OF KrbCredInfo,
- nonce[1] INTEGER OPTIONAL,
- timestamp[2] KerberosTime OPTIONAL,
- usec[3] INTEGER 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
-}
-
-pvno and msg-type
- These fields are described above in section 5.4.1. msg-type is
- KRB_CRED.
-tickets
- These are the tickets obtained from the KDC specifically for use by the
- intended recipient. Successive tickets are paired with the
- corresponding KrbCredInfo sequence from the enc-part of the KRB-CRED
- message.
-enc-part
- This field holds an encoding of the EncKrbCredPart sequence encrypted
- under the session key shared between the sender and the intended
- recipient. This encrypted encoding is used for the enc-part field of
- the KRB-CRED message. See section 6 for the format of the ciphertext.
-nonce
- If practical, an application may require the inclusion of a nonce
- generated by the recipient of the message. If the same value is
- included as the nonce in the message, it provides evidence that the
- message is fresh and has not been replayed by an attacker. A nonce must
- never be re-used; it should be generated randomly by the recipient of
- the message and provided to the sender of the message in an application
- specific manner.
-timestamp and usec
- These fields specify the time that the KRB-CRED message was generated.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- The time is used to provide assurance that the message is fresh.
-s-address and r-address
- These fields are described above in section 5.6.1. They are used
- optionally to provide additional assurance of the integrity of the
- KRB-CRED message.
-key
- This field exists in the corresponding ticket passed by the KRB-CRED
- message and is used to pass the session key from the sender to the
- intended recipient. The field's encoding is described in section 6.2.
-
-The following fields are optional. If present, they can be associated with
-the credentials in the remote ticket file. If left out, then it is assumed
-that the recipient of the credentials already knows their value.
-
-prealm and pname
- The name and realm of the delegated principal identity.
-flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr
- These fields contain the values of the correspond- ing fields from the
- ticket found in the ticket field. Descriptions of the fields are
- identical to the descriptions in the KDC-REP message.
-
-5.9. Error message specification
-
-This section specifies the format for the KRB_ERROR message. The fields
-included in the message are intended to return as much information as
-possible about an error. It is not expected that all the information
-required by the fields will be available for all types of errors. If the
-appropriate information is not available when the message is composed, the
-corresponding field will be left out of the message.
-
-Note that since the KRB_ERROR message is not protected by any encryption, it
-is quite possible for an intruder to synthesize or modify such a message. In
-particular, this means that the client should not use any fields in this
-message for security-critical purposes, such as setting a system clock or
-generating a fresh authenticator. The message can be useful, however, for
-advising a user on the reason for some failure.
-
-5.9.1. KRB_ERROR definition
-
-The KRB_ERROR message consists of the following fields:
-
-KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
- pvno[0] INTEGER,
- msg-type[1] INTEGER,
- ctime[2] KerberosTime OPTIONAL,
- cusec[3] INTEGER OPTIONAL,
- stime[4] KerberosTime,
- susec[5] INTEGER,
- error-code[6] INTEGER,
- crealm[7] Realm OPTIONAL,
- cname[8] PrincipalName OPTIONAL,
- realm[9] Realm, -- Correct realm
- sname[10] PrincipalName, -- Correct name
- e-text[11] GeneralString OPTIONAL,
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- e-data[12] OCTET STRING OPTIONAL,
- e-cksum[13] Checksum OPTIONAL,
- e-typed-data[14] SEQUENCE of ETypedData OPTIONAL
-}
-
-ETypedData ::= SEQUENCE {
- e-data-type [1] INTEGER,
- e-data-value [2] OCTET STRING,
-}
-
-
-
-pvno and msg-type
- These fields are described above in section 5.4.1. msg-type is
- KRB_ERROR.
-ctime
- This field is described above in section 5.4.1.
-cusec
- This field is described above in section 5.5.2.
-stime
- This field contains the current time on the server. It is of type
- KerberosTime.
-susec
- This field contains the microsecond part of the server's timestamp. Its
- value ranges from 0 to 999999. It appears along with stime. The two
- fields are used in conjunction to specify a reasonably accurate
- timestamp.
-error-code
- This field contains the error code returned by Kerberos or the server
- when a request fails. To interpret the value of this field see the list
- of error codes in section 8. Implementations are encouraged to provide
- for national language support in the display of error messages.
-crealm, cname, srealm and sname
- These fields are described above in section 5.3.1.
-e-text
- This field contains additional text to help explain the error code
- associated with the failed request (for example, it might include a
- principal name which was unknown).
-e-data
- This field contains additional data about the error for use by the
- application to help it recover from or handle the error. If the
- errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will
- contain an encoding of a sequence of padata fields, each corresponding
- to an acceptable pre-authentication method and optionally containing
- data for the method:
-
- METHOD-DATA ::= SEQUENCE of PA-DATA
-
- If the error-code is KRB_AP_ERR_METHOD, then the e-data field will
- contain an encoding of the following sequence:
-
- METHOD-DATA ::= SEQUENCE {
- method-type[0] INTEGER,
- method-data[1] OCTET STRING OPTIONAL
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- }
-
- method-type will indicate the required alternate method; method-data
- will contain any required additional information.
-e-cksum
- This field contains an optional checksum for the KRB-ERROR message. The
- checksum is calculated over the Kerberos ASN.1 encoding of the
- KRB-ERROR message with the checksum absent. The checksum is then added
- to the KRB-ERROR structure and the message is re-encoded. The Checksum
- should be calculated using the session key from the ticket granting
- ticket or service ticket, where available. If the error is in response
- to a TGS or AP request, the checksum should be calculated uing the the
- session key from the client's ticket. If the error is in response to an
- AS request, then the checksum should be calulated using the client's
- secret key ONLY if there has been suitable preauthentication to prove
- knowledge of the secret key by the client[33]. If a checksum can not be
- computed because the key to be used is not available, no checksum will
- be included.
-e-typed-data
- [This field for discussion, may be deleted from final spec] This field
- contains optional data that may be used to help the client recover from
- the indicated error. [This could contain the METHOD-DATA specified
- since I don't think anyone actually uses it yet. It could also contain
- the PA-DATA sequence for the preauth required error if we had a clear
- way to transition to the use of this field from the use of the untype
- e-data field.] For example, this field may specify the key version of
- the key used to verify preauthentication:
-
- e-data-type := 20 -- Key version number
- e-data-value := Integer -- Key version number used to verify
- preauthentication
-
-6. Encryption and Checksum Specifications
-
-The Kerberos protocols described in this document are designed to use stream
-encryption ciphers, which can be simulated using commonly available block
-encryption ciphers, such as the Data Encryption Standard, [DES77] in
-conjunction with block chaining and checksum methods [DESM80]. Encryption is
-used to prove the identities of the network entities participating in
-message exchanges. The Key Distribution Center for each realm is trusted by
-all principals registered in that realm to store a secret key in confidence.
-Proof of knowledge of this secret key is used to verify the authenticity of
-a principal.
-
-The KDC uses the principal's secret key (in the AS exchange) or a shared
-session key (in the TGS exchange) to encrypt responses to ticket requests;
-the ability to obtain the secret key or session key implies the knowledge of
-the appropriate keys and the identity of the KDC. The ability of a principal
-to decrypt the KDC response and present a Ticket and a properly formed
-Authenticator (generated with the session key from the KDC response) to a
-service verifies the identity of the principal; likewise the ability of the
-service to extract the session key from the Ticket and prove its knowledge
-thereof in a response verifies the identity of the service.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-The Kerberos protocols generally assume that the encryption used is secure
-from cryptanalysis; however, in some cases, the order of fields in the
-encrypted portions of messages are arranged to minimize the effects of
-poorly chosen keys. It is still important to choose good keys. If keys are
-derived from user-typed passwords, those passwords need to be well chosen to
-make brute force attacks more difficult. Poorly chosen keys still make easy
-targets for intruders.
-
-The following sections specify the encryption and checksum mechanisms
-currently defined for Kerberos. The encodings, chaining, and padding
-requirements for each are described. For encryption methods, it is often
-desirable to place random information (often referred to as a confounder) at
-the start of the message. The requirements for a confounder are specified
-with each encryption mechanism.
-
-Some encryption systems use a block-chaining method to improve the the
-security characteristics of the ciphertext. However, these chaining methods
-often don't provide an integrity check upon decryption. Such systems (such
-as DES in CBC mode) must be augmented with a checksum of the plain-text
-which can be verified at decryption and used to detect any tampering or
-damage. Such checksums should be good at detecting burst errors in the
-input. If any damage is detected, the decryption routine is expected to
-return an error indicating the failure of an integrity check. Each
-encryption type is expected to provide and verify an appropriate checksum.
-The specification of each encryption method sets out its checksum
-requirements.
-
-Finally, where a key is to be derived from a user's password, an algorithm
-for converting the password to a key of the appropriate type is included. It
-is desirable for the string to key function to be one-way, and for the
-mapping to be different in different realms. This is important because users
-who are registered in more than one realm will often use the same password
-in each, and it is desirable that an attacker compromising the Kerberos
-server in one realm not obtain or derive the user's key in another.
-
-For an discussion of the integrity characteristics of the candidate
-encryption and checksum methods considered for Kerberos, the the reader is
-referred to [SG92].
-
-6.1. Encryption Specifications
-
-The following ASN.1 definition describes all encrypted messages. The
-enc-part field which appears in the unencrypted part of messages in section
-5 is a sequence consisting of an encryption type, an optional key version
-number, and the ciphertext.
-
-EncryptedData ::= SEQUENCE {
- etype[0] INTEGER, -- EncryptionType
- kvno[1] INTEGER OPTIONAL,
- cipher[2] OCTET STRING -- ciphertext
-}
-
-
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-etype
- This field identifies which encryption algorithm was used to encipher
- the cipher. Detailed specifications for selected encryption types
- appear later in this section.
-kvno
- This field contains the version number of the key under which data is
- encrypted. It is only present in messages encrypted under long lasting
- keys, such as principals' secret keys.
-cipher
- This field contains the enciphered text, encoded as an OCTET STRING.
-
-The cipher field is generated by applying the specified encryption algorithm
-to data composed of the message and algorithm-specific inputs. Encryption
-mechanisms defined for use with Kerberos must take sufficient measures to
-guarantee the integrity of the plaintext, and we recommend they also take
-measures to protect against precomputed dictionary attacks. If the
-encryption algorithm is not itself capable of doing so, the protections can
-often be enhanced by adding a checksum and a confounder.
-
-The suggested format for the data to be encrypted includes a confounder, a
-checksum, the encoded plaintext, and any necessary padding. The msg-seq
-field contains the part of the protocol message described in section 5 which
-is to be encrypted. The confounder, checksum, and padding are all untagged
-and untyped, and their length is exactly sufficient to hold the appropriate
-item. The type and length is implicit and specified by the particular
-encryption type being used (etype). The format for the data to be encrypted
-is described in the following diagram:
-
- +-----------+----------+-------------+-----+
- |confounder | check | msg-seq | pad |
- +-----------+----------+-------------+-----+
-
-The format cannot be described in ASN.1, but for those who prefer an
-ASN.1-like notation:
-
-CipherText ::= ENCRYPTED SEQUENCE {
- confounder[0] UNTAGGED[35] OCTET STRING(conf_length) OPTIONAL,
- check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL,
- msg-seq[2] MsgSequence,
- pad UNTAGGED OCTET STRING(pad_length) OPTIONAL
-}
-
-One generates a random confounder of the appropriate length, placing it in
-confounder; zeroes out check; calculates the appropriate checksum over
-confounder, check, and msg-seq, placing the result in check; adds the
-necessary padding; then encrypts using the specified encryption type and the
-appropriate key.
-
-Unless otherwise specified, a definition of an encryption algorithm that
-specifies a checksum, a length for the confounder field, or an octet
-boundary for padding uses this ciphertext format[36]. Those fields which are
-not specified will be omitted.
-
-In the interest of allowing all implementations using a particular
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-encryption type to communicate with all others using that type, the
-specification of an encryption type defines any checksum that is needed as
-part of the encryption process. If an alternative checksum is to be used, a
-new encryption type must be defined.
-
-Some cryptosystems require additional information beyond the key and the
-data to be encrypted. For example, DES, when used in cipher-block-chaining
-mode, requires an initialization vector. If required, the description for
-each encryption type must specify the source of such additional information.
-6.2. Encryption Keys
-
-The sequence below shows the encoding of an encryption key:
-
- EncryptionKey ::= SEQUENCE {
- keytype[0] INTEGER,
- keyvalue[1] OCTET STRING
- }
-
-keytype
- This field specifies the type of encryption key that follows in the
- keyvalue field. It will almost always correspond to the encryption
- algorithm used to generate the EncryptedData, though more than one
- algorithm may use the same type of key (the mapping is many to one).
- This might happen, for example, if the encryption algorithm uses an
- alternate checksum algorithm for an integrity check, or a different
- chaining mechanism.
-keyvalue
- This field contains the key itself, encoded as an octet string.
-
-All negative values for the encryption key type are reserved for local use.
-All non-negative values are reserved for officially assigned type fields and
-interpreta- tions.
-
-6.3. Encryption Systems
-
-6.3.1. The NULL Encryption System (null)
-
-If no encryption is in use, the encryption system is said to be the NULL
-encryption system. In the NULL encryption system there is no checksum,
-confounder or padding. The ciphertext is simply the plaintext. The NULL Key
-is used by the null encryption system and is zero octets in length, with
-keytype zero (0).
-
-6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc)
-
-The des-cbc-crc encryption mode encrypts information under the Data
-Encryption Standard [DES77] using the cipher block chaining mode [DESM80]. A
-CRC-32 checksum (described in ISO 3309 [ISO3309]) is applied to the
-confounder and message sequence (msg-seq) and placed in the cksum field. DES
-blocks are 8 bytes. As a result, the data to be encrypted (the concatenation
-of confounder, checksum, and message) must be padded to an 8 byte boundary
-before encryption. The details of the encryption of this data are identical
-to those for the des-cbc-md5 encryption mode.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-Note that, since the CRC-32 checksum is not collision-proof, an attacker
-could use a probabilistic chosen-plaintext attack to generate a valid
-message even if a confounder is used [SG92]. The use of collision-proof
-checksums is recommended for environments where such attacks represent a
-significant threat. The use of the CRC-32 as the checksum for ticket or
-authenticator is no longer mandated as an interoperability requirement for
-Kerberos Version 5 Specification 1 (See section 9.1 for specific details).
-
-6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4)
-
-The des-cbc-md4 encryption mode encrypts information under the Data
-Encryption Standard [DES77] using the cipher block chaining mode [DESM80].
-An MD4 checksum (described in [MD492]) is applied to the confounder and
-message sequence (msg-seq) and placed in the cksum field. DES blocks are 8
-bytes. As a result, the data to be encrypted (the concatenation of
-confounder, checksum, and message) must be padded to an 8 byte boundary
-before encryption. The details of the encryption of this data are identical
-to those for the des-cbc-md5 encryption mode.
-
-6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5)
-
-The des-cbc-md5 encryption mode encrypts information under the Data
-Encryption Standard [DES77] using the cipher block chaining mode [DESM80].
-An MD5 checksum (described in [MD5-92].) is applied to the confounder and
-message sequence (msg-seq) and placed in the cksum field. DES blocks are 8
-bytes. As a result, the data to be encrypted (the concatenation of
-confounder, checksum, and message) must be padded to an 8 byte boundary
-before encryption.
-
-Plaintext and DES ciphtertext are encoded as blocks of 8 octets which are
-concatenated to make the 64-bit inputs for the DES algorithms. The first
-octet supplies the 8 most significant bits (with the octet's MSbit used as
-the DES input block's MSbit, etc.), the second octet the next 8 bits, ...,
-and the eighth octet supplies the 8 least significant bits.
-
-Encryption under DES using cipher block chaining requires an additional
-input in the form of an initialization vector. Unless otherwise specified,
-zero should be used as the initialization vector. Kerberos' use of DES
-requires an 8 octet confounder.
-
-The DES specifications identify some 'weak' and 'semi-weak' keys; those keys
-shall not be used for encrypting messages for use in Kerberos. Additionally,
-because of the way that keys are derived for the encryption of checksums,
-keys shall not be used that yield 'weak' or 'semi-weak' keys when
-eXclusive-ORed with the hexadecimal constant F0F0F0F0F0F0F0F0.
-
-A DES key is 8 octets of data, with keytype one (1). This consists of 56
-bits of key, and 8 parity bits (one per octet). The key is encoded as a
-series of 8 octets written in MSB-first order. The bits within the key are
-also encoded in MSB order. For example, if the encryption key is
-(B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where
-B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the parity
-bits, the first octet of the key would be B1,B2,...,B7,P1 (with B1 as the
-MSbit). [See the FIPS 81 introduction for reference.]
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
-String to key transformation
-
-To generate a DES key from a text string (password), the text string
-normally must have the realm and each component of the principal's name
-appended[37], then padded with ASCII nulls to an 8 byte boundary. This
-string is then fan-folded and eXclusive-ORed with itself to form an 8 byte
-DES key. The parity is corrected on the key, and it is used to generate a
-DES CBC checksum on the initial string (with the realm and name appended).
-Next, parity is corrected on the CBC checksum. If the result matches a
-'weak' or 'semi-weak' key as described in the DES specification, it is
-eXclusive-ORed with the constant 00000000000000F0. Finally, the result is
-returned as the key. Pseudocode follows:
-
- string_to_key(string,realm,name) {
- odd = 1;
- s = string + realm;
- for(each component in name) {
- s = s + component;
- }
- tempkey = NULL;
- pad(s); /* with nulls to 8 byte boundary */
- for(8byteblock in s) {
- if(odd == 0) {
- odd = 1;
- reverse(8byteblock)
- }
- else odd = 0;
- tempkey = tempkey XOR 8byteblock;
- }
- fixparity(tempkey);
- key = DES-CBC-check(s,tempkey);
- fixparity(key);
- if(is_weak_key_key(key))
- key = key XOR 0xF0;
- return(key);
- }
-
-6.3.5. Triple DES EDE in outer CBC mode with an SHA1 check-sum
-(des3-cbc-sha1)
-
-The des3-cbc-sha1 encryption encodes information using three Data Encryption
-Standard transformations with three DES keys. The first key is used to
-perform a DES ECB encryption on an eight-octet data block using the first
-DES key, followed by a DES ECB decryption of the result using the second DES
-key, and a DES ECB encryption of the result using the third DES key. Because
-DES blocks are 8 bytes, the data to be encrypted (the concatenation of
-confounder, checksum, and message) must first be padded to an 8 byte
-boundary before encryption. To support the outer CBC mode, the input is
-padded to an eight-octet boundary. The first 8 octets of the data to be
-encrypted (the confounder) is exclusive-ored with an initialization vector
-of zero and then ECB encrypted using triple DES as described above.
-Subsequent blocks of 8 octets are exclusive-ored with the ciphertext
-produced by the encryption on the previous block before ECB encryption.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
-An HMAC-SHA1 checksum (described in [KBC96].) is applied to the confounder
-and message sequence (msg-seq) and placed in the cksum field.
-
-Plaintext are encoded as blocks of 8 octets which are concatenated to make
-the 64-bit inputs for the DES algorithms. The first octet supplies the 8
-most significant bits (with the octet's MSbit used as the DES input block's
-MSbit, etc.), the second octet the next 8 bits, ..., and the eighth octet
-supplies the 8 least significant bits.
-
-Encryption under Triple DES using cipher block chaining requires an
-additional input in the form of an initialization vector. Unless otherwise
-specified, zero should be used as the initialization vector. Kerberos' use
-of DES requires an 8 octet confounder.
-
-The DES specifications identify some 'weak' and 'semi-weak' keys; those keys
-shall not be used for encrypting messages for use in Kerberos. Additionally,
-because of the way that keys are derived for the encryption of checksums,
-keys shall not be used that yield 'weak' or 'semi-weak' keys when
-eXclusive-ORed with the hexadecimal constant F0F0F0F0F0F0F0F0.
-
-A Triple DES key is 24 octets of data, with keytype seven (7). This consists
-of 168 bits of key, and 24 parity bits (one per octet). The key is encoded
-as a series of 24 octets written in MSB-first order, with the first 8 octets
-treated as the first DES key, the second 8 octets as the second key, and the
-third 8 octets the third DES key. The bits within each key are also encoded
-in MSB order. For example, if the encryption key is
-(B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where
-B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the parity
-bits, the first octet of the key would be B1,B2,...,B7,P1 (with B1 as the
-MSbit). [See the FIPS 81 introduction for reference.]
-
-Key derivation for specified operations (Horowitz)
-
-[Discussion is needed for this section, especially since it does not simply
-derive key generation, but also specifies encryption using triple DES in a
-manner that is different than the basic template that was specified for
-single DES and similar systems]
-
-In the Kerberos protocol cryptographic keys are used in a number of places.
-In order to minimize the effect of compromising a key, it is desirable to
-use a different key in each of these places. Key derivation [Horowitz96] can
-be used to construct different keys for each operation from the keys
-transported on the network or derived from the password specified by the
-user.
-
-For each place where a key is used in Kerberos, a ``key usage'' is specified
-for that purpose. The key, key usage, and encryption/checksum type together
-describe the transformation from plaintext to ciphertext. For backwards
-compatibility, this key derivation is only specified here for encryption
-methods based on triple DES. Encryption methods specified for use by
-Kerberos in the future should specify the key derivation function to be
-used.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-Kerberos requires that the ciphertext component of EncryptedData be
-tamper-resistant as well as confidential. This implies encryption and
-integrity functions, which must each use their own separate keys. So, for
-each key usage, two keys must be generated, one for encryption (Ke), and one
-for integrity (Ki):
-
- Ke = DK(protocol key, key usage | 0xAA)
- Ki = DK(protocol key, key usage | 0x55)
-
-where the key usage is represented as a 32 bit integer in network byte
-order. The ciphertest must be generated from the plaintext as follows:
-
- ciphertext = E(Ke, confounder | length | plaintext | padding) |
- H(Ki, confounder | length | plaintext | padding)
-
-The confounder and padding are specific to the encryption algorithm E.
-
-When generating a checksum only, there is no need for a confounder or
-padding. Again, a new key (Kc) must be used. Checksums must be generated
-from the plaintext as follows:
-
- Kc = DK(protocol key, key usage | 0x99)
- MAC = H(Kc, length | plaintext)
-
-
-Note that each enctype is described by an encryption algorithm E and a keyed
-hash algorithm H, and each checksum type is described by a keyed hash
-algorithm H. HMAC, with an appropriate hash, is recommended for use as H.
-
-The key usage value will be taken from the following list of places where
-keys are used in the Kerberos protocol, with key usage values and Kerberos
-specification section numbers:
-
- 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the
- client key (section 5.4.1)
- 2. AS-REP Ticket and TGS-REP Ticket (includes tgs session key or
- application session key), encrypted with the service key
- (section 5.4.2)
- 3. AS-REP encrypted part (includes tgs session key or application
- session key), encrypted with the client key (section 5.4.2)
-
- 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
- session key (section 5.4.1)
- 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
- authenticator subkey (section 5.4.1)
- 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed
- with the tgs session key (sections 5.3.2, 5.4.1)
- 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs
- authenticator subkey), encrypted with the tgs session key
- (section 5.3.2)
- 8. TGS-REP encrypted part (includes application session key),
- encrypted with the tgs session key (section 5.4.2)
- 9. TGS-REP encrypted part (includes application session key),
- encrypted with the tgs authenticator subkey (section 5.4.2)
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
- 10. AP-REQ Authenticator cksum, keyed with the application session
- key (section 5.3.2)
- 11. AP-REQ Authenticator (includes application authenticator
- subkey), encrypted with the application session key (section
- 5.3.2)
- 12. AP-REP encrypted part (includes application session subkey),
- encrypted with the application session key (section 5.5.2)
-
- 13. KRB-PRIV encrypted part, encrypted with a key chosen by the
- application (section 5.7.1)
- 14. KRB-CRED encrypted part, encrypted with a key chosen by the
- application (section 5.6.1)
- 15. KRB-SAFE cksum, keyed with a key chosen by the application
- (section 5.8.1)
-
- 16. Data which is defined in some specification outside of
- Kerberos to be encrypted using Kerberos encryption type.
- 17. Data which is defined in some specification outside of
- Kerberos to be checksummed using Kerberos checksum type.
-
- 18. KRB-ERROR checksum (e-cksum in section 5.9.1)
- 19. AD-KDCIssued checksum (ad-checksum in appendix B.1)
- 20. Checksum for Mandatory Ticket Extensions (appendix B.6)
- 21. Checksum in Authorization Data in Ticket Extensions (appendix B.7)
-
-String to key transformation
-
-To generate a DES key from a text string (password), the text string
-normally must have the realm and each component of the principal's name
-appended[38].
-
-The input string (with any salt data appended to it) is n-folded into a 24
-octet (192 bit) string. To n-fold a number X, replicate the input value to a
-length that is the least common multiple of n and the length of X. Before
-each repetition, the input X is rotated to the right by 13 bit positions.
-The successive n-bit chunks are added together using 1's-complement addition
-(addition with end-around carry) to yield a n-bit result. (This
-transformation was proposed by Richard Basch)
-
-Each successive set of 8 octets is taken as a DES key, and its parity is
-adjusted in the same manner as previously described. If any of the three
-sets of 8 octets match a 'weak' or 'semi-weak key as described in the DES
-specification, that chunk is eXclusive-ORed with the hexadecimal constant
-00000000000000F0. The resulting DES keys are then used in sequence to
-perform a Triple-DES CBC encryption of the n-folded input string (appended
-with any salt data), using a zero initial vector. Parity, weak, and
-semi-weak keys are once again corrected and the result is returned as the 24
-octet key.
-
-Pseudocode follows:
-
- string_to_key(string,realm,name) {
- s = string + realm;
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- for(each component in name) {
- s = s + component;
- }
- tkey[24] = fold(s);
- fixparity(tkey);
- if(isweak(tkey[0-7])) tkey[0-7] = tkey[0-7] XOR 0xF0;
- if(isweak(tkey[8-15])) tkey[8-15] = tkey[8-15] XOR 0xF0;
- if(is_weak(tkey[16-23])) tkey[16-23] = tkey[16-23] XOR 0xF0;
- key[24] = 3DES-CBC(data=fold(s),key=tkey,iv=0);
- fixparity(key);
- if(is_weak(key[0-7])) key[0-7] = key[0-7] XOR 0xF0;
- if(is_weak(key[8-15])) key[8-15] = key[8-15] XOR 0xF0;
- if(is_weak(key[16-23])) key[16-23] = key[16-23] XOR 0xF0;
- return(key);
- }
-
-6.4. Checksums
-
-The following is the ASN.1 definition used for a checksum:
-
- Checksum ::= SEQUENCE {
- cksumtype[0] INTEGER,
- checksum[1] OCTET STRING
- }
-
-cksumtype
- This field indicates the algorithm used to generate the accompanying
- checksum.
-checksum
- This field contains the checksum itself, encoded as an octet string.
-
-Detailed specification of selected checksum types appear later in this
-section. Negative values for the checksum type are reserved for local use.
-All non-negative values are reserved for officially assigned type fields and
-interpretations.
-
-Checksums used by Kerberos can be classified by two properties: whether they
-are collision-proof, and whether they are keyed. It is infeasible to find
-two plaintexts which generate the same checksum value for a collision-proof
-checksum. A key is required to perturb or initialize the algorithm in a
-keyed checksum. To prevent message-stream modification by an active
-attacker, unkeyed checksums should only be used when the checksum and
-message will be subsequently encrypted (e.g. the checksums defined as part
-of the encryption algorithms covered earlier in this section).
-
-Collision-proof checksums can be made tamper-proof if the checksum value is
-encrypted before inclusion in a message. In such cases, the composition of
-the checksum and the encryption algorithm must be considered a separate
-checksum algorithm (e.g. RSA-MD5 encrypted using DES is a new checksum
-algorithm of type RSA-MD5-DES). For most keyed checksums, as well as for the
-encrypted forms of unkeyed collision-proof checksums, Kerberos prepends a
-confounder before the checksum is calculated.
-
-6.4.1. The CRC-32 Checksum (crc32)
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
-The CRC-32 checksum calculates a checksum based on a cyclic redundancy check
-as described in ISO 3309 [ISO3309]. The resulting checksum is four (4)
-octets in length. The CRC-32 is neither keyed nor collision-proof. The use
-of this checksum is not recommended. An attacker using a probabilistic
-chosen-plaintext attack as described in [SG92] might be able to generate an
-alternative message that satisfies the checksum. The use of collision-proof
-checksums is recommended for environments where such attacks represent a
-significant threat.
-
-6.4.2. The RSA MD4 Checksum (rsa-md4)
-
-The RSA-MD4 checksum calculates a checksum using the RSA MD4 algorithm
-[MD4-92]. The algorithm takes as input an input message of arbitrary length
-and produces as output a 128-bit (16 octet) checksum. RSA-MD4 is believed to
-be collision-proof.
-
-6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4-des)
-
-The RSA-MD4-DES checksum calculates a keyed collision-proof checksum by
-prepending an 8 octet confounder before the text, applying the RSA MD4
-checksum algorithm, and encrypting the confounder and the checksum using DES
-in cipher-block-chaining (CBC) mode using a variant of the key, where the
-variant is computed by eXclusive-ORing the key with the constant
-F0F0F0F0F0F0F0F0[39]. The initialization vector should be zero. The
-resulting checksum is 24 octets long (8 octets of which are redundant). This
-checksum is tamper-proof and believed to be collision-proof.
-
-The DES specifications identify some weak keys' and 'semi-weak keys'; those
-keys shall not be used for generating RSA-MD4 checksums for use in Kerberos.
-
-The format for the checksum is described in the follow- ing diagram:
-
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-| des-cbc(confounder + rsa-md4(confounder+msg),key=var(key),iv=0) |
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The format cannot be described in ASN.1, but for those who prefer an
-ASN.1-like notation:
-
-rsa-md4-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE {
- confounder[0] UNTAGGED OCTET STRING(8),
- check[1] UNTAGGED OCTET STRING(16)
-}
-
-6.4.4. The RSA MD5 Checksum (rsa-md5)
-
-The RSA-MD5 checksum calculates a checksum using the RSA MD5 algorithm.
-[MD5-92]. The algorithm takes as input an input message of arbitrary length
-and produces as output a 128-bit (16 octet) checksum. RSA-MD5 is believed to
-be collision-proof.
-
-6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5-des)
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-The RSA-MD5-DES checksum calculates a keyed collision-proof checksum by
-prepending an 8 octet confounder before the text, applying the RSA MD5
-checksum algorithm, and encrypting the confounder and the checksum using DES
-in cipher-block-chaining (CBC) mode using a variant of the key, where the
-variant is computed by eXclusive-ORing the key with the hexadecimal constant
-F0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting
-checksum is 24 octets long (8 octets of which are redundant). This checksum
-is tamper-proof and believed to be collision-proof.
-
-The DES specifications identify some 'weak keys' and 'semi-weak keys'; those
-keys shall not be used for encrypting RSA-MD5 checksums for use in Kerberos.
-
-The format for the checksum is described in the following diagram:
-
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-| des-cbc(confounder + rsa-md5(confounder+msg),key=var(key),iv=0) |
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The format cannot be described in ASN.1, but for those who prefer an
-ASN.1-like notation:
-
-rsa-md5-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE {
- confounder[0] UNTAGGED OCTET STRING(8),
- check[1] UNTAGGED OCTET STRING(16)
-}
-
-6.4.6. DES cipher-block chained checksum (des-mac)
-
-The DES-MAC checksum is computed by prepending an 8 octet confounder to the
-plaintext, performing a DES CBC-mode encryption on the result using the key
-and an initialization vector of zero, taking the last block of the
-ciphertext, prepending the same confounder and encrypting the pair using DES
-in cipher-block-chaining (CBC) mode using a a variant of the key, where the
-variant is computed by eXclusive-ORing the key with the hexadecimal constant
-F0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting
-checksum is 128 bits (16 octets) long, 64 bits of which are redundant. This
-checksum is tamper-proof and collision-proof.
-
-The format for the checksum is described in the following diagram:
-
-+--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
-| des-cbc(confounder + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) |
-+--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
-
-The format cannot be described in ASN.1, but for those who prefer an
-ASN.1-like notation:
-
-des-mac-checksum ::= ENCRYPTED UNTAGGED SEQUENCE {
- confounder[0] UNTAGGED OCTET STRING(8),
- check[1] UNTAGGED OCTET STRING(8)
-}
-
-The DES specifications identify some 'weak' and 'semi-weak' keys; those keys
-shall not be used for generating DES-MAC checksums for use in Kerberos, nor
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-shall a key be used whose variant is 'weak' or 'semi-weak'.
-
-6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative (rsa-md4-des-k)
-
-The RSA-MD4-DES-K checksum calculates a keyed collision-proof checksum by
-applying the RSA MD4 checksum algorithm and encrypting the results using DES
-in cipher-block-chaining (CBC) mode using a DES key as both key and
-initialization vector. The resulting checksum is 16 octets long. This
-checksum is tamper-proof and believed to be collision-proof. Note that this
-checksum type is the old method for encoding the RSA-MD4-DES checksum and it
-is no longer recommended.
-
-6.4.8. DES cipher-block chained checksum alternative (des-mac-k)
-
-The DES-MAC-K checksum is computed by performing a DES CBC-mode encryption
-of the plaintext, and using the last block of the ciphertext as the checksum
-value. It is keyed with an encryption key and an initialization vector; any
-uses which do not specify an additional initialization vector will use the
-key as both key and initialization vector. The resulting checksum is 64 bits
-(8 octets) long. This checksum is tamper-proof and collision-proof. Note
-that this checksum type is the old method for encoding the DES-MAC checksum
-and it is no longer recommended. The DES specifications identify some 'weak
-keys' and 'semi-weak keys'; those keys shall not be used for generating
-DES-MAC checksums for use in Kerberos.
-
-7. Naming Constraints
-
-7.1. Realm Names
-
-Although realm names are encoded as GeneralStrings and although a realm can
-technically select any name it chooses, interoperability across realm
-boundaries requires agreement on how realm names are to be assigned, and
-what information they imply.
-
-To enforce these conventions, each realm must conform to the conventions
-itself, and it must require that any realms with which inter-realm keys are
-shared also conform to the conventions and require the same from its
-neighbors.
-
-Kerberos realm names are case sensitive. Realm names that differ only in the
-case of the characters are not equivalent. There are presently four styles
-of realm names: domain, X500, other, and reserved. Examples of each style
-follow:
-
- domain: ATHENA.MIT.EDU (example)
- X500: C=US/O=OSF (example)
- other: NAMETYPE:rest/of.name=without-restrictions (example)
- reserved: reserved, but will not conflict with above
-
-Domain names must look like domain names: they consist of components
-separated by periods (.) and they contain neither colons (:) nor slashes
-(/). Domain names must be converted to upper case when used as realm names.
-
-X.500 names contain an equal (=) and cannot contain a colon (:) before the
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-equal. The realm names for X.500 names will be string representations of the
-names with components separated by slashes. Leading and trailing slashes
-will not be included.
-
-Names that fall into the other category must begin with a prefix that
-contains no equal (=) or period (.) and the prefix must be followed by a
-colon (:) and the rest of the name. All prefixes must be assigned before
-they may be used. Presently none are assigned.
-
-The reserved category includes strings which do not fall into the first
-three categories. All names in this category are reserved. It is unlikely
-that names will be assigned to this category unless there is a very strong
-argument for not using the 'other' category.
-
-These rules guarantee that there will be no conflicts between the various
-name styles. The following additional constraints apply to the assignment of
-realm names in the domain and X.500 categories: the name of a realm for the
-domain or X.500 formats must either be used by the organization owning (to
-whom it was assigned) an Internet domain name or X.500 name, or in the case
-that no such names are registered, authority to use a realm name may be
-derived from the authority of the parent realm. For example, if there is no
-domain name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can
-authorize the creation of a realm with that name.
-
-This is acceptable because the organization to which the parent is assigned
-is presumably the organization authorized to assign names to its children in
-the X.500 and domain name systems as well. If the parent assigns a realm
-name without also registering it in the domain name or X.500 hierarchy, it
-is the parent's responsibility to make sure that there will not in the
-future exists a name identical to the realm name of the child unless it is
-assigned to the same entity as the realm name.
-
-7.2. Principal Names
-
-As was the case for realm names, conventions are needed to ensure that all
-agree on what information is implied by a principal name. The name-type
-field that is part of the principal name indicates the kind of information
-implied by the name. 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). The following name types are
-defined:
-
- name-type value meaning
-
- NT-UNKNOWN 0 Name type not known
- NT-PRINCIPAL 1 General principal name (e.g. username, or DCE principal)
- NT-SRV-INST 2 Service and other unique instance (krbtgt)
- NT-SRV-HST 3 Service with host name as instance (telnet, rcommands)
- NT-SRV-XHST 4 Service with slash-separated host name components
- NT-UID 5 Unique ID
- NT-X500-PRINCIPAL 6 Encoded X.509 Distingished name [RFC 1779]
-
-When a name implies no information other than its uniqueness at a particular
-time the name type PRINCIPAL should be used. The principal name type should
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-be used for users, and it might also be used for a unique server. If the
-name is a unique machine generated ID that is guaranteed never to be
-reassigned then the name type of UID should be used (note that it is
-generally a bad idea to reassign names of any type since stale entries might
-remain in access control lists).
-
-If the first component of a name identifies a service and the remaining
-components identify an instance of the service in a server specified manner,
-then the name type of SRV-INST should be used. An example of this name type
-is the Kerberos ticket-granting service whose name has a first component of
-krbtgt and a second component identifying the realm for which the ticket is
-valid.
-
-If instance is a single component following the service name and the
-instance identifies the host on which the server is running, then the name
-type SRV-HST should be used. This type is typically used for Internet
-services such as telnet and the Berkeley R commands. If the separate
-components of the host name appear as successive components following the
-name of the service, then the name type SRV-XHST should be used. This type
-might be used to identify servers on hosts with X.500 names where the slash
-(/) might otherwise be ambiguous.
-
-A name type of NT-X500-PRINCIPAL should be used when a name from an X.509
-certificiate is translated into a Kerberos name. The encoding of the X.509
-name as a Kerberos principal shall conform to the encoding rules specified
-in RFC 1779.
-
-A name type of UNKNOWN should be used when the form of the name is not
-known. When comparing names, a name of type UNKNOWN will match principals
-authenticated with names of any type. A principal authenticated with a name
-of type UNKNOWN, however, will only match other names of type UNKNOWN.
-
-Names of any type with an initial component of 'krbtgt' are reserved for the
-Kerberos ticket granting service. See section 8.2.3 for the form of such
-names.
-
-7.2.1. Name of server principals
-
-The principal identifier for a server on a host will generally be composed
-of two parts: (1) the realm of the KDC with which the server is registered,
-and (2) a two-component name of type NT-SRV-HST if the host name is an
-Internet domain name or a multi-component name of type NT-SRV-XHST if the
-name of the host is of a form such as X.500 that allows slash (/)
-separators. The first component of the two- or multi-component name will
-identify the service and the latter components will identify the host. Where
-the name of the host is not case sensitive (for example, with Internet
-domain names) the name of the host must be lower case. If specified by the
-application protocol for services such as telnet and the Berkeley R commands
-which run with system privileges, the first component may be the string
-'host' instead of a service specific identifier. When a host has an official
-name and one or more aliases, the official name of the host must be used
-when constructing the name of the server principal.
-
-8. Constants and other defined values
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
-8.1. Host address types
-
-All negative values for the host address type are reserved for local use.
-All non-negative values are reserved for officially assigned type fields and
-interpretations.
-
-The values of the types for the following addresses are chosen to match the
-defined address family constants in the Berkeley Standard Distributions of
-Unix. They can be found in with symbolic names AF_xxx (where xxx is an
-abbreviation of the address family name).
-
-Internet (IPv4) Addresses
-
-Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in MSB
-order. The type of IPv4 addresses is two (2).
-
-Internet (IPv6) Addresses
-
-IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. The
-type of IPv6 addresses is twenty-four (24). [RFC1883] [RFC1884]. The
-following addresses (see [RFC1884]) MUST not appear in any Kerberos packet:
-
- * the Unspecified Address
- * the Loopback Address
- * Link-Local addresses
-
-IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2.
-
-CHAOSnet addresses
-
-CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB order.
-The type of CHAOSnet addresses is five (5).
-
-ISO addresses
-
-ISO addresses are variable-length. The type of ISO addresses is seven (7).
-
-Xerox Network Services (XNS) addresses
-
-XNS addresses are 48-bit (6-octet) quantities, encoded in MSB order. The
-type of XNS addresses is six (6).
-
-AppleTalk Datagram Delivery Protocol (DDP) addresses
-
-AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit network
-number. The first octet of the address is the node number; the remaining two
-octets encode the network number in MSB order. The type of AppleTalk DDP
-addresses is sixteen (16).
-
-DECnet Phase IV addresses
-
-DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. The
-type of DECnet Phase IV addresses is twelve (12).
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
-8.2. KDC messages
-
-8.2.1. UDP/IP transport
-
-When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request using UDP
-IP transport, the client shall send a UDP datagram containing only an
-encoding of the request to port 88 (decimal) at the KDC's IP address; the
-KDC will respond with a reply datagram containing only an encoding of the
-reply message (either a KRB_ERROR or a KRB_KDC_REP) to the sending port at
-the sender's IP address. Kerberos servers supporting IP transport must
-accept UDP requests on port 88 (decimal). The response to a request made
-through UDP/IP transport must also use UDP/IP transport.
-
-8.2.2. TCP/IP transport
-
-Kerberos servers (KDC's) must accept TCP requests on port 88 (decimal). When
-the KRB_KDC_REQ message is sent to the KDC over a TCP stream, a new
-connection will be established for each authentication exchange (request and
-response). The KRB_KDC_REP or KRB_ERROR message will be returned to the
-client on the same TCP stream that was established for the request. The
-connection will be broken after the reply has been received (or upon
-time-out). Care must be taken in managing TCP/IP connections with the KDC to
-prevent denial of service attacks based on the number of TCP/IP connections
-with the KDC that remain open. If multiple exchanges with the KDC are needed
-for certain forms of preauthentication, multiple TCP connections will be
-required. The response to a request made through TCP/IP transport must also
-use TCP/IP transport.
-
-The first four octets of the TCP stream used to transmit the request request
-will encode in network byte order the length of the request (KRB_KDC_REQ),
-and the length will be followed by the request itself. The response will
-similarly be preceeded by a 4 octet encoding in network byte order of the
-length of the KRB_KDC_REP or the KRB_ERROR message and will be followed by
-the KRB_KDC_REP or the KRB_ERROR response.
-
-8.2.3. OSI transport
-
-During authentication of an OSI client to an OSI server, the mutual
-authentication of an OSI server to an OSI client, the transfer of
-credentials from an OSI client to an OSI server, or during exchange of
-private or integrity checked messages, Kerberos protocol messages may be
-treated as opaque objects and the type of the authentication mechanism will
-be:
-
-OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), security(5),kerberosv5(2)}
-
-Depending on the situation, the opaque object will be an authentication
-header (KRB_AP_REQ), an authentication reply (KRB_AP_REP), a safe message
-(KRB_SAFE), a private message (KRB_PRIV), or a credentials message
-(KRB_CRED). The opaque data contains an application code as specified in the
-ASN.1 description for each message. The application code may be used by
-Kerberos to determine the message type.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-8.2.3. Name of the TGS
-
-The principal identifier of the ticket-granting service shall be composed of
-three parts: (1) the realm of the KDC issuing the TGS ticket (2) a two-part
-name of type NT-SRV-INST, with the first part "krbtgt" and the second part
-the name of the realm which will accept the ticket-granting ticket. For
-example, a ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be
-used to get tickets from the ATHENA.MIT.EDU KDC has a principal identifier
-of "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A
-ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be used to get
-tickets from the MIT.EDU realm has a principal identifier of
-"ATHENA.MIT.EDU" (realm), ("krbtgt", "MIT.EDU") (name).
-
-8.3. Protocol constants and associated values
-
-The following tables list constants used in the protocol and defines their
-meanings.
-
-Encryption type etype value block size minimum pad size confounder size
-NULL 0 1 0 0
-des-cbc-crc 1 8 4 8
-des-cbc-md4 2 8 0 8
-des-cbc-md5 3 8 0 8
- 4
-des3-cbc-md5 5 8 0 8
- 6
-des3-cbc-sha1 7 8 0 8
-sign-dsa-generate 8 (pkinit)
-encrypt-rsa-priv 9 (pkinit)
-encrypt-rsa-pub 10 (pkinit)
-rsa-pub-md5 11 (pkinit)
-rsa-pub-sha1 12 (pkinit)
-ENCTYPE_PK_CROSS 48 (reserved for pkcross)
- 0x8003
-
-Checksum type sumtype value checksum size
-CRC32 1 4
-rsa-md4 2 16
-rsa-md4-des 3 24
-des-mac 4 16
-des-mac-k 5 8
-rsa-md4-des-k 6 16
-rsa-md5 7 16
-rsa-md5-des 8 24
-rsa-md5-des3 9 24
-hmac-sha1-des3 10 20 (I had this as 10, is it 12)
-
-padata type padata-type value
-
-PA-TGS-REQ 1
-PA-ENC-TIMESTAMP 2
-PA-PW-SALT 3
- 4
-PA-ENC-UNIX-TIME 5
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-PA-SANDIA-SECUREID 6
-PA-SESAME 7
-PA-OSF-DCE 8
-PA-CYBERSAFE-SECUREID 9
-PA-AFS3-SALT 10
-PA-ETYPE-INFO 11
-SAM-CHALLENGE 12 (sam/otp)
-SAM-RESPONSE 13 (sam/otp)
-PA-PK-AS-REQ 14 (pkinit)
-PA-PK-AS-REP 15 (pkinit)
-PA-PK-AS-SIGN 16 (pkinit)
-PA-PK-KEY-REQ 17 (pkinit)
-PA-PK-KEY-REP 18 (pkinit)
-PA-USE-SPECIFIED-KVNO 20
-
-authorization data type ad-type value
-AD-KDC-ISSUED 1
-AD-INTENDED-FOR-SERVER 2
-AD-INTENDED-FOR-APPLICATION-CLASS 3
-AD-IF-RELEVANT 4
-AD-OR 5
-AD-MANDATORY-TICKET-EXTENSIONS 6
-AD-IN-TICKET-EXTENSIONS 7
-reserved values 8-63
-OSF-DCE 64
-SESAME 65
-
-Ticket Extension Types
-
-TE-TYPE-NULL 0 Null ticket extension
-TE-TYPE-EXTERNAL-ADATA 1 Integrity protected authorization data
- 2 TE-TYPE-PKCROSS-KDC (I have reservations)
-TE-TYPE-PKCROSS-CLIENT 3 PKCROSS cross realm key ticket
-TE-TYPE-CYBERSAFE-EXT 4 Assigned to CyberSafe Corp
- 5 TE-TYPE-DEST-HOST (I have reservations)
-
-alternate authentication type method-type value
-reserved values 0-63
-ATT-CHALLENGE-RESPONSE 64
-
-transited encoding type tr-type value
-DOMAIN-X500-COMPRESS 1
-reserved values all others
-
-Label Value Meaning or MIT code
-
-pvno 5 current Kerberos protocol version number
-
-message types
-
-KRB_AS_REQ 10 Request for initial authentication
-KRB_AS_REP 11 Response to KRB_AS_REQ request
-KRB_TGS_REQ 12 Request for authentication based on TGT
-KRB_TGS_REP 13 Response to KRB_TGS_REQ request
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-KRB_AP_REQ 14 application request to server
-KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL
-KRB_SAFE 20 Safe (checksummed) application message
-KRB_PRIV 21 Private (encrypted) application message
-KRB_CRED 22 Private (encrypted) message to forward credentials
-KRB_ERROR 30 Error response
-
-name types
-
-KRB_NT_UNKNOWN 0 Name type not known
-KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users
-KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt)
-KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands)
-KRB_NT_SRV_XHST 4 Service with host as remaining components
-KRB_NT_UID 5 Unique ID
-KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distingished name [RFC 1779]
-
-error codes
-
-KDC_ERR_NONE 0 No error
-KDC_ERR_NAME_EXP 1 Client's entry in database has expired
-KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired
-KDC_ERR_BAD_PVNO 3 Requested protocol version number not
- supported
-KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key
-KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key
-KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database
-KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database
-KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database
-KDC_ERR_NULL_KEY 9 The client or server has a null key
-KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating
-KDC_ERR_NEVER_VALID 11 Requested start time is later than end time
-KDC_ERR_POLICY 12 KDC policy rejects request
-KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option
-KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type
-KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type
-KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type
-KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type
-KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked
-KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked
-KDC_ERR_TGT_REVOKED 20 TGT has been revoked
-KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later
-KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later
-KDC_ERR_KEY_EXPIRED 23 Password has expired - change password
- to reset
-KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid
-KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authenticationrequired [40]
-KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match
-KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user only
-KDC_ERR_PATH_NOT_ACCPETED 28 KDC Policy rejects transited path
-KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed
-KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired
-KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid
-KRB_AP_ERR_REPEAT 34 Request is a replay
-KRB_AP_ERR_NOT_US 35 The ticket isn't for us
-KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-KRB_AP_ERR_SKEW 37 Clock skew too great
-KRB_AP_ERR_BADADDR 38 Incorrect net address
-KRB_AP_ERR_BADVERSION 39 Protocol version mismatch
-KRB_AP_ERR_MSG_TYPE 40 Invalid msg type
-KRB_AP_ERR_MODIFIED 41 Message stream modified
-KRB_AP_ERR_BADORDER 42 Message out of order
-KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available
-KRB_AP_ERR_NOKEY 45 Service key not available
-KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed
-KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction
-KRB_AP_ERR_METHOD 48 Alternative authentication method required
-KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message
-KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message
-KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path
-KRB_ERR_GENERIC 60 Generic error (description in e-text)
-KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation
-KDC_ERROR_CLIENT_NOT_TRUSTED 62 (pkinit)
-KDC_ERROR_KDC_NOT_TRUSTED 63 (pkinit)
-KDC_ERROR_INVALID_SIG 64 (pkinit)
-KDC_ERR_KEY_TOO_WEAK 65 (pkinit)
-KDC_ERR_CERTIFICATE_MISMATCH 66 (pkinit)
-
-9. Interoperability requirements
-
-Version 5 of the Kerberos protocol supports a myriad of options. Among these
-are multiple encryption and checksum types, alternative encoding schemes for
-the transited field, optional mechanisms for pre-authentication, the
-handling of tickets with no addresses, options for mutual authentication,
-user to user authentication, support for proxies, forwarding, postdating,
-and renewing tickets, the format of realm names, and the handling of
-authorization data.
-
-In order to ensure the interoperability of realms, it is necessary to define
-a minimal configuration which must be supported by all implementations. This
-minimal configuration is subject to change as technology does. For example,
-if at some later date it is discovered that one of the required encryption
-or checksum algorithms is not secure, it will be replaced.
-
-9.1. Specification 2
-
-This section defines the second specification of these options.
-Implementations which are configured in this way can be said to support
-Kerberos Version 5 Specification 2 (5.1). Specification 1 (depricated) may
-be found in RFC1510.
-
-Transport
-
-TCP/IP and UDP/IP transport must be supported by KDCs claiming conformance
-to specification 2. Kerberos clients claiming conformance to specification 2
-must support UDP/IP transport for messages with the KDC and may support
-TCP/IP transport.
-
-Encryption and checksum methods
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-The following encryption and checksum mechanisms must be supported.
-Implementations may support other mechanisms as well, but the additional
-mechanisms may only be used when communicating with principals known to also
-support them: This list is to be determined.
-
-Encryption: DES-CBC-MD5
-Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5
-
-Realm Names
-
-All implementations must understand hierarchical realms in both the Internet
-Domain and the X.500 style. When a ticket granting ticket for an unknown
-realm is requested, the KDC must be able to determine the names of the
-intermediate realms between the KDCs realm and the requested realm.
-
-Transited field encoding
-
-DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported.
-Alternative encodings may be supported, but they may be used only when that
-encoding is supported by ALL intermediate realms.
-
-Pre-authentication methods
-
-The TGS-REQ method must be supported. The TGS-REQ method is not used on the
-initial request. The PA-ENC-TIMESTAMP method must be supported by clients
-but whether it is enabled by default may be determined on a realm by realm
-basis. If not used in the initial request and the error
-KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an
-acceptable method, the client should retry the initial request using the
-PA-ENC-TIMESTAMP preauthentication method. Servers need not support the
-PA-ENC-TIMESTAMP method, but if not supported the server should ignore the
-presence of PA-ENC-TIMESTAMP pre-authentication in a request.
-
-Mutual authentication
-
-Mutual authentication (via the KRB_AP_REP message) must be supported.
-
-Ticket addresses and flags
-
-All KDC's must pass on tickets that carry no addresses (i.e. if a TGT
-contains no addresses, the KDC will return derivative tickets), but each
-realm may set its own policy for issuing such tickets, and each application
-server will set its own policy with respect to accepting them.
-
-Proxies and forwarded tickets must be supported. Individual realms and
-application servers can set their own policy on when such tickets will be
-accepted.
-
-All implementations must recognize renewable and postdated tickets, but need
-not actually implement them. If these options are not supported, the
-starttime and endtime in the ticket shall specify a ticket's entire useful
-life. When a postdated ticket is decoded by a server, all implementations
-shall make the presence of the postdated flag visible to the calling server.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-User-to-user authentication
-
-Support for user to user authentication (via the ENC-TKT-IN-SKEY KDC option)
-must be provided by implementations, but individual realms may decide as a
-matter of policy to reject such requests on a per-principal or realm-wide
-basis.
-
-Authorization data
-
-Implementations must pass all authorization data subfields from
-ticket-granting tickets to any derivative tickets unless directed to
-suppress a subfield as part of the definition of that registered subfield
-type (it is never incorrect to pass on a subfield, and no registered
-subfield types presently specify suppression at the KDC).
-
-Implementations must make the contents of any authorization data subfields
-available to the server when a ticket is used. Implementations are not
-required to allow clients to specify the contents of the authorization data
-fields.
-
-9.2. Recommended KDC values
-
-Following is a list of recommended values for a KDC implementation, based on
-the list of suggested configuration constants (see section 4.4).
-
-minimum lifetime 5 minutes
-maximum renewable lifetime 1 week
-maximum ticket lifetime 1 day
-empty addresses only when suitable restrictions appear
- in authorization data
-proxiable, etc. Allowed.
-
-10. REFERENCES
-
-[NT94] B. Clifford Neuman and Theodore Y. Ts'o, "An Authenti-
- cation Service for Computer Networks," IEEE Communica-
- tions Magazine, Vol. 32(9), pp. 33-38 (September 1994).
-
-[MNSS87] S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H.
- Saltzer, Section E.2.1: Kerberos Authentication and
- Authorization System, M.I.T. Project Athena, Cambridge,
- Massachusetts (December 21, 1987).
-
-[SNS88] J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Ker-
- beros: An Authentication Service for Open Network Sys-
- tems," pp. 191-202 in Usenix Conference Proceedings,
- Dallas, Texas (February, 1988).
-
-[NS78] Roger M. Needham and Michael D. Schroeder, "Using
- Encryption for Authentication in Large Networks of Com-
- puters," Communications of the ACM, Vol. 21(12),
- pp. 993-999 (December, 1978).
-
-[DS81] Dorothy E. Denning and Giovanni Maria Sacco, "Time-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- stamps in Key Distribution Protocols," Communications
- of the ACM, Vol. 24(8), pp. 533-536 (August 1981).
-
-[KNT92] John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o,
- "The Evolution of the Kerberos Authentication Service,"
- in an IEEE Computer Society Text soon to be published
- (June 1992).
-
-[Neu93] B. Clifford Neuman, "Proxy-Based Authorization and
- Accounting for Distributed Systems," in Proceedings of
- the 13th International Conference on Distributed Com-
- puting Systems, Pittsburgh, PA (May, 1993).
-
-[DS90] Don Davis and Ralph Swick, "Workstation Services and
- Kerberos Authentication at Project Athena," Technical
- Memorandum TM-424, MIT Laboratory for Computer Science
- (February 1990).
-
-[LGDSR87] P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E. Som-
- merfeld, and K. Raeburn, Section E.1: Service Manage-
- ment System, M.I.T. Project Athena, Cambridge, Mas-
- sachusetts (1987).
-
-[X509-88] CCITT, Recommendation X.509: The Directory Authentica-
- tion Framework, December 1988.
-
-[Pat92]. J. Pato, Using Pre-Authentication to Avoid Password
- Guessing Attacks, Open Software Foundation DCE Request
- for Comments 26 (December 1992).
-
-[DES77] National Bureau of Standards, U.S. Department of Com-
- merce, "Data Encryption Standard," Federal Information
- Processing Standards Publication 46, Washington, DC
- (1977).
-
-[DESM80] National Bureau of Standards, U.S. Department of Com-
- merce, "DES Modes of Operation," Federal Information
- Processing Standards Publication 81, Springfield, VA
- (December 1980).
-
-[SG92] Stuart G. Stubblebine and Virgil D. Gligor, "On Message
- Integrity in Cryptographic Protocols," in Proceedings
- of the IEEE Symposium on Research in Security and
- Privacy, Oakland, California (May 1992).
-
-[IS3309] International Organization for Standardization, "ISO
- Information Processing Systems - Data Communication -
- High-Level Data Link Control Procedure - Frame Struc-
- ture," IS 3309 (October 1984). 3rd Edition.
-
-[MD4-92] R. Rivest, "The MD4 Message Digest Algorithm," RFC
- 1320, MIT Laboratory for Computer Science (April
- 1992).
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-[MD5-92] R. Rivest, "The MD5 Message Digest Algorithm," RFC
- 1321, MIT Laboratory for Computer Science (April
- 1992).
-
-[KBC96] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed-
- Hashing for Message Authentication," Working Draft
- draft-ietf-ipsec-hmac-md5-01.txt, (August 1996).
-
-A. Pseudo-code for protocol processing
-
-This appendix provides pseudo-code describing how the messages are to be
-constructed and interpreted by clients and servers.
-
-A.1. KRB_AS_REQ generation
-
- request.pvno := protocol version; /* pvno = 5 */
- request.msg-type := message type; /* type = KRB_AS_REQ */
-
- if(pa_enc_timestamp_required) then
- request.padata.padata-type = PA-ENC-TIMESTAMP;
- get system_time;
- padata-body.patimestamp,pausec = system_time;
- encrypt padata-body into request.padata.padata-value
- using client.key; /* derived from password */
- endif
-
- body.kdc-options := users's preferences;
- body.cname := user's name;
- body.realm := user's realm;
- body.sname := service's name; /* usually "krbtgt", "localrealm" */
- if (body.kdc-options.POSTDATED is set) then
- body.from := requested starting time;
- else
- omit body.from;
- endif
- body.till := requested end time;
- if (body.kdc-options.RENEWABLE is set) then
- body.rtime := requested final renewal time;
- endif
- body.nonce := random_nonce();
- body.etype := requested etypes;
- if (user supplied addresses) then
- body.addresses := user's addresses;
- else
- omit body.addresses;
- endif
- omit body.enc-authorization-data;
- request.req-body := body;
-
- kerberos := lookup(name of local kerberos server (or servers));
- send(packet,kerberos);
-
- wait(for response);
- if (timed_out) then
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- retry or use alternate server;
- endif
-
-A.2. KRB_AS_REQ verification and KRB_AS_REP generation
-
- decode message into req;
-
- client := lookup(req.cname,req.realm);
- server := lookup(req.sname,req.realm);
-
- get system_time;
- kdc_time := system_time.seconds;
-
- if (!client) then
- /* no client in Database */
- error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN);
- endif
- if (!server) then
- /* no server in Database */
- error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
- endif
-
- if(client.pa_enc_timestamp_required and
- pa_enc_timestamp not present) then
- error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP));
- endif
-
- if(pa_enc_timestamp present) then
- decrypt req.padata-value into decrypted_enc_timestamp
- using client.key;
- using auth_hdr.authenticator.subkey;
- if (decrypt_error()) then
- error_out(KRB_AP_ERR_BAD_INTEGRITY);
- if(decrypted_enc_timestamp is not within allowable skew) then
- error_out(KDC_ERR_PREAUTH_FAILED);
- endif
- if(decrypted_enc_timestamp and usec is replay)
- error_out(KDC_ERR_PREAUTH_FAILED);
- endif
- add decrypted_enc_timestamp and usec to replay cache;
- endif
-
- use_etype := first supported etype in req.etypes;
-
- if (no support for req.etypes) then
- error_out(KDC_ERR_ETYPE_NOSUPP);
- endif
-
- new_tkt.vno := ticket version; /* = 5 */
- new_tkt.sname := req.sname;
- new_tkt.srealm := req.srealm;
- reset all flags in new_tkt.flags;
-
- /* It should be noted that local policy may affect the */
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- /* processing of any of these flags. For example, some */
- /* realms may refuse to issue renewable tickets */
-
- if (req.kdc-options.FORWARDABLE is set) then
- set new_tkt.flags.FORWARDABLE;
- endif
- if (req.kdc-options.PROXIABLE is set) then
- set new_tkt.flags.PROXIABLE;
- endif
-
- if (req.kdc-options.ALLOW-POSTDATE is set) then
- set new_tkt.flags.MAY-POSTDATE;
- endif
- if ((req.kdc-options.RENEW is set) or
- (req.kdc-options.VALIDATE is set) or
- (req.kdc-options.PROXY is set) or
- (req.kdc-options.FORWARDED is set) or
- (req.kdc-options.ENC-TKT-IN-SKEY is set)) then
- error_out(KDC_ERR_BADOPTION);
- endif
-
- new_tkt.session := random_session_key();
- new_tkt.cname := req.cname;
- new_tkt.crealm := req.crealm;
- new_tkt.transited := empty_transited_field();
-
- new_tkt.authtime := kdc_time;
-
- if (req.kdc-options.POSTDATED is set) then
- if (against_postdate_policy(req.from)) then
- error_out(KDC_ERR_POLICY);
- endif
- set new_tkt.flags.POSTDATED;
- set new_tkt.flags.INVALID;
- new_tkt.starttime := req.from;
- else
- omit new_tkt.starttime; /* treated as authtime when omitted */
- endif
- if (req.till = 0) then
- till := infinity;
- else
- till := req.till;
- endif
-
- new_tkt.endtime := min(till,
- new_tkt.starttime+client.max_life,
- new_tkt.starttime+server.max_life,
- new_tkt.starttime+max_life_for_realm);
-
- if ((req.kdc-options.RENEWABLE-OK is set) and
- (new_tkt.endtime < req.till)) then
- /* we set the RENEWABLE option for later processing */
- set req.kdc-options.RENEWABLE;
- req.rtime := req.till;
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- endif
-
- if (req.rtime = 0) then
- rtime := infinity;
- else
- rtime := req.rtime;
- endif
-
- if (req.kdc-options.RENEWABLE is set) then
- set new_tkt.flags.RENEWABLE;
- new_tkt.renew-till := min(rtime,
- new_tkt.starttime+client.max_rlife,
- new_tkt.starttime+server.max_rlife,
- new_tkt.starttime+max_rlife_for_realm);
- else
- omit new_tkt.renew-till; /* only present if RENEWABLE */
- endif
-
- if (req.addresses) then
- new_tkt.caddr := req.addresses;
- else
- omit new_tkt.caddr;
- endif
-
- new_tkt.authorization_data := empty_authorization_data();
-
- encode to-be-encrypted part of ticket into OCTET STRING;
- new_tkt.enc-part := encrypt OCTET STRING
- using etype_for_key(server.key), server.key, server.p_kvno;
-
- /* Start processing the response */
-
- resp.pvno := 5;
- resp.msg-type := KRB_AS_REP;
- resp.cname := req.cname;
- resp.crealm := req.realm;
- resp.ticket := new_tkt;
-
- resp.key := new_tkt.session;
- resp.last-req := fetch_last_request_info(client);
- resp.nonce := req.nonce;
- resp.key-expiration := client.expiration;
- resp.flags := new_tkt.flags;
-
- resp.authtime := new_tkt.authtime;
- resp.starttime := new_tkt.starttime;
- resp.endtime := new_tkt.endtime;
-
- if (new_tkt.flags.RENEWABLE) then
- resp.renew-till := new_tkt.renew-till;
- endif
-
- resp.realm := new_tkt.realm;
- resp.sname := new_tkt.sname;
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
- resp.caddr := new_tkt.caddr;
-
- encode body of reply into OCTET STRING;
-
- resp.enc-part := encrypt OCTET STRING
- using use_etype, client.key, client.p_kvno;
- send(resp);
-
-A.3. KRB_AS_REP verification
-
- decode response into resp;
-
- if (resp.msg-type = KRB_ERROR) then
- if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) then
- set pa_enc_timestamp_required;
- goto KRB_AS_REQ;
- endif
- process_error(resp);
- return;
- endif
-
- /* On error, discard the response, and zero the session key */
- /* from the response immediately */
-
- key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype,
- resp.padata);
- unencrypted part of resp := decode of decrypt of resp.enc-part
- using resp.enc-part.etype and key;
- zero(key);
-
- if (common_as_rep_tgs_rep_checks fail) then
- destroy resp.key;
- return error;
- endif
-
- if near(resp.princ_exp) then
- print(warning message);
- endif
- save_for_later(ticket,session,client,server,times,flags);
-
-A.4. KRB_AS_REP and KRB_TGS_REP common checks
-
- if (decryption_error() or
- (req.cname != resp.cname) or
- (req.realm != resp.crealm) or
- (req.sname != resp.sname) or
- (req.realm != resp.realm) or
- (req.nonce != resp.nonce) or
- (req.addresses != resp.caddr)) then
- destroy resp.key;
- return KRB_AP_ERR_MODIFIED;
- endif
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- /* make sure no flags are set that shouldn't be, and that all that */
- /* should be are set */
- if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then
- destroy resp.key;
- return KRB_AP_ERR_MODIFIED;
- endif
-
- if ((req.from = 0) and
- (resp.starttime is not within allowable skew)) then
- destroy resp.key;
- return KRB_AP_ERR_SKEW;
- endif
- if ((req.from != 0) and (req.from != resp.starttime)) then
- destroy resp.key;
- return KRB_AP_ERR_MODIFIED;
- endif
- if ((req.till != 0) and (resp.endtime > req.till)) then
- destroy resp.key;
- return KRB_AP_ERR_MODIFIED;
- endif
-
- if ((req.kdc-options.RENEWABLE is set) and
- (req.rtime != 0) and (resp.renew-till > req.rtime)) then
- destroy resp.key;
- return KRB_AP_ERR_MODIFIED;
- endif
- if ((req.kdc-options.RENEWABLE-OK is set) and
- (resp.flags.RENEWABLE) and
- (req.till != 0) and
- (resp.renew-till > req.till)) then
- destroy resp.key;
- return KRB_AP_ERR_MODIFIED;
- endif
-
-A.5. KRB_TGS_REQ generation
-
- /* Note that make_application_request might have to recursivly */
- /* call this routine to get the appropriate ticket-granting ticket */
-
- request.pvno := protocol version; /* pvno = 5 */
- request.msg-type := message type; /* type = KRB_TGS_REQ */
-
- body.kdc-options := users's preferences;
- /* If the TGT is not for the realm of the end-server */
- /* then the sname will be for a TGT for the end-realm */
- /* and the realm of the requested ticket (body.realm) */
- /* will be that of the TGS to which the TGT we are */
- /* sending applies */
- body.sname := service's name;
- body.realm := service's realm;
-
- if (body.kdc-options.POSTDATED is set) then
- body.from := requested starting time;
- else
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- omit body.from;
- endif
- body.till := requested end time;
- if (body.kdc-options.RENEWABLE is set) then
- body.rtime := requested final renewal time;
- endif
- body.nonce := random_nonce();
- body.etype := requested etypes;
- if (user supplied addresses) then
- body.addresses := user's addresses;
- else
- omit body.addresses;
- endif
-
- body.enc-authorization-data := user-supplied data;
- if (body.kdc-options.ENC-TKT-IN-SKEY) then
- body.additional-tickets_ticket := second TGT;
- endif
-
- request.req-body := body;
- check := generate_checksum (req.body,checksumtype);
-
- request.padata[0].padata-type := PA-TGS-REQ;
- request.padata[0].padata-value := create a KRB_AP_REQ using
- the TGT and checksum
-
- /* add in any other padata as required/supplied */
-
- kerberos := lookup(name of local kerberose server (or servers));
- send(packet,kerberos);
-
- wait(for response);
- if (timed_out) then
- retry or use alternate server;
- endif
-
-A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation
-
- /* note that reading the application request requires first
- determining the server for which a ticket was issued, and choosing the
- correct key for decryption. The name of the server appears in the
- plaintext part of the ticket. */
-
- if (no KRB_AP_REQ in req.padata) then
- error_out(KDC_ERR_PADATA_TYPE_NOSUPP);
- endif
- verify KRB_AP_REQ in req.padata;
-
- /* Note that the realm in which the Kerberos server is operating is
- determined by the instance from the ticket-granting ticket. The realm
- in the ticket-granting ticket is the realm under which the ticket
- granting ticket was issued. It is possible for a single Kerberos
- server to support more than one realm. */
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- auth_hdr := KRB_AP_REQ;
- tgt := auth_hdr.ticket;
-
- if (tgt.sname is not a TGT for local realm and is not req.sname) then
- error_out(KRB_AP_ERR_NOT_US);
-
- realm := realm_tgt_is_for(tgt);
-
- decode remainder of request;
-
- if (auth_hdr.authenticator.cksum is missing) then
- error_out(KRB_AP_ERR_INAPP_CKSUM);
- endif
-
- if (auth_hdr.authenticator.cksum type is not supported) then
- error_out(KDC_ERR_SUMTYPE_NOSUPP);
- endif
- if (auth_hdr.authenticator.cksum is not both collision-proof and keyed) then
- error_out(KRB_AP_ERR_INAPP_CKSUM);
- endif
-
- set computed_checksum := checksum(req);
- if (computed_checksum != auth_hdr.authenticatory.cksum) then
- error_out(KRB_AP_ERR_MODIFIED);
- endif
-
- server := lookup(req.sname,realm);
-
- if (!server) then
- if (is_foreign_tgt_name(req.sname)) then
- server := best_intermediate_tgs(req.sname);
- else
- /* no server in Database */
- error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
- endif
- endif
-
- session := generate_random_session_key();
-
- use_etype := first supported etype in req.etypes;
-
- if (no support for req.etypes) then
- error_out(KDC_ERR_ETYPE_NOSUPP);
- endif
-
- new_tkt.vno := ticket version; /* = 5 */
- new_tkt.sname := req.sname;
- new_tkt.srealm := realm;
- reset all flags in new_tkt.flags;
-
- /* It should be noted that local policy may affect the */
- /* processing of any of these flags. For example, some */
- /* realms may refuse to issue renewable tickets */
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- new_tkt.caddr := tgt.caddr;
- resp.caddr := NULL; /* We only include this if they change */
- if (req.kdc-options.FORWARDABLE is set) then
- if (tgt.flags.FORWARDABLE is reset) then
- error_out(KDC_ERR_BADOPTION);
- endif
- set new_tkt.flags.FORWARDABLE;
- endif
- if (req.kdc-options.FORWARDED is set) then
- if (tgt.flags.FORWARDABLE is reset) then
- error_out(KDC_ERR_BADOPTION);
- endif
- set new_tkt.flags.FORWARDED;
- new_tkt.caddr := req.addresses;
- resp.caddr := req.addresses;
- endif
- if (tgt.flags.FORWARDED is set) then
- set new_tkt.flags.FORWARDED;
- endif
-
- if (req.kdc-options.PROXIABLE is set) then
- if (tgt.flags.PROXIABLE is reset)
- error_out(KDC_ERR_BADOPTION);
- endif
- set new_tkt.flags.PROXIABLE;
- endif
- if (req.kdc-options.PROXY is set) then
- if (tgt.flags.PROXIABLE is reset) then
- error_out(KDC_ERR_BADOPTION);
- endif
- set new_tkt.flags.PROXY;
- new_tkt.caddr := req.addresses;
- resp.caddr := req.addresses;
- endif
-
- if (req.kdc-options.ALLOW-POSTDATE is set) then
- if (tgt.flags.MAY-POSTDATE is reset)
- error_out(KDC_ERR_BADOPTION);
- endif
- set new_tkt.flags.MAY-POSTDATE;
- endif
- if (req.kdc-options.POSTDATED is set) then
- if (tgt.flags.MAY-POSTDATE is reset) then
- error_out(KDC_ERR_BADOPTION);
- endif
- set new_tkt.flags.POSTDATED;
- set new_tkt.flags.INVALID;
- if (against_postdate_policy(req.from)) then
- error_out(KDC_ERR_POLICY);
- endif
- new_tkt.starttime := req.from;
- endif
-
- if (req.kdc-options.VALIDATE is set) then
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- if (tgt.flags.INVALID is reset) then
- error_out(KDC_ERR_POLICY);
- endif
- if (tgt.starttime > kdc_time) then
- error_out(KRB_AP_ERR_NYV);
- endif
- if (check_hot_list(tgt)) then
- error_out(KRB_AP_ERR_REPEAT);
- endif
- tkt := tgt;
- reset new_tkt.flags.INVALID;
- endif
-
- if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW,
- and those already processed) is set) then
- error_out(KDC_ERR_BADOPTION);
- endif
-
- new_tkt.authtime := tgt.authtime;
-
- if (req.kdc-options.RENEW is set) then
- /* Note that if the endtime has already passed, the ticket would */
- /* have been rejected in the initial authentication stage, so */
- /* there is no need to check again here */
- if (tgt.flags.RENEWABLE is reset) then
- error_out(KDC_ERR_BADOPTION);
- endif
- if (tgt.renew-till < kdc_time) then
- error_out(KRB_AP_ERR_TKT_EXPIRED);
- endif
- tkt := tgt;
- new_tkt.starttime := kdc_time;
- old_life := tgt.endttime - tgt.starttime;
- new_tkt.endtime := min(tgt.renew-till,
- new_tkt.starttime + old_life);
- else
- new_tkt.starttime := kdc_time;
- if (req.till = 0) then
- till := infinity;
- else
- till := req.till;
- endif
- new_tkt.endtime := min(till,
- new_tkt.starttime+client.max_life,
- new_tkt.starttime+server.max_life,
- new_tkt.starttime+max_life_for_realm,
- tgt.endtime);
-
- if ((req.kdc-options.RENEWABLE-OK is set) and
- (new_tkt.endtime < req.till) and
- (tgt.flags.RENEWABLE is set) then
- /* we set the RENEWABLE option for later processing */
- set req.kdc-options.RENEWABLE;
- req.rtime := min(req.till, tgt.renew-till);
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- endif
- endif
-
- if (req.rtime = 0) then
- rtime := infinity;
- else
- rtime := req.rtime;
- endif
-
- if ((req.kdc-options.RENEWABLE is set) and
- (tgt.flags.RENEWABLE is set)) then
- set new_tkt.flags.RENEWABLE;
- new_tkt.renew-till := min(rtime,
- new_tkt.starttime+client.max_rlife,
- new_tkt.starttime+server.max_rlife,
- new_tkt.starttime+max_rlife_for_realm,
- tgt.renew-till);
- else
- new_tkt.renew-till := OMIT; /* leave the renew-till field out */
- endif
- if (req.enc-authorization-data is present) then
- decrypt req.enc-authorization-data into decrypted_authorization_data
- using auth_hdr.authenticator.subkey;
- if (decrypt_error()) then
- error_out(KRB_AP_ERR_BAD_INTEGRITY);
- endif
- endif
- new_tkt.authorization_data := req.auth_hdr.ticket.authorization_data +
- decrypted_authorization_data;
-
- new_tkt.key := session;
- new_tkt.crealm := tgt.crealm;
- new_tkt.cname := req.auth_hdr.ticket.cname;
-
- if (realm_tgt_is_for(tgt) := tgt.realm) then
- /* tgt issued by local realm */
- new_tkt.transited := tgt.transited;
- else
- /* was issued for this realm by some other realm */
- if (tgt.transited.tr-type not supported) then
- error_out(KDC_ERR_TRTYPE_NOSUPP);
- endif
- new_tkt.transited := compress_transited(tgt.transited + tgt.realm)
- /* Don't check tranited field if TGT for foreign realm,
- * or requested not to check */
- if (is_not_foreign_tgt_name(new_tkt.server)
- && req.kdc-options.DISABLE-TRANSITED-CHECK not set) then
- /* Check it, so end-server does not have to
- * but don't fail, end-server may still accept it */
- if (check_transited_field(new_tkt.transited) == OK)
- set new_tkt.flags.TRANSITED-POLICY-CHECKED;
- endif
- endif
- endif
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
- encode encrypted part of new_tkt into OCTET STRING;
- if (req.kdc-options.ENC-TKT-IN-SKEY is set) then
- if (server not specified) then
- server = req.second_ticket.client;
- endif
- if ((req.second_ticket is not a TGT) or
- (req.second_ticket.client != server)) then
- error_out(KDC_ERR_POLICY);
- endif
-
- new_tkt.enc-part := encrypt OCTET STRING using
- using etype_for_key(second-ticket.key), second-ticket.key;
- else
- new_tkt.enc-part := encrypt OCTET STRING
- using etype_for_key(server.key), server.key, server.p_kvno;
- endif
-
- resp.pvno := 5;
- resp.msg-type := KRB_TGS_REP;
- resp.crealm := tgt.crealm;
- resp.cname := tgt.cname;
- resp.ticket := new_tkt;
-
- resp.key := session;
- resp.nonce := req.nonce;
- resp.last-req := fetch_last_request_info(client);
- resp.flags := new_tkt.flags;
-
- resp.authtime := new_tkt.authtime;
- resp.starttime := new_tkt.starttime;
- resp.endtime := new_tkt.endtime;
-
- omit resp.key-expiration;
-
- resp.sname := new_tkt.sname;
- resp.realm := new_tkt.realm;
-
- if (new_tkt.flags.RENEWABLE) then
- resp.renew-till := new_tkt.renew-till;
- endif
-
- encode body of reply into OCTET STRING;
-
- if (req.padata.authenticator.subkey)
- resp.enc-part := encrypt OCTET STRING using use_etype,
- req.padata.authenticator.subkey;
- else resp.enc-part := encrypt OCTET STRING using use_etype, tgt.key;
-
- send(resp);
-
-A.7. KRB_TGS_REP verification
-
- decode response into resp;
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
- if (resp.msg-type = KRB_ERROR) then
- process_error(resp);
- return;
- endif
-
- /* On error, discard the response, and zero the session key from
- the response immediately */
-
- if (req.padata.authenticator.subkey)
- unencrypted part of resp := decode of decrypt of resp.enc-part
- using resp.enc-part.etype and subkey;
- else unencrypted part of resp := decode of decrypt of resp.enc-part
- using resp.enc-part.etype and tgt's session key;
- if (common_as_rep_tgs_rep_checks fail) then
- destroy resp.key;
- return error;
- endif
-
- check authorization_data as necessary;
- save_for_later(ticket,session,client,server,times,flags);
-
-A.8. Authenticator generation
-
- body.authenticator-vno := authenticator vno; /* = 5 */
- body.cname, body.crealm := client name;
- if (supplying checksum) then
- body.cksum := checksum;
- endif
- get system_time;
- body.ctime, body.cusec := system_time;
- if (selecting sub-session key) then
- select sub-session key;
- body.subkey := sub-session key;
- endif
- if (using sequence numbers) then
- select initial sequence number;
- body.seq-number := initial sequence;
- endif
-
-A.9. KRB_AP_REQ generation
-
- obtain ticket and session_key from cache;
-
- packet.pvno := protocol version; /* 5 */
- packet.msg-type := message type; /* KRB_AP_REQ */
-
- if (desired(MUTUAL_AUTHENTICATION)) then
- set packet.ap-options.MUTUAL-REQUIRED;
- else
- reset packet.ap-options.MUTUAL-REQUIRED;
- endif
- if (using session key for ticket) then
- set packet.ap-options.USE-SESSION-KEY;
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- else
- reset packet.ap-options.USE-SESSION-KEY;
- endif
- packet.ticket := ticket; /* ticket */
- generate authenticator;
- encode authenticator into OCTET STRING;
- encrypt OCTET STRING into packet.authenticator using session_key;
-
-A.10. KRB_AP_REQ verification
-
- receive packet;
- if (packet.pvno != 5) then
- either process using other protocol spec
- or error_out(KRB_AP_ERR_BADVERSION);
- endif
- if (packet.msg-type != KRB_AP_REQ) then
- error_out(KRB_AP_ERR_MSG_TYPE);
- endif
- if (packet.ticket.tkt_vno != 5) then
- either process using other protocol spec
- or error_out(KRB_AP_ERR_BADVERSION);
- endif
- if (packet.ap_options.USE-SESSION-KEY is set) then
- retrieve session key from ticket-granting ticket for
- packet.ticket.{sname,srealm,enc-part.etype};
- else
- retrieve service key for
- packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno};
- endif
- if (no_key_available) then
- if (cannot_find_specified_skvno) then
- error_out(KRB_AP_ERR_BADKEYVER);
- else
- error_out(KRB_AP_ERR_NOKEY);
- endif
- endif
- decrypt packet.ticket.enc-part into decr_ticket using retrieved key;
- if (decryption_error()) then
- error_out(KRB_AP_ERR_BAD_INTEGRITY);
- endif
- decrypt packet.authenticator into decr_authenticator
- using decr_ticket.key;
- if (decryption_error()) then
- error_out(KRB_AP_ERR_BAD_INTEGRITY);
- endif
- if (decr_authenticator.{cname,crealm} !=
- decr_ticket.{cname,crealm}) then
- error_out(KRB_AP_ERR_BADMATCH);
- endif
- if (decr_ticket.caddr is present) then
- if (sender_address(packet) is not in decr_ticket.caddr) then
- error_out(KRB_AP_ERR_BADADDR);
- endif
- elseif (application requires addresses) then
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- error_out(KRB_AP_ERR_BADADDR);
- endif
- if (not in_clock_skew(decr_authenticator.ctime,
- decr_authenticator.cusec)) then
- error_out(KRB_AP_ERR_SKEW);
- endif
- if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then
- error_out(KRB_AP_ERR_REPEAT);
- endif
- save_identifier(decr_authenticator.{ctime,cusec,cname,crealm});
- get system_time;
- if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or
- (decr_ticket.flags.INVALID is set)) then
- /* it hasn't yet become valid */
- error_out(KRB_AP_ERR_TKT_NYV);
- endif
- if (system_time-decr_ticket.endtime > CLOCK_SKEW) then
- error_out(KRB_AP_ERR_TKT_EXPIRED);
- endif
- if (decr_ticket.transited) then
- /* caller may ignore the TRANSITED-POLICY-CHECKED and do
- * check anyway */
- if (decr_ticket.flags.TRANSITED-POLICY-CHECKED not set) then
- if (check_transited_field(decr_ticket.transited) then
- error_out(KDC_AP_PATH_NOT_ACCPETED);
- endif
- endif
- endif
- /* caller must check decr_ticket.flags for any pertinent details */
- return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED);
-
-A.11. KRB_AP_REP generation
-
- packet.pvno := protocol version; /* 5 */
- packet.msg-type := message type; /* KRB_AP_REP */
-
- body.ctime := packet.ctime;
- body.cusec := packet.cusec;
- if (selecting sub-session key) then
- select sub-session key;
- body.subkey := sub-session key;
- endif
- if (using sequence numbers) then
- select initial sequence number;
- body.seq-number := initial sequence;
- endif
-
- encode body into OCTET STRING;
-
- select encryption type;
- encrypt OCTET STRING into packet.enc-part;
-
-A.12. KRB_AP_REP verification
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- receive packet;
- if (packet.pvno != 5) then
- either process using other protocol spec
- or error_out(KRB_AP_ERR_BADVERSION);
- endif
- if (packet.msg-type != KRB_AP_REP) then
- error_out(KRB_AP_ERR_MSG_TYPE);
- endif
- cleartext := decrypt(packet.enc-part) using ticket's session key;
- if (decryption_error()) then
- error_out(KRB_AP_ERR_BAD_INTEGRITY);
- endif
- if (cleartext.ctime != authenticator.ctime) then
- error_out(KRB_AP_ERR_MUT_FAIL);
- endif
- if (cleartext.cusec != authenticator.cusec) then
- error_out(KRB_AP_ERR_MUT_FAIL);
- endif
- if (cleartext.subkey is present) then
- save cleartext.subkey for future use;
- endif
- if (cleartext.seq-number is present) then
- save cleartext.seq-number for future verifications;
- endif
- return(AUTHENTICATION_SUCCEEDED);
-
-A.13. KRB_SAFE generation
-
- collect user data in buffer;
-
- /* assemble packet: */
- packet.pvno := protocol version; /* 5 */
- packet.msg-type := message type; /* KRB_SAFE */
-
- body.user-data := buffer; /* DATA */
- if (using timestamp) then
- get system_time;
- body.timestamp, body.usec := system_time;
- endif
- if (using sequence numbers) then
- body.seq-number := sequence number;
- endif
- body.s-address := sender host addresses;
- if (only one recipient) then
- body.r-address := recipient host address;
- endif
- checksum.cksumtype := checksum type;
- compute checksum over body;
- checksum.checksum := checksum value; /* checksum.checksum */
- packet.cksum := checksum;
- packet.safe-body := body;
-
-A.14. KRB_SAFE verification
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- receive packet;
- if (packet.pvno != 5) then
- either process using other protocol spec
- or error_out(KRB_AP_ERR_BADVERSION);
- endif
- if (packet.msg-type != KRB_SAFE) then
- error_out(KRB_AP_ERR_MSG_TYPE);
- endif
- if (packet.checksum.cksumtype is not both collision-proof and keyed) then
- error_out(KRB_AP_ERR_INAPP_CKSUM);
- endif
- if (safe_priv_common_checks_ok(packet)) then
- set computed_checksum := checksum(packet.body);
- if (computed_checksum != packet.checksum) then
- error_out(KRB_AP_ERR_MODIFIED);
- endif
- return (packet, PACKET_IS_GENUINE);
- else
- return common_checks_error;
- endif
-
-A.15. KRB_SAFE and KRB_PRIV common checks
-
- if (packet.s-address != O/S_sender(packet)) then
- /* O/S report of sender not who claims to have sent it */
- error_out(KRB_AP_ERR_BADADDR);
- endif
- if ((packet.r-address is present) and
- (packet.r-address != local_host_address)) then
- /* was not sent to proper place */
- error_out(KRB_AP_ERR_BADADDR);
- endif
- if (((packet.timestamp is present) and
- (not in_clock_skew(packet.timestamp,packet.usec))) or
- (packet.timestamp is not present and timestamp expected)) then
- error_out(KRB_AP_ERR_SKEW);
- endif
- if (repeated(packet.timestamp,packet.usec,packet.s-address)) then
- error_out(KRB_AP_ERR_REPEAT);
- endif
-
- if (((packet.seq-number is present) and
- ((not in_sequence(packet.seq-number)))) or
- (packet.seq-number is not present and sequence expected)) then
- error_out(KRB_AP_ERR_BADORDER);
- endif
- if (packet.timestamp not present and packet.seq-number not present)
- then
- error_out(KRB_AP_ERR_MODIFIED);
- endif
-
- save_identifier(packet.{timestamp,usec,s-address},
- sender_principal(packet));
-
- return PACKET_IS_OK;
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
-A.16. KRB_PRIV generation
-
- collect user data in buffer;
-
- /* assemble packet: */
- packet.pvno := protocol version; /* 5 */
- packet.msg-type := message type; /* KRB_PRIV */
-
- packet.enc-part.etype := encryption type;
-
- body.user-data := buffer;
- if (using timestamp) then
- get system_time;
- body.timestamp, body.usec := system_time;
- endif
- if (using sequence numbers) then
- body.seq-number := sequence number;
- endif
- body.s-address := sender host addresses;
- if (only one recipient) then
- body.r-address := recipient host address;
- endif
-
- encode body into OCTET STRING;
-
- select encryption type;
- encrypt OCTET STRING into packet.enc-part.cipher;
-
-A.17. KRB_PRIV verification
-
- receive packet;
- if (packet.pvno != 5) then
- either process using other protocol spec
- or error_out(KRB_AP_ERR_BADVERSION);
- endif
- if (packet.msg-type != KRB_PRIV) then
- error_out(KRB_AP_ERR_MSG_TYPE);
- endif
-
- cleartext := decrypt(packet.enc-part) using negotiated key;
- if (decryption_error()) then
- error_out(KRB_AP_ERR_BAD_INTEGRITY);
- endif
-
- if (safe_priv_common_checks_ok(cleartext)) then
- return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED);
- else
- return common_checks_error;
- endif
-
-A.18. KRB_CRED generation
-
- invoke KRB_TGS; /* obtain tickets to be provided to peer */
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
- /* assemble packet: */
- packet.pvno := protocol version; /* 5 */
- packet.msg-type := message type; /* KRB_CRED */
-
- for (tickets[n] in tickets to be forwarded) do
- packet.tickets[n] = tickets[n].ticket;
- done
-
- packet.enc-part.etype := encryption type;
-
- for (ticket[n] in tickets to be forwarded) do
- body.ticket-info[n].key = tickets[n].session;
- body.ticket-info[n].prealm = tickets[n].crealm;
- body.ticket-info[n].pname = tickets[n].cname;
- body.ticket-info[n].flags = tickets[n].flags;
- body.ticket-info[n].authtime = tickets[n].authtime;
- body.ticket-info[n].starttime = tickets[n].starttime;
- body.ticket-info[n].endtime = tickets[n].endtime;
- body.ticket-info[n].renew-till = tickets[n].renew-till;
- body.ticket-info[n].srealm = tickets[n].srealm;
- body.ticket-info[n].sname = tickets[n].sname;
- body.ticket-info[n].caddr = tickets[n].caddr;
- done
-
- get system_time;
- body.timestamp, body.usec := system_time;
-
- if (using nonce) then
- body.nonce := nonce;
- endif
-
- if (using s-address) then
- body.s-address := sender host addresses;
- endif
- if (limited recipients) then
- body.r-address := recipient host address;
- endif
-
- encode body into OCTET STRING;
-
- select encryption type;
- encrypt OCTET STRING into packet.enc-part.cipher
- using negotiated encryption key;
-
-A.19. KRB_CRED verification
-
- receive packet;
- if (packet.pvno != 5) then
- either process using other protocol spec
- or error_out(KRB_AP_ERR_BADVERSION);
- endif
- if (packet.msg-type != KRB_CRED) then
- error_out(KRB_AP_ERR_MSG_TYPE);
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- endif
-
- cleartext := decrypt(packet.enc-part) using negotiated key;
- if (decryption_error()) then
- error_out(KRB_AP_ERR_BAD_INTEGRITY);
- endif
- if ((packet.r-address is present or required) and
- (packet.s-address != O/S_sender(packet)) then
- /* O/S report of sender not who claims to have sent it */
- error_out(KRB_AP_ERR_BADADDR);
- endif
- if ((packet.r-address is present) and
- (packet.r-address != local_host_address)) then
- /* was not sent to proper place */
- error_out(KRB_AP_ERR_BADADDR);
- endif
- if (not in_clock_skew(packet.timestamp,packet.usec)) then
- error_out(KRB_AP_ERR_SKEW);
- endif
- if (repeated(packet.timestamp,packet.usec,packet.s-address)) then
- error_out(KRB_AP_ERR_REPEAT);
- endif
- if (packet.nonce is required or present) and
- (packet.nonce != expected-nonce) then
- error_out(KRB_AP_ERR_MODIFIED);
- endif
-
- for (ticket[n] in tickets that were forwarded) do
- save_for_later(ticket[n],key[n],principal[n],
- server[n],times[n],flags[n]);
- return
-
-A.20. KRB_ERROR generation
-
- /* assemble packet: */
- packet.pvno := protocol version; /* 5 */
- packet.msg-type := message type; /* KRB_ERROR */
-
- get system_time;
- packet.stime, packet.susec := system_time;
- packet.realm, packet.sname := server name;
-
- if (client time available) then
- packet.ctime, packet.cusec := client_time;
- endif
- packet.error-code := error code;
- if (client name available) then
- packet.cname, packet.crealm := client name;
- endif
- if (error text available) then
- packet.e-text := error text;
- endif
- if (error data available) then
- packet.e-data := error data;
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
- endif
-
-B. Definition of common authorization data elements
-
-This appendix contains the definitions of common authorization data
-elements. These common authorization data elements are recursivly defined,
-meaning the ad-data for these types will itself contain a sequence of
-authorization data whose interpretation is affected by the encapsulating
-element. Depending on the meaning of the encapsulating element, the
-encapsulated elements may be ignored, might be interpreted as issued
-directly by the KDC, or they might be stored in a separate plaintext part of
-the ticket. The types of the encapsulating elements are specified as part of
-the Kerberos specification ebcause the behavior based on these values should
-be understood across implementations whereas other elements need only be
-understood by the applications which they affect.
-
-In the definitions that follow, the value of the ad-type for the element
-will be specified in the subsection number, and the value of the ad-data
-will be as shown in the ASN.1 structure that follows the subsection heading.
-
-B.1. KDC Issued
-
-AD-KDCIssued SEQUENCE {
- ad-checksum[0] Checksum,
- i-realm[1] Realm OPTIONAL,
- i-sname[2] PrincipalName OPTIONAL,
- elements[3] AuthorizationData.
-}
-
-ad-checksum
- A checksum over the elements field using a cryptographic checksum
- method that is identical to the checksum used to protect the ticket
- itself (i.e. using the same hash function and the same encryption
- algorithm used to encrypt the ticket) and using a key derived from the
- same key used to protect the ticket.
-i-realm, i-sname
- The name of the issuing principal if different from the KDC itself.
- This field would be used when the KDC can verify the authenticity of
- elements signed by the issuing principal and it allows this KDC to
- notify the application server of the validity of those elements.
-elements
- A sequence of authorization data elements issued by the KDC.
-
-The KDC-issued ad-data field is intended to provide a means for Kerberos
-principal credentials to embed within themselves privilege attributes and
-other mechanisms for positive authorization, amplifying the priveleges of
-the principal beyond what can be done using a credentials without such an
-a-data element.
-
-This can not be provided without this element because the definition of the
-authorization-data field allows elements to be added at will by the bearer
-of a TGT at the time that they request service tickets and elements may also
-be added to a delegated ticket by inclusion in the authenticator.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-For KDC-issued elements this is prevented because the elements are signed by
-the KDC by including a checksum encrypted using the server's key (the same
-key used to encrypt the ticket - or a key derived from that key). Elements
-encapsulated with in the KDC-issued element will be ignored by the
-application server if this "signature" is not present. Further, elements
-encapsulated within this element from a ticket granting ticket may be
-interpreted by the KDC, and used as a basis according to policy for
-including new signed elements within derivative tickets, but they will not
-be copied to a derivative ticket directly. If they are copied directly to a
-derivative ticket by a KDC that is not aware of this element, the signature
-will not be correct for the application ticket elements, and the field will
-be ignored by the application server.
-
-This element and the elements it encapulates may be safely ignored by
-applications, application servers, and KDCs that do not implement this
-element.
-
-B.2. Intended for server
-
-AD-INTENDED-FOR-SERVER SEQUENCE {
- intended-server[0] SEQUENCE OF PrincipalName
- elements[1] AuthorizationData
-}
-
-AD elements encapsulated within the intended-for-server element may be
-ignored if the application server is not in the list of principal names of
-intended servers. Further, a KDC issuing a ticket for an application server
-can remove this element if the application server is not in the list of
-intended servers.
-
-Application servers should check for their principal name in the
-intended-server field of this element. If their principal name is not found,
-this element should be ignored. If found, then the encapsulated elements
-should be evaluated in the same manner as if they were present in the top
-level authorization data field. Applications and application servers that do
-not implement this element should reject tickets that contain authorization
-data elements of this type.
-
-B.3. Intended for application class
-
-AD-INTENDED-FOR-APPLICATION-CLASS SEQUENCE { intended-application-class[0]
-SEQUENCE OF GeneralString elements[1] AuthorizationData } AD elements
-encapsulated within the intended-for-application-class element may be
-ignored if the application server is not in one of the named classes of
-application servers. Examples of application server classes include
-"FILESYSTEM", and other kinds of servers.
-
-This element and the elements it encapulates may be safely ignored by
-applications, application servers, and KDCs that do not implement this
-element.
-
-B.4. If relevant
-
-AD-IF-RELEVANT AuthorizationData
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
-AD elements encapsulated within the if-relevant element are intended for
-interpretation only by application servers that understand the particular
-ad-type of the embedded element. Application servers that do not understand
-the type of an element embedded within the if-relevant element may ignore
-the uninterpretable element. This element promotes interoperability across
-implementations which may have local extensions for authorization.
-
-B.5. And-Or
-
-AD-AND-OR SEQUENCE {
- condition-count[0] INTEGER,
- elements[1] AuthorizationData
-}
-
-When restrictive AD elements encapsulated within the and-or element are
-encountered, only the number specified in condition-count of the
-encapsulated conditions must be met in order to satisfy this element. This
-element may be used to implement an "or" operation by setting the
-condition-count field to 1, and it may specify an "and" operation by setting
-the condition count to the number of embedded elements. Application servers
-that do not implement this element must reject tickets that contain
-authorization data elements of this type.
-
-B.6. Mandatory ticket extensions
-
-AD-Mandatory-Ticket-Extensions Checksum
-
-An authorization data element of type mandatory-ticket-extensions specifies
-a collision-proof checksum using the same has angorithm used to protect the
-integrity of the ticket itself. This checksum will be calculated over the
-entire extensions field. If there are more than one extension, all will be
-covered by the checksum. This restriction indicates that the ticket should
-not be accepted if the checksum does not match that calculated over the
-ticket extensions. Application servers that do not implement this element
-must reject tickets that contain authorization data elements of this type.
-
-B.7. Authorization Data in ticket extensions
-
-AD-IN-Ticket-Extensions Checksum
-
-An authorization data element of type in-ticket-extensions specifies a
-collision-proof checksum using the same has angorithm used to protect the
-integrity of the ticket itself. This checksum is calculated over a separate
-external AuthorizationData field carried in the ticket extensions.
-Application servers that do not implement this element must reject tickets
-that contain authorization data elements of this type. Application servers
-that do implement this element will search the ticket extensions for
-authorization data fields, calculate the specified checksum over each
-authorization data field and look for one matching the checksum in this
-in-ticket-extensions element. If not found, then the ticket must be
-rejected. If found, the corresponding authorization data elements will be
-interpreted in the same manner as if they were contained in the top level
-authorization data field.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
-Note that if multiple external authorization data fields are present in a
-ticket, each will have a corresponding element of type in-ticket-extensions
-in the top level authorization data field, and the external entries will be
-linked to the corresponding element by their checksums.
-
-C. Definition of common ticket extensions
-
-This appendix contains the definitions of common ticket extensions. Support
-for these extensions is optional. However, certain extensions have
-associated authorization data elements that may require rejection of a
-ticket containing an extension by application servers that do not implement
-the particular extension. Other extensions have been defined beyond those
-described in this specification. Such extensions are described elswhere and
-for some of those extensions the reserved number may be found in the list of
-constants.
-
-It is known that older versions of Kerberos did not support this field, and
-that some clients will strip this field from a ticket when they parse and
-then reassemble a ticket as it is passed to the application servers. The
-presence of the extension will not break such clients, but any functionaly
-dependent on the extensions will not work when such tickets are handled by
-old clients. In such situations, some implementation may use alternate
-methods to transmit the information in the extensions field.
-
-C.1. Null ticket extension
-
-TE-NullExtension OctetString -- The empty Octet String
-
-The te-data field in the null ticket extension is an octet string of lenght
-zero. This extension may be included in a ticket granting ticket so that the
-KDC can determine on presentation of the ticket granting ticket whether the
-client software will strip the extensions field.
-
-C.2. External Authorization Data
-
-TE-ExternalAuthorizationData AuthorizationData
-
-The te-data field in the external authorization data ticket extension is
-field of type AuthorizationData containing one or more authorization data
-elements. If present, a corresponding authorization data element will be
-present in the primary authorization data for the ticket and that element
-will contain a checksum of the external authorization data ticket extension.
-----------------------------------------------------------------------------
-[TM] Project Athena, Athena, and Kerberos are trademarks of the
-Massachusetts Institute of Technology (MIT). No commercial use of these
-trademarks may be made without prior written permission of MIT.
-
-[1] Note, however, that many applications use Kerberos' functions only upon
-the initiation of a stream-based network connection. Unless an application
-subsequently provides integrity protection for the data stream, the identity
-verification applies only to the initiation of the connection, and does not
-guarantee that subsequent messages on the connection originate from the same
-principal.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
-[2] Secret and private are often used interchangeably in the literature. In
-our usage, it takes two (or more) to share a secret, thus a shared DES key
-is a secret key. Something is only private when no one but its owner knows
-it. Thus, in public key cryptosystems, one has a public and a private key.
-
-[3] Of course, with appropriate permission the client could arrange
-registration of a separately-named prin- cipal in a remote realm, and engage
-in normal exchanges with that realm's services. However, for even small
-numbers of clients this becomes cumbersome, and more automatic methods as
-described here are necessary.
-
-[4] Though it is permissible to request or issue tick- ets with no network
-addresses specified.
-
-[5] The password-changing request must not be honored unless the requester
-can provide the old password (the user's current secret key). Otherwise, it
-would be possible for someone to walk up to an unattended ses- sion and
-change another user's password.
-
-[6] To authenticate a user logging on to a local system, the credentials
-obtained in the AS exchange may first be used in a TGS exchange to obtain
-credentials for a local server. Those credentials must then be verified by a
-local server through successful completion of the Client/Server exchange.
-
-[7] "Random" means that, among other things, it should be impossible to
-guess the next session key based on knowledge of past session keys. This can
-only be achieved in a pseudo-random number generator if it is based on
-cryptographic principles. It is more desirable to use a truly random number
-generator, such as one based on measurements of random physical phenomena.
-
-[8] Tickets contain both an encrypted and unencrypted portion, so cleartext
-here refers to the entire unit, which can be copied from one message and
-replayed in another without any cryptographic skill.
-
-[9] Note that this can make applications based on unreliable transports
-difficult to code correctly. If the transport might deliver duplicated
-messages, either a new authenticator must be generated for each retry, or
-the application server must match requests and replies and replay the first
-reply in response to a detected duplicate.
-
-[10] This is used for user-to-user authentication as described in [8].
-
-[11] Note that the rejection here is restricted to authenticators from the
-same principal to the same server. Other client principals communicating
-with the same server principal should not be have their authenticators
-rejected if the time and microsecond fields happen to match some other
-client's authenticator.
-
-[12] In the Kerberos version 4 protocol, the timestamp in the reply was the
-client's timestamp plus one. This is not necessary in version 5 because
-version 5 messages are formatted in such a way that it is not possible to
-create the reply by judicious message surgery (even in encrypted form)
-without knowledge of the appropriate encryption keys.
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-
-[13] Note that for encrypting the KRB_AP_REP message, the sub-session key is
-not used, even if present in the Authenticator.
-
-[14] Implementations of the protocol may wish to provide routines to choose
-subkeys based on session keys and random numbers and to generate a
-negotiated key to be returned in the KRB_AP_REP message.
-
-[15]This can be accomplished in several ways. It might be known beforehand
-(since the realm is part of the principal identifier), it might be stored in
-a nameserver, or it might be obtained from a configura- tion file. If the
-realm to be used is obtained from a nameserver, there is a danger of being
-spoofed if the nameservice providing the realm name is not authenti- cated.
-This might result in the use of a realm which has been compromised, and
-would result in an attacker's ability to compromise the authentication of
-the application server to the client.
-
-[16] If the client selects a sub-session key, care must be taken to ensure
-the randomness of the selected sub- session key. One approach would be to
-generate a random number and XOR it with the session key from the
-ticket-granting ticket.
-
-[17] This allows easy implementation of user-to-user authentication [8],
-which uses ticket-granting ticket session keys in lieu of secret server keys
-in situa- tions where such secret keys could be easily comprom- ised.
-
-[18] For the purpose of appending, the realm preceding the first listed
-realm is considered to be the null realm ("").
-
-[19] For the purpose of interpreting null subfields, the client's realm is
-considered to precede those in the transited field, and the server's realm
-is considered to follow them.
-
-[20] This means that a client and server running on the same host and
-communicating with one another using the KRB_SAFE messages should not share
-a common replay cache to detect KRB_SAFE replays.
-
-[21] The implementation of the Kerberos server need not combine the database
-and the server on the same machine; it is feasible to store the principal
-database in, say, a network name service, as long as the entries stored
-therein are protected from disclosure to and modification by unauthorized
-parties. However, we recommend against such strategies, as they can make
-system management and threat analysis quite complex.
-
-[22] See the discussion of the padata field in section 5.4.2 for details on
-why this can be useful.
-
-[23] Warning for implementations that unpack and repack data structures
-during the generation and verification of embedded checksums: Because any
-checksums applied to data structures must be checked against the original
-data the length of bit strings must be preserved within a data structure
-between the time that a checksum is generated through transmission to the
-time that the checksum is verified.
-
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-[24] It is NOT recommended that this time value be used to adjust the
-workstation's clock since the workstation cannot reliably determine that
-such a KRB_AS_REP actually came from the proper KDC in a timely manner.
-
-[25] Note, however, that if the time is used as the nonce, one must make
-sure that the workstation time is monotonically increasing. If the time is
-ever reset backwards, there is a small, but finite, probability that a nonce
-will be reused.
-
-[27] An application code in the encrypted part of a message provides an
-additional check that the message was decrypted properly.
-
-[29] An application code in the encrypted part of a message provides an
-additional check that the message was decrypted properly.
-
-[31] An application code in the encrypted part of a message provides an
-additional check that the message was decrypted properly.
-
-[32] If supported by the encryption method in use, an initialization vector
-may be passed to the encryption procedure, in order to achieve proper cipher
-chaining. The initialization vector might come from the last block of the
-ciphertext from the previous KRB_PRIV message, but it is the application's
-choice whether or not to use such an initialization vector. If left out, the
-default initialization vector for the encryption algorithm will be used.
-
-[33] This prevents an attacker who generates an incorrect AS request from
-obtaining verifiable plaintext for use in an off-line password guessing
-attack.
-
-[35] In the above specification, UNTAGGED OCTET STRING(length) is the
-notation for an octet string with its tag and length removed. It is not a
-valid ASN.1 type. The tag bits and length must be removed from the
-confounder since the purpose of the confounder is so that the message starts
-with random data, but the tag and its length are fixed. For other fields,
-the length and tag would be redundant if they were included because they are
-specified by the encryption type. [36] The ordering of the fields in the
-CipherText is important. Additionally, messages encoded in this format must
-include a length as part of the msg-seq field. This allows the recipient to
-verify that the message has not been truncated. Without a length, an
-attacker could use a chosen plaintext attack to generate a message which
-could be truncated, while leaving the checksum intact. Note that if the
-msg-seq is an encoding of an ASN.1 SEQUENCE or OCTET STRING, then the length
-is part of that encoding.
-
-[37] In some cases, it may be necessary to use a different "mix-in" string
-for compatibility reasons; see the discussion of padata in section 5.4.2.
-
-[38] In some cases, it may be necessary to use a different "mix-in" string
-for compatibility reasons; see the discussion of padata in section 5.4.2.
-
-[39] A variant of the key is used to limit the use of a key to a particular
-function, separating the functions of generating a checksum from other
-encryption performed using the session key. The constant F0F0F0F0F0F0F0F0
-was chosen because it maintains key parity. The properties of DES precluded
-
-
-draft-ietf-cat-kerberos-r-01 Expires 21 May 1998\f
-
-the use of the complement. The same constant is used for similar purpose in
-the Message Integrity Check in the Privacy Enhanced Mail standard.
-
-[40] This error carries additional information in the e- data field. The
-contents of the e-data field for this message is described in section 5.9.1.
git.samba.org / samba.git / blobdiff