Subject: Section 1 Kerberos Revisions for comment

From: Clifford Neuman <[email-masked]>
Date: Wed, 2 Aug 2000 19:27:14 -0700 (PDT)

Below is the preamble and section 1 (introduction) of the Kerberos
revisions.  It is followed by a list of things that have changed in
this section since RFC1510.  I think that there is not much that is
unresolved in this section, though I would like feedback in particular
on section 1.2 which is new.  Please provide feedback on the list
regarding any objections or suggestions for improvement this section.

Clifford Neuman

---

<TITLE>The Kerberos  Network Authentication Service (V5)</TITLE>

<PRE>
INTERNET-DRAFT                                          Clifford Neuman
                                                              John Kohl
                                                          Theodore Ts'o
                                                          July 14, 2000  
                                        <B>Expires January 14, 2001</B>

</B>
</PRE>

<H2>The <A HREF="#tmarks">Kerberos</A> Network Authentication Service (V5)</H2>

<H3>STATUS OF THIS MEMO</H3>

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.  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.

<P>

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."

<P>

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

<P>

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

<P>

To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.ietf.org (US East Coast),
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
munnari.oz.au (Pacific Rim).

<P>

The distribution of this memo is unlimited.  It is filed as
draft-ietf-cat-kerberos-revisions-0-.txt, and expires January 14, 2001.
Please send comments to:

<A HREF="mailto:[email-masked]">[email-masked]</A>

<H3>ABSTRACT</H3>

This document provides an overview and specification of Version 5 of
the Kerberos protocol, and updates RFC1510 to clarify aspects of the
protocol and its intended use that require more detailed or clearer
explanation than was provided in RFC1510.  This document is intended
to provide a detailed description of the protocol, suitable for
implementation, together with descriptions of the appropriate use of
protocol messages and fields within those messages.

<P>

This document is not intended to describe Kerberos to the end user,
system administrator, or application developer.  Higher level papers
describing Version 5 of the Kerberos system [NT94] and documenting
version 4 [SNS88], are available elsewhere.

<H3>OVERVIEW</H3>

This INTERNET-DRAFT describes the concepts and model upon which the
Kerberos network authentication system is based.  It also specifies
Version 5 of the Kerberos protocol.

<P>

The motivations, goals, assumptions, and rationale behind most design
decisions are treated cursorily; they are more fully described in a
paper available in IEEE communications [NT94] and earlier in the Kerberos
portion of the Athena Technical Plan [MNSS87].  The protocols have been a
proposed 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.

<P>

Requests for addition to an electronic mailing list for discussion of
Kerberos, [email-masked], may be addressed to <A
HREF="mailto:[email-masked]">[email-masked]</A>.
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 <A
HREF="mailto:[email-masked]">[email-masked]</A>.

<H3>BACKGROUND</H3>

The Kerberos model is based in part on Needham and Schroeder's trusted
third-party authentication protocol [NS78] and on modifications suggested
by Denning and Sacco [DS81].  The original design and implementation of
Kerberos Versions 1 through 4 was the work of two former Project
Athena staff members, Steve Miller of Digital Equipment Corporation
and Clifford Neuman (now at the Information Sciences Institute of the
University of Southern California), along with Jerome Saltzer,
Technical Director of Project Athena, and Jeffrey Schiller, MIT Campus
Network Manager.  Many other members of Project Athena have also
contributed to the work on Kerberos.

<P>

Version 5 of the Kerberos protocol (described in this document) has
evolved from Version 4 based on new requirements and desires for
features not available in Version 4.  The design of Version 5 of the
Kerberos protocol was led by Clifford Neuman and John Kohl with much
input from the community.  The development of the MIT reference
implementation was led at MIT by John Kohl and Theodore T'so, with
help and contributed code from many others.  Since RFC1510 was issued,
extensions and revisions to the protocol have been proposed by many
individuals.  Some of these proposals are reflected in this document.
Where such changes involved significant effort, the document cites the
contribution of the proposer.

<P>

Reference implementations of both version 4 and version 5 of Kerberos
are publicly available and commercial implementations have been
developed and are widely used.  Details on the differences between
Kerberos Versions 4 and 5 can be found in [KNT92].

<P>

