% This is a LaTeX document.  The files preamble.tex, intro.tex, and
% references.tex must also be in this directory.
% The command "latex user" should be used to process the document
% in this directory.

%\input{preamble}
% article style
%\documentstyle[twocolumn,titlepage]{article}		% two column
\documentstyle[11pt,titlepage]{article}			% one column
% page headings include section name and page number
\pagestyle{headings}

%% The following set of commands should give a 1.25in top and bottom
%% margin and a 0.75in left and right margin.
% 1.25in top margin
\topmargin 0.25in
%\textheight 8in					% two column
\textheight 8.5in				% one column
% 0.75in left margin
%\oddsidemargin -0.25in \evensidemargin -0.25in	% two column
\oddsidemargin 0in \evensidemargin 0in		% one column
%\textwidth 6.875in				% two column
\textwidth 6.375in				% one column

% no paragraph indentation and skip a line between paragraphs
\parindent 0in
\parskip \bigskipamount

%% Define some macros for highlighting text in a consistent manner.
\newcommand{\idea}[1]{\mbox{\em #1}}
\newcommand{\id}[1]{\mbox{\it #1}}
\newcommand{\key}[1]{\mbox{\bf{#1}}}
\newcommand{\lit}[1]{{\tt #1}}
\newcommand{\q}[1]{``#1''}
\newcommand{\qt}[1]{\q{\lit{#1}}}
\newcommand{\home}[1]{\mbox{\lit{\~{\ }\hspace{-0.5em}/#1}}}

\newcommand{\Kerberos}{$K\epsilon\rho\beta\epsilon\rho o\varsigma$}

\title{Living with Your Three-Headed Dog}
\author{Document Number IAG-90-012 \\ \\ \\ \\
Tai Jin \\ tai@IAG.HP.COM}
\date{May 22, 1990}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\maketitle

\begin{verse}
This is about a dog from hell \\
Guarding the gates he does well. \\
Kerberos is his name \\
Security is his game. \\
In many directions can he see \\
For the number of heads, he has three!

You cannot run away \\
For he will keep you at bay. \\
Try not to put up a fight \\
For he has a deadly bite! \\
I tell you he is second to none \\
For three heads are better than one!
\end{verse}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Introduction}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Now that you have inherited a three-headed dog, is it safe to keep him
in the house?  He must be a good guard dog.

%\input{intro}
In a distributed computing environment, the network poses new problems
for security.  \key{Kerberos} is one system which provides the
necessary protection for users and services in this kind of
environment.  The goal at the Information Architecture Group (IAG) is
to incorporate Kerberos\footnote{We will use whatever security system
that the standards bodies embrace.  Currently, Kerberos is the only
one that is already implemented and is widely available, and it has
been selected by the OSF.  It currently uses the \key{DES} symmetric
cryptosystem.  However, the next version of Kerberos will be able to
support different types of cryptosystems.  ISO has defined X.509, and
they are considering the use of a public key cryptosystem (such as
\key{RSA}) in the implementation.} as an integral part of our
computing environment.  This is an on-going process since new commands
and services will have to be
\idea{Kerberized}.

The Kerberos environment described in this document has been modified
from the original MIT distribution.  The intent has been to improve
the ease of use and administration.  Some changes were also made to
eliminate the need for creating context dependent files on diskless
systems.

This document describes the end user aspect of Kerberos.  Some
Kerberos terminology is introduced, but no effort has been made to
describe the technical details of the Kerberos design---references
\cite{usenix} and \cite{techplan} can provide you with all the
technical details and explanations.  I would recommend that you at
least read \cite{dialogue} for an entertaining look at the issues
involved in designing such a system.
% You may also want to read
% \cite{tai:develop} if you are interested in Kerberizing any
% applications.
Those aspiring to be Kerberos administrators can also
read \cite{tai:admin}.

This document contains two major sections.  The first section is an
introduction to what Kerberos is, and the second section describes how
to live with Kerberos.  The appendix contains a summary, a list of
files and their descriptions, and some user examples.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{What Is Kerberos?}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%\begin{quote}
%\Kerberos; also spelled {\it Cerberus}.  {\it \q{n. The watch dog of
%Hades, whose duty it was to guard the entrance---against whom or what
%does not clearly appear;\ldots is known to have had three
%heads\ldots}}
%
%\flushright ---Ambrose Bierce, {\it The Enlarged Devil's
%Dictionary}\footnote{This quote appeared in \cite{techplan}.}
%\end{quote}

Kerberos is an authentication system for distributed environments.  An
authentication system provides the means by which a user's or other
agent's claimed identity can be verified (ie. \idea{you are who you
say you are}).  This should not be confused with authorization, which
is the access given by a service to an authenticated client.  The
authentication mechanism is somewhat complex, and passwords and
encryption are at the very heart of the scheme.  However, the weakest
link in the system is the password---in this sense, Kerberos is no
more secure than existing password schemes.  But assuming that the
password is not compromised then Kerberos does provide the extra
security needed in a distributed environment.\footnote{There are other
security issues---for example, if the real server for a realm is
faked.  To prevent this from happening, the name service must also be
secured.  This is in addition to keeping the Kerberos configuration
files secure.}

How does a user authenticate herself to a service on another host?
Kerberos authentication is applicable within a \idea{realm}.  A user
is is therefore authenticated for the entire realm and not just for
one host.  This is managed by a central Kerberos database for the
realm.  Each host is an \idea{instance} within the realm, and they
provide instances of common services.  A user (or service) identifies
herself with a \idea{principal}.  The \{\idea{principal,password}\}
pair is used to obtain a \idea{ticket}, which is the token of
authentication.

The following sections describe the principals and the tickets that
you will be using.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Principal Identifiers}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

A principal identifier is the name which identifies a user or service
to Kerberos.  A fully-qualified principal name, as it is often called,
has three parts, the \idea{principal} name, the \idea{instance}
name, the \idea{realm} name, and has the following format:
\begin{center}
\idea{principal.instance@realm}
\end{center}
There are two kinds of principal identifiers: users and services.  In
the case of a user, the principal is typically the username, the
instance is typically null, and the realm is typically the local
Internet domain (in upper-case).  For example, user \key{tai} in the
Internet domain \key{IAG.HP.COM} would have \key{tai@IAG.HP.COM} as
his principal identifier.  Note that this principal identifier has no
instance.  An instance may be defined in special cases.  One such case
is where a user has the superuser capability.  In this case, the
principal identifier would be \key{tai.root@IAG.HP.COM}.  A user may
have multiple instances as in the case here, where there is a null
instance and a \key{root} instance.

Your principal identifier is used in place of your username when using
Kerberized services.  Typically, it is only necessary to specify the
principal name alone, or the \idea{principal.instance} pair (if a
particular instance is being used) when asked for a principal
identifier.  The use of the principal identifier is transparent to
most users since their principal name will be the same as their
username.\footnote{This is not strictly necessary and is not enforced
other than by the sanity of the administrator.}

In the case of a service principal identifier, the principal is the
name of the service, the instance is the name of the host on which the
service is provided, and the realm is typically the local Internet
domain name (in upper-case, the same as it is for a user).  Since
there most likely will be more than one host providing a Kerberized
service, there will be many instances of the same service---one for
each host.  For example, the \key{rcmd} remote command service on the
hosts \key{aspen.iag.hp.com} and \key{kenzo.iag.hp.com} will have the
principal identifiers \key{rcmd.aspen.iag.hp.com@IAG.HP.COM} and
\key{rcmd.kenzo.iag.hp.com@IAG.HP.COM}, respectively.\footnote{The
software expects the instance name to be the full domain name.}

The word \idea{principal} will be used throughout the remainder of
this document to mean either the principal identifier (ie.
fully-qualified principal name) or just the principal name depending
on the context.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Tickets}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

A Kerberos ticket is much like a ticket you would buy for an event in
real life.  Only after you have purchased your ticket can you attend
the event.  In much the same way, you must \q{purchase} a Kerberos
ticket in order to gain access to a particular service.  There is one
ticket which is special---it is the ticket by which you can obtain
other tickets.  Without this special \idea{ticket-granting ticket} you
cannot obtain any other tickets.

The ticket-granting ticket is given to you only when you have
successfully authenticated yourself to Kerberos---the authentication
procedure requires that you type in your Kerberos password.  This is
the first ticket you will get since you need this ticket to get
tickets for other services.  The ticket-granting ticket is issued on a
per-host basis---the host on which you obtain your ticket is the only
host on which the ticket can be used.

The ticket-granting ticket has a non-null instance which is the local
realm name.  There may be other ticket-granting tickets with other
realm names for their instances if inter-realm authentication has been
configured with other realms.

The other tickets are issued on a per-service basis.  A ticket is
valid only for the instance of the service for which it is issued---a
ticket for \key{rcmd.aspen.iag.hp.com} can be used only for the
\key{rcmd} service on \key{aspen.iag.hp.com}.

All tickets have a lifetime after which they expire and cannot be
used, and typically, the service tickets have a shorter lifetime than
the ticket-granting ticket.  You can always get a new ticket at any
time with the \id{kinit} command.

One thing that you should remember is that a ticket is semantically
independent of your UNIX user id.  As you will see, a non-superuser
can get a \key{root} instance ticket which would effectively enable
the user to access superuser capabilities through Kerberized services.
The user's current UNIX id does not change.

In the this implementation, your Kerberos tickets are stored in a
temporary file.  You can have multiple ticket files, but only one is
active at any given time.  A UNIX environment variable is used to
specify the ticket file to use.

The word \idea{ticket} will be used throughout the remainder of this
document to mean either the ticket-granting ticket or a service
ticket depending on the context.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Living with Kerberos}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Getting Started}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

As a first-time user you must either register yourself with Kerberos
or get your systems administrator to do it for you.  Then you must get
a ticket before you can start using any Kerberized service.  By
registering with Kerberos, you will have a principal assigned to you.

The \id{kaddme} command is used to add yourself to the Kerberos
database.  You must supply your UNIX login password to validate that
you are a valid user on the system.  Your UNIX password will also be
your Kerberos password.  The command will register you in the Kerberos
database, and your principal will be the same as your username.  If
you have problems with this procedure then you should ask your systems
administrator to create a Kerberos principal for you.

Before you can start using any of the Kerberized services you must get
a ticket-granting ticket.  The command,
\begin{center}
\lit{kinit}
\end{center}
will give you a new ticket-granting ticket in exchange for typing in
your Kerberos password.  The ticket is cached in the file
\lit{/tmp/tkt\idea{uid.host}}, but you can change this by specifying an
alternate file name in the \key{KRBTKFILE} environment varaible.  This
variable also overrides the default ticket file name for all
Kerberized services.  The ticket has a default lifetime of twenty-one
hours.\footnote{This is the maximum ticket lifetime in the current
version of Kerberos.} When the ticket expires, or if the ticket file
is removed, then you will have to get a new ticket again.  It does not
hurt to get a new ticket at any time before your current ticket
expires, as it essentially renews your ticket.

Although the \id{kinit} command is the primary means of getting a new
ticket, it is not the only way.  The \id{xlogin} and \id{x11lock}
programs have also been Kerberized and named \id{kxlogin} and
\id{kx11lock}, respectively.  What this means is that whenever you log
in through \id{kxlogin}, and whenever you unlock your screen with
\id{kx11lock} you will get a new ticket-granting ticket.  The idea of
Kerberizing such programs is to get a new ticket whenever you have to
type your password, so that you don't normally have to run the
\id{kinit} program.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Using Berkeley Commands}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Kerberos is good for authenticating users and services when no
passwords are involved in using the service.  Therefore, the \id{rcp},
\id{rlogin}, and \id{remsh} commands lend themselves well to Kerberos
authentication.  Instead of relying on host names and addresses for
authentication we authenticate with Kerberos.

The Kerberized versions of these commands are \id{krlogin}, \id{krcp},
and \id{kremsh}.  The options and arguments of the Kerberized commands
are the same as those of the original commands with the addition of a
few Kerberos-specific options.  For example, both \id{krlogin} and
\id{krcp} have an additional \qt{-x} option which when used encrypts
the session.  You would use these Kerberized commands in the same way
you would use the original commands.  The only differences are that
you must already have a ticket-granting ticket, and the system
providing the service is more confident that you are indeed the user
you claim to be and you know that the server is indeed the one that
you think it is.

Analogous to the \home{.rhosts} file is the Kerberos equivalent
\home{.klogin}.  The \home{.klogin} file lists the principals who are
allowed to use your account on the local system without having to
enter your password.  It should contain one principal identifier per
line; wildcards are not allowed.  If you have more than one instance
(eg. a null and a \key{root} instance) then you should create this
file and list all instances of your principal identifier.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Superusers and Kerberos}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

By convention, any user who can become the superuser should have a
principal with a \key{root} instance in addition to the normal
principal with a null instance.  The \key{root} instance is used when
you want to become the superuser.

Analogous to the \lit{/.rhosts} file is the Kerberos equivalent
\lit{/.klogin}.  There is no Kerberos equivalent for the
\lit{/etc/hosts.equiv} file.  The \lit{/.klogin} file lists the
principals who are allowed to become the superuser on the system.  It
should contain one principal identifier per line:
\begin{center}
\idea{principal}\lit{.root@}\idea{realm}
\end{center}
The instance should always be \key{root} unless you want to allow
non-superusers to become superuser on the system.  The \id{krlogin},
\id{kremsh} and \id{krcp} services and the \id{ksu2} command all use
this file.

The \id{ksu2} command is the Kerberized version of \id{su2}, a program
which allows you to become the superuser.  The only difference between
the two is that \id{ksu2} will prompt you for your Kerberos password
(or your \key{root} instance password if you are becoming the
superuser).  The default ticket lifetime when becoming the superuser
is two hours.  When you use \id{kinit} to renew your \key{root}
instance ticket, the default ticket lifetime will also be two hours.

Remember that your Kerberos principal is not the same as your UNIX
username.  That is, as a normal user, you can use \id{kinit} to get a
ticket for any principal for which you know the password.  For
example, you can say,
\begin{center}
\lit{kinit \idea{your\_principal}.root}
\end{center}
if you have a \key{root} instance.  This does not change your UNIX
user id---you have not become the superuser.  However, as far as
Kerberos and the Kerberized services are concerned, you have become
the superuser.  The same is true when you are the superuser and you
get a ticket for a non-\key{root} instance---UNIX doesn't know the
difference but Kerberos does.  This is the difference between
authentication (what Kerberos provides) and authorization (what UNIX
provides).  Without Kerberos, UNIX is providing both the
authentication and the authorization, and if you used the \key{su}
command to change your user id you are authenticating yourself to UNIX
as the new user and UNIX is also authorizing you to become that user.
So most people think of authentication and authorization as one and
the same, whereas they are truly different and separable as you can
see with Kerberos.

If you do not change the default ticket file name by setting the
\key{KRBTKFILE} environment variable then each time you get a new
ticket the old ticket is replaced with the new ticket.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Changing Your Password}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The \id{kadmin} command is used to change your Kerberos password.  Use
the \key{passwd} command within \id{kadmin} to change your password.
Specify your principal name as an argument, and you will be prompted
for the password of the specified principal.  If the password is
correct then you are prompted for the new password.  The \key{quit}
command will get you out of the \id{kadmin} program.  If you have
forgotten your Kerberos password then you can ask your systems
administrator to change it for you.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Getting a Ticket from a Cron Job}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

If you have a \id{cron} job which requires the use of a Kerberized
service then your batch job must be able to get a Kerberos ticket.  As
you have seen for a user you must type in your password, but this is
not acceptable for a batch job.  So the \id{ksrvtgt} program can be
used to get your key from a \lit{srvtab} file.  The permissions on the
\lit{srvtab} file may allow only the superuser or the owner of the file
to access the key in the file.

Since the \lit{/usr/local/etc/srvtab} file is only readable by the
superuser and is only intended for use by standard services such as
\key{rcmd} the keys you will need to use for Kerberized services are
kept in your own \lit{srvtab} file (eg. \home{.srvtab}).  Your
\lit{srvtab} file should be readable only by you.  The \id{ksrvtgt}
and \id{ksrvutil} programs allow you to specify the \lit{srvtab} file
to use so that you can specify your own file.

Here are the instructions for setting up your \lit{srvtab} file and
getting a ticket-granting ticket from a \id{cron} job:

\begin{enumerate}
\item \lit{ksrvutil -f \idea{srvtab} add}

This command will add a key to the file \idea{srvtab}.  You will be
prompted for various information:

\begin{itemize}
\item \lit{Name: \idea{principal}}

Enter you principal name.

\item \lit{Instance: <cr>}

Just press return to specify a null instance, otherwise specify the
instance.  If your cron job is to invoke a Kerberized service as
superuser then the instance should be \key{root}.  The
principal.instance must already be registered in the Kerberos
database.

\item \lit{Realm: <cr>}

Just press return to specify the local realm, otherwise specify the
realm name.

\item \lit{Version number: <cr>}

Just press return.

\item \lit{New principal: \idea{principal}@\idea{realm}; version 0 \\
Is this correct? (y,n) [y] <cr>}

Just press return to confirm.

\item \lit{Password: <password> \\
Verifying, please re-enter Password: <password> \\
Key successfully added.}

Enter the password for the principal.instance entered above.  The
password is not echoed.

\item \lit{Would you like to add another key? (y,n) [y] \idea{n}}

Just enter \qt{n} to exit.
\end{itemize}

You may add as many keys to your \lit{srvtab} file as you want.

\item In your \id{cron} job before invoking a Kerberized service,
execute:

\lit{ksrvtgt \idea{principal} "" \idea{srvtab}}

(the quotes specify a null instance) or if you have a specific
instance:

\lit{ksrvtgt \idea{principal} \idea{instance} \idea{srvtab}}

to get your ticket-granting ticket using the key for
\idea{principal}.\idea{instance} from the file \idea{srvtab} (this
is equivalent to executing the \id{kinit} command).  The ticket
lifetime is only five minutes.  So it is a good idea to execute this
command before each invocation of a Kerberized service.

\item At the end of your \id{cron} job, execute:

\lit{kdestroy}

to delete your ticket file.
\end{enumerate}

You can also use the \id{ksrvutil} program to list the tickets in your
\lit{srvtab} file.  You cannot delete tickets from your \lit{srvtab}
file---you have to delete the file.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Inter-realm Authentication}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Since your principal only identifies you within your realm, how do you
use services in other realms?  The answer is inter-realm
authentication.  If the administrators of two realms collaborate to
set up authentication between the two realms then you can authenticate
yourself in the other realm and everything is almost transparent.
This assumes that the administrator for your realm has listed a server
for the other realm in the \lit{krb.conf} file.

For example, if you are registered in the \key{IAG.HP.COM} realm and
you want to login to a host in the \key{SDE.HP.COM} realm then all is
transparent:
\begin{verbatim}
krlogin hpfcbig.sde.hp.com
\end{verbatim}
This assumes that you have a \home{.klogin} file on the remote host
which lists your principal identifier.  For example, the following
entries in your \home{.klogin} file,
\begin{verbatim}
tai@IAG.HP.COM
tai.root@IAG.HP.COM
\end{verbatim}
gives access to the user \key{tai} in the \key{IAG.HP.COM} realm.
Without this file or the appropriate entries in this file, any of the
\key{rcmd} services would either ask you for your UNIX password on the
remote system or deny you access to the service.  The \home{.klogin}
file is necessary to associate your UNIX account with your Kerberos
principal when the account is not in your realm.

Now consider the case where the remote host is in the \key{sde.hp.com}
domain but where the realm name is \key{SDE-FC.HP.COM}.  The previous
example worked because the realm name matches the Internet domain.  In
this example, however, the names are different, and this means that
you will also have to specify the domain name if you want to login to
the remote host:
\begin{verbatim}
krlogin hpfcbig.sde.hp.com -k SDE-FC.HP.COM
\end{verbatim}
You can avoid having to remember such details as the realm a
particular host is in if your systems administrator properly
configures the \lit{krb.realms} file.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\input{references}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{thebibliography}{99}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\bibitem{tai:user} Tai Jin.  \q{Living with Your Three-Headed Dog}.  HP
Internal Document (April 1990).

\bibitem{tai:admin} Tai Jin.  \q{Caring and Feeding of Your
Three-Headed Dog}.  HP Internal Document (April 1990).

%\bibitem{tai:develop} Tai Jin.  \q{Teaching Your Three-Headed Dog New
%Tricks}.  HP Internal Document (to be written?).

\bibitem{techplan} S. P. Miller, B. C. Newman, J. I. Schiller, J. H.
Saltzer.  Section E.2.1: Kerberos Authentication and Authorization
System, MIT Project Athena Technical Plan (December 1987).

\bibitem{usenix} J. G. Steiner, B. C. Neuman, J. I. Schiller.
\q{Kerberos: An Authentication Service for Open Network Systems}.
Usenix Conference Proceedings (March 1988).

\bibitem{dialogue} B. Bryant.  \q{Designing an Authentication System: a
Dialogue in Four Scenes}.  MIT Project Athena (February 1988).
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{thebibliography}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%\onecolumn					% two column
\appendix

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{User Summary}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The visible impact of Kerberos on the user is very minimal and only in
rare cases is it noticeable.  Just keep in mind the following simple
rules:

\begin{itemize}
\item You need a valid ticket before you can do anything.  The
\id{kinit} command or other programs, such as \id{ksrvtgt},
\id{kx11lock}, and \id{kxlogin}, can give you a ticket-granting ticket.

\item Once you have your ticket, everything is almost transparent.
The only time that you will notice a difference is in inter-realm
activity.  If the configuration files have not been fully configured
then you may have to specify the realm of the Kerberized service.

\item Remember that your UNIX username and password are distinct from
your Kerberos principal and password, but they should be kept the same
to avoid confusion.

\item You must obtain a ticket on each host from which you wish to use
Kerberized services.  For example, if you \id{krlogin} to another host
then you must first get a ticket (eg. by running \id{kinit}) on the
remote host before you can \id{krlogin} from that host.

\item UNIX \id{cron} scripts which need to use Kerberized services
must also get tickets.  The program \id{ksrvtgt} can be used for this
purpose.
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{File Descriptions}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Here are the descriptions of the programs and files that are relevant
to the user.
\begin{list}{}{\itemindent 0in \labelsep 0.25in
\listparindent 0in \itemsep \medskipamount
\setlength{\labelwidth}{2in} \setlength{\leftmargin}{2.25in}
\setlength{\rightmargin}{0in}}
\item[/usr/local/etc/krb.conf\hfill]
Kerberos server configuration file.  Lists realms and servers.  Your
systems administrator should configure this file.

\item[/usr/local/etc/krb.realms\hfill]
Realm translation file.  Translates host names and Internet domain to
realms.  Your systems administrator should configure this file when
inter-realm authentication configured.

\item[/.klogin\hfill]
This file is needed for \id{krcp}, \id{kremsh}, \id{krlogin} to work
with the \key{root} instance of a user.  This is essentially a
\home{.rhosts} file for all \key{root} instance users.  You also
need this file if you use \id{ksu2} to become the superuser.

\item[\~{\ }\hspace{-0.5em}/.klogin\hfill]
This file is needed to give your UNIX account access to users and
other instances of yourself.  For example, this is needed in the case
of inter-realm authentication.

\item[/usr/local/bin/kaddme\hfill]
This program allows you to add yourself to the Kerberos database.
This program must be run on the Kerberos master server (if it is run
on another system, it will tell you what system to run it on).

\item[/usr/local/bin/kdestroy\hfill]
Destroy your tickets.  This program removes your ticket file.  The
\key{KRBTKFILE} environment variable can override the default ticket
file name.

\item[/usr/local/bin/kinit\hfill]
Obtain a ticket-granting ticket.  Your tickets are cached in a
temporary file.  The default ticket lifetime is twenty-one hours; a
\key{root} instance ticket has a default lifetime of two hours.  The
\key{KRBTKFILE} environment variable can override the default ticket
file name.

\item[/usr/local/bin/klist\hfill]
List your tickets.  The \key{KRBTKFILE} environment variable can
override the default ticket file name.

\item[/usr/local/bin/kadmin\hfill]
Kerberos administrative utility.  This program allows you to change
your Kerberos password.

\item[/usr/local/bin/krcp\hfill]
Kerberized version of \id{rcp}.  Use \qt{-x} to encrypt the session.
The \key{KRBTKFILE} environment variable can override the default ticket
file name.

\item[/usr/local/bin/kremsh\hfill]
Kerberized version of \id{remsh}.  The
\key{KRBTKFILE} environment variable can override the default ticket
file name.  \id{kremsh} does not have a \qt{-x} option.

\item[/usr/local/bin/krlogin\hfill]
Kerberized version of \id{rlogin}.  Use \qt{-x} to encrypt the session.
The \key{KRBTKFILE} environment variable can override the default ticket
file name.

\item[/usr/local/etc/ksrvtgt\hfill]
Get a ticket from the \lit{/usr/local/etc/srvtab} service file or from
another \lit{srvtab} file.  This program is typically used by \id{cron}
jobs to get a ticket-granting ticket.

\item[/usr/local/bin/ksu2\hfill]
Kerberized version of \id{su2}.  You must have a \key{root} instance
to use this program to become the superuser.  Your \key{root} instance
principal identifier must also be listed in the \lit{/.klogin} file.
The ticket has a lifetime of two hours.  When you exit from the
superuser shell your \key{root} instance tickets will be destroyed.
The configuration file \lit{/usr/local/lib/super-users} is used by
\id{ksu2} to control who can become the superuser.

\item[/usr/local/bin/kx11lock\hfill]
Kerberized version of \id{x11lock}.  The only difference between this
program and the non-Kerberized version is that the password you
provide will be used to obtain a new ticket.  The \key{KRBTKFILE}
environment variable can override the default ticket file name.

\item[/usr/local/bin/kxlogin\hfill]
Kerberized version of \id{xlogin}.  The only difference between this
program and the non-Kerberized version is that the password you
provide will be used to obtain a new ticket.

\item[/usr/local/etc/srvtab\hfill]
This file contains the service keys for a particular system.  A user's
\id{cron} job may use the \id{ksrvtgt} program to get a ticket from
the user's own \lit{srvtab} file.  All \lit{srvtab} files must be
protected with UNIX mode 400.
\end{list}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{User Examples}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The following sequence of events illustrates several scenarios that a
user may encounter when using Kerberos.

\begin{verbatim}
aspen% klist
Ticket file:	/tmp/tkt754.aspen
Principal:	tai@IAG.HP.COM

  Issued           Expires          Principal
Jan 10 14:10:18  Jan 11 11:25:18  krbtgt.IAG.HP.COM@IAG.HP.COM
Jan 10 14:10:27  Jan 10 22:10:27  rcmd.telford.iag.hp.com@IAG.HP.COM
aspen% date
Fri Jan 12 12:50:11 PST 1990
\end{verbatim}

Each ticket has its own expiration date.  This means that if a service
ticket has not yet expired, it can still be used even if the
ticket-granting ticket has expired.  Remember, the ticket-granting
ticket is only used to get new tickets.  Well, it looks like my
tickets have expired.  Let me try \id{kremsh} anyway to see what
happens.

\begin{verbatim}
aspen% kremsh kenzo who
kremsh: Kerberos rcmd failed: Ticket expired (krb_rd_req).
kremsh: You can obtain a new ticket by running the kinit command.
\end{verbatim}

Well, as you can see, the \id{kremsh} failed because my ticket had
expired.  So now I will have to run the \id{kinit} command to get a
new ticket-granting ticket.

\begin{verbatim}
aspen% kinit
Hewlett-Packard (aspen.iag.hp.com)
Kerberos Initialization for "tai"
Ticket lifetime is 21.2 hours
Password: <password>
aspen% klist
Ticket file:	/tmp/tkt754.aspen
Principal:	tai@IAG.HP.COM

  Issued           Expires          Principal
Jan 12 12:59:29  Jan 13 10:14:29  krbtgt.IAG.HP.COM@IAG.HP.COM
aspen% kremsh telford finger
Login       Name              TTY Idle    When    Where
tai      Tai Jin               p1   38 Mon 10:15  vertigo.iag.hp.c
laubach  Mark Laubach          s1   1d Thu 09:16  isenbard.iag.hp.
huck     Jerry Huck            s2  20: Thu 15:58  aspen.iag.hp.com
kincl    Norm Kincl            p2  19: Thu 17:03  wren.iag.hp.com:
kincl    Norm Kincl            p3 2:21 Fri 10:33  wren.iag.hp.com:
aspen% klist
Ticket file:	/tmp/tkt754.aspen
Principal:	tai@IAG.HP.COM

  Issued           Expires          Principal
Jan 12 12:59:29  Jan 13 10:14:29  krbtgt.IAG.HP.COM@IAG.HP.COM
Jan 12 12:59:42  Jan 12 20:59:42  rcmd.telford.iag.hp.com@IAG.HP.COM
\end{verbatim}

Then I got a new ticket by executing the \id{kinit} command.  If you
do not give your principal name as a command-line argument then your
login name will be used.  It also tells you the ticket lifetime.  Now
my \id{kremsh} works.  Since I did not already have a ticket for this
service, the ticket was obtained and added to my ticket file.
Remember that the \id{kinit} command gives you a new ticket-granting
ticket.  If a service ticket (such as one for \key{rcmd}) has expired
and your ticket-granting ticket has not expired then the service will
get a new service ticket.  You only have to get a new ticket if the
ticket-granting ticket expires.

Now I will show you an example using my \key{root} instance.

\begin{verbatim}
aspen% ksu2
Password for principal tai.root: <password>
Ticket expires in 2.0 hours
aspen-root# klist
Ticket file:	/tmp/tkt_root_754.aspen
Principal:	tai.root@IAG.HP.COM

  Issued           Expires          Principal
Jan 12 13:36:48  Jan 12 15:36:48  krbtgt.IAG.HP.COM@IAG.HP.COM
\end{verbatim}

I used the \id{ksu2} command to become \key{root}, and in doing so I
had to provide my \key{root} instance password.  Note also that the
ticket filename is somewhat different now that I am the superuser.

\begin{verbatim}
aspen-root# kremsh kenzo cat /.klogin
kincl.root@IAG.HP.COM
krishnan.root@IAG.HP.COM
tai.root@IAG.HP.COM
gascon.root@IAG.HP.COM
laubach.root@IAG.HP.COM
jhiggins.root@IAG.HP.COM
\end{verbatim}

Now when I use \id{kremsh} I am authenticating myself as the
\key{tai.root} or the \key{root} user on \key{kenzo}.  The \id{kremsh}
worked because \key{tai.root@IAG.HP.COM} was listed in the
\lit{/.klogin} file.  This file controls \key{root} access to the
system from the Kerberized \key{rcmd} services.

\begin{verbatim}
aspen-root# kremsh kenzo -l tai
login: tai has not given you permission to login without a password.
Password: <cr>
Login incorrect
login: ^D
Connection closed.
\end{verbatim}

Still authenticating myself as \key{tai.root}, I tried to \id{kremsh}
as user \key{tai} on \key{kenzo}.  But this failed due to a permission
failure.

\begin{verbatim}
aspen-root# kinit
Hewlett-Packard (aspen.iag.hp.com)
Kerberos Initialization for "tai"
Ticket lifetime is 21.2 hours
Password: <password>
aspen-root# klist
Ticket file:	/tmp/tkt_root_754.aspen
Principal:	tai@IAG.HP.COM

  Issued           Expires          Principal
Jan 12 13:40:21  Jan 13 10:55:21  krbtgt.IAG.HP.COM@IAG.HP.COM
aspen-root# kremsh kenzo -l tai cat .klogin
tai@IAG.HP.COM
\end{verbatim}

So what I did was to get a ticket for \key{tai} (replacing my
\key{tai.root} ticket).  Now the \id{kremsh} worked and you can see
why the permission failure occured before.  The \home{.klogin}
file controls access to my account similar to the way the
\home{.rhosts} file does for the normal \key{rcmd} services.

After adding \key{tai.root@IAG.HP.COM} to my \home{.klogin}
file, I try again as \key{tai.root}.

\begin{verbatim}
aspen-root# kinit tai.root
Hewlett-Packard (aspen.iag.hp.com)
Kerberos Initialization for "tai.root"
Ticket lifetime is 2.0 hours
Password: <password>
aspen-root# klist
Ticket file:	/tmp/tkt_root_754.aspen
Principal:	tai.root@IAG.HP.COM

  Issued           Expires          Principal
Jan 12 13:40:53  Jan 13 10:55:53  krbtgt.IAG.HP.COM@IAG.HP.COM
aspen-root# kremsh kenzo -l tai cat .klogin
tai@IAG.HP.COM
tai.root@IAG.HP.COM
\end{verbatim}

You will have noticed that I was the superuser ever since I executed
the \id{ksu2} command.  However, I was able to assume different
identities, as far as Kerberos is concerned, by getting tickets for
\key{tai.root} and \key{tai}.  This illustrates the difference between
the authentication that Kerberos provides and the authorization that
UNIX provides.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
