summaryrefslogtreecommitdiffstats
path: root/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt
diff options
context:
space:
mode:
Diffstat (limited to 'crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt')
-rw-r--r--crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt8277
1 files changed, 0 insertions, 8277 deletions
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt
deleted file mode 100644
index 2284c3c..0000000
--- a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt
+++ /dev/null
@@ -1,8277 +0,0 @@
-
-INTERNET-DRAFT Clifford Neuman
- John Kohl
- Theodore Ts'o
- 11 July 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-revisions-00.txt, and expires
-11 January 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 pro-
-vided in RFC1510. This document is intended to provide a
-detailed description of the protocol, suitable for implemen-
-tation, together with descriptions of the appropriate use of
-protocol messages and fields within those messages.
-
- This document is not intended to describe Kerberos to
-__________________________
-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.
-
-
-
-Overview - 1 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-the end user, system administrator, or application
-developer. Higher level papers describing Version 5 of the
-Kerberos system [1] and documenting version 4 [23], 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 proto-
-col.
-
- The motivations, goals, assumptions, and rationale
-behind most design decisions are treated cursorily; they are
-more fully described in a paper available in IEEE communica-
-tions [1] and earlier in the Kerberos portion of the Athena
-Technical Plan [2]. The protocols have been a proposed
-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 [4]
-and on modifications suggested by Denning and Sacco [5].
-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 Ker-
-beros.
-
- Version 5 of the Kerberos protocol (described in this
-document) has evolved from Version 4 based on new require-
-ments 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 com-
-munity. 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 implementa-
-tions of both version 4 and version 5 of Kerberos are pub-
-licly available and commercial implementations have been
-
-Overview - 2 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-developed and are widely used.
-
- Details on the differences between Kerberos Versions 4
-and 5 can be found in [6].
-
-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 per-
-forms 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 certifi-
-cation 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 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 con-
-tains the client's identity and a copy of the session key,
-all encrypted in the server's key) to the server. The ses-
-sion key (now shared by the client and server) is used to
-authenticate the client, and may optionally be used to
-__________________________
-[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.
-[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.
-
-
-
-Section 1. - 3 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 transac-
-tions, 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 authenti-
-cation.
-
- 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 pro-
-tocol specification describes the AS and the TGS as separate
-servers, they are implemented in practice as different pro-
-tocol 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 tran-
-saction, 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, addi-
-tional information is sent to prove that the message ori-
-ginated 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 ses-
-sion key. Since no one except the requesting principal and
-
-
-Section 1. - 4 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-the server know the session key (it is never sent over the
-network in the clear) this guarantees the identity of the
-client.
-
- The integrity of the messages exchanged between princi-
-pals 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, how-
-ever, 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
-__________________________
-[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.
-
-
-Section 1.1. - 5 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 tran-
-sited 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 authen-
-tication 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, intermedi-
-ate realms may be bypassed to achieve cross-realm authenti-
-cation 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.
-
-1.2. Authorization
-
-As an authentication service, Kerberos provides a means of
-verifying the identity of principals on a network. Authen-
-tication 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 con-
-sidered 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 [7] , or on other authorization services.
-
- Applications should not be modified to accept the
-issuance of a service ticket by the Kerberos server (even by
-
-Section 1.2. - 6 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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
-where they interoperate with other KDCs or where other
-options for application authentication (e.g. the PKTAPP pro-
-posal) 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 Ker-
- beros. 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 not-uncommon "normal" failure modes for the system)
- is usually best left to the human administrators and
- users.
-
-+ 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 suc-
- cessive 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 detec-
- tion. 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 net-
- work, 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.
-
-
-
-Section 1.3. - 7 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-1.4. Glossary of terms
-
-Below is a list of terms used throughout this document.
-
-
-Authentication Verifying the claimed identity of a
- principal.
-
-
-Authentication headerA 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 tran-
- sited 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 permis-
- sion 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 (e.g. a
- print server may be a client of a file
- server).
-
-
-
-Section 1.4. - 8 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-Credentials A ticket plus the secret session key
- necessary to successfully use that
- ticket in an authentication exchange.
-
-
-KDC Key Distribution Center, a network ser-
- vice 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 ser-
- vice).
-
-
-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 authentica-
- tion 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 identifierThe 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 life-
- time. In the case of a human user's
- principal, the secret key is derived
-
-
-Section 1.4. - 9 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- from a password.
-
-
-Server A particular Principal which provides a
- resource to network clients. The server
- is sometimes refered to as the Applica-
- tion 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 "ses-
- sion".
-
-
-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 dura-
- tion of a single association.
-
-
-Ticket A record that helps a client authenti-
- cate 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
-
-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
-
-
-Section 2.1. - 10 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 tick-
-ets 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.
-
- The RENEWABLE flag in a ticket is normally only inter-
-preted by the ticket-granting service (discussed below in
-section 3.3). It can usually be ignored by application
-servers. However, some particularly careful application
-
-
-Section 2.3. - 11 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 ser-
-viced. 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; post-
-dated 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
-
-
-Section 2.5. - 12 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-must be able to take on the identity of the client, but only
-for a particular purpose. A principal can allow a service
-to take on the principal's identity for a particular purpose
-by granting it a proxy.
-
- The process of granting a proxy using the proxy and
-proxiable flags is used to provide credentials for use with
-specific services. Though conceptually also a proxy, user's
-wishing to delegate their identity for ANY purpose must use
-the ticket forwarding mechanism described in the next sec-
-tion to forward a ticket granting ticket.
-
- The PROXIABLE flag in a ticket is normally only inter-
-preted 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 grant-
-ing 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 ser-
-vice 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 authen-
-tication 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
-__________________________
-[4] Though it is permissible to request or issue tick-
-ets with no network addresses specified.
-
-
-Section 2.6. - 13 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 set. Application servers may choose to pro-
-cess FORWARDED tickets differently than non-FORWARDED tick-
-ets.
-
-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 indi-
-cates 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 pro-
-vided with the request. See section 3.3.3 for specific
-details.
-
-__________________________
-[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 sys-
-tem, the credentials obtained in the AS exchange may
-first be used in a TGS exchange to obtain credentials
-
-
-Section 3.1. - 14 - Expires 11 January 1998
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-
-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 creden-
-tials for a given server but currently holds no credentials.
-In its basic form, the client's secret key is used for en-
-cryption 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 ser-
-vices 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 sec-
-tions 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 ses-
-sion key that will be shared by the client and the server.
-The session 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
-__________________________
-for a local server. Those credentials must then be
-verified by a local server through successful comple-
-tion of the Client/Server exchange.
-
-
-
-Section 3.1. - 15 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-message is not encrypted. The KRB_ERROR message contains
-information which can be used to associate it with the mes-
-sage 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 know-
-ing 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 ini-
-tial 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 pre-
-authentication as described in section <<sec preauth>>.
-
-3.1.1. Generation of KRB_AS_REQ message
-
- The client may specify a number of options in the ini-
-tial 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 sec-
-tion 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].
-__________________________
-
-
-Section 3.1.3. - 16 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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 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 infor-
-mation 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 speci-
-fied, 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 cer-
-tain types or ranges of postdated tickets), and if accept-
-able, 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.
-
-
-
-
-
-
-
-
-
-__________________________
-[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 desir-
-able to use a truly random number generator, such as
-one based on measurements of random physical phenomena.
-
-
-
-Section 3.1.3. - 17 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 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 follow-
-ing options set if they have been requested and if the pol-
-icy 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
-
-
-Section 3.1.3. - 18 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 suf-
-ficient 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.
-
-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
-
-
-
-Section 3.2. - 19 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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 authenti-
-cated 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 insuf-
-ficient to authenticate a client, since tickets are passed
-across the network in cleartext[8], 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 mes-
-sage 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 con-
-structs 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[9]. 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 col-
-lide with other sequence numbers in use.
-
- The client may indicate a requirement of mutual
-__________________________
-[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 un-
-reliable 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.
-
-
-
-Section 3.2.2. - 20 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 addi-
-tional 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 authentica-
-tor, and the ticket. Several errors are 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 accept-
-able 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 indi-
-cates to the server that the ticket is encrypted in the ses-
-sion 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 encryp-
-tion 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
-__________________________
-[10] This is used for user-to-user authentication as
-described in [8].
-
-
-Section 3.2.3. - 21 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 authen-
-ticators 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 authentica-
-tor 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.
-
- 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. Oth-
-erwise, 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
-__________________________
-[11] Note that the rejection here is restricted to au-
-thenticators from the same principal to the same
-server. Other client principals communicating with the
-same server principal should not be have their authen-
-ticators rejected if the time and microsecond fields
-happen to match some other client's authenticator.
-
-
-Section 3.2.3. - 22 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 ser-
-vice.
-
-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 ran-
-domly 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
-__________________________
-[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 mes-
-sages are formatted in such a way that it is not possi-
-ble to create the reply by judicious message surgery
-(even in encrypted form) without knowledge of the ap-
-propriate encryption keys.
-[13] Note that for encrypting the KRB_AP_REP message,
-the sub-session key is not used, even if present in the
-Authenticator.
-
-
-Section 3.2.5. - 23 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-timestamp and microsecond fields match those in the Authen-
-ticator 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, 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 check-
-sum type) to the application programmer; the Kerberos proto-
-col 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 protec-
-tion 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
-__________________________
-[14] Implementations of the protocol may wish to pro-
-vide 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.
-
-
-Section 3.2.6. - 24 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 authenti-
-cates to the system, such as when a user logs in). The mes-
-sage format for the TGS exchange is almost identical to that
-for the AS exchange. The primary difference is that encryp-
-tion 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 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 authentica-
-tion 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 col-
-lection 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 creden-
-tials, 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 authentica-
-tion header). The KRB_ERROR message contains an error code
-
-
-Section 3.3. - 25 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-and text explaining what went wrong. The KRB_ERROR message
-is not encrypted. The KRB_TGS_REP message contains informa-
-tion which can be used to detect replays, and to associate
-it with the message to which it replies. The KRB_ERROR mes-
-sage also contains information which can be used to associ-
-ate 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 ser-
-vice, the client must determine in which realm the applica-
-tion 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 mes-
-sage recursively). The Kerberos server may return a TGT for
-the desired realm in which case one can proceed. Alterna-
-tively, 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.
-__________________________
-[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 appli-
-cation server to the client.
-
-
-
-Section 3.3.1. - 26 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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
-optional fields: the enc-authorization-data field for appli-
-cation 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 authentica-
-tion 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 simi-
-lar 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 ser-
-vice, 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 grant-
-ing 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
-__________________________
-[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 ran-
-dom number and XOR it with the session key from the
-ticket-granting ticket.
-
-
-Section 3.3.2. - 27 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 sup-
-ported, 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 "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
-
-
-Section 3.3.3. - 28 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 speci-
-fied, 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 dif-
-ferent, the request will be rejected. If the request
-succeeds, the session key from the additional ticket will be
-used to encrypt the new 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
-__________________________
-[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.
-
-
-Section 3.3.3. - 29 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 Authen-
-ticator, 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).
-
-
-
-Section 3.3.3.2. - 30 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- Note that the ticket-granting service does not add the
-name of its own realm. Instead, its responsibility is to
-add the name of the previous realm. This prevents a mali-
-cious 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 arrange-
-ment 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".
-__________________________
-[18] For the purpose of appending, the realm preceding
-the first listed realm is considered to be the null
-realm ("").
-
-
-Section 3.3.3.2. - 31 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 hierar-
-chy) 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 hierar-
-chy shares an inter-realm key directly with the /COM realm
-in another hierarchy.
-
-3.3.4. Receipt of KRB_TGS_REP message
-
-When the KRB_TGS_REP is received by the client, it is pro-
-cessed in the same manner as the KRB_AS_REP processing
-described above. The primary difference is that the cipher-
-text part of the response must be decrypted using the ses-
-sion 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 informa-
-tion. 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
-__________________________
-[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 con-
-sidered to follow them.
-
-
-Section 3.4.1. - 32 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 prob-
-lem.
-
- 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 pro-
-tocol version and type fields match the current version and
-KRB_SAFE, respectively. A mismatch 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
-__________________________
-[20] This means that a client and server running on the
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 check-
-sum 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 mes-
-sages 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 pro-
-tocol 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 gen-
-erated. The recipient verifies that the operating system's
-report of the sender's address matches the sender's address
-__________________________
-same host and communicating with one another using the
-KRB_SAFE messages should not share a common replay
-cache to detect KRB_SAFE replays.
-
-
-
-Section 3.5.2. - 34 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 mes-
-sage 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
-
-
-Section 3.6.2. - 35 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 gen-
-erated.
-
- If present or required, the recipient verifies that the
-operating system's 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 identif-
-ier
-key Principal's secret key
-p_kvno Principal's key version
-max_life Maximum lifetime for Tickets
-__________________________
-[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.
-
-
-Section 4.1. - 36 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 mas-
-ter 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 (end-
-time - 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 prin-
-cipal, the principal 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
-
-
-Section 4.2. - 37 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 tick-
-ets as or for the principal. (A database may want to main-
-tain 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 con-
-trolled by the system-wide database service, Moira [9]), 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 authentica-
-tion, 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 modifica-
-tion 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 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
-__________________________
-[22] See the discussion of the padata field in section
-5.4.2 for details on why this can be useful.
-
-
-Section 4.3. - 38 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-section 5.2).
-
- Other frequently changing information that can be main-
-tained 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 confi-
-gurable 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 tick-
- ets 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 encryp-
-tion 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 Dis-
-tinguished Encoding Representation of the data elements as
-described in the X.509 specification, section 8.7 [10].
-
-
-
-
-
-Section 5.1. - 39 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 char-
-acter (_) 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
-}
-
-
-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 com-
-ponents consisting of the following sub-fields:
-
-name-type This field specifies the type of name that fol-
- lows. 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-stringThis field encodes a sequence of components that
- form a name, each component encoded as a General-
- String. Taken together, a PrincipalName and a
- Realm form a principal identifier. Most Princi-
- palNames will have only a few components (typi-
- cally one or two).
-
-
-
- KerberosTime ::= GeneralizedTime
- -- Specifying UTC time zone (Z)
-
-
- The timestamps used in Kerberos are encoded as General-
-izedTimes. 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
-
-
-Section 5.2. - 40 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- }
-
- HostAddresses ::= SEQUENCE OF SEQUENCE {
- addr-type[0] INTEGER,
- address[1] OCTET STRING
- }
-
-
- 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 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.
-
- 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),
-
-
-Section 5.2. - 41 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- pre-authent(10),
- hw-authent(11),
- transited-policy-checked(12),
- ok-as-delegate(13)
- }
-
-
- 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].
-
-__________________________
-[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.
-
-
-
-Section 5.2. - 42 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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 indi-
- cate 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 informa-
- tion 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 con-
- tents of the accompanying lr-type subfield.
-
- See section 6 for the definitions of Checksum, Check-
-sumType, EncryptedData, EncryptionKey, EncryptionType, and
-KeyType.
-
-
-5.3. Tickets and Authenticators
-
- This section describes the format and encryption param-
-eters 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
-}
-
-
-Section 5.3.1. - 43 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
--- 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, the two will always be identi-
- cal.
-
-
-sname This field specifies the name part of the server's
- identity.
-
-
-enc-part This field holds the encrypted encoding of the
- EncTicketPart sequence.
-
-
-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:
-
-
-Section 5.3.1. - 44 - Expires 11 January 1998
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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
- 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.
-
-
-
-
-
-
-
-
-Section 5.3.1. - 45 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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.
-
- 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.
-
-
-
-
-Section 5.3.1. - 46 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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.
-
-Section 5.3.1. - 47 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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.
-
-
-
-
-Section 5.3.1. - 48 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 14 ANONYMOUS
- This flag indicates that the principal
- named in the ticket is a generic princi-
- pal for the realm and does not identify
- 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 authenti-
- cation 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 implementa-
- tion of a `hot list' service at the KDC. An end
- service that is particularly paranoid could refuse
- to accept tickets for which the initial authenti-
- cation 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
-
-
-Section 5.3.1. - 49 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- (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-tillThis 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 abso-
- lute expiration 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 sug-
- gested and default policy, however, is that such
- tickets will only be issued or accepted when addi-
- tional 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
-__________________________
-[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 actu-
-ally came from the proper KDC in a timely manner.
-
-
-Section 5.3.1. - 50 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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 ser-
- vice. 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 bases 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 addi-
- tional entries when a new ticket is obtained dur-
- ing 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 ser-
- vice specific objects, and the rights to those
- objects. The format for this field is described
- in section 5.2. Although Kerberos is not con-
- cerned with the format of the contents of the sub-
- fields, it does carry type information (ad-type).
-
-
-
-Section 5.3.1. - 51 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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 providing authoriza-
- tion or certifying group membership may be built
- using the authorization-data field. In this case,
- the entity granting authorization (not the author-
- ized 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 restric-
- tions on its own authority and delegates the res-
- tricted 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 [7] for some sug-
- gested 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
-}
-
-
-
-Section 5.3.2. - 52 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-authenticator-vno
- This field specifies the version number for the
- format of the authenticator. This document speci-
- fies version 5.
-
-
-crealm and cname
- These fields are the same as those described for
- the ticket in section 5.3.1.
-
-
-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 applica-
- tion specifies otherwise, if this field is left
- out the session key from the ticket will be used.
-
-seq-numberThis optional field includes the initial sequence
- number to be used by the KRB_PRIV or KRB_SAFE mes-
- sages when sequence numbers are used to detect
- replays (It may also be used by application
- specific messages). When included in the authen-
- ticator 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.
-
-
-
-Section 5.3.2. - 53 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 car-
- ried 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
-
-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
-
-
-Section 5.4.1. - 54 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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 speci-
- fies the protocol version number. This document
- specifies protocol version 5.
-
-
-msg-type This field indicates the type of a protocol mes-
- sage. 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 con-
- tains 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 most requests for initial authenti-
- cation (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
-
-
-Section 5.4.1. - 55 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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.
-
- 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 [11] for
- additional uses of this field.
-
-padata-type
- The padata-type element of the padata field indi-
- cates 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
- 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:
-
-
-
-
-Section 5.4.1. - 56 - Expires 11 January 1998
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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
- 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.
-
-
-
-
-
-
-
-Section 5.4.1. - 57 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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
- 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.
-
-
-
-Section 5.4.1. - 58 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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
- 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
-
-
-Section 5.4.1. - 59 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- absent when the ENC-TKT-IN-SKEY option is speci-
- fied. 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 encod-
- ing 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.
-
-
-
-till This field contains the expiration date requested
- by the client in a ticket request. It is option
- 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 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 gen-
- erated randomly, but if the correct time is known,
- it may suffice[25].
-__________________________
-[25] Note, however, that if the time is used as the
-
-Section 5.4.1. - 60 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-etype This field specifies the desired encryption algo-
- rithm 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 per-
-form 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 subse-
-quent (TGS) request. There is no message type for
-__________________________
-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.
-
-
-
-Section 5.4.2. - 61 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 cipher-
-text is encrypted in the sub-session key from the Authenti-
-cator, or if absent, the session key from the ticket-
-granting ticket used in the request. In that case, no ver-
-sion number will be present in the EncryptedData sequence.
-
- 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.
-__________________________
-[27] An application code in the encrypted part of a
-message provides an additional check that the message
-was decrypted properly.
-
-
-Section 5.4.2. - 62 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 use-
- ful 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 appear-
- ance of this field. 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
-
-
-Section 5.4.2. - 63 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- client's secret key is due to expire. The expira-
- tion 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 expira-
- tion 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 sec-
- tion 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
-}
-
-APOptions ::= BIT STRING {
- reserved(0),
- use-session-key(1),
- mutual-required(2)
-
-
-Section 5.5.1. - 64 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-}
-
-
-pvno and msg-type
- These fields are described above in section 5.4.1.
- msg-type is KRB_AP_REQ.
-
-
-ap-optionsThis 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
-
-
-Section 5.5.2. - 65 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-has been selected in the ap-options field.
-
-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 associa-
-tion 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 ses-
- sion. 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 authentica-
- tor, or if also left out, the session key from the
- ticket will be used.
-
-
-
-__________________________
-[29] An application code in the encrypted part of a
-message provides an additional check that the message
-was decrypted properly.
-
-
-
-Section 5.5.2. - 66 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 exam-
-ple, 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 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.
-
-
-
-Section 5.6.1. - 67 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-cksum This field contains the checksum of the applica-
- tion data. Checksum details are described in sec-
- tion 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 reci-
- pient.
-
-
-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
-
- 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:
-
-__________________________
-[31] An application code in the encrypted part of a
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-
-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
-__________________________
-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 mes-
-sage, 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 algo-
-rithm will be used.
-
-
-Section 5.8. - 69 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-another. It is presented here to encourage a common mechan-
-ism 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:
-
-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.
-
-
-
-
-Section 5.8.1. - 70 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-tickets
- These are the tickets obtained from the KDC
- specifically for use by the intended recipient.
- Successive tickets are paired with the correspond-
- ing 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 mes-
- sage in an application specific manner.
-
-
-timestamp and usec
-
- These fields specify the time that the KRB-CRED
- message was generated. The time is used to pro-
- vide 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 mes-
- sage.
-
-
-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
-
-
-Section 5.8.1. - 71 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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 mes-
-sage for security-critical purposes, such as setting a sys-
-tem 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,
- e-data[12] OCTET STRING OPTIONAL,
- e-cksum[13] Checksum OPTIONAL
-}
-
-
-
-
-
-Section 5.9.1. - 72 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 rea-
- sonably accurate timestamp.
-
-
-error-codeThis 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 sup-
- port 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 error-
- code 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 contain-
- ing data for the method:
-
-
-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
-
-
-Section 5.9.1. - 73 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- message with the checksum absent. The checksum is
- then added to the KRB-ERROR structure and the mes-
- sage is re-encoded. The Checksum should be calcu-
- lated using the session key from the ticket grant-
- ing 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 preau-
- thentication to prove knowledge of the secret key
- by the client[33]. If a checksum can not be com-
- puted because the key to be used is not available,
- no checksum will be included.
-
- 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 fol-
- lowing sequence:
-
- METHOD-DATA ::= SEQUENCE {
- method-type[0] INTEGER,
- method-data[1] OCTET STRING OPTIONAL
- }
-
- method-type will indicate the required alternate
- method; method-data will contain any required
- additional information.
-
-
-
-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, [12] in conjunction
-with block chaining and checksum methods [13]. Encryption
-is used to prove the identities of the network entities par-
-ticipating 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 confi-
-dence. 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
-__________________________
-[33] This prevents an attacker who generates an in-
-correct AS request from obtaining verifiable plaintext
-for use in an off-line password guessing attack.
-
-
-Section 6. - 74 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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.
-
- 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 dif-
-ficult. 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 con-
-founder 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 map-
-ping 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.
-
-
-
-Section 6. - 75 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- For an discussion of the integrity characteristics of
-the candidate encryption and checksum methods considered for
-Kerberos, the the reader is referred to [14].
-
-6.1. Encryption Specifications
-
- The following ASN.1 definition describes all encrypted
-messages. The enc-part field which appears in the unen-
-crypted part of messages in section 5 is a sequence consist-
-ing 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
-}
-
-
-etype This field identifies which encryption algorithm
- was used to encipher the cipher. Detailed specif-
- ications 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 dic-
-tionary 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 suffi-
-cient to hold the appropriate item. The type and length is
-implicit and specified by the particular encryption type
-
-
-Section 6.1. - 76 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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; calcu-
-lates 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 encryp-
-tion 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
-__________________________
-[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 be-
-cause they are specified by the encryption type.
-[36] The ordering of the fields in the CipherText is
-important. Additionally, messages encoded in this for-
-mat 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 mes-
-sage which could be truncated, while leaving the check-
-sum 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.
-
-
-
-Section 6.1. - 77 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-particular 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 encryp-
-tion 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 addi-
-tional 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 algo-
- rithm 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 hap-
- pen, 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 encryp-
-tion 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).
-
-
-
-Section 6.3.1. - 78 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 [12] using the cipher
-block chaining mode [13]. A CRC-32 checksum (described in
-ISO 3309 [15]) 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.
-
- 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 con-
-founder is used [14]. 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 Specifi-
-cation 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 [12] using the cipher
-block chaining mode [13]. An MD4 checksum (described in
-[16]) 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 concate-
-nation 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 [12] using the cipher
-block chaining mode [13]. An MD5 checksum (described in
-[17].) 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 concate-
-nation of confounder, checksum, and message) must be padded
-to an 8 byte boundary before encryption.
-
- Plaintext and DES ciphtertext are encoded as 8-octet
-blocks 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
-
-
-Section 6.3.4. - 79 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-bits, ..., and the eighth octet supplies the 8 least signi-
-ficant bits.
-
- Encryption under DES using cipher block chaining
-requires an additional input in the form of an initializa-
-tion 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 mes-
-sages 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 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.]
-
- To generate a DES key from a text string (password),
-the text string normally must have the realm and each com-
-ponent 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) {
-__________________________
-[37] In some cases, it may be necessary to use a dif-
-ferent "mix-in" string for compatibility reasons; see
-the discussion of padata in section 5.4.2.
-
-
-Section 6.3.4. - 80 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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 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.
-
- An HMAC-SHA1 checksum (described in [18].) is applied
-to the confounder and message sequence (msg-seq) and placed
-in the cksum field.
-
- Plaintext are encoded as 8-octet blocks which are con-
-catenated 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 initializa-
-tion 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-
-
-
-Section 6.3.5. - 81 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-weak" keys; those keys shall not be used for encrypting mes-
-sages 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 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.]
-
- To generate a DES key from a text string (password),
-the text string normally must have the realm and each com-
-ponent 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 specifica-
-tion, that chunk is eXclusive-ORed with the 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) {
-__________________________
-[38] In some cases, it may be necessary to use a dif-
-ferent "mix-in" string for compatibility reasons; see
-the discussion of padata in section 5.4.2.
-
-
-Section 6.3.5. - 82 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- s = string + realm;
- 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 check-
-sum:
-
- Checksum ::= SEQUENCE {
- cksumtype[0] INTEGER,
- checksum[1] OCTET STRING
- }
-
-
-cksumtype This field indicates the algorithm used to gen-
- erate 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 subse-
-quently 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 mes-
-sage. In such cases, the composition of the checksum and
-
-
-Section 6.4. - 83 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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)
-
- The CRC-32 checksum calculates a checksum based on a
-cyclic redundancy check as described in ISO 3309 [15]. 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 proba-
-bilistic chosen-plaintext attack as described in [14] 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 [16]. 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
-__________________________
-[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 per-
-formed using the session key. The constant
-F0F0F0F0F0F0F0F0 was chosen because it maintains key
-parity. The properties of DES precluded the use of the
-complement. The same constant is used for similar pur-
-pose in the Message Integrity Check in the Privacy
-Enhanced Mail standard.
-
-
-Section 6.4.3. - 84 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-"semi-weak keys"; those keys shall not be used for generat-
-ing 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. [17]. 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)
-
- 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 constant F0F0F0F0F0F0F0F0. The initialization vec-
-tor 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 encrypt-
-ing RSA-MD5 checksums for use in Kerberos.
-
- The format for the checksum is described in the follow-
-ing 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
-
-
-Section 6.4.5. - 85 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 constant F0F0F0F0F0F0F0F0. The initializa-
-tion 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 follow-
-ing 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 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
-
-
-Section 6.4.7. - 86 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 vec-
-tor 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 generat-
-ing 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
-
-
-Section 7.1. - 87 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-colon (:) before the 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 organiza-
-tion 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 adminis-
-trator 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 dif-
-ferent). This constraint may be eliminated in the future.
-The following name types are defined:
-
- name-type value meaning
-
-
-Section 7.2. - 88 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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
-
-
-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 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 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 UNK-
-NOWN.
-
- 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
-
-
-Section 7.2.1. - 89 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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
-
-
-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 interpreta-
-tions.
-
- 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 <sys/socket.h> with symbolic names AF_xxx (where xxx is
-an abbreviation of the address family name).
-
-
-Internet addresses
-
- Internet addresses are 32-bit (4-octet) quantities,
-encoded in MSB order. The type of internet addresses is two
-(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).
-
-
-Section 8.1. - 90 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 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 net-
-work 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).
-
-8.2. KDC messages
-
-8.2.1. 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). Servers may also accept
-TCP requests on port 88 (decimal). When the KRB_KDC_REQ
-message is sent to the KDC by TCP, a new connection will be
-established for each authentication exchange and the
-KRB_KDC_REP or KRB_ERROR message will be returned to the
-client on the 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.
-
-8.2.2. 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 mechan-
-ism 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
-
-
-Section 8.2.2. - 91 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-(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.
-
-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
-<reserved> 4
-des3-cbc-md5 5 8 0 8
-<reserved> 6
-des3-cbc-sha1 7 8 0 8
-sign-dsa-generate 8 (pkinit)
-encrypt-rsa-priv 9 (pkinit)
-encrypt-rsa-pub 10 (pkinit)
-ENCTYPE_PK_CROSS 48 (reserved for pkcross)
-<reserved> 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)
-
-
-Section 8.3. - 92 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-padata type padata-type value
-
-PA-TGS-REQ 1
-PA-ENC-TIMESTAMP 2
-PA-PW-SALT 3
-<reserved> 4
-PA-ENC-UNIX-TIME 5
-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)
-
-authorization data type ad-type value
-reserved values 0-63
-OSF-DCE 64
-SESAME 65
-
-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
-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
-
-
-Section 8.3. - 93 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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
-
-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-
-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
-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
-
-
-
-Section 8.3. - 94 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message
-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)
-
-
-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 authentica-
-tion, user to user authentication, support for proxies, for-
-warding, 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 configura-
-tion 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 1
-
- This section defines the first specification of these
-options. Implementations which are configured in this way
-can be said to support Kerberos Version 5 Specification 1
-(5.1).
-
-Encryption and checksum methods
-
-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
-
-
-__________________________
-- 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.
-
-
-
-Section 9.1. - 95 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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 pre-
-authentication 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 deriva-
-tive 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. Indi-
-vidual realms and application servers can set their own pol-
-icy on when such tickets will be accepted.
-
- All implementations must recognize renewable and post-
-dated 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 imple-
-mentations shall make the presence of the postdated flag
-
-
-Section 9.1. - 96 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-visible to the calling server.
-
-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 defin-
-ition 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 authori-
-zation 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 imple-
-mentation, based on the list of suggested configuration con-
-stants (see section 4.4).
-
-minimum lifetime 5 minutes
-
-maximum renewable lifetime1 week
-
-maximum ticket lifetime1 day
-
-empty addresses only when suitable restrictions appear
- in authorization data
-
-proxiable, etc. Allowed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Section 9.2. - 97 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-10. REFERENCES
-
-
-
-1. 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).
-
-2. 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).
-
-3. 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).
-
-4. 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).
-
-5. Dorothy E. Denning and Giovanni Maria Sacco, "Time-
- stamps in Key Distribution Protocols," Communications
- of the ACM, Vol. 24(8), pp. 533-536 (August 1981).
-
-6. 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).
-
-7. 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).
-
-8. Don Davis and Ralph Swick, "Workstation Services and
- Kerberos Authentication at Project Athena," Technical
- Memorandum TM-424, MIT Laboratory for Computer Science
- (February 1990).
-
-9. 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).
-
-10. CCITT, Recommendation X.509: The Directory Authentica-
- tion Framework, December 1988.
-
-11. J. Pato, Using Pre-Authentication to Avoid Password
- Guessing Attacks, Open Software Foundation DCE Request
- for Comments 26 (December 1992).
-
-
-
-Section 10. - 98 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-12. National Bureau of Standards, U.S. Department of Com-
- merce, "Data Encryption Standard," Federal Information
- Processing Standards Publication 46, Washington, DC
- (1977).
-
-13. National Bureau of Standards, U.S. Department of Com-
- merce, "DES Modes of Operation," Federal Information
- Processing Standards Publication 81, Springfield, VA
- (December 1980).
-
-14. 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).
-
-15. 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.
-
-16. R. Rivest, "The MD4 Message Digest Algorithm," RFC
- 1320, MIT Laboratory for Computer Science (April
- 1992).
-
-17. R. Rivest, "The MD5 Message Digest Algorithm," RFC
- 1321, MIT Laboratory for Computer Science (April
- 1992).
-
-18. H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed-
- Hashing for Message Authentication," Working Draft
- draft-ietf-ipsec-hmac-md5-01.txt, (August 1996).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Section 10. - 99 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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
- 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);
-
-
-Section A.2. - 100 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-
- 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 */
- /* 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
-
-
-Section A.2. - 101 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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;
- 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;
-
-
-Section A.2. - 102 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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;
-
- 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);
-
-
-
-Section A.2. - 103 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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
-
- /* 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;
-
-
-Section A.4. - 104 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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
- 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;
-
-
-Section A.5. - 105 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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. */
-
- 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
-
-
-Section A.6. - 106 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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(server)) then
- server := best_intermediate_tgs(server);
- 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 */
-
- 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;
-
-
-Section A.6. - 107 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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
- 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
-
-
-Section A.6. - 108 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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);
- 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,
-
-
-Section A.6. - 109 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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)
- endif
-
- 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;
-
-
-
-Section A.6. - 110 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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;
-
- 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);
-
-
-
-Section A.7. - 111 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-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;
- 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};
-
-
-Section A.10. - 112 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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
- 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
- /* 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 */
-
-
-Section A.11. - 113 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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
- 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;
-
-
-Section A.13. - 114 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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
- 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
-
-
-Section A.15. - 115 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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;
-
-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
-
-
-Section A.17. - 116 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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 */
-
- /* 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
-
-
-Section A.18. - 117 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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);
- 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
-
-
-Section A.20. - 118 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
- 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;
- endif
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- - 119 - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- - cxx - Expires 11 January 1998
-
-
-
-
-
-
-
-
-
-
- Table of Contents
-
-
-
-
-Overview .............................................. 2
-
-Background ............................................ 2
-
-1. Introduction ....................................... 3
-
-1.1. Cross-Realm Operation ............................ 5
-
-1.2. Authorization .................................... 6
-
-1.3. Environmental assumptions ........................ 7
-
-1.4. Glossary of terms ................................ 8
-
-2. Ticket flag uses and requests ...................... 10
-
-2.1. Initial and pre-authenticated tickets ............ 10
-
-2.2. Invalid tickets .................................. 11
-
-2.3. Renewable tickets ................................ 11
-
-2.4. Postdated tickets ................................ 12
-
-2.5. Proxiable and proxy tickets ...................... 12
-
-2.6. Forwardable tickets .............................. 13
-
-2.7. Other KDC options ................................ 14
-
-3. Message Exchanges .................................. 14
-
-3.1. The Authentication Service Exchange .............. 14
-
-3.1.1. Generation of KRB_AS_REQ message ............... 16
-
-3.1.2. Receipt of KRB_AS_REQ message .................. 16
-
-3.1.3. Generation of KRB_AS_REP message ............... 16
-
-3.1.4. Generation of KRB_ERROR message ................ 19
-
-3.1.5. Receipt of KRB_AS_REP message .................. 19
-
-3.1.6. Receipt of KRB_ERROR message ................... 19
-
-3.2. The Client/Server Authentication Exchange ........ 19
-
-3.2.1. The KRB_AP_REQ message ......................... 20
-
-
- - i - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-3.2.2. Generation of a KRB_AP_REQ message ............. 20
-
-3.2.3. Receipt of KRB_AP_REQ message .................. 21
-
-3.2.4. Generation of a KRB_AP_REP message ............. 23
-
-3.2.5. Receipt of KRB_AP_REP message .................. 23
-
-3.2.6. Using the encryption key ....................... 24
-
-3.3. The Ticket-Granting Service (TGS) Exchange ....... 25
-
-3.3.1. Generation of KRB_TGS_REQ message .............. 26
-
-3.3.2. Receipt of KRB_TGS_REQ message ................. 27
-
-3.3.3. Generation of KRB_TGS_REP message .............. 28
-
-3.3.3.1. Checking for revoked tickets ................. 30
-
-3.3.3.2. Encoding the transited field ................. 30
-
-3.3.4. Receipt of KRB_TGS_REP message ................. 32
-
-3.4. The KRB_SAFE Exchange ............................ 32
-
-3.4.1. Generation of a KRB_SAFE message ............... 32
-
-3.4.2. Receipt of KRB_SAFE message .................... 33
-
-3.5. The KRB_PRIV Exchange ............................ 34
-
-3.5.1. Generation of a KRB_PRIV message ............... 34
-
-3.5.2. Receipt of KRB_PRIV message .................... 34
-
-3.6. The KRB_CRED Exchange ............................ 35
-
-3.6.1. Generation of a KRB_CRED message ............... 35
-
-3.6.2. Receipt of KRB_CRED message .................... 35
-
-4. The Kerberos Database .............................. 36
-
-4.1. Database contents ................................ 36
-
-4.2. Additional fields ................................ 37
-
-4.3. Frequently Changing Fields ....................... 38
-
-4.4. Site Constants ................................... 39
-
-5. Message Specifications ............................. 39
-
-
-
- - ii - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-5.1. ASN.1 Distinguished Encoding Representation ...... 39
-
-5.2. ASN.1 Base Definitions ........................... 40
-
-5.3. Tickets and Authenticators ....................... 43
-
-5.3.1. Tickets ........................................ 43
-
-5.3.2. Authenticators ................................. 52
-
-5.4. Specifications for the AS and TGS exchanges ...... 54
-
-5.4.1. KRB_KDC_REQ definition ......................... 54
-
-5.4.2. KRB_KDC_REP definition ......................... 61
-
-5.5. Client/Server (CS) message specifications ........ 64
-
-5.5.1. KRB_AP_REQ definition .......................... 64
-
-5.5.2. KRB_AP_REP definition .......................... 65
-
-5.5.3. Error message reply ............................ 67
-
-5.6. KRB_SAFE message specification ................... 67
-
-5.6.1. KRB_SAFE definition ............................ 67
-
-5.7. KRB_PRIV message specification ................... 68
-
-5.7.1. KRB_PRIV definition ............................ 68
-
-5.8. KRB_CRED message specification ................... 69
-
-5.8.1. KRB_CRED definition ............................ 70
-
-5.9. Error message specification ...................... 72
-
-5.9.1. KRB_ERROR definition ........................... 72
-
-6. Encryption and Checksum Specifications ............. 74
-
-6.1. Encryption Specifications ........................ 76
-
-6.2. Encryption Keys .................................. 78
-
-6.3. Encryption Systems ............................... 78
-
-6.3.1. The NULL Encryption System (null) .............. 78
-
-6.3.2. DES in CBC mode with a CRC-32 checksum (des-
-cbc-crc) .............................................. 79
-
-6.3.3. DES in CBC mode with an MD4 checksum (des-
-
-
- - iii - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-cbc-md4) .............................................. 79
-
-6.3.4. DES in CBC mode with an MD5 checksum (des-
-cbc-md5) .............................................. 79
-
-6.3.5. Triple DES EDE in outer CBC mode with an SHA1
-checksum (des3-cbc-sha1) .............................. 81
-
-6.4. Checksums ........................................ 83
-
-6.4.1. The CRC-32 Checksum (crc32) .................... 84
-
-6.4.2. The RSA MD4 Checksum (rsa-md4) ................. 84
-
-6.4.3. RSA MD4 Cryptographic Checksum Using DES
-(rsa-md4-des) ......................................... 84
-
-6.4.4. The RSA MD5 Checksum (rsa-md5) ................. 85
-
-6.4.5. RSA MD5 Cryptographic Checksum Using DES
-(rsa-md5-des) ......................................... 85
-
-6.4.6. DES cipher-block chained checksum (des-mac)
-
-6.4.7. RSA MD4 Cryptographic Checksum Using DES
-alternative (rsa-md4-des-k) ........................... 86
-
-6.4.8. DES cipher-block chained checksum alternative
-(des-mac-k) ........................................... 87
-
-7. Naming Constraints ................................. 87
-
-7.1. Realm Names ...................................... 87
-
-7.2. Principal Names .................................. 88
-
-7.2.1. Name of server principals ...................... 89
-
-8. Constants and other defined values ................. 90
-
-8.1. Host address types ............................... 90
-
-8.2. KDC messages ..................................... 91
-
-8.2.1. IP transport ................................... 91
-
-8.2.2. OSI transport .................................. 91
-
-8.2.3. Name of the TGS ................................ 92
-
-8.3. Protocol constants and associated values ......... 92
-
-9. Interoperability requirements ...................... 95
-
-
-
- - iv - Expires 11 January 1998
-
-
-
-
-
-
-
- Version 5 - Specification Revision 6
-
-
-9.1. Specification 1 .................................. 95
-
-9.2. Recommended KDC values ........................... 97
-
-10. REFERENCES ........................................ 98
-
-A. Pseudo-code for protocol processing ................ 100
-
-A.1. KRB_AS_REQ generation ............................ 100
-
-A.2. KRB_AS_REQ verification and KRB_AS_REP genera-
-tion .................................................. 100
-
-A.3. KRB_AS_REP verification .......................... 104
-
-A.4. KRB_AS_REP and KRB_TGS_REP common checks ......... 104
-
-A.5. KRB_TGS_REQ generation ........................... 105
-
-A.6. KRB_TGS_REQ verification and KRB_TGS_REP gen-
-eration ............................................... 106
-
-A.7. KRB_TGS_REP verification ......................... 111
-
-A.8. Authenticator generation ......................... 112
-
-A.9. KRB_AP_REQ generation ............................ 112
-
-A.10. KRB_AP_REQ verification ......................... 112
-
-A.11. KRB_AP_REP generation ........................... 113
-
-A.12. KRB_AP_REP verification ......................... 114
-
-A.13. KRB_SAFE generation ............................. 114
-
-A.14. KRB_SAFE verification ........................... 115
-
-A.15. KRB_SAFE and KRB_PRIV common checks ............. 115
-
-A.16. KRB_PRIV generation ............................. 116
-
-A.17. KRB_PRIV verification ........................... 116
-
-A.18. KRB_CRED generation ............................. 117
-
-A.19. KRB_CRED verification ........................... 118
-
-A.20. KRB_ERROR generation ............................ 118
-
-
-
-
-
-
-
- - v - Expires 11 January 1998
-
-
-
-
OpenPOWER on IntegriCloud