<H3>1. Introduction</H3>

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<A HREF="#fn1">[1]</A>.  Kerberos
performs authentication under these conditions as a trusted
third-party authentication service by using conventional (shared
secret key <A HREF="#fn2">[2]</A> cryptography.  Kerberos extensions
have been proposed and implemented [PKINIT reference as RFC] that
provide for the use of public key cryptography during certain phases
of the authentication protocol.  These extensions provide for
authentication of users registered with public key certification
authorities, and allow the system to provide certain benefits of
public key cryptography in situations where they are needed.

<P>

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 contains the client's identity and a copy of the session key,
all encrypted in the server's key) to the server.  The session key
(now shared by the client and server) is used to authenticate the
client, and may optionally be used to authenticate the server.  It may
also be used to encrypt further communication between the two parties
or to exchange a separate sub-session key to be used to encrypt
further communication.

<P>

Implementation of the basic protocol consists of one or more
authentication servers running on physically secure hosts.  The
authentication servers maintain a database of principals (i.e., users
and servers) and their secret keys.  Code libraries provide encryption
and implement the Kerberos protocol.  In order to add authentication
to its transactions, a typical network application adds one or two
calls to the Kerberos library directly or through the Generic Security
Services Application Programming Interface, GSSAPI, described in
separate document [ref to GSSAPI RFC].  These calls result in the
transmission of the necessary messages to achieve authentication.

<P>

The Kerberos protocol consists of several sub-protocols (or
exchanges).  There are two basic methods by which a client can ask a
Kerberos server for credentials.  In the first approach, the client
sends a cleartext request for a ticket for the desired server to the
AS.  The reply is sent encrypted in the client's secret key.  Usually
this request is for a ticket-granting ticket (TGT) which can later be
used with the ticket-granting server (TGS).  In the second method, the
client sends a request to the TGS.  The client uses the TGT to
authenticate itself to the TGS in the same manner as if it were
contacting any other application server that requires Kerberos
authentication.  The reply is encrypted in the session key from the
TGT.  Though the protocol specification describes the AS and the TGS
as separate servers, they are implemented in practice as different
protocol entry points within a single Kerberos server.

<P>

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.

<P>

To verify the identities of the principals in a transaction, the
client transmits the ticket to the application server.  Since the
ticket is sent "in the clear" (parts of it are encrypted, but this
encryption doesn't thwart replay) and might be intercepted and reused
by an attacker, additional information is sent to prove that the
message originated with the principal to whom the ticket was issued.
This information (called the authenticator) is encrypted in the
session key, and includes a timestamp.  The timestamp proves that the
message was recently generated and is not a replay.  Encrypting the
authenticator in the session key proves that it was generated by a
party possessing the session key.  Since no one except the requesting
principal and the server know the session key (it is never sent over
the network in the clear) this guarantees the identity of the client.

<P>

The integrity of the messages exchanged between principals can also be
guaranteed using the session key (passed in the ticket and contained
in the credentials).  This approach provides detection of both replay
attacks and message stream modification attacks.  It is accomplished
by generating and transmitting a collision-proof checksum (elsewhere
called a hash or digest function) of the client's message, keyed with
the session key.  Privacy and integrity of the messages exchanged
between principals can be secured by encrypting the data to be passed
using the session key contained in the ticket or the sub-session key
found in the authenticator.

<P>

The authentication exchanges mentioned above require read-only access
to the Kerberos database.  Sometimes, however, the entries in the
database must be modified, such as when adding new principals or
changing a principal's key.  This is done using a protocol between a
client and a third Kerberos server, the Kerberos Administration Server
(KADM).  There is also a protocol for maintaining multiple copies of
the Kerberos database.  Neither of these protocols are described in
this document.

<H3>1.1.  Cross-Realm Operation</H3>

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.

<P>

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<A HREF="#fn3">[3]</A>.  The
exchange of inter-realm keys (a separate key may be used for each
direction) registers the ticket-granting service of each realm as a
principal in the other realm.  A client is then able to obtain a
ticket-granting ticket for the remote realm's ticket-granting service
from its local realm.  When that ticket-granting ticket is used, the
remote ticket-granting service uses the inter-realm key (which usually
differs from its own normal TGS key) to decrypt the ticket-granting
ticket, and is thus certain that it was issued by the client's own
TGS.  Tickets issued by the remote ticket-granting service will
indicate to the end-service that the client was authenticated from
another realm.

<P>

A realm is said to communicate with another realm if the two realms
share an inter-realm key, or if the local realm shares an inter-realm
key with an intermediate realm that communicates with the remote
realm.  An authentication path is the sequence of intermediate realms
that are transited in communicating from one realm to another.

<P>

Realms are typically organized hierarchically.  Each realm shares a
key with its parent and a different key with each child.  If an
inter-realm key is not directly shared by two realms, the hierarchical
organization allows an authentication path to be easily constructed.
If a hierarchical organization is not used, it may be necessary to
consult a database in order to construct an authentication path
between realms.

<P>

Although realms are typically hierarchical, intermediate realms may be
bypassed to achieve cross-realm authentication through alternate
authentication paths (these might be established to make communication
between two realms more efficient).  It is important for the
end-service to know which realms were transited when deciding how much
faith to place in the authentication process.  To facilitate this
decision, a field in each ticket contains the names of the realms that
were involved in authenticating the client.

<P>

The application server is ultimately responsible for accepting or
rejecting authentication and should check the transited field.  The
application server may choose to rely on the KDC for the application
server's realm to check the transited field. The application server's
KDC will set the TRANSITED-POLICY-CHECKED flag in this case. The KDC's
for intermediate realms may also check the transited field as they
issue ticket-granting-tickets for other realms, but they are
encouraged not to do so. A client may request that the KDC's not check
the transited field by setting the DISABLE-TRANSITED-CHECK flag. KDC's
are encouraged but not required to honor this flag.

<P>1.2.  Choosing a principal with which to communicate

While the Kerberos protocol provides the means for verifying the
claimed identity of a principal, it is left to the user or application
to determine the name (including realm) of the principal with which it
wishes to communicate.  This determination may be performed in two
ways: it may be performed in advance by the application or it may
optionally be assisted by the KDC through name canonicalization.

<P>

When performed directly by the application, the server principal name
(including realm) is derived from a user specified server name (for
example, the hostname specified in a telnet or ssh command).  The
derivation method might be syntactic, relying on local configuration
files, or it might also utilize a network directory server (in which
case care must be taken to protect this mapping).

<P> 

When utilizing the name canonicalization function provided by the
Kerberos server, the client can make a request providing just the
service principal name (which may be one of several used by a service)
and requesting name canonicalization from the Kerberos server. The
Kerberos server will attempt to locate a service principal in its
database that best matches the request principal or provide a referral
to another Kerberos realm that may be contain the requested service
principal.

<H3>1.3.  Authorization</H3>

As an authentication service, Kerberos provides a means of verifying
the identity of principals on a network.  Authentication is usually
useful primarily as a first step in the process of authorization,
determining whether a client may use a service, which objects the
client is allowed to access, and the type of access allowed for each.
Kerberos does not, by itself, provide authorization.  Possession of a
client ticket for a service provides only for authentication of the
client to that service, and in the absence of a separate authorization
procedure, it should not be considered by an application as
authorizing the use of that service.

<P>

Such separate authorization methods may be implemented as application
specific access control functions and may utilize  files on
the application server, or on separately issued authorization
credentials such as those based on proxies [Neu93], or on other
authorization services.  Separately authenticated authorization
credentials may be embedded in a tickets authorization data when
encapsulated by the kdc-issued authorization data element.

<P>

Applications should not be modified to accept the mere issuance of a
service ticket by the Kerberos server (even by a modified Kerberos
server) as granting authority to use the service, since such
applications may become vulnerable to the bypass of this authorization
check in an environment if they interoperate with other KDCs or where
other options for application authentication (e.g. the PKTAPP
proposal) are provided.

<H3>1.4.  Environmental assumptions</H3>

Kerberos imposes a few assumptions on the environment in which it can
properly function:

<UL>
<LI>'Denial of service' attacks are not solved with Kerberos.  There
are places in the 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.

<LI>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.

<LI>'Password guessing' attacks are not solved by Kerberos.  If a user
chooses a poor password, it is possible for an attacker to
successfully mount an offline dictionary attack by repeatedly
attempting to decrypt, with successive entries from a dictionary,
messages obtained which are encrypted under a key derived from the
user's password.

<LI>Each host on the network must have a clock which is 'loosely
synchronized' to the time of the other hosts; this synchronization is
used to reduce the bookkeeping needs of application servers when they
do replay detection.  The degree of "looseness" can be configured on a
per-server basis, but is typically on the order of 5 minutes.  If the
clocks are synchronized over the network, the clock synchronization
protocol must itself be secured from network attackers.

<LI>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.

</UL>

<h3>1.5.  Glossary of terms</H3>

Below is a list of terms used throughout this document.

<DL>

<DT>Authentication <DD>Verifying the claimed identity of a principal.

<DT>Authentication header <DD>A record containing a Ticket and an
Authenticator to be presented to a server as part of the
authentication process.

<DT>Authentication path <DD>A sequence of intermediate realms
transited in the authentication process when communicating from one
realm to another.

<DT>Authenticator <DD>A record containing information that can be
shown to have been recently generated using the session key known only
by the client and server.

<DT>Authorization  <DD>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.

<DT>Capability <DD>A token that grants the bearer permission to access
an object or service.  In Kerberos, this might be a ticket whose use
is restricted by the contents of the authorization data field, but
which lists no network addresses, together with the session key
necessary to use the ticket.

<DT>Ciphertext <DD>The output of an encryption function.  Encryption
transforms plaintext into ciphertext.

<DT>Client <DD>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).

<DT>Credentials <DD>A ticket plus the secret session key necessary to
successfully use that ticket in an authentication exchange.

<DT>KDC <DD>Key Distribution Center, a network service that supplies tickets
and temporary session keys; or an instance of that service or the host
on which it runs.  The KDC services both initial ticket and
ticket-granting ticket requests.  The initial ticket portion is
sometimes referred to as the Authentication Server (or service).  The
ticket-granting ticket portion is sometimes referred to as the
ticket-granting server (or service).

<DT>Kerberos <DD>Aside from the 3-headed dog guarding Hades, the name
given to Project Athena's authentication service, the protocol used by
that service, or the code used to implement the authentication
service.

<DT>Plaintext <DD>The input to an encryption function or the output of
a decryption function.  Decryption transforms ciphertext into
plaintext.

<DT>Principal <DD>A uniquely named client or server instance that
participates in a network communication.

<DT>Principal identifier <DD>The name used to uniquely identify each
different principal.

<DT>Seal <DD>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.

<DT>Secret key <DD>An encryption key shared by a principal and the
KDC, distributed outside the bounds of the system, with a long
lifetime.  In the case of a human user's principal, the secret key may 
be derived from a password.

<DT>Server <DD>A particular Principal which provides a resource to
network clients.  The server is sometimes referred to as the
Application Server.

<DT>Service <DD>A resource provided to network clients; often provided
by more than one server (for example, remote file service).

<DT>Session key <DD>A temporary encryption key used between two
principals, with a lifetime limited to the duration of a single login
"session".

<DT>Sub-session key <DD>A temporary encryption key used between two
principals, selected and exchanged by the principals using the session
key, and with a lifetime limited to the duration of a single
association.

<DT>Ticket <DD>A record that helps a client authenticate itself to a
server; it contains the client's identity, a session key, a timestamp,
and other information, all sealed using the server's secret key.  It
only serves to authenticate a client when presented along with a fresh
Authenticator.

</DL>

-----

Commentary:

Section 1: The preamble and introduction does not define the protocol,
mention is made in the introduction regarding the ability to rely on
the KDC to check the transited field, and on the inclusion of a flag
in a ticket indicating that this check has occurred.  This is a new
capability not present in RFC1510.  Pre-existing implementation may
ignore or not set this flag without negative security implications.

The definition of the secret key says that in the case of a user the
key may be derived from a password.  In 1510, it said that the key was
derived from the password.  This change was made to accommodate
situations where the user key might be stored on a smart-card, or
otherwise obtained independent of a password.

The introduction also mentions the use of public key for initial
authentication in Kerberos by reference.  RFC1510 did not include such
a reference.

Section 1.2 was added to explain that while Kerberos provides
authentication of a named principal, it is still the responsibility of
the application to ensure that the authenticated name is the entity
with which the application wishes to communicate.  Because section 1.2
is completely new, I am particularly interested in suggestions to
improve the wording of this section.  Sections 1.2-4 were renumbered.

---

From: Sam Hartman <[email-masked]>
Date: 03 Aug 2000 09:48:34 -0400

In section 1.2, you have the following text:

<P> 

This implies that I could use the Kerberos database as a service
directory, asking for the fileserver simply by asking fdor the
fileserver principal and then decomposing the result to get a name.
The Kerberos protocol should not be in the business of service
location.  SLP or SRV records or numerous other protocols  in the IETF already do a better job of this task.