diff options
| -rw-r--r-- | doc/HOW_TO_BUILD | 298 | ||||
| -rw-r--r-- | doc/SOURCE-TREE | 118 | ||||
| -rw-r--r-- | doc/TREE-GRAPH | 95 | ||||
| -rw-r--r-- | doc/krb5-protocol/krb5.constants | 159 | ||||
| -rw-r--r-- | doc/krb5-protocol/rfc1510.errata | 64 | ||||
| -rw-r--r-- | doc/krb5-protocol/rfc1510.txt | 6275 | ||||
| -rw-r--r-- | doc/old-V4-docs/README | 4 | ||||
| -rw-r--r-- | doc/old-V4-docs/installation.PS | 2338 | ||||
| -rw-r--r-- | doc/old-V4-docs/installation.mss | 681 | ||||
| -rw-r--r-- | doc/old-V4-docs/operation.PS | 2669 | ||||
| -rw-r--r-- | doc/old-V4-docs/operation.mss | 799 |
11 files changed, 13500 insertions, 0 deletions
diff --git a/doc/HOW_TO_BUILD b/doc/HOW_TO_BUILD new file mode 100644 index 0000000..eac32b7 --- /dev/null +++ b/doc/HOW_TO_BUILD @@ -0,0 +1,298 @@ +In the Beta 4 distribution, we have included a new build system, which +was built using the Free Software Foundation's autoconf program. This +system will hopefully make Kerberos V5 much simpler to build for most +people, and reduce the amount of effort required in porting Kerberos V5 +to a new platform. + +In the future, we will be supporting only the configure method as the +method for configuring and building Kerberos. In this release, both +the autoconf and the old imake system are included, both to make +things easier for sites who have existing imake config files to +convert, and because the autoconf makefiles aren't quite as flexible +as the old imake system (although this will be fixed where the +flexibility is really needed) and because not all of the application +directories have been converted over to use configure. + +If you want to use the old imake system, skip down to the section +labeled "HOW TO BUILD KERBEROS V5 USING IMAKE". + +HOW TO BUILD KERBEROS V5 USING CONFIGURE +======================================== + +A) Find about 65 meg free; untar the krb5 sources. For example, + we will assume that you've untar'ed the sources into /u1/krb5, + so that the top of the source tree is /u1/krb5/src. + +B) If you don't want separate build trees for each architecture, then +use the following abbreviated procedure. + 1) cd /u1/krb5/src + 2) ./configure + 3) make + +C. If you want to separate build trees for different architectures, +then create each build tree in the top level; for example, +/u1/krb5/solaris, /u1/krb5/pmax, etc. Then on each platform, do +something like the following: + 1) cd /u1/krb5/pmax + 2) ../src/autotools/lndir /u1/krb5/src + 3) ./configure + 4) make + +If you have a make that supports VPATH (GNU make, for example), you +can simplify this procedure slightly: + 1) cd /u1/krb5/pmax + 2) ../src/configure + 3) make + +That's all there is to it! + +By default, Kerberos will expect its configuration files to be in +/krb5. This can be changed by passing the +"--with-krb5-root=/KRB5_ROOT_DIR" option to configure, where +/KRB5_ROOT_DIR should be replaced with the appropriate pathname. + +If you want Kerberos V4 backwards compatibility, pass the +"--with-krb4=/KRB4_DIRECTORY" option to configure. This requires that +the V4 include files be available in /KRB4_DIRECTORY/include, and that +the V4 Kerberos library be available in /KRB4_DIRECTORY/lib. + +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= + +HOW TO BUILD KERBEROS V5 USING IMAKE +==================================== + + +To build kerberos v5 Beta four distribution (using imake): + +A) find about 65M free. + +B) pick up and build the following support pieces/programs if you don't +have them already installed: + + isode from ftp.psi.com:/isode/ + ISODE 6.8 works, but you must apply our + patches (pepsy-diffs) before buidling. ISODE + 7.0 is what we're using in-house. I believe + ISODE 8.0 should also work + + n.b. The isode in the sources isn't linked + into the imake build files. So you can use + this isode, but you'll have to compile it + yourself manually. + +C) building the system: + +1) edit any files you need to change (see below) +2) run 'make world' and everything should get built. +3) If you want to install stuff, you can later run 'make install'. + +Most of things you should need to change will be in +include/krb5/stock/osconf.h, config/site.def and/or an +architecture-specific file in config/. + +config/site.def: +--------------- + +If you don't have pepsy in your $PATH, then add #defines to +config/site.def to give its location. See the top of Project.tmpl for +the #define'ed names you should use. + +If you need additional library search paths to get the libraries, then +put the appropriate -L flag(s) into the #define of LdLibLocations in +config/site.def. + +See the other comments in config/site.def for other options you may wish +to turn on (such as moving the default locations for various installed +programs & manual pages). + +config/<machine>.cf: +------------------ + +Imake uses a separate configuration file to turn on/off certain options +on a per-system/architecture basis. See config/Imake.tmpl if you need +to figure out the name of the config file your machine will use. +[They're the same as those for X11R4, except that BSD on a VAX uses +<vaxbsd.cf> rather than <bsd.cf> (XXX)] + +See ultrix.cf, sun.cf, vaxbsd.cf, ibm.cf for examples of things you +might want to include in this file. + +Certain options which control some conditional compilations of interest +are: +HasVoidSignalReturn YES if signal catching functions should + be void; NO if they should return int. +HasPosixTermios YES if you have POSIX termios terminal controls + NO if you have BSD/V7 sgtty stuff. + (if you have neither, check out the code + in lib/os/read_pwd.c) + +HasPosixFileLocks YES if you have POSIX file locking commands + NO if you have BSD-style flock() commands + (if you have neither, check out the code + in lib/os/lock_file.c) + +HasPosixTypes YES if you have POSIX *_t types in your + header files + NO if you don't +HasStringH YES if you have <string.h> + NO if you don't +HasStdlibH YES if you have <stdlib.h> + NO if you don't +UseSysTimeH YES if you should use <sys/time.h> for + struct timeval + NO if you shouldn't +UseTimeH YES if you should use <time.h> for ... + if neither this nor UseSysTimeH is defined, + then <sys/time.h> will be used if OS_BSD + is set, otherwise <time.h> will be used. + +HasInet YES if you have BSD internet sockets + NO if you don't (not much will work in + this dist without them, though... see lib/os/) +HaveSetenv YES if you have setenv() in your library + NO if you don't +HasGcc YES if you have gcc and want to use it, + NO if you don't +HasNdbm YES if you have ndbm(3), <ndbm.h> + NO if you have dbm(3) + +Bitsize32 #define'd if you have 32-bit words + if not, good luck with the DES library. +Bitsize16 +Bitsize64 + +DesDefines -D flags to configure the DES library. + common flags here are: + -DMSBFIRST (big-endian) + -DLSBFIRST (little-endian) + -DMUSTALIGN (if you have to align + references to longwords) + -DBIG (32 bits) + +HasSaberC YES if you have Saber-C (this turns on + Makefile additions to make loading easier) + NO if you don't (but you should get it!) +SaberDefines extra -D flags for Saber-C loading + (such as -Dconst= to avoid a bug in + older versions of saber) + +WantPrototypes YES if your C compiler supports function + prototypes. redundant if your compiler + defines __STDC__, but may be useful if + your compiler has prototypes but isn't + fully __STDC__ + +NeedNarrowPrototypes YES if your C compiler supports function + prototypes AND you do not want the + parameter types to be widened/promoted. + NO if you want them widened (normal + setting, since narrow versions can lead + to interoperability problems between + modules compiled with different compilers) + +MakeDependFlags extra defines to be passed onto + makedepend when generating include file + dependencies. These might be flags that + your compiler sends automatically but + makedepend doesn't know about, e.g.: + -D__STDC__ -I/local/gcc-includes +STDCTopIncludes XXX include path for alternate STDC-ized + include files +StandardDefines -D flags for this system, e.g. + -YPOSIX -D_POSIX_SOURCE +StandardCppDefines -D flags to pass when only calling cpp, e.g. + -DPOSIX -D_POSIX_SOURCE + +telnet/telnetd need special configuration options, which are sometimes +determined by the operating system defines. see +appl/telnet/telnet/Imakefile, appl/telnet/telnetd/Imakefile, and +appl/telnet/old-makefiles/* for details. + +include/krb5/stock/osconf.h: +--------------------------- +There are several defaults you may wish to adjust in osconf.h: + +DEFAULT_CONFIG_FILENAME The pathname to the file which defines + the known realms and their KDCs. Same + format as V4 krb.conf +DEFAULT_TRANS_FILENAME The pathname to the file which a priori + assigns hosts to realms. Same format as + V4 krb.realms +DEFAULT_LNAME_FILENAME The pathname to the database mapping + authentication names to local account names. + See kdb5_anadd(8). +DEFAULT_KEYTAB_NAME The type and pathname to the default + server keytab file (the equivalent of v4 + /etc/srvtab). +DEFAULT_KDC_ETYPE The default encryption type for the KDC. +DEFAULT_KDC_KEYTYPE The default keytype for the KDC. +KDCRCACHE The name of the replay cache used by + the KDC. +RCTMPDIR The directory which stores replay + caches. + +include/krb5/stock/config.h +---------------------------- +Most of the defines in this file should be adjusted using your imake +.cf file; however, some of the defines located at the end of the file +may be of interest (and are adjusted manually since they tend to be of +interest on a site-wide basis) + +KRBCONF_VAGUE_ERRORS If defined, give vague and unhelpful + error messages to the client... er, + attacker. (Needed to meet silly + government regulations; most other + sites will want to keep this + undefined.) + +KRBCONF_KDC_MODIFIES_KDB Define this if you want to allow the + KDC to modify the Kerberos database; + this allows the last request + information to be updated, as well as + the failure count information. + + Note that this doesn't work if you're + using slave servers!!! It also causes + the database to be modified (and thus + need to be locked) frequently. + + + +NOTE for building Kerberos for multiple platforms +================================================= + +This is how we build Kerberos for multiple platforms here at MIT: + +1) Use the synctree program to build a symlink tree. The .rconf files +included in the distribution are for use with synctree. You can find +the synctree program in the same directory as you found this release, +athena-dist.mit.edu. + +Assuming you have a directory hierarchy which looks something like this: + + + |-decmips- + |-hpux---- +|-krb5-|-linux--- + |-solaris- + |-src----- + +A typical invokation of synctree might be: + + cd XXX/krb5 + mkdir decmips; cd decmips + synctree -s ../src -d . + +2) At the top level of the build tree (in the example above, krb5/decmips) +execute the following command to regenerate the top level makefile: + + imake -I./config + +3) Run a "make world". It is often advisiable to redirect the output +to a file, so that you can puruse any error messages when the compile +is finished. + + + + + diff --git a/doc/SOURCE-TREE b/doc/SOURCE-TREE new file mode 100644 index 0000000..944126d --- /dev/null +++ b/doc/SOURCE-TREE @@ -0,0 +1,118 @@ +Source tree organization (15 Jun 1994): + +admin: administrative tools + aname: manipulate aname/lname translation database + convert: convert a V4 database to a V5 database + create: create database + destroy: destroy database + edit: edit database [the most useful of the bunch] + stash: store db key for unattended service + +autotools: Tools to allow rebuild the configure scripts; requires that + you have GNU autoconf installed. + +appl: applications + bsd: The Berkeley rlogin/rsh/rcp suite + movemail: Emacs 18.57 'movemail' program with Kerberos + hooks for POP support. + popper: Berkeley POP server, with Kerberos and other + athena mods + gss-sample: sample client & server using the GSSAPI library + sample: sample client & server (using byte stream sockets) + simple: another sample client & server (using datagrams) + telnet: telnet client (v4 & v5 kerberized, plus other goodies) + libtelnet: support for telnet/telnetd + telnet: the client-side + telnetd: BSD UNIX telnet daemon + login: a version of login(8) which has the '-f' flag + necessary for using authenticated telnet + connections without a password + user-user: sample client & server using the user-to-user + protocol features. (NOTE: the client and server + programs are somewhat "backwards" in terms of how + they call the Kerberos 5 routines. Don't let this + confuse you.) + +clients: base-level kerberos clients + kinit: get tickets using password + klist: list ticket cache + kdestroy: destroy ticket cache + ksu: kerberized su program + +config: configuration control for source + >>> look at site.def, vaxbsd.cf, ultrix.cf, ibm.cf in + >>> particular for hints on things you might want to modify. + >>> Ignore the comments on the X11 stuff for now. + +doc: documentation hierarchy + api: The Kerberos api + +include: include hierarchy + krb5: kerberos-specific includes + kerberosIV: copies of kerberos v4 include files (used + for some programs which support both) + +isode: isode hierarchy. A subset of ISODE 8.0. Used only for + the autoconf setup. + +kadmin: Remote kerberos administration tools + client: The client program + kpasswd: User-client which allos users to change their + passwords + server: The server daemon + v4server: A V4 kadmin server which updates a V5 database + +kdc: Kerberos Server/Key Distribution Center + +krb524: Program which issues krb4 tickets when handed a krb5 TGT + +lib: library hierarchy + crypto: The cryptographic routines + crc-32: CRC-32 function(s) + des: MIT DES library + md4: MD4 code from Internet RFC 1186B + md5: MD5 code from Internet + os: Operating-system or configuration-specific code + + kdb: database interface routines + + krb425: link-level compatibility library; lets you link + v4 applications with v5 back-end code + + krb5: The Kerberos library + asn.1: ASN.1 definitions & glue files + The current set-up assumes that you + have ISODE 7.0 (or later) installed. + A subset of ISODE can be found in the + same directory where you picked up the + Kerberos distribution. + + ccache: credentials cache + file: file descriptor-based ccache + stdio: STDIO-based ccache + error_tables: Common Error description files & headers + free: routines to free various allocated data + structures + gssapi: GSSAPI implementation for Kerberos V5 + keytab: server key table routines + file: STDIO-based keytab + krb: Main kerberos library functions + os: Operating-system or configuration-specific code + posix: POSIX routines provided for systems + that don't have them + rcache: authenticator replay-cache code + +slave: Routines to propagate the Kerberos database from the + master to the slave databases (kprop/kpropd) + +tests: various tests + create: create a bunch of principals in a KDC database + verify: verify that the principals have the right keys + hammer: "hammer" the KDC with requests to help assure + proper KDC operation + +util: Utilities + et: The com_err library + ss: The subsystem library + makedepend: Program to rebuild the makefile dependencies + unifdef: Removes #ifdef/#endif code diff --git a/doc/TREE-GRAPH b/doc/TREE-GRAPH new file mode 100644 index 0000000..4630ec2 --- /dev/null +++ b/doc/TREE-GRAPH @@ -0,0 +1,95 @@ + + |-aname------ + |-convert---- + |-admin--------|-create----- + | |-destroy---- + | |-edit------- + | |-stash------ + | + | |-bsd-------- + | |-gss-sample- + | |-movemail--- + | | + | |-popper-----|-orig-makefiles- + | | + | |-sample-----|-sclient-------- + | | |-sserver-------- + | | + |-appl---------|-simple-----|-client--------- + | | |-server--------- + | | + | | |-arpa----------- + | |-telnet-----|-libtelnet------ + | | |-telnet--------- + | | |-telnetd-------- + | |-user_user-- + |-autotools---- + | + | |-kdestroy--- + |-clients------|-kinit------ + | |-klist------ + | |-ksu-------- + | + |-config-------|-doc-------- + |-config-files- + | + | |-gssapi----- + | |-kerberosIV- + | | + |-include------|-krb5-------|-asn.1---------- + | | |-stock---------- + | |-sys-------- + | + | |-compat----- + | |-h---------- + | | + |-isode--------|-pepsy------|-doc------------ + | | + | |-psap-------|-test----------- + | |-support---- +|-src-| |-util------- + | + | |-client----- + |-kadmin-------|-kpasswd---- + | |-server----- + | |-v4server--- + |-kdc---------- + |-krb524------- + | + | |-crc32---------- + | | + | |-des------------|-doc--- + | |-crypto-----|-md4------------ + | | |-md5------------ + | | |-os------------- + | |-des425----- + | | + | | |-generic-------- + | |-gssapi-----|-krb5----------- + | | |-sample--------- + | |-kdb-------- + |-lib----------|-krb425----- + | | + | | |-asn.1---------- + | | | + | | |-ccache---------|-file-- + | | | |-stdio- + | | |-error_tables--- + | |-krb5-------|-free----------- + | | + | |-keytab---------|-file-- + | |-krb------------ + | |-os------------- + | |-posix---------- + | |-rcache--------- + |-prototype---- + |-slave-------- + | + | |-create----- + |-tests--------|-hammer----- + | |-verify----- + | + | |-et--------- + |-util---------|-makedepend- + |-ss--------- + |-unifdef---- diff --git a/doc/krb5-protocol/krb5.constants b/doc/krb5-protocol/krb5.constants new file mode 100644 index 0000000..bf1a2e4 --- /dev/null +++ b/doc/krb5-protocol/krb5.constants @@ -0,0 +1,159 @@ +8.3. Protocol constants and associated values as of December 19, 1993 + + 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 + +-------------------------------+-------------------+------------- +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 + +-------------------------------+----------------- +padata type |padata-type value +-------------------------------+----------------- +PA-TGS-REQ 1 +PA-ENC-TIMESTAMP 2 +PA-PW-SALT 3 +PA-DATA-SESAME 4 + +-------------------------------+------------- +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 + +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-authentication + required* +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 +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 + + *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. + diff --git a/doc/krb5-protocol/rfc1510.errata b/doc/krb5-protocol/rfc1510.errata new file mode 100644 index 0000000..fff0d98 --- /dev/null +++ b/doc/krb5-protocol/rfc1510.errata @@ -0,0 +1,64 @@ +---rfc1510.eratta---as of June 14, 1994--- + +1. [19940312] The following lines describes corrections to pseudocode + in rfc1510 as of March 12, 1994. + + A: Throughout the pseudocode (section A), flags.ALLOW-POSTDATE should be + replaced by flags.MAY-POSTDATE. kdc-options.ALLOW-POSTDATE is + correct, however. + +A.2: In the processing for the kdc-options.POSTDATE (imperitive), both + the POSTDATED and the INVALID flag should be set. The setting of the + POSTDATE flag was inadvertantly omitted. + + You should change: + + 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.INVALID; + new_tkt.starttime := req.from; + else + omit new_tkt.starttime; /* treated as authtime when + + To: + 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 + +A.6: In section A.6, all occursences of kdc-options.POSTDATE (imperitive) + should be replaced by kdc-options.ALLOW-POSTDATE and tgt.flags.POSTDATE + should be replaced by tgt.flags.MAY-POSTDATE. + + Note that instances of POSTDATED (adjective) are correct. + + +--- +2. [19940614] Processing of the etype filed, described in 3.1.3, and 5.4.1. + +If a 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 +information from the Kerberos database indicating acceptable +encryption methods for the application server. The KDC will not issue +tickets with a weak session key encryption type. + diff --git a/doc/krb5-protocol/rfc1510.txt b/doc/krb5-protocol/rfc1510.txt new file mode 100644 index 0000000..bc810cc --- /dev/null +++ b/doc/krb5-protocol/rfc1510.txt @@ -0,0 +1,6275 @@ + + + + + + +Network Working Group J. Kohl +Request for Comments: 1510 Digital Equipment Corporation + C. Neuman + ISI + September 1993 + + + The Kerberos Network Authentication Service (V5) + +Status of this Memo + + This RFC specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" for the standardization state and status + of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document gives an overview and specification of Version 5 of the + protocol for the Kerberos network authentication system. Version 4, + described elsewhere [1,2], is presently in production use at MIT's + Project Athena, and at other Internet sites. + +Overview + + Project Athena, Athena, Athena MUSE, Discuss, Hesiod, Kerberos, + Moira, and Zephyr are trademarks of the Massachusetts Institute of + Technology (MIT). No commercial use of these trademarks may be made + without prior written permission of MIT. + + This RFC describes the concepts and model upon which the Kerberos + network authentication system is based. It also specifies Version 5 + of the Kerberos protocol. + + The motivations, goals, assumptions, and rationale behind most design + decisions are treated cursorily; for Version 4 they are fully + described in the Kerberos portion of the Athena Technical Plan [1]. + The protocols are under review, and are not being submitted for + consideration as an Internet standard at this time. Comments are + encouraged. 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. + + + + + +Kohl & Neuman [Page 1] + +RFC 1510 Kerberos September 1993 + + +Background + + The Kerberos model is based in part on Needham and Schroeder's + trusted third-party authentication protocol [3] and on modifications + suggested by Denning and Sacco [4]. The original design and + implementation of Kerberos Versions 1 through 4 was the work of two + former Project Athena staff members, Steve Miller of Digital + Equipment Corporation and Clifford Neuman (now at the Information + Sciences Institute of the University of Southern California), along + with Jerome Saltzer, Technical Director of Project Athena, and + Jeffrey Schiller, MIT Campus Network Manager. Many other members of + Project Athena have also contributed to the work on Kerberos. + Version 4 is publicly available, and has seen wide use across the + Internet. + + Version 5 (described in this document) has evolved from Version 4 + based on new requirements and desires for features not available in + Version 4. Details on the differences between Kerberos Versions 4 + and 5 can be found in [5]. + +Table of Contents + + 1. Introduction ....................................... 5 + 1.1. Cross-Realm Operation ............................ 7 + 1.2. Environmental assumptions ........................ 8 + 1.3. Glossary of terms ................................ 9 + 2. Ticket flag uses and requests ...................... 12 + 2.1. Initial and pre-authenticated tickets ............ 12 + 2.2. Invalid tickets .................................. 12 + 2.3. Renewable tickets ................................ 12 + 2.4. Postdated tickets ................................ 13 + 2.5. Proxiable and proxy tickets ...................... 14 + 2.6. Forwardable tickets .............................. 15 + 2.7. Other KDC options ................................ 15 + 3. Message Exchanges .................................. 16 + 3.1. The Authentication Service Exchange .............. 16 + 3.1.1. Generation of KRB_AS_REQ message ............... 17 + 3.1.2. Receipt of KRB_AS_REQ message .................. 17 + 3.1.3. Generation of KRB_AS_REP message ............... 17 + 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 ................... 20 + 3.2. The Client/Server Authentication Exchange ........ 20 + 3.2.1. The KRB_AP_REQ message ......................... 20 + 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 + + + +Kohl & Neuman [Page 2] + +RFC 1510 Kerberos September 1993 + + + 3.2.6. Using the encryption key ....................... 24 + 3.3. The Ticket-Granting Service (TGS) Exchange ....... 24 + 3.3.1. Generation of KRB_TGS_REQ message .............. 25 + 3.3.2. Receipt of KRB_TGS_REQ message ................. 26 + 3.3.3. Generation of KRB_TGS_REP message .............. 27 + 3.3.3.1. Encoding the transited field ................. 29 + 3.3.4. Receipt of KRB_TGS_REP message ................. 31 + 3.4. The KRB_SAFE Exchange ............................ 31 + 3.4.1. Generation of a KRB_SAFE message ............... 31 + 3.4.2. Receipt of KRB_SAFE message .................... 32 + 3.5. The KRB_PRIV Exchange ............................ 33 + 3.5.1. Generation of a KRB_PRIV message ............... 33 + 3.5.2. Receipt of KRB_PRIV message .................... 33 + 3.6. The KRB_CRED Exchange ............................ 34 + 3.6.1. Generation of a KRB_CRED message ............... 34 + 3.6.2. Receipt of KRB_CRED message .................... 34 + 4. The Kerberos Database .............................. 35 + 4.1. Database contents ................................ 35 + 4.2. Additional fields ................................ 36 + 4.3. Frequently Changing Fields ....................... 37 + 4.4. Site Constants ................................... 37 + 5. Message Specifications ............................. 38 + 5.1. ASN.1 Distinguished Encoding Representation ...... 38 + 5.2. ASN.1 Base Definitions ........................... 38 + 5.3. Tickets and Authenticators ....................... 42 + 5.3.1. Tickets ........................................ 42 + 5.3.2. Authenticators ................................. 47 + 5.4. Specifications for the AS and TGS exchanges ...... 49 + 5.4.1. KRB_KDC_REQ definition ......................... 49 + 5.4.2. KRB_KDC_REP definition ......................... 56 + 5.5. Client/Server (CS) message specifications ........ 58 + 5.5.1. KRB_AP_REQ definition .......................... 58 + 5.5.2. KRB_AP_REP definition .......................... 60 + 5.5.3. Error message reply ............................ 61 + 5.6. KRB_SAFE message specification ................... 61 + 5.6.1. KRB_SAFE definition ............................ 61 + 5.7. KRB_PRIV message specification ................... 62 + 5.7.1. KRB_PRIV definition ............................ 62 + 5.8. KRB_CRED message specification ................... 63 + 5.8.1. KRB_CRED definition ............................ 63 + 5.9. Error message specification ...................... 65 + 5.9.1. KRB_ERROR definition ........................... 66 + 6. Encryption and Checksum Specifications ............. 67 + 6.1. Encryption Specifications ........................ 68 + 6.2. Encryption Keys .................................. 71 + 6.3. Encryption Systems ............................... 71 + 6.3.1. The NULL Encryption System (null) .............. 71 + 6.3.2. DES in CBC mode with a CRC-32 checksum (descbc-crc)71 + + + +Kohl & Neuman [Page 3] + +RFC 1510 Kerberos September 1993 + + + 6.3.3. DES in CBC mode with an MD4 checksum (descbc-md4) 72 + 6.3.4. DES in CBC mode with an MD5 checksum (descbc-md5) 72 + 6.4. Checksums ........................................ 74 + 6.4.1. The CRC-32 Checksum (crc32) .................... 74 + 6.4.2. The RSA MD4 Checksum (rsa-md4) ................. 75 + 6.4.3. RSA MD4 Cryptographic Checksum Using DES + (rsa-md4-des) ......................................... 75 + 6.4.4. The RSA MD5 Checksum (rsa-md5) ................. 76 + 6.4.5. RSA MD5 Cryptographic Checksum Using DES + (rsa-md5-des) ......................................... 76 + 6.4.6. DES cipher-block chained checksum (des-mac) + 6.4.7. RSA MD4 Cryptographic Checksum Using DES + alternative (rsa-md4-des-k) ........................... 77 + 6.4.8. DES cipher-block chained checksum alternative + (des-mac-k) ........................................... 77 + 7. Naming Constraints ................................. 78 + 7.1. Realm Names ...................................... 77 + 7.2. Principal Names .................................. 79 + 7.2.1. Name of server principals ...................... 80 + 8. Constants and other defined values ................. 80 + 8.1. Host address types ............................... 80 + 8.2. KDC messages ..................................... 81 + 8.2.1. IP transport ................................... 81 + 8.2.2. OSI transport .................................. 82 + 8.2.3. Name of the TGS ................................ 82 + 8.3. Protocol constants and associated values ......... 82 + 9. Interoperability requirements ...................... 86 + 9.1. Specification 1 .................................. 86 + 9.2. Recommended KDC values ........................... 88 + 10. Acknowledgments ................................... 88 + 11. References ........................................ 89 + 12. Security Considerations ........................... 90 + 13. Authors' Addresses ................................ 90 + A. Pseudo-code for protocol processing ................ 91 + A.1. KRB_AS_REQ generation ............................ 91 + A.2. KRB_AS_REQ verification and KRB_AS_REP generation 92 + A.3. KRB_AS_REP verification .......................... 95 + A.4. KRB_AS_REP and KRB_TGS_REP common checks ......... 96 + A.5. KRB_TGS_REQ generation ........................... 97 + A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation 98 + A.7. KRB_TGS_REP verification ......................... 104 + A.8. Authenticator generation ......................... 104 + A.9. KRB_AP_REQ generation ............................ 105 + A.10. KRB_AP_REQ verification ......................... 105 + A.11. KRB_AP_REP generation ........................... 106 + A.12. KRB_AP_REP verification ......................... 107 + A.13. KRB_SAFE generation ............................. 107 + A.14. KRB_SAFE verification ........................... 108 + + + +Kohl & Neuman [Page 4] + +RFC 1510 Kerberos September 1993 + + + A.15. KRB_SAFE and KRB_PRIV common checks ............. 108 + A.16. KRB_PRIV generation ............................. 109 + A.17. KRB_PRIV verification ........................... 110 + A.18. KRB_CRED generation ............................. 110 + A.19. KRB_CRED verification ........................... 111 + A.20. KRB_ERROR generation ............................ 112 + +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 + authentication 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. (Note, + however, that many applications use Kerberos' functions only upon the + initiation of a stream-based network connection, and assume the + absence of any "hijackers" who might subvert such a connection. Such + use implicitly trusts the host addresses involved.) Kerberos + performs authentication under these conditions as a trusted third- + party authentication service by using conventional cryptography, + i.e., shared secret key. (shared secret key - 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.) + + The 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. + + The implementation 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 + + + +Kohl & Neuman [Page 5] + +RFC 1510 Kerberos September 1993 + + + transactions, a typical network application adds one or two calls to + the Kerberos library, which results in the transmission of the + necessary messages to achieve authentication. + + The Kerberos protocol consists of several sub-protocols (or + exchanges). There are two 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 sends the TGT to + the TGS in the same manner as if it were contacting any other + application server which requires Kerberos credentials. The reply is + encrypted in the session key from the TGT. + + Once obtained, credentials may be used to verify the identity of the + principals in a transaction, to ensure the integrity of messages + exchanged between them, or to preserve privacy of the messages. The + application is free to choose whatever protection may be necessary. + + To verify the identities of the principals in a transaction, the + client transmits the ticket to the 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 + was originated by 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. + + 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 passed in the ticket, and + contained in the credentials. + + The authentication exchanges mentioned above require read-only access + to the Kerberos database. Sometimes, however, the entries in the + + + +Kohl & Neuman [Page 6] + +RFC 1510 Kerberos September 1993 + + + 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). The administration protocol is not described in this + document. There is also a protocol for maintaining multiple copies of + the Kerberos database, but this can be considered an implementation + detail and may vary to support different database technologies. + +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 use its + authentication remotely (Of course, with appropriate permission the + client could arrange registration of a separately-named principal 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). The exchange of inter-realm keys (a separate key may be + used for each direction) registers the ticket-granting service of + each realm as a principal in the other realm. A client is then able + to obtain a ticket-granting ticket for the remote realm's ticket- + granting service from its local realm. When that ticket-granting + ticket is used, the remote ticket-granting service uses the inter- + realm key (which usually differs from its own normal TGS key) to + decrypt the ticket-granting ticket, and is thus certain that it was + issued by the client's own TGS. Tickets issued by the remote ticket- + granting service will indicate to the end-service that the client was + authenticated from another realm. + + A realm is said to communicate with another realm if the two realms + share an inter-realm key, or if the local realm shares an inter-realm + key with an intermediate realm that communicates with the remote + realm. An authentication path is the sequence of intermediate realms + that are transited in communicating from one realm to another. + + Realms are typically organized hierarchically. Each realm shares a + key with its parent and a different key with each child. If an + inter-realm key is not directly shared by two realms, the + hierarchical organization allows an authentication path to be easily + constructed. If a hierarchical organization is not used, it may be + necessary to consult some database in order to construct an + + + +Kohl & Neuman [Page 7] + +RFC 1510 Kerberos September 1993 + + + authentication path between realms. + + 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. + +1.2. Environmental assumptions + + Kerberos imposes a few assumptions on the environment in which it can + properly function: + + + "Denial of service" attacks are not solved with Kerberos. There + are places in these protocols where an intruder 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 successive entries from a + dictionary, messages obtained which are encrypted under a key + derived from the user's password. + + + Each host on the network must have a clock which is "loosely + synchronized" to the time of the other hosts; this + synchronization is used to reduce the bookkeeping needs of + application servers when they do replay detection. The degree + of "looseness" can be configured on a per-server basis. If the + clocks are synchronized over the network, the clock + synchronization protocol must itself be secured from network + attackers. + + + Principal identifiers are not recycled on a short-term basis. A + typical mode of access control will use access control lists + (ACLs) to grant permissions to particular principals. If a + + + +Kohl & Neuman [Page 8] + +RFC 1510 Kerberos September 1993 + + + stale ACL entry remains for a deleted principal and the + principal identifier is reused, the new principal will inherit + rights specified in the stale ACL entry. By not re-using + principal identifiers, the danger of inadvertent access is + removed. + +1.3. Glossary of terms + + Below is a list of terms used throughout this document. + + + Authentication Verifying the claimed identity of a + principal. + + + Authentication header A record containing a Ticket and an + Authenticator to be presented to a + server as part of the authentication + process. + + + Authentication path A sequence of intermediate realms transited + in the authentication process when + communicating from one realm to another. + + Authenticator A record containing information that can + be shown to have been recently generated + using the session key known only by the + client and server. + + + Authorization The process of determining whether a + client may use a service, which objects + the client is allowed to access, and the + type of access allowed for each. + + + Capability A token that grants the bearer permission + to access an object or service. In + Kerberos, this might be a ticket whose + use is restricted by the contents of the + authorization data field, but which + lists no network addresses, together + with the session key necessary to use + the ticket. + + + + + + +Kohl & Neuman [Page 9] + +RFC 1510 Kerberos September 1993 + + + 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). + + + Credentials A ticket plus the secret session key + necessary to successfully use that + ticket in an authentication exchange. + + + KDC Key Distribution Center, a network service + that supplies tickets and temporary + session keys; or an instance of that + service or the host on which it runs. + The KDC services both initial ticket and + ticket-granting ticket requests. The + initial ticket portion is sometimes + referred to as the Authentication Server + (or service). The ticket-granting + ticket portion is sometimes referred to + as the ticket-granting server (or service). + + Kerberos Aside from the 3-headed dog guarding + Hades, the name given to Project + Athena's authentication service, the + protocol used by that service, or the + code used to implement the authentication + service. + + + Plaintext The input to an encryption function or + the output of a decryption function. + Decryption transforms ciphertext into + plaintext. + + + Principal A uniquely named client or server + instance that participates in a network + communication. + + + + +Kohl & Neuman [Page 10] + +RFC 1510 Kerberos September 1993 + + + Principal identifier The name used to uniquely identify each + different principal. + + + Seal To encipher a record containing several + fields in such a way that the fields + cannot be individually replaced without + either knowledge of the encryption key + or leaving evidence of tampering. + + + Secret key An encryption key shared by a principal + and the KDC, distributed outside the + bounds of the system, with a long lifetime. + In the case of a human user's + principal, the secret key is derived + from a password. + + + Server A particular Principal which provides a + resource to network clients. + + + Service A resource provided to network clients; + often provided by more than one server + (for example, remote file service). + + + Session key A temporary encryption key used between + two principals, with a lifetime limited + to the duration of a single login "session". + + + Sub-session key A temporary encryption key used between + two principals, selected and exchanged + by the principals using the session key, + and with a lifetime limited to the duration + of a single association. + + + Ticket A record that helps a client authenticate + itself to a server; it contains the + client's identity, a session key, a + timestamp, and other information, all + sealed using the server's secret key. + It only serves to authenticate a client + when presented along with a fresh + Authenticator. + + + +Kohl & Neuman [Page 11] + +RFC 1510 Kerberos September 1993 + + +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 knowledge of a client's + secret key (e.g., a passwordchanging program) can insist that this + flag be set in any tickets they accept, and thus be assured that the + client's key was recently presented to the application client. + + The PRE-AUTHENT and HW-AUTHENT flags provide addition information + about the initial authentication, regardless of whether the current + ticket was issued directly (in which case INITIAL will also be set) + or issued on the basis of a ticket-granting ticket (in which case the + INITIAL flag is clear, but the PRE-AUTHENT and HW-AUTHENT flags are + carried forward from the ticket-granting ticket). + +2.2. Invalid tickets + + The INVALID flag indicates that a ticket is invalid. Application + servers must reject tickets which have this flag set. A postdated + ticket will usually be issued in this form. Invalid tickets must be + validated by the KDC before use, by presenting them to the KDC in a + TGS request with the VALIDATE option specified. The KDC will only + validate tickets after their starttime has passed. The validation is + required so that postdated tickets which have been stolen before + their starttime can be rendered permanently invalid (through a hot- + list mechanism). + +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 shortlived 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 + + + +Kohl & Neuman [Page 12] + +RFC 1510 Kerberos September 1993 + + + 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 interpreted by the + ticket-granting service (discussed below in section 3.3). It can + usually be ignored by application servers. However, some + particularly careful application servers may wish to disallow + renewable tickets. + + If a renewable ticket is not renewed by its expiration time, the KDC + will not renew the ticket. The RENEWABLE flag is reset by default, + but a client may request it be set by setting the RENEWABLE option + in the KRB_AS_REQ message. If it is set, then the renew-till field + in the ticket contains the time after which the ticket may not be + renewed. + +2.4. Postdated tickets + + Applications may occasionally need to obtain tickets for use much + later, e.g., a batch submission system would need tickets to be valid + at the time the batch job is serviced. However, it is dangerous to + hold valid tickets in a batch queue, since they will be on-line + longer and more prone to theft. Postdated tickets provide a way to + obtain these tickets from the KDC at job submission time, but to + leave them "dormant" until they are activated and validated by a + further request of the KDC. If a ticket theft were reported in the + interim, the KDC would refuse to validate the ticket, and the thief + would be foiled. + + The MAY-POSTDATE flag in a ticket is normally only interpreted by the + ticket-granting service. It can be ignored by application servers. + This flag must be set in a ticket-granting ticket in order to issue a + postdated ticket based on the presented ticket. It is reset by + default; it may be requested by a client by setting the ALLOW- + POSTDATE option in the KRB_AS_REQ message. This flag does not allow + a client to obtain a postdated ticket-granting ticket; postdated + ticket-granting tickets can only by obtained by requesting the + postdating in the KRB_AS_REQ message. The life (endtime-starttime) + of a postdated ticket will be the remaining life of the ticket- + + + +Kohl & Neuman [Page 13] + +RFC 1510 Kerberos September 1993 + + + granting ticket at the time of the request, unless the RENEWABLE + option is also set, in which case it can be the full life (endtime- + starttime) of the ticket-granting ticket. The KDC may limit how far + in the future a ticket may be postdated. + + The POSTDATED flag indicates that a ticket has been postdated. The + application server can check the authtime field in the ticket to see + when the original authentication occurred. Some services may choose + to reject postdated tickets, or they may only accept them within a + certain period after the original authentication. When the KDC issues + a POSTDATED ticket, it will also be marked as INVALID, so that the + application client must present the ticket to the KDC to be validated + before use. + +2.5. Proxiable and proxy tickets + + At times it may be necessary for a principal to allow a service to + perform an operation on its behalf. The service must be able to take + on the identity of the client, but only for a particular purpose. A + principal can allow a service to take on the principal's identity for + a particular purpose by granting it a proxy. + + The PROXIABLE flag in a ticket is normally only interpreted by the + ticket-granting service. It can be ignored by application servers. + When set, this flag tells the ticket-granting server that it is OK to + issue a new ticket (but not a ticket-granting ticket) with a + different network address based on this ticket. This flag is set by + default. + + This flag allows a client to pass a proxy to a server to perform a + remote request on its behalf, e.g., a print service client can give + the print server a proxy to access the client's files on a particular + file server in order to satisfy a print request. + + In order to complicate the use of stolen credentials, Kerberos + tickets are usually valid from only those network addresses + specifically included in the ticket (It is permissible to request or + issue tickets with no network addresses specified, but we do not + recommend it). For this reason, a client wishing to grant a proxy + must request a new ticket valid for the network address of the + service to be granted the proxy. + + The PROXY flag is set in a ticket by the TGS when it issues a + proxy ticket. Application servers may check this flag and require + additional authentication from the agent presenting the proxy in + order to provide an audit trail. + + + + + +Kohl & Neuman [Page 14] + +RFC 1510 Kerberos September 1993 + + +2.6. Forwardable tickets + + Authentication forwarding is an instance of the proxy case where the + service is granted complete use of the client's identity. An example + where it might be used is when a user logs in to a remote system and + wants authentication to work from that system as if the login were + local. + + The FORWARDABLE flag in a ticket is normally only interpreted by the + ticket-granting service. It can be ignored by application servers. + The FORWARDABLE flag has an interpretation similar to that of the + PROXIABLE flag, except ticket-granting tickets may also be issued + with different network addresses. This flag is reset by default, but + users may request that it be set by setting the FORWARDABLE option in + the AS request when they request their initial ticket-granting + ticket. + + This flag allows for authentication forwarding without requiring the + user to enter a password again. If the flag is not set, then + authentication forwarding is not permitted, but the same end result + can still be achieved if the user engages in the AS exchange with 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 it be set 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 wish to process + FORWARDED tickets differently than non-FORWARDED tickets. + +2.7. Other KDC options + + There are two additional options which may be set in a client's + request of the KDC. The RENEWABLE-OK option indicates that the + client will accept a renewable ticket if a ticket with the requested + life cannot otherwise be provided. If a ticket with the requested + life cannot be provided, then the KDC may issue a renewable ticket + with a renew-till equal to the the requested endtime. The value of + the renew-till field may still be adjusted by site-determined limits + or limits imposed by the individual principal or server. + + The ENC-TKT-IN-SKEY option is honored only by the ticket-granting + service. It indicates that the to-be-issued ticket for the end + server is to be encrypted in the session key from the additional + ticket-granting ticket provided with the request. See section 3.3.3 + for specific details. + + + + + +Kohl & Neuman [Page 15] + +RFC 1510 Kerberos September 1993 + + +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 usually initiated by a client when + it wishes to obtain authentication credentials for a given server but + currently holds no credentials. The client's secret key is used for + encryption and decryption. This exchange is typically used at the + initiation of a login session, to obtain credentials for a Ticket- + Granting Server, which will subsequently be used to obtain + credentials for other servers (see section 3.3) without requiring + further use of the client's secret key. This exchange is also used + to request credentials for services which must not be mediated + through the Ticket-Granting Service, but rather require a principal's + secret key, such as the password-changing service. (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 session and + change another user's password.) This exchange does not by itself + provide any assurance of the the identity of the user. (To + authenticate a user logging on to a local system, the credentials + obtained in the AS exchange may first be used in a TGS exchange to + obtain credentials for a local server. Those credentials must then + be verified by the local server through successful completion of the + Client/Server exchange.) + + The exchange consists of two messages: KRB_AS_REQ from the client to + Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these + messages are described in sections 5.4.1, 5.4.2, and 5.9.1. + + In the request, the client sends (in cleartext) its own identity and + the identity of the server for which it is requesting credentials. + The response, KRB_AS_REP, contains a ticket for the client to present + to the server, and a session key that will be shared by the client + and the server. The session 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 + + + +Kohl & Neuman [Page 16] + +RFC 1510 Kerberos September 1993 + + + associate it with the message to which it replies. Various errors + can occur; these are indicated by an error response (KRB_ERROR) + instead of the KRB_AS_REP response. The error message is not + encrypted. The KRB_ERROR message also contains information which can + be used to associate it with the message to which it replies. The + lack of encryption in the KRB_ERROR message precludes the ability to + detect replays or fabrications of such messages. + + In the normal case the authentication server does not know whether + the client is actually the principal named in the request. It simply + sends a reply without knowing or caring whether they are the same. + This is acceptable because nobody but the principal whose identity + was given in the request will be able to use the reply. Its critical + information is encrypted in that principal's key. The initial + request supports an optional field that can be used to pass + additional information that might be needed for the initial exchange. + This field may be used for preauthentication if desired, but the + mechanism is not currently specified. + +3.1.1. Generation of KRB_AS_REQ message + + The client may specify a number of options in the initial request. + Among these options are whether preauthentication 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 nonrenewable ticket (due to + configuration constraints; see section 4). See section A.1 for + pseudocode. + + The client prepares the KRB_AS_REQ message and sends it to the KDC. + +3.1.2. Receipt of KRB_AS_REQ message + + If all goes well, processing the KRB_AS_REQ message will result in + the creation of a ticket for the client to present to the server. + The format for the ticket is described in section 5.3.1. The + contents of the ticket are determined as follows. + +3.1.3. Generation of KRB_AS_REP message + + The authentication server looks up the client and server principals + named in the KRB_AS_REQ in its database, extracting their respective + keys. If required, the server pre-authenticates the request, and if + the pre-authentication check fails, an error message with the code + KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate + the requested encryption type, an error message with code + + + +Kohl & Neuman [Page 17] + +RFC 1510 Kerberos September 1993 + + + KDC_ERR_ETYPE_NOSUPP is returned. Otherwise it generates a "random" + session key ("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 would be + more desirable to use a truly random number generator, such as one + based on measurements of random physical phenomena.). + + If the requested start time is absent or indicates a time in the + past, then the start time of the ticket is set to the authentication + server's current time. If it indicates a time in the future, but the + POSTDATED option has not been specified, then the error + KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the requested start + time is checked against the policy of the local realm (the + administrator might decide to prohibit certain types or ranges of + postdated tickets), and if acceptable, the ticket's start time is set + as requested and the INVALID flag is set in the new ticket. The + postdated ticket must be validated before use by presenting it to the + KDC after the start time has been reached. + + The expiration time of the ticket will be set to the minimum of the + following: + + +The expiration time (endtime) requested in the KRB_AS_REQ + message. + + +The ticket's start time plus the maximum allowable lifetime + associated with the client principal (the authentication + server's database includes a maximum ticket lifetime field + in each principal's record; see section 4). + + +The ticket's start time plus the maximum allowable lifetime + associated with the server principal. + + +The ticket's start time plus the maximum lifetime set by + the policy of the local realm. + + If the requested expiration time minus the start time (as determined + above) is less than a site-determined minimum lifetime, an error + message with code KDC_ERR_NEVER_VALID is returned. If the requested + expiration time for the ticket exceeds what was determined as above, + and if the "RENEWABLE-OK" option was requested, then the "RENEWABLE" + flag is set in the new ticket, and the renew-till value is set as if + the "RENEWABLE" option were requested (the field and option names are + described fully in section 5.4.1). If the RENEWABLE option has been + requested or if the RENEWABLE-OK option has been set and a renewable + ticket is to be issued, then the renew-till field is set to the + minimum of: + + + +Kohl & Neuman [Page 18] + +RFC 1510 Kerberos September 1993 + + + +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 following options set + if they have been requested and if the policy of the local realm + allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. + If the new ticket is postdated (the start time is in the future), its + INVALID flag will also be set. + + If all of the above succeed, the server formats a KRB_AS_REP message + (see section 5.4.2), copying the addresses in the request into the + caddr of the response, placing any required pre-authentication data + into the padata of the response, and encrypts the ciphertext part in + the client's key using the requested encryption method, and sends it + to the client. See section A.2 for pseudocode. + +3.1.4. Generation of KRB_ERROR message + + Several errors can occur, and the Authentication Server responds by + returning an error message, KRB_ERROR, to the client, with the + error-code and e-text fields set to appropriate values. The error + message contents and details are described in Section 5.9.1. + +3.1.5. Receipt of KRB_AS_REP message + + If the reply message type is KRB_AS_REP, then the client verifies + that the cname and crealm fields in the cleartext portion of the + reply match what it requested. If any padata fields are present, + they may be used to derive the proper secret key to decrypt the + message. The client decrypts the encrypted part of the response + using its secret key, verifies that the nonce in the encrypted part + matches the nonce it supplied in its request (to detect replays). It + also verifies that the sname and srealm in the response match those + in the request, and that the host address field is also correct. It + then stores the ticket, session key, start and expiration times, and + other information for later use. The key-expiration field from the + encrypted part of the response may be checked to notify the user of + impending key expiration (the client program could then suggest + remedial action, such as a password change). See section A.3 for + pseudocode. + + Proper decryption of the KRB_AS_REP message is not sufficient to + + + +Kohl & Neuman [Page 19] + +RFC 1510 Kerberos September 1993 + + + 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. 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 + + The client/server authentication (CS) exchange is used by network + applications to authenticate the client to the server and vice versa. + The client must have already acquired credentials for the server + using the AS or TGS exchange. + +3.2.1. The KRB_AP_REQ message + + The KRB_AP_REQ contains authentication information which should be + part of the first message in an authenticated transaction. It + contains a ticket, an authenticator, and some additional bookkeeping + information (see section 5.5.1 for the exact format). The ticket by + itself is insufficient to authenticate a client, since tickets are + passed across the network in cleartext(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.), 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 it. The KRB_AP_REQ message is referred to elsewhere + as the "authentication header." + +3.2.2. Generation of a KRB_AP_REQ message + + When a client wishes to initiate authentication to a server, it + obtains (either through a credentials cache, the AS exchange, or the + + + +Kohl & Neuman [Page 20] + +RFC 1510 Kerberos September 1993 + + + TGS exchange) a ticket and session key for the desired service. The + client may re-use any tickets it holds until they expire. The client + then constructs a new Authenticator from the the system time, its + name, and optionally an application specific checksum, an initial + sequence number to be used in KRB_SAFE or KRB_PRIV messages, and/or a + session subkey to be used in negotiations for a session key unique to + this particular session. Authenticators may not be re-used and will + be rejected if replayed to a server (Note that this can make + applications based on unreliable transports difficult to code + correctly, if the transport might deliver duplicated messages. In + such cases, a new authenticator must be generated for each retry.). + If a sequence number is to be included, it should be randomly chosen + so that even after many messages have been exchanged it is not likely + to collide with other sequence numbers in use. + + The client may indicate a requirement of mutual authentication or the + use of a session-key based ticket by setting the appropriate flag(s) + in the ap-options field of the message. + + The Authenticator is encrypted in the session key and combined with + the ticket to form the KRB_AP_REQ message which is then sent to the + end server along with any additional application-specific + information. See section A.9 for pseudocode. + +3.2.3. Receipt of KRB_AP_REQ message + + Authentication is based on the server's current time of day (clocks + must be loosely synchronized), the authenticator, and the ticket. + Several errors are possible. If an error occurs, the server is + expected to reply to the client with a KRB_ERROR message. This + message may be encapsulated in the application protocol if its "raw" + form is not acceptable to the protocol. The format of error messages + is described in section 5.9.1. + + The algorithm for verifying authentication information is as follows. + If the message type is not KRB_AP_REQ, the server returns the + KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the Ticket + in the KRB_AP_REQ is not one the server can use (e.g., it indicates + an old key, and the server no longer possesses a copy of the old + key), the KRB_AP_ERR_BADKEYVER error is returned. If the USE- + SESSION-KEY flag is set in the ap-options field, it indicates to the + server that the ticket is encrypted in the session key from the + server's ticket-granting ticket rather than its secret key (This is + used for user-to-user authentication as described in [6]). 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 + + + +Kohl & Neuman [Page 21] + +RFC 1510 Kerberos September 1993 + + + error code is returned if the server doesn't have the proper key to + decipher the ticket. + + The ticket is decrypted using the version of the server's key + specified by the ticket. If the decryption routines detect a + modification of the ticket (each encryption system must provide + safeguards to detect modified ciphertext; see section 6), the + KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that + different keys were used to encrypt and decrypt). + + The authenticator is decrypted using the session key extracted from + the decrypted ticket. If decryption shows it to have been modified, + the KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm + of the client from the ticket are compared against the same fields in + the authenticator. If they don't match, the KRB_AP_ERR_BADMATCH + error is returned (they might not match, for example, if the wrong + session key was used to encrypt the authenticator). The addresses in + the ticket (if any) are then searched for an address matching the + operating-system reported address of the client. If no match is + found or the server insists on ticket addresses but none are present + in the ticket, the KRB_AP_ERR_BADADDR error is returned. + + If the local (server) time and the client time in the authenticator + differ by more than the allowable clock skew (e.g., 5 minutes), the + KRB_AP_ERR_SKEW error is returned. If the server name, along with + the client name, time and microsecond fields from the Authenticator + match any recently-seen such tuples, the KRB_AP_ERR_REPEAT error is + returned (Note that the rejection here is restricted to + authenticators from the same principal to the same server. Other + client principals communicating with the same server principal should + not be have their authenticators rejected if the time and microsecond + fields happen to match some other client's authenticator.). The + server must remember any authenticator presented within the allowable + clock skew, so that a replay attempt is guaranteed to fail. If a + server loses track of any authenticator presented within the + allowable clock skew, it must reject all requests until the clock + skew interval has passed. This assures that any lost or re-played + authenticators will fall outside the allowable clock skew and can no + longer be successfully replayed (If this is not done, an attacker + could conceivably record the ticket and authenticator sent over the + network to a server, then disable the client's host, pose as the + disabled host, and replay the ticket and authenticator to subvert the + authentication.). If a sequence number is provided in the + authenticator, the server saves it for later use in processing + KRB_SAFE and/or KRB_PRIV messages. If a subkey is present, the + server either saves it for later use or uses it to help generate its + own choice for a subkey to be returned in a KRB_AP_REP message. + + + + +Kohl & Neuman [Page 22] + +RFC 1510 Kerberos September 1993 + + + The server computes the age of the ticket: local (server) time minus + the start time inside the Ticket. If the start time is later than + the current time by more than the allowable clock skew or if the + INVALID flag is set in the ticket, the KRB_AP_ERR_TKT_NYV error is + returned. Otherwise, if the current time is later than end time by + more than the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error + is returned. + + If all these checks succeed without an error, the server is assured + that the client possesses the credentials of the principal named in + the ticket and thus, the client has been authenticated to the server. + See section A.10 for pseudocode. + +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). [Note: In the Kerberos version 4 protocol, the + timestamp in the reply was the client's timestamp plus one. This is + not necessary in version 5 because version 5 messages are formatted + in such a way that it is not possible to create the reply by + judicious message surgery (even in encrypted form) without knowledge + of the appropriate encryption keys.] If a sequence number is to be + included, it should be randomly chosen as described above for the + authenticator. A subkey may be included if the server desires to + negotiate a different subkey. The KRB_AP_REP message is encrypted in + the session key extracted from the ticket. See section A.11 for + pseudocode. + +3.2.5. Receipt of KRB_AP_REP message + + If a KRB_AP_REP message is returned, the client uses the session key + from the credentials obtained for the server (Note that for + encrypting the KRB_AP_REP message, the sub-session key is not used, + even if present in the Authenticator.) to decrypt the message, and + verifies that the timestamp and microsecond fields match those in the + Authenticator it sent to the server. If they match, then the client + is assured that the server is genuine. The sequence number and subkey + (if present) are retained for later use. See section A.12 for + + + +Kohl & Neuman [Page 23] + +RFC 1510 Kerberos September 1993 + + + 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 + (Implementations of the protocol may wish to provide routines to + choose subkeys based on session keys and random numbers and to + orchestrate a negotiated key to be returned in the KRB_AP_REP + message.). 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 a several alternatives. We leave the protocol negotiations of + how to use the key (e.g., selecting an encryption or checksum type) + to the application programmer; the Kerberos protocol does not + constrain the implementation options. + + 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 or KRB_ERROR responses + from the server to client to assure both client and server of their + peer's identity. If an application protocol requires privacy of its + messages, it can use the KRB_PRIV message (section 3.5). The KRB_SAFE + message (section 3.4) can be used to assure integrity. + +3.3. The Ticket-Granting Service (TGS) Exchange + + Summary + + Message direction Message type Section + 1. Client to Kerberos KRB_TGS_REQ 5.4.1 + 2. Kerberos to client KRB_TGS_REP or 5.4.2 + KRB_ERROR 5.9.1 + + The TGS exchange between a client and the Kerberos Ticket-Granting + Server is initiated by a client when it wishes to obtain + authentication credentials for a given server (which might be + registered in a remote realm), when it wishes to renew or validate an + existing ticket, or when it wishes to obtain a proxy ticket. In the + first case, the client must already have acquired a ticket for the + Ticket-Granting Service using the AS exchange (the ticket-granting + ticket is usually obtained when a client initially authenticates to + the system, such as when a user logs in). The message format for the + TGS exchange is almost identical to that for the AS exchange. The + primary difference is that encryption and decryption in the TGS + + + +Kohl & Neuman [Page 24] + +RFC 1510 Kerberos September 1993 + + + 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 authentication information consists of the authentication header + (KRB_AP_REQ) which includes the client's previously obtained ticket- + granting, renewable, or invalid ticket. In the ticket-granting + ticket and proxy cases, the request may include one or more of: a + list of network addresses, a collection of typed authorization data + to be sealed in the ticket for authorization use by the application + server, or additional tickets (the use of which are described later). + The TGS reply (KRB_TGS_REP) contains the requested credentials, + encrypted in the session key from the ticket-granting ticket or + renewable ticket, or if present, in the subsession key from the + Authenticator (part of the authentication header). The KRB_ERROR + message contains an error code and text explaining what went wrong. + The KRB_ERROR message is not encrypted. The KRB_TGS_REP message + contains information which can be used to detect replays, and to + associate it with the message to which it replies. The KRB_ERROR + message also contains information which can be used to associate it + with the message to which it replies, but the lack of encryption in + the KRB_ERROR message precludes the ability to detect replays or + fabrications of such messages. + +3.3.1. Generation of KRB_TGS_REQ message + + Before sending a request to the ticket-granting service, the client + must determine in which realm the application server is registered + [Note: This can be accomplished in several ways. It might be known + beforehand (since the realm is part of the principal identifier), or + it might be stored in a nameserver. Presently, however, this + information is obtained from a configuration 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 + authenticated. This might result in the use of a realm which has + been compromised, and would result in an attacker's ability to + compromise the authentication of the application server to the + client.]. 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 the local Kerberos server (using the + + + +Kohl & Neuman [Page 25] + +RFC 1510 Kerberos September 1993 + + + KRB_TGS_REQ message recursively). The Kerberos server may return a + TGT for the desired realm in which case one can proceed. + Alternatively, the Kerberos server may return a TGT for a realm which + is "closer" to the desired realm (further along the standard + hierarchical path), in which case this step must be repeated with a + Kerberos server in the realm specified in the returned TGT. If + neither are returned, then the request must be retried with a + Kerberos server for a realm higher in the hierarchy. This request + will itself require a ticket-granting ticket for the higher realm + which must be obtained by recursively applying these directions. + + Once the client obtains a ticket-granting ticket for the appropriate + realm, it determines which Kerberos servers serve that realm, and + contacts one. The list might be obtained through a configuration file + or network service; as long as the secret keys exchanged by realms + are kept secret, only denial of service results from a false Kerberos + server. + + As in the AS exchange, the client may specify a number of options in + the KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ + message, providing an authentication header as an element of the + padata field, and including the same fields as used in the KRB_AS_REQ + message along with several optional fields: the enc-authorization- + data field for application server use and additional tickets required + by some options. + + In preparing the authentication header, the client can select a sub- + session key under which the response from the Kerberos server will be + encrypted (If the client selects a sub-session key, care must be + taken to ensure the randomness of the selected subsession key. One + approach would be to generate a random number and XOR it with the + session key from the ticket-granting ticket.). If the sub-session key + is not specified, the session key from the ticket-granting ticket + will be used. If the enc-authorization-data is present, it must be + encrypted in the sub-session key, if present, from the authenticator + portion of the authentication header, or if not present in the + session key from the ticket-granting ticket. + + Once prepared, the message is sent to a Kerberos server for the + destination realm. See section A.5 for pseudocode. + +3.3.2. Receipt of KRB_TGS_REQ message + + The KRB_TGS_REQ message is processed in a manner similar to the + KRB_AS_REQ message, but there are many additional checks to be + performed. First, the Kerberos server must determine which server + the accompanying ticket is for and it must select the appropriate key + to decrypt it. For a normal KRB_TGS_REQ message, it will be for the + + + +Kohl & Neuman [Page 26] + +RFC 1510 Kerberos September 1993 + + + ticket granting service, and the TGS's key will be used. If the TGT + was issued by another realm, then the appropriate inter-realm key + must be used. If the accompanying ticket is not a ticket granting + ticket for the current realm, but is for an application server in the + current realm, the RENEW, VALIDATE, or PROXY options are specified in + the request, and the server for which a ticket is requested is the + server named in the accompanying ticket, then the KDC will decrypt + the ticket in the authentication header using the key of the server + for which it was issued. If no ticket can be found in the padata + field, the KDC_ERR_PADATA_TYPE_NOSUPP error is returned. + + Once the accompanying ticket has been decrypted, the user-supplied + checksum in the Authenticator must be verified against the contents + of the request, and the message rejected if the checksums do not + match (with an error code of KRB_AP_ERR_MODIFIED) or if the checksum + is not keyed or not collision-proof (with an error code of + KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported, the + KDC_ERR_SUMTYPE_NOSUPP error is returned. If the authorization-data + are present, they are decrypted using the sub-session key from the + Authenticator. + + If any of the decryptions indicate failed integrity checks, the + KRB_AP_ERR_BAD_INTEGRITY error is returned. + +3.3.3. Generation of KRB_TGS_REP message + + The KRB_TGS_REP message shares its format with the KRB_AS_REP + (KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The + detailed specification is in section 5.4.2. + + The response will include a ticket for the requested server. The + Kerberos database is queried to retrieve the record for the requested + server (including the key with which the ticket will be encrypted). + If the request is for a ticket granting ticket for a remote realm, + and if no key is shared with the requested realm, then the Kerberos + server will select the realm "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. + + + + +Kohl & Neuman [Page 27] + +RFC 1510 Kerberos September 1993 + + + 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 (endtimestarttime) of the old + ticket. + + If the FORWARDED option has been requested, then the resulting ticket + will contain the addresses specified by the client. This option will + only be honored if the FORWARDABLE flag is set in the TGT. The PROXY + option is similar; the resulting ticket will contain the addresses + specified by the client. It will be honored only if the PROXIABLE + flag in the TGT is set. The PROXY option will not be honored on + requests for additional ticket-granting tickets. + + If the requested start time is absent or indicates a time in the + past, then the start time of the ticket is set to the authentication + server's current time. If it indicates a time in the future, 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 + MAYPOSTDATE flag set, then the resulting ticket will be postdated and + the requested starttime is checked against the policy of the local + realm. If acceptable, the ticket's start time is set as requested, + and the INVALID flag is set. The postdated ticket must be validated + before use by presenting it to the KDC after the starttime has been + reached. However, in no case may the starttime, endtime, or renew- + till time of a newly-issued postdated ticket extend beyond the + renew-till time of the ticket-granting ticket. + + If the ENC-TKT-IN-SKEY option has been specified and an additional + ticket has been included in the request, the KDC will decrypt the + additional ticket using the key for the server to which the + additional ticket was issued and verify that it is a ticket-granting + ticket. If the name of the requested server is missing from the + request, the name of the client in the additional ticket will be + used. Otherwise the name of the requested server will be compared to + the name of the client in the additional ticket and if different, the + request will be rejected. If the request succeeds, the session key + from the additional ticket will be used to encrypt the new ticket + that is issued instead of using the key of the server for which the + new ticket will be used (This allows easy implementation of user-to- + user authentication [6], which uses ticket-granting ticket session + keys in lieu of secret server keys in situations where such secret + + + +Kohl & Neuman [Page 28] + +RFC 1510 Kerberos September 1993 + + + keys could be easily compromised.). + + 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, and the server is registered in the realm of + the KDC, If the RENEW option is requested, then the KDC will verify + that the RENEWABLE flag is set in the ticket and that the renew_till + time is still in the future. If the VALIDATE option is rqeuested, + the KDC will check that the starttime has passed and the INVALID flag + is set. If the PROXY option is requested, then the KDC will check + that the PROXIABLE flag is set in the ticket. If the tests succeed, + the KDC will issue the appropriate new ticket. + + 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 dates for "suspect tickets"; if a presented + ticket had an authtime in that range, it would be rejected. In this + way, a stolen ticket-granting ticket or renewable ticket cannot be + used to gain additional tickets (renewals or otherwise) once the + theft has been reported. Any normal ticket obtained before it was + reported stolen will still be valid (because they require no + interaction with the KDC), but only until their normal expiration + time. + + The ciphertext part of the response in the KRB_TGS_REP message is + encrypted in the sub-session key from the Authenticator, if present, + or the session key key from the ticket-granting ticket. It is not + encrypted using the client's secret key. Furthermore, the client's + key's expiration date and the key version number fields are left out + since these values are stored along with the client's database + record, and that record is not needed to satisfy a request based on a + ticket-granting ticket. See section A.6 for pseudocode. + +3.3.3.1. 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, + + + +Kohl & Neuman [Page 29] + +RFC 1510 Kerberos September 1993 + + + then constructing and writing out its encoded (shorthand) form (this + may involve a rearrangement of the existing encoding). + + Note that the ticket-granting service does not add the name of its + own realm. Instead, its responsibility is to add the name of the + previous realm. This prevents a malicious Kerberos server from + intentionally leaving out its own name (it could, however, omit other + realms' names). + + The names of neither the local realm nor the principal's realm are to + be included in the transited field. They appear elsewhere in the + ticket and both are known to have taken part in authenticating the + principal. Since the endpoints are not included, both local and + single-hop inter-realm authentication result in a transited field + that is empty. + + Because the name of each realm transited is added to this field, + it might potentially be very long. To decrease the length of this + field, its contents are encoded. The initially supported encoding is + optimized for the normal case of inter-realm communication: a + hierarchical arrangement of realms using either domain or X.500 style + realm names. This encoding (called DOMAIN-X500-COMPRESS) is now + described. + + Realm names in the transited field are separated by a ",". The ",", + "\", trailing "."s, and leading spaces (" ") are special characters, + and if they are part of a realm name, they must be quoted in the + transited field by preceding 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 endpoints, + 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 (For the purpose of appending, the realm preceding + the first listed realm is considered to be the null realm ("")). 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". + + + +Kohl & Neuman [Page 30] + +RFC 1510 Kerberos September 1993 + + + 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 (For the purpose of interpreting null subfields, the + client's realm is considered to precede those in the transited field, + and the server's realm is considered to follow them.). Thus, "," + means that all realms along the path between the client and the + server have been traversed. ",EDU, /COM," means that that all realms + from the client's realm up to EDU (in a domain style hierarchy) have + been traversed, and that everything from /COM down to the server's + realm in an X.500 style has also been traversed. This could occur if + the EDU realm in one hierarchy shares an inter-realm key directly + with the /COM realm in another hierarchy. + +3.3.4. Receipt of KRB_TGS_REP message + + When the KRB_TGS_REP is received by the client, it is processed in + the same manner as the KRB_AS_REP processing described above. The + primary difference is that the ciphertext part of the response must + be decrypted using the session key from the ticket-granting ticket + rather than the client's secret key. See section A.7 for pseudocode. + +3.4. The KRB_SAFE Exchange + + The KRB_SAFE message may be used by clients requiring the ability to + detect modifications of messages they exchange. It achieves this by + including a keyed collisionproof checksum of the user data and some + control information. The checksum is keyed with an encryption key + (usually the last key negotiated via subkeys, or the session key if + no negotiation has occured). + +3.4.1. Generation of a KRB_SAFE message + + When an application wishes to send a KRB_SAFE message, it collects + its data and the appropriate control information and computes a + checksum over them. The checksum algorithm should be some sort of + keyed one-way hash function (such as the RSA-MD5-DES checksum + algorithm specified in section 6.4.5, or the DES MAC), generated + using the sub-session key if present, or the session key. Different + algorithms may be selected by changing the checksum type in the + message. Unkeyed or non-collision-proof checksums are not suitable + for this use. + + The control information for the KRB_SAFE message includes both a + + + +Kohl & Neuman [Page 31] + +RFC 1510 Kerberos September 1993 + + + timestamp and a sequence number. The designer of an application + using the KRB_SAFE message must choose at least one of the two + mechanisms. This choice should be based on the needs of the + application protocol. + + Sequence numbers are useful when all messages sent will be received + by one's peer. Connection state is presently required to maintain + the session key, so maintaining the next sequence number should not + present an additional problem. + + If the application protocol is expected to tolerate lost messages + without them being resent, the use of the timestamp is the + appropriate replay detection mechanism. Using timestamps is also the + appropriate mechanism for multi-cast protocols where all of one's + peers share a common sub-session key, but some messages will be sent + to a subset of one's peers. + + After computing the checksum, the client then transmits the + information and checksum to the recipient in the message format + specified in section 5.6.1. + +3.4.2. Receipt of KRB_SAFE message + + When an application receives a KRB_SAFE message, it verifies it as + follows. If any error occurs, an error code is reported for use by + the application. + + The message is first checked by verifying that the protocol version + and type fields match the current version and KRB_SAFE, respectively. + A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE + error. The application verifies that the checksum used is a + collisionproof 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 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 timestamp and usec or a sequence + number is present, a KRB_AP_ERR_MODIFIED error is generated. + + + +Kohl & Neuman [Page 32] + +RFC 1510 Kerberos September 1993 + + + Finally, the checksum is computed over the data and control + information, and if it doesn't match the received checksum, a + KRB_AP_ERR_MODIFIED error is generated. + + If all the checks succeed, the application is assured that the + message was generated by its peer and was not modified in transit. + +3.5. The KRB_PRIV Exchange + + The KRB_PRIV message may be used by clients requiring confidentiality + and the ability to detect modifications of exchanged messages. It + achieves this by encrypting the messages and adding control + information. + +3.5.1. Generation of a KRB_PRIV message + + When an application wishes to send a KRB_PRIV message, it collects + its data and the appropriate control information (specified in + section 5.7.1) and encrypts them under an encryption key (usually the + last key negotiated via subkeys, or the session key if no negotiation + has occured). As part of the control information, the client must + choose to use either a timestamp or a sequence number (or both); see + the discussion in section 3.4.1 for guidelines on which to use. + After the user data and control information are encrypted, the client + transmits the ciphertext and some "envelope" information to the + recipient. + +3.5.2. Receipt of KRB_PRIV message + + When an application receives a KRB_PRIV message, it verifies it as + follows. If any error occurs, an error code is reported for use by + the application. + + The message is first checked by verifying that the protocol version + and type fields match the current version and KRB_PRIV, respectively. + A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE + error. The application then decrypts the ciphertext and processes + the resultant plaintext. If decryption shows the data to have been + modified, a KRB_AP_ERR_BAD_INTEGRITY error is generated. The + recipient verifies that the operating system's report of the sender's + address matches the sender's 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 + + + +Kohl & Neuman [Page 33] + +RFC 1510 Kerberos September 1993 + + + 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 timestamp and usec or a sequence + number is present, a KRB_AP_ERR_MODIFIED error is generated. + + If all the checks succeed, the application can assume the message was + generated by its peer, and was securely transmitted (without + intruders able to see the unencrypted contents). + +3.6. The KRB_CRED Exchange + + The KRB_CRED message may be used by clients requiring the ability to + send Kerberos credentials from one host to another. It achieves this + by sending the tickets together with encrypted data containing the + session keys and other information associated with the tickets. + +3.6.1. Generation of a KRB_CRED message + + When an application wishes to send a KRB_CRED message it first (using + the KRB_TGS exchange) obtains credentials to be sent to the remote + host. It then constructs a KRB_CRED message using the ticket or + tickets so obtained, placing the session key needed to use each + ticket in the key field of the corresponding KrbCredInfo sequence of + the encrypted part of the the KRB_CRED message. + + Other information associated with each ticket and obtained during the + KRB_TGS exchange is also placed in the corresponding KrbCredInfo + sequence in the encrypted part of the KRB_CRED message. The current + time and, if specifically required by the application the nonce, s- + address, and raddress fields, are placed in the encrypted part of the + KRB_CRED message which is then encrypted under an encryption key + previosuly exchanged in the KRB_AP exchange (usually the last key + negotiated via subkeys, or the session key if no negotiation has + occured). + +3.6.2. Receipt of KRB_CRED message + + When an application receives a KRB_CRED message, it verifies it. If + any error occurs, an error code is reported for use by the + application. The message is verified by checking that the protocol + version and type fields match the current version and KRB_CRED, + respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or + KRB_AP_ERR_MSG_TYPE error. The application then decrypts the + ciphertext and processes the resultant plaintext. If decryption shows + the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is + generated. + + + +Kohl & Neuman [Page 34] + +RFC 1510 Kerberos September 1993 + + + 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 containing the + principal identifiers and secret keys of principals to be + authenticated (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.). + +4.1. Database contents + + A database entry should contain at least the following fields: + + Field Value + + name Principal's identifier + key Principal's secret key + p_kvno Principal's key version + max_life Maximum lifetime for Tickets + max_renewable_life Maximum total lifetime for renewable + Tickets + + The name field is an encoding of the principal's identifier. The key + field contains an encryption key. This key is the principal's secret + key. (The key can be encrypted before storage under a Kerberos + "master key" to protect it in case the database is compromised but + the master key is not. In that case, an extra field must be added to + indicate the master key version used, see below.) The p_kvno field is + the key version number of the principal's secret key. The max_life + field contains the maximum allowable lifetime (endtime - starttime) + for any Ticket issued for this principal. The max_renewable_life + + + +Kohl & Neuman [Page 35] + +RFC 1510 Kerberos September 1993 + + + field contains the maximum allowable total lifetime for any renewable + Ticket issued for this principal. (See section 3.1 for a description + of how these lifetimes are used in determining the lifetime of a + given Ticket.) + + A server may provide KDC service to several realms, as long as the + database representation provides a mechanism to distinguish between + principal records with identifiers which differ only in the realm + name. + + When an application server's key changes, if the change is routine + (i.e., not the result of disclosure of the old key), the old key + should be retained by the server until all tickets that had been + issued using that key have expired. Because of this, it is possible + for several keys to be active for a single principal. Ciphertext + encrypted in a principal's key is always tagged with the version of + the key that was used for encryption, to help the recipient find the + proper key for decryption. + + When more than one key is active for a particular principal, the + principal will have more than one record in the Kerberos database. + The keys and key version numbers will differ between the records (the + rest of the fields may or may not be the same). Whenever Kerberos + issues a ticket, or responds to a request for initial authentication, + the most recent key (known by the Kerberos server) will be used for + encryption. This is the key with the highest key version number. + +4.2. Additional fields + + Project Athena's KDC implementation uses additional fields in its + database: + + Field Value + + K_kvno Kerberos' key version + expiration Expiration date for entry + attributes Bit field of attributes + mod_date Timestamp of last modification + mod_name Modifying principal's identifier + + The K_kvno field indicates the key version of the Kerberos master key + under which the principal's secret key is encrypted. + + After an entry's expiration date has passed, the KDC will return an + error to any client attempting to gain tickets as or for the + principal. (A database may want to maintain two expiration dates: + one for the principal, and one for the principal's current key. This + allows password aging to work independently of the principal's + + + +Kohl & Neuman [Page 36] + +RFC 1510 Kerberos September 1993 + + + expiration date. However, due to the limited space in the responses, + the KDC must combine the key expiration and principal expiration date + into a single value called "key_exp", which is used as a hint to the + user to take administrative action.) + + The attributes field is a bitfield used to govern the operations + involving the principal. This field might be useful in conjunction + with user registration procedures, for site-specific policy + implementations (Project Athena currently uses it for their user + registration process controlled by the system-wide database service, + Moira [7]), or to identify the "string to key" conversion algorithm + used for a principal's key. (See the discussion of the padata field + in section 5.4.2 for details on why this can be useful.) Other bits + are used to indicate that certain ticket options should not be + allowed in tickets encrypted under a principal's key (one bit each): + Disallow issuing postdated tickets, disallow issuing forwardable + tickets, disallow issuing tickets based on TGT authentication, + disallow issuing renewable tickets, disallow issuing proxiable + tickets, and disallow issuing tickets for which the principal is the + server. + + The mod_date field contains the time of last modification of the + entry, and the mod_name field contains the name of the principal + which last modified the entry. + +4.3. Frequently Changing Fields + + Some KDC implementations may wish to maintain the last time that a + request was made by a particular principal. Information that might + be maintained includes the time of the last request, the time of the + last request for a ticket-granting ticket, the time of the last use + of a ticket-granting ticket, or other times. This information can + then be returned to the user in the last-req field (see section 5.2). + + Other frequently changing information that can be maintained is the + latest expiration time for any tickets that have been issued using + each key. This field would be used to indicate how long old keys + must remain valid to allow the continued use of outstanding tickets. + +4.4. Site Constants + + The KDC implementation should have the following configurable + constants or options, to allow an administrator to make and enforce + policy decisions: + + + The minimum supported lifetime (used to determine whether the + KDC_ERR_NEVER_VALID error should be returned). This constant + should reflect reasonable expectations of round-trip time to the + + + +Kohl & Neuman [Page 37] + +RFC 1510 Kerberos September 1993 + + + KDC, encryption/decryption time, and processing time by the client + and target server, and it should allow for a minimum "useful" + lifetime. + + + The maximum allowable total (renewable) lifetime of a ticket + (renew_till - starttime). + + + The maximum allowable lifetime of a ticket (endtime - starttime). + + + Whether to allow the issue of tickets with empty address fields + (including the ability to specify that such tickets may only be + issued if the request specifies some authorization_data). + + + Whether proxiable, forwardable, renewable or post-datable tickets + are to be issued. + +5. Message Specifications + + The following sections describe the exact contents and encoding of + protocol messages and objects. The ASN.1 base definitions are + presented in the first subsection. The remaining subsections specify + the protocol objects (tickets and authenticators) and messages. + Specification of encryption and checksum techniques, and the fields + related to them, appear in section 6. + +5.1. ASN.1 Distinguished Encoding Representation + + All uses of ASN.1 in Kerberos shall use the Distinguished Encoding + Representation of the data elements as described in the X.509 + specification, section 8.7 [8]. + +5.2. ASN.1 Base Definitions + + The following ASN.1 base definitions are used in the rest of this + section. Note that since the underscore character (_) is not + permitted in ASN.1 names, the hyphen (-) is used in its place for the + purposes of ASN.1 names. + + Realm ::= GeneralString + PrincipalName ::= SEQUENCE { + name-type[0] INTEGER, + name-string[1] SEQUENCE OF GeneralString + } + + 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 + + + +Kohl & Neuman [Page 38] + +RFC 1510 Kerberos September 1993 + + + the style of X.500 names. Acceptable forms for realm names are + specified in section 7. A PrincipalName is a typed sequence of + components consisting of the following sub-fields: + + name-type This field specifies the type of name that follows. + Pre-defined values for this field are + specified in section 7.2. The name-type should be + treated as a hint. Ignoring the name type, no two + names can be the same (i.e., at least one of the + components, or the realm, must be different). + This constraint may be eliminated in the future. + + name-string This field encodes a sequence of components that + form a name, each component encoded as a General + String. Taken together, a PrincipalName and a Realm + form a principal identifier. Most PrincipalNames + will have only a few components (typically one or two). + + KerberosTime ::= GeneralizedTime + -- Specifying UTC time zone (Z) + + The timestamps used in Kerberos are encoded as GeneralizedTimes. An + encoding shall specify the UTC time zone (Z) and shall not include + any fractional portions of the seconds. It further shall not include + any separators. Example: The only valid format for UTC time 6 + minutes, 27 seconds after 9 pm on 6 November 1985 is 19851106210627Z. + + HostAddress ::= SEQUENCE { + addr-type[0] INTEGER, + address[1] OCTET STRING + } + + HostAddresses ::= SEQUENCE OF 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 + + + +Kohl & Neuman [Page 39] + +RFC 1510 Kerberos September 1993 + + + 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), + pre-authent(10), + hw-authent(11) + } + + KDCOptions ::= BIT STRING { + reserved(0), + forwardable(1), + forwarded(2), + proxiable(3), + proxy(4), + allow-postdate(5), + postdated(6), + + + +Kohl & Neuman [Page 40] + +RFC 1510 Kerberos September 1993 + + + unused7(7), + renewable(8), + unused9(9), + unused10(10), + unused11(11), + renewable-ok(27), + enc-tkt-in-skey(28), + renew(30), + validate(31) + } + + + LastReq ::= SEQUENCE OF SEQUENCE { + lr-type[0] INTEGER, + lr-value[1] KerberosTime + } + + lr-type This field indicates how the following lr-value + field is to be interpreted. Negative values indicate + that the information pertains only to the + responding server. Non-negative values pertain to + all servers for the realm. + + If the lr-type field is zero (0), then no information + is conveyed by the lr-value subfield. If the + absolute value of the lr-type field is one (1), + then the lr-value subfield is the time of last + initial request for a TGT. If it is two (2), then + the lr-value subfield is the time of last initial + request. If it is three (3), then the lr-value + subfield is the time of issue for the newest + ticket-granting ticket used. If it is four (4), + then the lr-value subfield is the time of the last + renewal. If it is five (5), then the lr-value + subfield is the time of last request (of any + type). + + lr-value This field contains the time of the last request. + The time must be interpreted according to the contents + of the accompanying lr-type subfield. + + See section 6 for the definitions of Checksum, ChecksumType, + EncryptedData, EncryptionKey, EncryptionType, and KeyType. + + + + + + + + +Kohl & Neuman [Page 41] + +RFC 1510 Kerberos September 1993 + + +5.3. Tickets and Authenticators + + This section describes the format and encryption parameters for + tickets and authenticators. When a ticket or authenticator is + included in a protocol message it is treated as an opaque object. + +5.3.1. Tickets + + A ticket is a record that helps a client authenticate to a service. + A Ticket contains the following information: + +Ticket ::= [APPLICATION 1] SEQUENCE { + tkt-vno[0] INTEGER, + realm[1] Realm, + sname[2] PrincipalName, + enc-part[3] EncryptedData +} +-- 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 + + + +Kohl & Neuman [Page 42] + +RFC 1510 Kerberos September 1993 + + + always be identical. + + sname This field specifies the name part of the server's + identity. + + enc-part This field holds the encrypted encoding of the + EncTicketPart sequence. + + flags This field indicates which of various options were used or + requested when the ticket was issued. It is a bit-field, + where the selected options are indicated by the bit being + set (1), and the unselected options and reserved fields + being reset (0). Bit 0 is the most significant bit. The + encoding of the bits is specified in section 5.2. The + flags are described in more detail above in section 2. The + meanings of the flags are: + + Bit(s) Name Description + + 0 RESERVED Reserved for future expansion of this + field. + + 1 FORWARDABLE The FORWARDABLE flag is normally only + interpreted by the TGS, and can be + ignored by end servers. When set, + this flag tells the ticket-granting + server that it is OK to issue a new + ticket- granting ticket with a + different network address based on + the presented ticket. + + 2 FORWARDED When set, this flag indicates that + the ticket has either been forwarded + or was issued based on authentication + involving 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. + + + + +Kohl & Neuman [Page 43] + +RFC 1510 Kerberos September 1993 + + + 4 PROXY When set, this flag indicates that a + ticket is a proxy. + + 5 MAY-POSTDATE The MAY-POSTDATE flag is normally + only interpreted by the TGS, and can + be ignored by end servers. This flag + tells the ticket-granting server that + a post- dated ticket may be issued + based on this ticket-granting ticket. + + 6 POSTDATED This flag indicates that this ticket + has been postdated. The end-service + can check the authtime field to see + when the original authentication + occurred. + + 7 INVALID This flag indicates that a ticket is + invalid, and it must be validated by + the KDC before use. Application + servers must reject tickets which + have this flag set. + + 8 RENEWABLE The RENEWABLE flag is normally only + interpreted by the TGS, and can + usually be ignored by end servers + (some particularly careful servers + may wish to disallow renewable + tickets). A renewable ticket can be + used to obtain a replacement 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 authenticated by the KDC before a + ticket was issued. The strength of + the preauthentication 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 + + + +Kohl & Neuman [Page 44] + +RFC 1510 Kerberos September 1993 + + + client. The hardware authentication + method is selected by the KDC and the + strength of the method is not + indicated. + + 12-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.1 for details on how + this field encodes the traversed realms. + + authtime This field indicates the time of initial authentication for + the named principal. It is the time of issue for the + original ticket on which this ticket is based. It is + included in the ticket to provide additional information to + the end service, and to provide the necessary information + for implementation of a `hot list' service at the KDC. An + end service that is particularly paranoid could refuse to + accept tickets for which the initial authentication + occurred "too far" in the past. + + This field is also returned as part of the response from + the KDC. When returned as part of the response to initial + authentication (KRB_AS_REP), this is the current time on + the Kerberos server (It is NOT recommended that this time + value be used to adjust the workstation's clock since the + workstation cannot reliably determine that such a + KRB_AS_REP actually came from the proper KDC in a timely + manner.). + + 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 + + + +Kohl & Neuman [Page 45] + +RFC 1510 Kerberos September 1993 + + + authtime field. + + endtime This field contains the time after which the ticket will + not be honored (its expiration time). Note that individual + services may place their own limits on the life of a ticket + and may reject tickets which have not yet expired. As + such, this is really an upper bound on the expiration time + for the ticket. + + renew-till This field is only present in tickets that have the + RENEWABLE flag set in the flags field. It indicates the + maximum endtime that may be included in a renewal. It can + be thought of as the absolute expiration time for the + ticket, including all renewals. + + caddr This field in a ticket contains zero (if omitted) or more + (if present) host addresses. These are the addresses from + which the ticket can be used. If there are no addresses, + the ticket can be used from any location. The decision + by the KDC to issue or by the end server to accept zero- + address tickets is a policy decision and is left to the + Kerberos and end-service administrators; they may refuse to + issue or accept such tickets. The suggested and default + policy, however, is that such tickets will only be issued + or accepted when additional information that can be used to + restrict the use of the ticket is included in the + authorization_data field. Such a ticket is a capability. + + Network addresses are included in the ticket to make it + harder for an attacker to use stolen credentials. Because + the session key is not sent over the network in cleartext, + credentials can't be stolen simply by listening to the + network; an attacker has to gain access to the session key + (perhaps through operating system security breaches or a + careless user's unattended session) to make use of stolen + tickets. + + It is important to note that the network address from which + a connection is received cannot be reliably determined. + Even if it could be, an attacker who has compromised the + client's workstation 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. + + + + + + +Kohl & Neuman [Page 46] + +RFC 1510 Kerberos September 1993 + + + authorization-data The authorization-data field is used to pass + authorization data from the principal on whose behalf a + ticket was issued to the application service. If no + authorization data is included, this field will be left + out. The data in this field are specific to the end + service. It is expected that the field will contain the + names of service specific objects, and the rights to those + objects. The format for this field is described in section + 5.2. Although Kerberos is not concerned with the format of + the contents of the subfields, it does carry type + information (ad-type). + + 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. + + It is interesting to note that 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 [9] for some suggested + uses of this field. + + The authorization-data field is optional and does not have + to be included in a ticket. + +5.3.2. Authenticators + + An authenticator is a record sent with a ticket to a server to + certify the client's knowledge of the encryption key in the ticket, + to help the server detect replays, and to help choose a "true session + key" to use with the particular session. The encoding is encrypted + in the ticket's session key shared by the client and the server: + +-- Unencrypted authenticator +Authenticator ::= [APPLICATION 2] SEQUENCE { + authenticator-vno[0] INTEGER, + crealm[1] Realm, + cname[2] PrincipalName, + cksum[3] Checksum OPTIONAL, + cusec[4] INTEGER, + ctime[5] KerberosTime, + subkey[6] EncryptionKey OPTIONAL, + seq-number[7] INTEGER OPTIONAL, + + + +Kohl & Neuman [Page 47] + +RFC 1510 Kerberos September 1993 + + + authorization-data[8] AuthorizationData OPTIONAL + } + + authenticator-vno This field specifies the version number for the + format of the authenticator. This document specifies + version 5. + + crealm and cname These fields are the same as those described for the + ticket in section 5.3.1. + + cksum This field contains a checksum of the the application data + that accompanies the KRB_AP_REQ. + + cusec This field contains the microsecond part of the client's + timestamp. Its value (before encryption) ranges from 0 to + 999999. It often appears along with ctime. The two fields + are used together to specify a reasonably accurate + timestamp. + + ctime This field contains the current time on the client's host. + + subkey This field contains the client's choice for an encryption + key which is to be used to protect this specific + application session. Unless an application specifies + otherwise, if this field is left out the session key from + the ticket will be used. + + seq-number This optional field includes the initial sequence number + to be used by the KRB_PRIV or KRB_SAFE messages when + sequence numbers are used to detect replays (It may also be + used by application specific messages). When included in + the authenticator this field specifies the initial sequence + number for messages from the client to the server. When + included in the AP-REP message, the initial sequence number + is that for messages from the server to the client. When + used in KRB_PRIV or KRB_SAFE messages, it is incremented by + one after each message is sent. + + For sequence numbers to adequately support the detection of + replays they should be non-repeating, even across + connection boundaries. The initial sequence number should + be random and uniformly distributed across the full space + of possible sequence numbers, so that it cannot be guessed + by an attacker and so that it and the successive sequence + numbers do not repeat other sequences. + + + + + + +Kohl & Neuman [Page 48] + +RFC 1510 Kerberos September 1993 + + + authorization-data This field is the same as described for the ticket + in section 5.3.1. It is optional and will only appear when + additional restrictions are to be placed on the use of a + ticket, beyond those carried in the ticket itself. + +5.4. Specifications for the AS and TGS exchanges + + This section specifies the format of the messages used in 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, + rtime[6] KerberosTime OPTIONAL, + nonce[7] INTEGER, + + + +Kohl & Neuman [Page 49] + +RFC 1510 Kerberos September 1993 + + + etype[8] SEQUENCE OF INTEGER, -- EncryptionType, + -- in preference order + addresses[9] HostAddresses OPTIONAL, + enc-authorization-data[10] EncryptedData OPTIONAL, + -- Encrypted AuthorizationData encoding + additional-tickets[11] SEQUENCE OF Ticket OPTIONAL +} + + The fields in this message are: + + pvno This field is included in each message, and specifies the + protocol version number. This document specifies protocol + version 5. + + msg-type This field indicates the type of a protocol message. It + will almost always be the same as the application + identifier associated with a message. It is included to + make the identifier more readily accessible to the + application. For the KDC-REQ message, this type will be + KRB_AS_REQ or KRB_TGS_REQ. + + padata The padata (pre-authentication data) field contains a 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 collisionproof) is to be computed over the + KDC-REQ-BODY encoding. In most requests for initial + authentication (KRB_AS_REQ) and most replies (KDC-REP), the + padata field will be left out. + + This field may also contain information needed by certain + extensions to the Kerberos protocol. For example, it might + be used to initially verify the identity of a client before + any response is returned. This is accomplished with a + padata field with padata-type equal to PA-ENC-TIMESTAMP and + padata-value defined as follows: + + padata-type ::= PA-ENC-TIMESTAMP + padata-value ::= EncryptedData -- PA-ENC-TS-ENC + + PA-ENC-TS-ENC ::= SEQUENCE { + patimestamp[0] KerberosTime, -- client's time + pausec[1] INTEGER OPTIONAL + } + + + + +Kohl & Neuman [Page 50] + +RFC 1510 Kerberos September 1993 + + + with patimestamp containing the client's time and pausec + containing the microseconds which may be omitted if a + client will not generate more than one request per second. + The ciphertext (padata-value) consists of the PA-ENC-TS-ENC + sequence, encrypted using the client's secret key. + + 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 + "smartcards" with Kerberos. The details of such extensions + are beyond the scope of this specification. See [10] for + additional uses of this field. + + padata-type The padata-type element of the padata field indicates the + way that the padata-value element is to be interpreted. + Negative values of padata-type are reserved for + unregistered use; non-negative values are used for a + registered interpretation of the element type. + + req-body This field is a placeholder delimiting the extent of the + remaining fields. If a checksum is to be calculated over + the request, it is calculated over an encoding of the KDC- + REQ-BODY sequence which is enclosed within the req-body + field. + + kdc-options This field appears in the KRB_AS_REQ and KRB_TGS_REQ + requests to the KDC and indicates the flags that the client + wants set on the tickets as 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: + + + + + + + +Kohl & Neuman [Page 51] + +RFC 1510 Kerberos September 1993 + + + 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 + subsequent request if the ticket- + granting ticket on which it is based + is also forwardable. + + 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 + proxiable 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 subsequent request if + + + +Kohl & Neuman [Page 52] + +RFC 1510 Kerberos September 1993 + + + the ticket-granting ticket on which it + is based also has its MAY-POSTDATE + flag set. + + 6 POSTDATED The POSTDATED option indicates that + this is a request for a postdated + ticket. This option will only be + honored if the ticket-granting ticket + on which it is based has its MAY- + POSTDATE flag set. The resulting + ticket will also have its INVALID flag + set, and that flag may be reset by a + subsequent request to the KDC after + the starttime in the ticket has been + reached. + + 7 UNUSED This option is presently unused. + + 8 RENEWABLE The RENEWABLE option indicates that + the ticket to be issued is to have its + RENEWABLE flag set. It may only be + set on the initial request, or when + the ticket-granting ticket on which + the request is based is also + renewable. If this option is + requested, then the rtime field in the + request contains the desired absolute + expiration time for the ticket. + + 9-26 RESERVED Reserved for future use. + + 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 + + + +Kohl & Neuman [Page 53] + +RFC 1510 Kerberos September 1993 + + + 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 validate 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 validated before its + starttime. The ticket presented for + validation is encrypted in the key of + the server for which it is valid and + is passed in the padata field as part + of the authentication header. + + cname and sname These fields are the same as those described for the + ticket in section 5.3.1. sname may only be absent when the + ENC-TKT-IN-SKEY option is specified. If absent, the name + of the server is taken from the name of the client in the + ticket passed as additional-tickets. + + enc-authorization-data The enc-authorization-data, if present (and it + can only be present in the TGS_REQ form), is an encoding of + the desired authorization-data encrypted under the sub- + session key if present in the Authenticator, or + alternatively from the session key in the ticket-granting + ticket, both from the padata field in the KRB_AP_REQ. + + + + +Kohl & Neuman [Page 54] + +RFC 1510 Kerberos September 1993 + + + 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. + + 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 + (Note, however, that if the time is used as the nonce, one + must make sure that the workstation time is monotonically + increasing. If the time is ever reset backwards, there is + a small, but finite, probability that a nonce will be + reused.). + + etype This field specifies the desired encryption algorithm to be + used in the response. + + addresses This field is included in the initial request for tickets, + and optionally included in requests for additional tickets + from the ticket-granting server. It specifies the + addresses from which the requested ticket is to be valid. + Normally it includes the addresses for the client's host. + If a proxy is requested, this field will contain other + addresses. The contents of this field are usually copied + by the KDC into the caddr field of the resulting ticket. + + additional-tickets Additional tickets may be optionally included in a + request to the ticket-granting server. If the ENC-TKT-IN- + SKEY option has been specified, then the session key from + the additional ticket will be used in place of the server's + key to encrypt the new ticket. If more than one option + which requires additional tickets has been specified, then + the additional tickets are used in the order specified by + the ordering of the options bits (see kdc-options, above). + + + +Kohl & Neuman [Page 55] + +RFC 1510 Kerberos September 1993 + + + The application code will be either ten (10) or twelve (12) depending + on whether the request is for an initial ticket (AS-REQ) or for an + additional ticket (TGS-REQ). + + The optional fields (addresses, authorization-data and additional- + tickets) are only included if necessary to perform the operation + specified in the kdc-options field. + + It should be noted that in KRB_TGS_REQ, the protocol version number + appears twice and two different message types appear: the KRB_TGS_REQ + message contains these fields as does the authentication header + (KRB_AP_REQ) that is passed in the padata field. + +5.4.2. KRB_KDC_REP definition + + The KRB_KDC_REP message format is used for the reply from the KDC for + either an initial (AS) request or a subsequent (TGS) request. There + is no message type for KRB_KDC_REP. Instead, the type will be either + KRB_AS_REP or KRB_TGS_REP. The key used to encrypt the ciphertext + part of the reply depends on the message type. For KRB_AS_REP, the + ciphertext is encrypted in the client's secret key, and the client's + key version number is included in the key version number for the + encrypted data. For KRB_TGS_REP, the ciphertext is encrypted in the + sub-session key from the Authenticator, or if absent, the session key + from the ticket-granting ticket used in the request. In that case, + no version number will be present in the EncryptedData sequence. + + 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[25]] EncKDCRepPart + EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart + + EncKDCRepPart ::= SEQUENCE { + key[0] EncryptionKey, + last-req[1] LastReq, + + + +Kohl & Neuman [Page 56] + +RFC 1510 Kerberos September 1993 + + + 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 + } + + NOTE: In EncASRepPart, the application code in the encrypted + part of a message provides an additional check that + the message was decrypted properly. + + pvno and msg-type These fields are described above in section 5.4.1. + msg-type is either KRB_AS_REP or KRB_TGS_REP. + + padata This field is described in detail in section 5.4.1. One + possible use for this field is to encode an alternate + "mix-in" string to be used with a string-to-key algorithm + (such as is described in section 6.3.2). This ability is + useful to ease transitions if a realm name needs to change + (e.g., when a company is acquired); in such a case all + existing password-derived entries in the KDC database would + be flagged as needing a special mix-in string until the + next password change. + + crealm, cname, srealm and sname These fields are the same as those + described for the ticket in section 5.3.1. + + ticket The newly-issued ticket, from section 5.3.1. + + enc-part This field is a place holder for the ciphertext and related + information that forms the encrypted part of a message. + The description of the encrypted part of the message + follows each appearance of this field. 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 + + + +Kohl & Neuman [Page 57] + +RFC 1510 Kerberos September 1993 + + + was successful. It also might cover all servers for a + realm, or just the particular server. Some implementations + may display this information to the user to aid in + discovering unauthorized use of one's identity. It is + similar in spirit to the last login time displayed when + logging into timesharing systems. + + nonce This field is described above in section 5.4.1. + + key-expiration The key-expiration field is part of the response from + the KDC and specifies the time that the client's secret key + is due to expire. The expiration might be the result of + password aging or an account expiration. This field will + usually be left out of the TGS reply since the response to + the TGS request is encrypted in a session key and no client + information need be retrieved from the KDC database. It is + up to the application client (usually the login program) to + take appropriate action (such as notifying the user) if the + 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 section 5.3.1), + provided so the client may verify they match the intended + request and to assist in proper ticket caching. If the + message is of type KRB_TGS_REP, the caddr field will only + be filled in if the request was for a proxy or forwarded + ticket, or if the user is substituting a subset of the + addresses from the ticket granting ticket. If the client- + requested addresses are not present or not used, then the + addresses contained in the ticket will be the same as those + included in the ticket-granting ticket. + +5.5. Client/Server (CS) message specifications + + This section specifies the format of the messages used for the + authentication of the client to the application server. + +5.5.1. KRB_AP_REQ definition + + The KRB_AP_REQ message contains the Kerberos protocol version number, + the message type KRB_AP_REQ, an options field to indicate any options + in use, and the ticket and authenticator themselves. The KRB_AP_REQ + message is often referred to as the "authentication header". + + AP-REQ ::= [APPLICATION 14] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + + + +Kohl & Neuman [Page 58] + +RFC 1510 Kerberos September 1993 + + + ap-options[2] APOptions, + ticket[3] Ticket, + authenticator[4] EncryptedData + } + + APOptions ::= BIT STRING { + reserved(0), + use-session-key(1), + mutual-required(2) + } + + pvno and msg-type These fields are described above in section 5.4.1. + msg-type is KRB_AP_REQ. + + ap-options This field appears in the application request (KRB_AP_REQ) + and affects the way the request is processed. It is a + bit-field, where the selected options are indicated by the + bit being set (1), and the unselected options and reserved + fields being reset (0). The encoding of the bits is + specified in section 5.2. The meanings of the options are: + + Bit(s) Name Description + + 0 RESERVED Reserved for future expansion of + this field. + + 1 USE-SESSION-KEYThe 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 specified, the ticket is + encrypted in the server's secret key. + + 2 MUTUAL-REQUIREDThe 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. + + + + +Kohl & Neuman [Page 59] + +RFC 1510 Kerberos September 1993 + + +5.5.2. KRB_AP_REP definition + + The KRB_AP_REP message contains the Kerberos protocol version number, + the message type, and an encrypted timestamp. The message is sent in + in response to an application request (KRB_AP_REQ) where the mutual + authentication option has been selected in the ap-options field. + + AP-REP ::= [APPLICATION 15] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + enc-part[2] EncryptedData + } + + EncAPRepPart ::= [APPLICATION 27] SEQUENCE { + ctime[0] KerberosTime, + cusec[1] INTEGER, + subkey[2] EncryptionKey OPTIONAL, + seq-number[3] INTEGER OPTIONAL + } + + NOTE: in EncAPRepPart, the application code in the encrypted part of + a message provides an additional check that the message was decrypted + properly. + + The encoded EncAPRepPart is encrypted in the shared session key of + the ticket. The optional subkey field can be used in an + application-arranged negotiation to choose a per association session + key. + + pvno and msg-type These fields are described above in section 5.4.1. + msg-type is KRB_AP_REP. + + enc-part This field is described above in section 5.4.2. + + ctime This field contains the current time on the client's host. + + cusec This field contains the microsecond part of the client's + timestamp. + + subkey This field contains an encryption key which is to be used + to protect this specific application session. See section + 3.2.6 for specifics on how this field is used to negotiate + a key. Unless an application specifies otherwise, if this + field is left out, the sub-session key from the + authenticator, or if also left out, the session key from + the ticket will be used. + + + + + +Kohl & Neuman [Page 60] + +RFC 1510 Kerberos September 1993 + + +5.5.3. Error message reply + + If an error occurs while processing the application request, the + KRB_ERROR message will be sent in response. See section 5.9.1 for + the format of the error message. The cname and crealm fields may be + left out if the server cannot determine their appropriate values from + the corresponding KRB_AP_REQ message. If the authenticator was + decipherable, the ctime and cusec fields will contain the values from + it. + +5.6. KRB_SAFE message specification + + This section specifies the format of a message that can be used by + either side (client or server) of an application to send a tamper- + proof message to its peer. It presumes that a session key has + previously been exchanged (for example, by using the + KRB_AP_REQ/KRB_AP_REP messages). + +5.6.1. KRB_SAFE definition + + The KRB_SAFE message contains user data along with a collision-proof + checksum keyed with the session key. 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, + r-address[5] HostAddress OPTIONAL + } + + pvno and msg-type These fields are described above in section 5.4.1. + msg-type is KRB_SAFE. + + safe-body This field is a placeholder for the body of the KRB-SAFE + message. It is to be encoded separately and then have the + checksum computed over it, for use in the cksum field. + + cksum This field contains the checksum of the application data. + Checksum details are described in section 6.4. The + + + +Kohl & Neuman [Page 61] + +RFC 1510 Kerberos September 1993 + + + checksum is computed over the encoding of the KRB-SAFE-BODY + sequence. + + user-data This field is part of the KRB_SAFE and KRB_PRIV messages + and contain the application specific data that is being + passed from the sender to the recipient. + + timestamp This field is part of the KRB_SAFE and KRB_PRIV messages. + Its contents are the current time as known by the sender of + the message. By checking the timestamp, the recipient of + the message is able to make sure that it was recently + generated, and is not a replay. + + usec This field is part of the KRB_SAFE and KRB_PRIV headers. + It contains the microsecond part of the timestamp. + + seq-number This field is described above in section 5.3.2. + + s-address This field specifies the address in use by the sender of + the message. + + r-address This field specifies the address in use by the recipient of + the message. It may be omitted for some uses (such as + broadcast protocols), but the recipient may arbitrarily + reject such messages. This field along with s-address can + be used to help detect messages which have been incorrectly + or maliciously delivered to the wrong recipient. + +5.7. KRB_PRIV message specification + + This section specifies the format of a message that can be used by + either side (client or server) of an application to securely and + privately send a message to its peer. It presumes that a session key + has previously been exchanged (for example, by using the + KRB_AP_REQ/KRB_AP_REP messages). + +5.7.1. KRB_PRIV definition + + The KRB_PRIV message contains user data encrypted in the Session Key. + The message fields are: + + KRB-PRIV ::= [APPLICATION 21] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + enc-part[3] EncryptedData + } + + + + + +Kohl & Neuman [Page 62] + +RFC 1510 Kerberos September 1993 + + + EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { + user-data[0] OCTET STRING, + timestamp[1] KerberosTime OPTIONAL, + usec[2] INTEGER OPTIONAL, + seq-number[3] INTEGER OPTIONAL, + s-address[4] HostAddress, -- sender's addr + r-address[5] HostAddress OPTIONAL + -- recip's addr + } + + NOTE: In EncKrbPrivPart, the application code in the encrypted part + of a message provides an additional check that the message was + decrypted properly. + + 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 (If supported by the + encryption method in use, an initialization vector may be + passed to the encryption procedure, in order to achieve + proper cipher chaining. The initialization vector might + come from the last block of the ciphertext from the + previous KRB_PRIV message, but it is the application's + choice whether or not to use such an initialization vector. + If left out, the default initialization vector for the + encryption algorithm will be used.). This encrypted + encoding is used for the enc-part field of the KRB-PRIV + message. See section 6 for the format of the ciphertext. + + user-data, timestamp, usec, s-address and r-address These fields are + described above in section 5.6.1. + + seq-number This field is described above in section 5.3.2. + +5.8. KRB_CRED message specification + + This section specifies the format of a message that can be used to + send Kerberos credentials from one principal to another. It is + presented here to encourage a common mechanism to be used by + applications when forwarding tickets or providing proxies to + subordinate servers. It presumes that a session key has already been + exchanged perhaps by using the KRB_AP_REQ/KRB_AP_REP messages. + +5.8.1. KRB_CRED definition + + The KRB_CRED message contains a sequence of tickets to be sent and + information needed to use the tickets, including the session key from + + + +Kohl & Neuman [Page 63] + +RFC 1510 Kerberos September 1993 + + + each. The information needed to use the tickets is encryped under an + encryption key previously exchanged. 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. + + tickets + These are the tickets obtained from the KDC specifically + for use by the intended recipient. Successive tickets are + paired with the corresponding KrbCredInfo sequence from the + enc-part of the KRB-CRED message. + + enc-part This field holds an encoding of the EncKrbCredPart sequence + encrypted under the session key shared between the sender + and the intended recipient. This encrypted encoding is + used for the enc-part field of the KRB-CRED message. See + section 6 for the format of the ciphertext. + + + +Kohl & Neuman [Page 64] + +RFC 1510 Kerberos September 1993 + + + 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 provide + assurance that the message is fresh. + + s-address and r-address These fields are described above in section + 5.6.1. They are used optionally to provide additional + assurance of the integrity of the KRB-CRED message. + + key This field exists in the corresponding ticket passed by the + KRB-CRED message and is used to pass the session key from + the sender to the intended recipient. The field's encoding + is described in section 6.2. + + The following fields are optional. If present, they can be + associated with the credentials in the remote ticket file. If left + out, then it is assumed that the recipient of the credentials already + knows their value. + + prealm and pname The name and realm of the delegated principal + identity. + + flags, authtime, starttime, endtime, renew-till, srealm, sname, + and caddr These fields contain the values of the + corresponding 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 + + + +Kohl & Neuman [Page 65] + +RFC 1510 Kerberos September 1993 + + + modify such a message. In particular, this means that the client + should not use any fields in this message for security-critical + purposes, such as setting a system clock or generating a fresh + authenticator. The message can be useful, however, for advising a + user on the reason for some failure. + +5.9.1. KRB_ERROR definition + + The KRB_ERROR message consists of the following fields: + + KRB-ERROR ::= [APPLICATION 30] SEQUENCE { + pvno[0] INTEGER, + msg-type[1] INTEGER, + ctime[2] KerberosTime OPTIONAL, + cusec[3] INTEGER OPTIONAL, + stime[4] KerberosTime, + susec[5] INTEGER, + error-code[6] INTEGER, + crealm[7] Realm OPTIONAL, + cname[8] PrincipalName OPTIONAL, + realm[9] Realm, -- Correct realm + sname[10] PrincipalName, -- Correct name + e-text[11] GeneralString OPTIONAL, + e-data[12] OCTET STRING OPTIONAL + } + + 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 999. It appears + along with stime. The two fields are used in conjunction to + specify a reasonably accurate timestamp. + + error-code This field contains the error code returned by Kerberos or + the server when a request fails. To interpret the value of + this field see the list of error codes in section 8. + Implementations are encouraged to provide for national + language support in the display of error messages. + + crealm, cname, srealm and sname These fields are described above in + + + +Kohl & Neuman [Page 66] + +RFC 1510 Kerberos September 1993 + + + section 5.3.1. + + e-text This field contains additional text to help explain the + error code associated with the failed request (for example, + it might include a principal name which was unknown). + + e-data This field contains additional data about the error for use + by the application to help it recover from or handle the + error. If the errorcode is KDC_ERR_PREAUTH_REQUIRED, then + the e-data field will contain an encoding of a sequence of + padata fields, each corresponding to an acceptable pre- + authentication method and optionally containing data for + the method: + + METHOD-DATA ::= SEQUENCE of PA-DATA + + If the error-code is KRB_AP_ERR_METHOD, then the e-data field will + contain an encoding of the following sequence: + + METHOD-DATA ::= SEQUENCE { + method-type[0] INTEGER, + method-data[1] OCTET STRING OPTIONAL + } + + 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 [11], in conjunction with block chaining and checksum + methods [12]. Encryption is used to prove the identities of the + network entities participating in message exchanges. The Key + Distribution Center for each realm is trusted by all principals + registered in that realm to store a secret key in confidence. Proof + of knowledge of this secret key is used to verify the authenticity of + a principal. + + The KDC uses the principal's secret key (in the AS exchange) or a + shared session key (in the TGS exchange) to encrypt responses to + ticket requests; the ability to obtain the secret key or session key + implies the knowledge of the appropriate keys and the identity of the + KDC. The ability of a principal to decrypt the KDC response and + present a Ticket and a properly formed Authenticator (generated with + the session key from the KDC response) to a service verifies the + identity of the principal; likewise the ability of the service to + + + +Kohl & Neuman [Page 67] + +RFC 1510 Kerberos September 1993 + + + 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 + difficult. Poorly chosen keys still make easy targets for intruders. + + The following sections specify the encryption and checksum mechanisms + currently defined for Kerberos. The encodings, chaining, and padding + requirements for each are described. For encryption methods, it is + often desirable to place random information (often referred to as a + confounder) at the start of the message. The requirements for a + confounder are specified with each encryption mechanism. + + Some encryption systems use a block-chaining method to improve the + the security characteristics of the ciphertext. However, these + chaining methods often don't provide an integrity check upon + decryption. Such systems (such as DES in CBC mode) must be augmented + with a checksum of the plaintext which can be verified at decryption + and used to detect any tampering or damage. Such checksums should be + good at detecting burst errors in the input. If any damage is + detected, the decryption routine is expected to return an error + indicating the failure of an integrity check. Each encryption type is + expected to provide and verify an appropriate checksum. The + specification of each encryption method sets out its checksum + requirements. + + Finally, where a key is to be derived from a user's password, an + algorithm for converting the password to a key of the appropriate + type is included. It is desirable for the string to key function to + be one-way, and for the mapping to be different in different realms. + This is important because users who are registered in more than one + realm will often use the same password in each, and it is desirable + that an attacker compromising the Kerberos server in one realm not + obtain or derive the user's key in another. + + For a discussion of the integrity characteristics of the candidate + encryption and checksum methods considered for Kerberos, the the + reader is referred to [13]. + +6.1. Encryption Specifications + + The following ASN.1 definition describes all encrypted messages. The + enc-part field which appears in the unencrypted part of messages in + + + +Kohl & Neuman [Page 68] + +RFC 1510 Kerberos September 1993 + + + section 5 is a sequence consisting of an encryption type, an optional + key version number, and the ciphertext. + + EncryptedData ::= SEQUENCE { + etype[0] INTEGER, -- EncryptionType + kvno[1] INTEGER OPTIONAL, + cipher[2] OCTET STRING -- ciphertext + } + + etype This field identifies which encryption algorithm was used + to encipher the cipher. Detailed specifications for + selected encryption types appear later in this section. + + kvno This field contains the version number of the key under + which data is encrypted. It is only present in messages + encrypted under long lasting keys, such as principals' + secret keys. + + cipher This field contains the enciphered text, encoded as an + OCTET STRING. + + The cipher field is generated by applying the specified encryption + algorithm to data composed of the message and algorithm-specific + inputs. Encryption mechanisms defined for use with Kerberos must + take sufficient measures to guarantee the integrity of the plaintext, + and we recommend they also take measures to protect against + precomputed dictionary attacks. If the encryption algorithm is not + itself capable of doing so, the protections can often be enhanced by + adding a checksum and a confounder. + + The suggested format for the data to be encrypted includes a + confounder, a checksum, the encoded plaintext, and any necessary + padding. The msg-seq field contains the part of the protocol message + described in section 5 which is to be encrypted. The confounder, + checksum, and padding are all untagged and untyped, and their length + is exactly sufficient to hold the appropriate item. The type and + length is implicit and specified by the particular encryption type + being used (etype). The format for the data to be encrypted is + described in the following diagram: + + +-----------+----------+-------------+-----+ + |confounder | check | msg-seq | pad | + +-----------+----------+-------------+-----+ + + The format cannot be described in ASN.1, but for those who prefer an + ASN.1-like notation: + + + + + +Kohl & Neuman [Page 69] + +RFC 1510 Kerberos September 1993 + + +CipherText ::= ENCRYPTED SEQUENCE { + confounder[0] UNTAGGED OCTET STRING(conf_length) OPTIONAL, + check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL, + msg-seq[2] MsgSequence, + pad UNTAGGED OCTET STRING(pad_length) OPTIONAL +} + + In the above specification, UNTAGGED OCTET STRING(length) is the + notation for an octet string with its tag and length removed. It is + not a valid ASN.1 type. The tag bits and length must be removed from + the confounder since the purpose of the confounder is so that the + message starts with random data, but the tag and its length are + fixed. For other fields, the length and tag would be redundant if + they were included because they are specified by the encryption type. + + One generates a random confounder of the appropriate length, placing + it in confounder; zeroes out check; calculates the appropriate + checksum over confounder, check, and msg-seq, placing the result in + check; adds the necessary padding; then encrypts using the specified + encryption type and the appropriate key. + + Unless otherwise specified, a definition of an encryption algorithm + that specifies a checksum, a length for the confounder field, or an + octet boundary for padding uses this ciphertext format (The ordering + of the fields in the CipherText is important. Additionally, messages + encoded in this format must include a length as part of the msg-seq + field. This allows the recipient to verify that the message has not + been truncated. Without a length, an attacker could use a chosen + plaintext attack to generate a message which could be truncated, + while leaving the checksum intact. Note that if the msg-seq is an + encoding of an ASN.1 SEQUENCE or OCTET STRING, then the length is + part of that encoding.). Those fields which are not specified will be + omitted. + + In the interest of allowing all implementations using a 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 encryption process. If an alternative checksum + is to be used, a new encryption type must be defined. + + Some cryptosystems require additional information beyond the key and + the data to be encrypted. For example, DES, when used in cipher- + block-chaining mode, requires an initialization vector. If required, + the description for each encryption type must specify the source of + such additional information. + + + + + + +Kohl & Neuman [Page 70] + +RFC 1510 Kerberos September 1993 + + +6.2. Encryption Keys + + The sequence below shows the encoding of an encryption key: + + EncryptionKey ::= SEQUENCE { + keytype[0] INTEGER, + keyvalue[1] OCTET STRING + } + + keytype This field specifies the type of encryption key that + follows in the keyvalue field. It will almost always + correspond to the encryption algorithm used to generate the + EncryptedData, though more than one algorithm may use the + same type of key (the mapping is many to one). This might + happen, for example, if the encryption algorithm uses an + alternate checksum algorithm for an integrity check, or a + different chaining mechanism. + + keyvalue This field contains the key itself, encoded as an octet + string. + + All negative values for the encryption key type are reserved for + local use. All non-negative values are reserved for officially + assigned type fields and interpretations. + +6.3. Encryption Systems + +6.3.1. The NULL Encryption System (null) + + If no encryption is in use, the encryption system is said to be the + NULL encryption system. In the NULL encryption system there is no + checksum, confounder or padding. The ciphertext is simply the + plaintext. The NULL Key is used by the null encryption system and is + zero octets in length, with keytype zero (0). + +6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc) + + The des-cbc-crc encryption mode encrypts information under the Data + Encryption Standard [11] using the cipher block chaining mode [12]. + A CRC-32 checksum (described in ISO 3309 [14]) 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 collisionproof, an + + + +Kohl & Neuman [Page 71] + +RFC 1510 Kerberos September 1993 + + + attacker could use a probabilistic chosenplaintext attack to generate + a valid message even if a confounder is used [13]. The use of + collision-proof checksums is recommended for environments where such + attacks represent a significant threat. The use of the CRC-32 as the + checksum for ticket or authenticator is no longer mandated as an + interoperability requirement for Kerberos Version 5 Specification 1 + (See section 9.1 for specific details). + +6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4) + + The des-cbc-md4 encryption mode encrypts information under the Data + Encryption Standard [11] using the cipher block chaining mode [12]. + An MD4 checksum (described in [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 descbc-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 [11] using the cipher block chaining mode [12]. + An MD5 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 + concatenation 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 bits, ..., and the eighth octet supplies the 8 least + significant bits. + + Encryption under DES using cipher block chaining requires an + additional input in the form of an initialization vector. Unless + otherwise specified, zero should be used as the initialization + vector. Kerberos' use of DES requires an 8-octet confounder. + + The DES specifications identify some "weak" and "semiweak" keys; + those keys shall not be used for encrypting messages for use in + Kerberos. Additionally, because of the way that keys are derived for + the encryption of checksums, keys shall not be used that yield "weak" + or "semi-weak" keys when eXclusive-ORed with the constant + F0F0F0F0F0F0F0F0. + + + +Kohl & Neuman [Page 72] + +RFC 1510 Kerberos September 1993 + + + 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 component of the principal's + name appended(In some cases, it may be necessary to use a different + "mix-in" string for compatibility reasons; see the discussion of + padata in section 5.4.2.), 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 "semiweak" + key as described in the DES specification, it is eXclusive-ORed with + the constant 00000000000000F0. Finally, the result is returned as + the key. Pseudocode follows: + + string_to_key(string,realm,name) { + odd = 1; + s = string + realm; + for(each component in name) { + s = s + component; + } + tempkey = NULL; + pad(s); /* with nulls to 8 byte boundary */ + for(8byteblock in s) { + if(odd == 0) { + odd = 1; + reverse(8byteblock) + } + else odd = 0; + tempkey = tempkey XOR 8byteblock; + } + fixparity(tempkey); + key = DES-CBC-check(s,tempkey); + fixparity(key); + if(is_weak_key_key(key)) + key = key XOR 0xF0; + return(key); + } + + + +Kohl & Neuman [Page 73] + +RFC 1510 Kerberos September 1993 + + +6.4. Checksums + + The following is the ASN.1 definition used for a checksum: + + Checksum ::= SEQUENCE { + cksumtype[0] INTEGER, + checksum[1] OCTET STRING + } + + cksumtype This field indicates the algorithm used to generate the + accompanying checksum. + + checksum This field contains the checksum itself, encoded + as an octet string. + + Detailed specification of selected checksum types appear later in + this section. Negative values for the checksum type are reserved for + local use. All non-negative values are reserved for officially + assigned type fields and interpretations. + + Checksums used by Kerberos can be classified by two properties: + whether they are collision-proof, and whether they are keyed. It is + infeasible to find two plaintexts which generate the same checksum + value for a collision-proof checksum. A key is required to perturb + or initialize the algorithm in a keyed checksum. To prevent + message-stream modification by an active attacker, unkeyed checksums + should only be used when the checksum and message will be + subsequently encrypted (e.g., the checksums defined as part of the + encryption algorithms covered earlier in this section). Collision- + proof checksums can be made tamper-proof as well if the checksum + value is encrypted before inclusion in a message. In such cases, the + composition of the checksum and the encryption algorithm must be + considered a separate checksum algorithm (e.g., RSA-MD5 encrypted + using DES is a new checksum algorithm of type RSA-MD5-DES). For most + keyed checksums, as well as for the encrypted forms of collisionproof + 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 [14]. The resulting + checksum is four (4) octets in length. The CRC-32 is neither keyed + nor collision-proof. The use of this checksum is not recommended. + An attacker using a probabilistic chosen-plaintext attack as + described in [13] 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 + + + +Kohl & Neuman [Page 74] + +RFC 1510 Kerberos September 1993 + + + significant threat. + +6.4.2. The RSA MD4 Checksum (rsa-md4) + + The RSA-MD4 checksum calculates a checksum using the RSA MD4 + algorithm [15]. 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-md4des) + + The RSA-MD4-DES checksum calculates a keyed collisionproof 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 (A variant of the key is + used to limit the use of a key to a particular function, separating + the functions of generating a checksum from other encryption + performed using the session key. The constant F0F0F0F0F0F0F0F0 was + chosen because it maintains key parity. The properties of DES + precluded the use of the complement. The same constant is used for + similar purpose in the Message Integrity Check in the Privacy + Enhanced Mail standard.). 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"; those keys shall + not be used for generating RSA-MD4 checksums for use in Kerberos. + + The format for the checksum is described in the following 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) + } + + + +Kohl & Neuman [Page 75] + +RFC 1510 Kerberos September 1993 + + +6.4.4. The RSA MD5 Checksum (rsa-md5) + + The RSA-MD5 checksum calculates a checksum using the RSA MD5 + algorithm [16]. 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-md5des) + + The RSA-MD5-DES checksum calculates a keyed collisionproof 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 + 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"; those keys shall + not be used for encrypting RSA-MD5 checksums for use in Kerberos. + + The format for the checksum is described in the following diagram: + + +--+--+--+--+--+--+--+-- + | des-cbc(confounder + +--+--+--+--+--+--+--+-- + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + rsa-md5(confounder+msg),key=var(key),iv=0) | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The format cannot be described in ASN.1, but for those who prefer an + ASN.1-like notation: + + rsa-md5-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { + confounder[0] UNTAGGED OCTET STRING(8), + check[1] UNTAGGED OCTET STRING(16) + } + +6.4.6. DES cipher-block chained checksum (des-mac) + + The DES-MAC checksum is computed by prepending an 8 octet confounder + to the plaintext, performing a DES CBC-mode encryption on the result + using the key and an initialization vector of zero, taking the last + block of the ciphertext, prepending the same confounder and + encrypting the pair using DES in cipher-block-chaining (CBC) mode + using a a variant of the key, where the variant is computed by + + + +Kohl & Neuman [Page 76] + +RFC 1510 Kerberos September 1993 + + + eXclusive-ORing the key with the constant F0F0F0F0F0F0F0F0. The + initialization vector should be zero. The resulting checksum is 128 + bits (16 octets) long, 64 bits of which are redundant. This checksum + is tamper-proof and collision-proof. + + The format for the checksum is described in the following diagram: + + +--+--+--+--+--+--+--+-- + | des-cbc(confounder + +--+--+--+--+--+--+--+-- + + +-----+-----+-----+-----+-----+-----+-----+-----+ + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) | + +-----+-----+-----+-----+-----+-----+-----+-----+ + + The format cannot be described in ASN.1, but for those who prefer an + ASN.1-like notation: + + des-mac-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { + confounder[0] UNTAGGED OCTET STRING(8), + check[1] UNTAGGED OCTET STRING(8) + } + + The DES specifications identify some "weak" and "semiweak" keys; + those keys shall not be used for generating DES-MAC checksums for use + in Kerberos, nor shall a key be used whose veriant 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 cipherblock-chaining (CBC) mode using a DES + key as both key and initialization vector. The resulting checksum is + 16 octets long. This checksum is tamper-proof and believed to be + collision-proof. Note that this checksum type is the old method for + encoding the RSA-MD4-DES checksum and it is no longer recommended. + +6.4.8. DES cipher-block chained checksum alternative (desmac-k) + + The DES-MAC-K checksum is computed by performing a DES CBC-mode + encryption of the plaintext, and using the last block of the + ciphertext as the checksum value. It is keyed with an encryption key + and an initialization vector; any uses which do not specify an + additional initialization vector will use the key as both key and + initialization vector. The resulting checksum is 64 bits (8 octets) + long. This checksum is tamper-proof and collision-proof. Note that + + + +Kohl & Neuman [Page 77] + +RFC 1510 Kerberos September 1993 + + + this checksum type is the old method for encoding the DESMAC checksum + and it is no longer recommended. + + The DES specifications identify some "weak keys"; those keys shall + not be used for generating DES-MAC checksums for use in Kerberos. + +7. Naming Constraints + +7.1. Realm Names + + Although realm names are encoded as GeneralStrings and although a + realm can technically select any name it chooses, interoperability + across realm boundaries requires agreement on how realm names are to + be assigned, and what information they imply. + + To enforce these conventions, each realm must conform to the + conventions itself, and it must require that any realms with which + inter-realm keys are shared also conform to the conventions and + require the same from its neighbors. + + There are presently four styles of realm names: domain, X500, other, + and reserved. Examples of each style follow: + + domain: host.subdomain.domain (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 (/). + + X.500 names contain an equal (=) and cannot contain a 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 + + + +Kohl & Neuman [Page 78] + +RFC 1510 Kerberos September 1993 + + + various name styles. The following additional constraints apply to + the assignment of realm names in the domain and X.500 categories: the + name of a realm for the domain or X.500 formats must either be used + by the organization owning (to whom it was assigned) an Internet + domain name or X.500 name, or in the case that no such names are + registered, authority to use a realm name may be derived from the + authority of the parent realm. For example, if there is no domain + name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can + authorize the creation of a realm with that name. + + This is acceptable because the organization to which the parent is + assigned is presumably the organization authorized to assign names to + its children in the X.500 and domain name systems as well. If the + parent assigns a realm name without also registering it in the domain + name or X.500 hierarchy, it is the parent's responsibility to make + sure that there will not in the future exists a name identical to the + realm name of the child unless it is assigned to the same entity as + the realm name. + +7.2. Principal Names + + As was the case for realm names, conventions are needed to ensure + that all agree on what information is implied by a principal name. + The name-type field that is part of the principal name indicates the + kind of information implied by the name. The name-type should be + treated as a hint. Ignoring the name type, no two names can be the + same (i.e., at least one of the components, or the realm, must be + different). This constraint may be eliminated in the future. The + following name types are defined: + + name-type value meaning + NT-UNKNOWN 0 Name type not known + NT-PRINCIPAL 1 Just the name of the principal as in + DCE, or for users + 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 host as remaining 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). + + + +Kohl & Neuman [Page 79] + +RFC 1510 Kerberos September 1993 + + + 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 ticket + which 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 SRVXHST 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 UNKNOWN. + + Names of any type with an initial component of "krbtgt" are reserved + for the Kerberos ticket granting service. See section 8.2.3 for the + form of such names. + +7.2.1. Name of server principals + + The principal identifier for a server on a host will generally be + composed of two parts: (1) the realm of the KDC with which the server + is registered, and (2) a two-component name of type NT-SRV-HST if the + host name is an Internet domain name or a multi-component name of + type NT-SRV-XHST if the name of the host is of a form such as X.500 + that allows slash (/) separators. The first component of the two- or + multi-component name will identify the service and the latter + components will identify the host. Where the name of the host is not + case sensitive (for example, with Internet domain names) the name of + the host must be lower case. For services such as telnet and the + Berkeley R commands which run with system privileges, the first + component will be the string "host" instead of a service specific + identifier. + +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 + + + +Kohl & Neuman [Page 80] + +RFC 1510 Kerberos September 1993 + + + type fields and interpretations. + + The values of the types for the following addresses are chosen to + match the defined address family constants in the Berkeley Standard + Distributions of Unix. They can be found in <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). + + AppleTalk Datagram Delivery Protocol (DDP) addresses + + AppleTalk DDP addresses consist of an 8-bit node number and a 16- + bit network number. The first octet of the address is the node + number; the remaining two octets encode the network number in MSB + order. The type of AppleTalk DDP addresses is sixteen (16). + + DECnet Phase IV addresses + + DECnet Phase IV addresses are 16-bit addresses, encoded in LSB + order. The type of DECnet Phase IV addresses is twelve (12). + +8.2. KDC messages + +8.2.1. IP transport + + When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request + using 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 + + + +Kohl & Neuman [Page 81] + +RFC 1510 Kerberos September 1993 + + + 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. + +8.2.2. OSI transport + + During authentication of an OSI client to and OSI server, the mutual + authentication of an OSI server to an OSI client, the transfer of + credentials from an OSI client to an OSI server, or during exchange + of private or integrity checked messages, Kerberos protocol messages + may be treated as opaque objects and the type of the authentication + mechanism will be: + + OBJECT IDENTIFIER ::= {iso (1), org(3), dod(5),internet(1), + security(5), kerberosv5(2)} + + Depending on the situation, the opaque object will be an + authentication header (KRB_AP_REQ), an authentication reply + (KRB_AP_REP), a safe message (KRB_SAFE), a private message + (KRB_PRIV), or a credentials message (KRB_CRED). The opaque data + contains an application code as specified in the ASN.1 description + for each message. The application code may be used by Kerberos to + determine the message type. + +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-SRVINST, 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. + + + + + + + + + +Kohl & Neuman [Page 82] + +RFC 1510 Kerberos September 1993 + + +---------------+-----------+----------+----------------+--------------- +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 + +-------------------------------+-------------------+------------- +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 + +-------------------------------+----------------- +padata type |padata-type value +-------------------------------+----------------- +PA-TGS-REQ 1 +PA-ENC-TIMESTAMP 2 +PA-PW-SALT 3 + +-------------------------------+------------- +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 + + + + + + +Kohl & Neuman [Page 83] + +RFC 1510 Kerberos September 1993 + + +--------------+-------+----------------------------------------- +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 + +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 + + + +Kohl & Neuman [Page 84] + +RFC 1510 Kerberos September 1993 + + +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-authentication + required* +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 +KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in + + + +Kohl & Neuman [Page 85] + +RFC 1510 Kerberos September 1993 + + + message +KRB_ERR_GENERIC 60 Generic error (description in e-text) +KRB_ERR_FIELD_TOOLONG 61 Field is too long for this + implementation + + *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. + +9. Interoperability requirements + + Version 5 of the Kerberos protocol supports a myriad of options. + Among these are multiple encryption and checksum types, alternative + encoding schemes for the transited field, optional mechanisms for + pre-authentication, the handling of tickets with no addresses, + options for mutual authentication, user to user authentication, + support for proxies, forwarding, postdating, and renewing tickets, + the format of realm names, and the handling of authorization data. + + In order to ensure the interoperability of realms, it is necessary to + define a minimal configuration which must be supported by all + implementations. This minimal configuration is subject to change as + technology does. For example, if at some later date it is discovered + that one of the required encryption or checksum algorithms is not + secure, it will be replaced. + +9.1. Specification 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: Encryption: DES-CBC-MD5 + Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5 + + Realm Names + + All implementations must understand hierarchical realms in both the + Internet Domain and the X.500 style. When a ticket granting ticket + for an unknown realm is requested, the KDC must be able to determine + the names of the intermediate realms between the KDCs realm and the + requested realm. + + + + +Kohl & Neuman [Page 86] + +RFC 1510 Kerberos September 1993 + + + Transited field encoding + + DOMAIN-X500-COMPRESS (described in section 3.3.3.1) 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-ENCTIMESTAMP + as an acceptable method, the client should retry the initial request + using the PA-ENC-TIMESTAMP preauthentication method. Servers need not + support the PAENC-TIMESTAMP method, but if not supported the server + should ignore the presence of PA-ENC-TIMESTAMP pre-authentication in + a request. + + Mutual authentication + + Mutual authentication (via the KRB_AP_REP message) must be supported. + + Ticket addresses and flags + + All KDC's must pass on tickets that carry no addresses (i.e., if a + TGT contains no addresses, the KDC will return derivative tickets), + but each realm may set its own policy for issuing such tickets, and + each application server will set its own policy with respect to + accepting them. By default, servers should not accept them. + + Proxies and forwarded tickets must be supported. Individual realms + and application servers can set their own policy on when such tickets + will be accepted. + + All implementations must recognize renewable and postdated tickets, + but need not actually implement them. If these options are not + supported, the starttime and endtime in the ticket shall specify a + ticket's entire useful life. When a postdated ticket is decoded by a + server, all implementations shall make the presence of the postdated + flag visible to the calling server. + + User-to-user authentication + + Support for user to user authentication (via the ENC-TKTIN-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. + + + +Kohl & Neuman [Page 87] + +RFC 1510 Kerberos September 1993 + + + Authorization data + + Implementations must pass all authorization data subfields from + ticket-granting tickets to any derivative tickets unless directed to + suppress a subfield as part of the definition of that registered + subfield type (it is never incorrect to pass on a subfield, and no + registered subfield types presently specify suppression at the KDC). + + Implementations must make the contents of any authorization data + subfields available to the server when a ticket is used. + Implementations are not required to allow clients to specify the + contents of the authorization data fields. + +9.2. Recommended KDC values + + Following is a list of recommended values for a KDC implementation, + based on the list of suggested configuration constants (see section + 4.4). + + minimum lifetime 5 minutes + + maximum renewable lifetime 1 week + + maximum ticket lifetime 1 day + + empty addresses only when suitable restrictions appear + in authorization data + + proxiable, etc. Allowed. + +10. Acknowledgments + + Early versions of this document, describing version 4 of the + protocol, were written by Jennifer Steiner (formerly at Project + Athena); these drafts provided an excellent starting point for this + current version 5 specification. Many people in the Internet + community have contributed ideas and suggested protocol changes for + version 5. Notable contributions came from Ted Anderson, Steve + Bellovin and Michael Merritt [17], Daniel Bernstein, Mike Burrows, + Donald Davis, Ravi Ganesan, Morrie Gasser, Virgil Gligor, Bill + Griffeth, Mark Lillibridge, Mark Lomas, Steve Lunt, Piers McMahon, + Joe Pato, William Sommerfeld, Stuart Stubblebine, Ralph Swick, Ted + T'so, and Stanley Zanarotti. Many others commented and helped shape + this specification into its current form. + + + + + + + +Kohl & Neuman [Page 88] + +RFC 1510 Kerberos September 1993 + + +11. References + + [1] Miller, S., Neuman, C., Schiller, J., and J. Saltzer, "Section + E.2.1: Kerberos Authentication and Authorization System", + M.I.T. Project Athena, Cambridge, Massachusetts, December 21, + 1987. + + [2] Steiner, J., Neuman, C., and J. Schiller, "Kerberos: An + Authentication Service for Open Network Systems", pp. 191-202 in + Usenix Conference Proceedings, Dallas, Texas, February, 1988. + + [3] Needham, R., and M. Schroeder, "Using Encryption for + Authentication in Large Networks of Computers", Communications + of the ACM, Vol. 21 (12), pp. 993-999, December 1978. + + [4] Denning, D., and G. Sacco, "Time stamps in Key Distribution + Protocols", Communications of the ACM, Vol. 24 (8), pp. 533-536, + August 1981. + + [5] Kohl, J., Neuman, C., and T. Ts'o, "The Evolution of the + Kerberos Authentication Service", in an IEEE Computer Society + Text soon to be published, June 1992. + + [6] Davis, D., and R. Swick, "Workstation Services and Kerberos + Authentication at Project Athena", Technical Memorandum TM-424, + MIT Laboratory for Computer Science, February 1990. + + [7] Levine, P., Gretzinger, M, Diaz, J., Sommerfeld, W., and K. + Raeburn, "Section E.1: Service Management System, M.I.T. + Project Athena, Cambridge, Mas sachusetts (1987). + + [8] CCITT, Recommendation X.509: The Directory Authentication + Framework, December 1988. + + [9] Neuman, C., "Proxy-Based Authorization and Accounting for + Distributed Systems," in Proceedings of the 13th International + Conference on Distributed Computing Systems", Pittsburgh, PA, + May 1993. + + [10] Pato, J., "Using Pre-Authentication to Avoid Password Guessing + Attacks", Open Software Foundation DCE Request for Comments 26, + December 1992. + + [11] National Bureau of Standards, U.S. Department of Commerce, "Data + Encryption Standard", Federal Information Processing Standards + Publication 46, Washington, DC (1977). + + + + + +Kohl & Neuman [Page 89] + +RFC 1510 Kerberos September 1993 + + + [12] National Bureau of Standards, U.S. Department of Commerce, "DES + Modes of Operation", Federal Information Processing Standards + Publication 81, Springfield, VA, December 1980. + + [13] Stubblebine S., and V. Gligor, "On Message Integrity in + Cryptographic Protocols", in Proceedings of the IEEE Symposium + on Research in Security and Privacy, Oakland, California, May + 1992. + + [14] International Organization for Standardization, "ISO Information + Processing Systems - Data Communication High-Level Data Link + Control Procedure - Frame Structure", IS 3309, October 1984, 3rd + Edition. + + [15] Rivest, R., "The MD4 Message Digest Algorithm", RFC 1320, MIT + Laboratory for Computer Science, April 1992. + + [16] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, MIT + Laboratory for Computer Science, April 1992. + + [17] Bellovin S., and M. Merritt, "Limitations of the Kerberos + Authentication System", Computer Communications Review, Vol. + 20(5), pp. 119-132, October 1990. + +12. Security Considerations + + Security issues are discussed throughout this memo. + +13. Authors' Addresses + + John Kohl + Digital Equipment Corporation + 110 Spit Brook Road, M/S ZKO3-3/U14 + Nashua, NH 03062 + + Phone: 603-881-2481 + EMail: jtkohl@zk3.dec.com + + + B. Clifford Neuman + USC/Information Sciences Institute + 4676 Admiralty Way #1001 + Marina del Rey, CA 90292-6695 + + Phone: 310-822-1511 + EMail: bcn@isi.edu + + + + + +Kohl & Neuman [Page 90] + +RFC 1510 Kerberos September 1993 + + +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 + + + +Kohl & Neuman [Page 91] + +RFC 1510 Kerberos September 1993 + + +A.2. KRB_AS_REQ verification and KRB_AS_REP generation + decode message into req; + + client := lookup(req.cname,req.realm); + server := lookup(req.sname,req.realm); + get system_time; + kdc_time := system_time.seconds; + + if (!client) then + /* no client in Database */ + error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN); + endif + if (!server) then + /* no server in Database */ + error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN); + endif + + if(client.pa_enc_timestamp_required and + pa_enc_timestamp not present) then + error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)); + endif + + if(pa_enc_timestamp present) then + decrypt req.padata-value into decrypted_enc_timestamp + using client.key; + using auth_hdr.authenticator.subkey; + if (decrypt_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + if(decrypted_enc_timestamp is not within allowable + skew) then error_out(KDC_ERR_PREAUTH_FAILED); + endif + if(decrypted_enc_timestamp and usec is replay) + error_out(KDC_ERR_PREAUTH_FAILED); + endif + add decrypted_enc_timestamp and usec to replay cache; + endif + + use_etype := first supported etype in req.etypes; + + if (no support for req.etypes) then + error_out(KDC_ERR_ETYPE_NOSUPP); + endif + + new_tkt.vno := ticket version; /* = 5 */ + new_tkt.sname := req.sname; + new_tkt.srealm := req.srealm; + reset all flags in new_tkt.flags; + + + + +Kohl & Neuman [Page 92] + +RFC 1510 Kerberos September 1993 + + + /* 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 + if (req.kdc-options.ALLOW-POSTDATE is set) then + set new_tkt.flags.ALLOW-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.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); + + + +Kohl & Neuman [Page 93] + +RFC 1510 Kerberos September 1993 + + + 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; + 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; + + + +Kohl & Neuman [Page 94] + +RFC 1510 Kerberos September 1993 + + + 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); + +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 + + + +Kohl & Neuman [Page 95] + +RFC 1510 Kerberos September 1993 + + + 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; + 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; + + + +Kohl & Neuman [Page 96] + +RFC 1510 Kerberos September 1993 + + + 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; + 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 + + + + +Kohl & Neuman [Page 97] + +RFC 1510 Kerberos September 1993 + + + /* 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 + 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 + + + +Kohl & Neuman [Page 98] + +RFC 1510 Kerberos September 1993 + + + 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; + new_tkt.caddr := req.addresses; + + + +Kohl & Neuman [Page 99] + +RFC 1510 Kerberos September 1993 + + + 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.POSTDATE is set) then + if (tgt.flags.POSTDATE is reset) + error_out(KDC_ERR_BADOPTION); + endif + set new_tkt.flags.POSTDATE; + endif + if (req.kdc-options.POSTDATED is set) then + if (tgt.flags.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 + + + +Kohl & Neuman [Page 100] + +RFC 1510 Kerberos September 1993 + + + error_out(KRB_AP_ERR_REPEAT); + endif + tkt := tgt; + reset new_tkt.flags.INVALID; + endif + + if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW, + and those already processed) is set) then + error_out(KDC_ERR_BADOPTION); + endif + + new_tkt.authtime := tgt.authtime; + + if (req.kdc-options.RENEW is set) then + /* Note that if the endtime has already passed, the ticket */ + /* would have been rejected in the initial authentication */ + /* stage, so there is no need to check again here */ + if (tgt.flags.RENEWABLE is reset) then + error_out(KDC_ERR_BADOPTION); + endif + if (tgt.renew-till >= kdc_time) then + error_out(KRB_AP_ERR_TKT_EXPIRED); + endif + tkt := tgt; + new_tkt.starttime := kdc_time; + old_life := tgt.endttime - tgt.starttime; + new_tkt.endtime := min(tgt.renew-till, + new_tkt.starttime + old_life); + else + new_tkt.starttime := kdc_time; + if (req.till = 0) then + till := infinity; + else + till := req.till; + endif + new_tkt.endtime := min(till, + new_tkt.starttime+client.max_life, + new_tkt.starttime+server.max_life, + new_tkt.starttime+max_life_for_realm, + tgt.endtime); + + if ((req.kdc-options.RENEWABLE-OK is set) and + (new_tkt.endtime < req.till) and + (tgt.flags.RENEWABLE is set) then + /* we set the RENEWABLE option for later */ + /* processing */ + set req.kdc-options.RENEWABLE; + req.rtime := min(req.till, tgt.renew-till); + + + +Kohl & Neuman [Page 101] + +RFC 1510 Kerberos September 1993 + + + endif + endif + + if (req.rtime = 0) then + rtime := infinity; + else + rtime := req.rtime; + endif + + if ((req.kdc-options.RENEWABLE is set) and + (tgt.flags.RENEWABLE is set)) then + set new_tkt.flags.RENEWABLE; + new_tkt.renew-till := min(rtime, + new_tkt.starttime+client.max_rlife, + new_tkt.starttime+server.max_rlife, + new_tkt.starttime+max_rlife_for_realm, + tgt.renew-till); + else + new_tkt.renew-till := OMIT; + /* leave the renew-till field out */ + endif + if (req.enc-authorization-data is present) then + decrypt req.enc-authorization-data + into decrypted_authorization_data + using auth_hdr.authenticator.subkey; + if (decrypt_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + endif + new_tkt.authorization_data := + req.auth_hdr.ticket.authorization_data + + decrypted_authorization_data; + + new_tkt.key := session; + new_tkt.crealm := tgt.crealm; + new_tkt.cname := req.auth_hdr.ticket.cname; + + if (realm_tgt_is_for(tgt) := tgt.realm) then + /* tgt issued by local realm */ + new_tkt.transited := tgt.transited; + else + /* was issued for this realm by some other realm */ + if (tgt.transited.tr-type not supported) then + error_out(KDC_ERR_TRTYPE_NOSUPP); + endif + new_tkt.transited + := compress_transited(tgt.transited + tgt.realm) + endif + + + +Kohl & Neuman [Page 102] + +RFC 1510 Kerberos September 1993 + + + encode encrypted part of new_tkt into OCTET STRING; + if (req.kdc-options.ENC-TKT-IN-SKEY is set) then + if (server not specified) then + server = req.second_ticket.client; + endif + if ((req.second_ticket is not a TGT) or + (req.second_ticket.client != server)) then + error_out(KDC_ERR_POLICY); + endif + + new_tkt.enc-part := encrypt OCTET STRING using + using etype_for_key(second-ticket.key), + second-ticket.key; + else + new_tkt.enc-part := encrypt OCTET STRING + using etype_for_key(server.key), server.key, + server.p_kvno; + endif + + resp.pvno := 5; + resp.msg-type := KRB_TGS_REP; + resp.crealm := tgt.crealm; + resp.cname := tgt.cname; + resp.ticket := new_tkt; + + resp.key := session; + resp.nonce := req.nonce; + resp.last-req := fetch_last_request_info(client); + resp.flags := new_tkt.flags; + + resp.authtime := new_tkt.authtime; + resp.starttime := new_tkt.starttime; + resp.endtime := new_tkt.endtime; + + omit resp.key-expiration; + + resp.sname := new_tkt.sname; + resp.realm := new_tkt.realm; + + if (new_tkt.flags.RENEWABLE) then + resp.renew-till := new_tkt.renew-till; + endif + + + encode body of reply into OCTET STRING; + + if (req.padata.authenticator.subkey) + resp.enc-part := encrypt OCTET STRING using use_etype, + + + +Kohl & Neuman [Page 103] + +RFC 1510 Kerberos September 1993 + + + 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); + +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 + + + +Kohl & Neuman [Page 104] + +RFC 1510 Kerberos September 1993 + + +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}; + 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 + + + +Kohl & Neuman [Page 105] + +RFC 1510 Kerberos September 1993 + + + 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 */ + body.ctime := packet.ctime; + body.cusec := packet.cusec; + + + +Kohl & Neuman [Page 106] + +RFC 1510 Kerberos September 1993 + + + 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 */ + + + +Kohl & Neuman [Page 107] + +RFC 1510 Kerberos September 1993 + + + body.user-data := buffer; /* DATA */ + if (using timestamp) then + get system_time; + body.timestamp, body.usec := system_time; + endif + if (using sequence numbers) then + body.seq-number := sequence number; + endif + body.s-address := sender host addresses; + if (only one recipient) then + body.r-address := recipient host address; + endif + checksum.cksumtype := checksum type; + compute checksum over body; + checksum.checksum := checksum value; /* checksum.checksum */ + packet.cksum := checksum; + packet.safe-body := body; + +A.14. KRB_SAFE verification + 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 + + + +Kohl & Neuman [Page 108] + +RFC 1510 Kerberos September 1993 + + + /* was not sent to proper place */ + error_out(KRB_AP_ERR_BADADDR); + endif + if (((packet.timestamp is present) and + (not in_clock_skew(packet.timestamp,packet.usec))) or + (packet.timestamp is not present and timestamp expected)) + then error_out(KRB_AP_ERR_SKEW); + endif + if (repeated(packet.timestamp,packet.usec,packet.s-address)) + then error_out(KRB_AP_ERR_REPEAT); + endif + if (((packet.seq-number is present) and + ((not in_sequence(packet.seq-number)))) or + (packet.seq-number is not present and sequence expected)) + then error_out(KRB_AP_ERR_BADORDER); + endif + if (packet.timestamp not present and + packet.seq-number not present) then + error_out(KRB_AP_ERR_MODIFIED); + endif + + save_identifier(packet.{timestamp,usec,s-address}, + sender_principal(packet)); + + return PACKET_IS_OK; + +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 + + + + +Kohl & Neuman [Page 109] + +RFC 1510 Kerberos September 1993 + + + encode body into OCTET STRING; + + select encryption type; + encrypt OCTET STRING into packet.enc-part.cipher; + +A.17. KRB_PRIV verification + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_PRIV) then + error_out(KRB_AP_ERR_MSG_TYPE); + endif + + cleartext := decrypt(packet.enc-part) using negotiated key; + if (decryption_error()) then + error_out(KRB_AP_ERR_BAD_INTEGRITY); + endif + + if (safe_priv_common_checks_ok(cleartext)) then + return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED); + else + return common_checks_error; + endif + +A.18. KRB_CRED generation + invoke KRB_TGS; /* obtain tickets to be provided to peer */ + + /* 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; + + + +Kohl & Neuman [Page 110] + +RFC 1510 Kerberos September 1993 + + + body.ticket-info[n].srealm = tickets[n].srealm; + body.ticket-info[n].sname = tickets[n].sname; + body.ticket-info[n].caddr = tickets[n].caddr; + done + + get system_time; + body.timestamp, body.usec := system_time; + + if (using nonce) then + body.nonce := nonce; + endif + + if (using s-address) then + body.s-address := sender host addresses; + endif + if (limited recipients) then + body.r-address := recipient host address; + endif + + encode body into OCTET STRING; + + select encryption type; + encrypt OCTET STRING into packet.enc-part.cipher + using negotiated encryption key; + +A.19. KRB_CRED verification + receive packet; + if (packet.pvno != 5) then + either process using other protocol spec + or error_out(KRB_AP_ERR_BADVERSION); + endif + if (packet.msg-type != KRB_CRED) then + error_out(KRB_AP_ERR_MSG_TYPE); + 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); + + + +Kohl & Neuman [Page 111] + +RFC 1510 Kerberos September 1993 + + + endif + if (not in_clock_skew(packet.timestamp,packet.usec)) then + error_out(KRB_AP_ERR_SKEW); + endif + if (repeated(packet.timestamp,packet.usec,packet.s-address)) + then error_out(KRB_AP_ERR_REPEAT); + endif + if (packet.nonce is required or present) and + (packet.nonce != expected-nonce) then + error_out(KRB_AP_ERR_MODIFIED); + endif + + for (ticket[n] in tickets that were forwarded) do + save_for_later(ticket[n],key[n],principal[n], + server[n],times[n],flags[n]); + return + +A.20. KRB_ERROR generation + + /* assemble packet: */ + packet.pvno := protocol version; /* 5 */ + packet.msg-type := message type; /* KRB_ERROR */ + + get system_time; + packet.stime, packet.susec := system_time; + packet.realm, packet.sname := server name; + + if (client time available) then + packet.ctime, packet.cusec := client_time; + endif + packet.error-code := error code; + if (client name available) then + packet.cname, packet.crealm := client name; + endif + if (error text available) then + packet.e-text := error text; + endif + if (error data available) then + packet.e-data := error data; + endif + + + + + + + + + + + +Kohl & Neuman [Page 112] +
\ No newline at end of file diff --git a/doc/old-V4-docs/README b/doc/old-V4-docs/README new file mode 100644 index 0000000..8858655 --- /dev/null +++ b/doc/old-V4-docs/README @@ -0,0 +1,4 @@ +These documentation files are old --- and refer to the Kerberos V4 +implementation. They are included because the equivalent V5 documentation +set have not been written yet, and the concepts contained in these documents +may be helpful. diff --git a/doc/old-V4-docs/installation.PS b/doc/old-V4-docs/installation.PS new file mode 100644 index 0000000..7609d4e --- /dev/null +++ b/doc/old-V4-docs/installation.PS @@ -0,0 +1,2338 @@ +%!PS-Adobe-2.0 +%%Title: installation.mss +%%DocumentFonts: (atend) +%%Creator: John T Kohl,,E40-351M,31510,6176432831 and Scribe 7(1700) +%%CreationDate: 4 January 1990 11:56 +%%Pages: (atend) +%%EndComments +% PostScript Prelude for Scribe. +/BS {/SV save def 0.0 792.0 translate .01 -.01 scale} bind def +/ES {showpage SV restore} bind def +/SC {setrgbcolor} bind def +/FMTX matrix def +/RDF {WFT SLT 0.0 eq + {SSZ 0.0 0.0 SSZ neg 0.0 0.0 FMTX astore} + {SSZ 0.0 SLT neg sin SLT cos div SSZ mul SSZ neg 0.0 0.0 FMTX astore} + ifelse makefont setfont} bind def +/SLT 0.0 def +/SI { /SLT exch cvr def RDF} bind def +/WFT /Courier findfont def +/SF { /WFT exch findfont def RDF} bind def +/SSZ 1000.0 def +/SS { /SSZ exch 100.0 mul def RDF} bind def +/AF { /WFT exch findfont def /SSZ exch 100.0 mul def RDF} bind def +/MT /moveto load def +/XM {currentpoint exch pop moveto} bind def +/UL {gsave newpath moveto dup 2.0 div 0.0 exch rmoveto + setlinewidth 0.0 rlineto stroke grestore} bind def +/LH {gsave newpath moveto setlinewidth + 0.0 rlineto + gsave stroke grestore} bind def +/LV {gsave newpath moveto setlinewidth + 0.0 exch rlineto + gsave stroke grestore} bind def +/BX {gsave newpath moveto setlinewidth + exch + dup 0.0 rlineto + exch 0.0 exch neg rlineto + neg 0.0 rlineto + closepath + gsave stroke grestore} bind def +/BX1 {grestore} bind def +/BX2 {setlinewidth 1 setgray stroke grestore} bind def +/PB {/PV save def newpath translate + 100.0 -100.0 scale pop /showpage {} def} bind def +/PE {PV restore} bind def +/GB {/PV save def newpath translate rotate + div dup scale 100.0 -100.0 scale /showpage {} def} bind def +/GE {PV restore} bind def +/FB {dict dup /FontMapDict exch def begin} bind def +/FM {cvn exch cvn exch def} bind def +/FE {end /original-findfont /findfont load def /findfont + {dup FontMapDict exch known{FontMapDict exch get} if + original-findfont} def} bind def +/BC {gsave moveto dup 0 exch rlineto exch 0 rlineto neg 0 exch rlineto closepath clip} bind def +/EC /grestore load def +/SH /show load def +/MX {exch show 0.0 rmoveto} bind def +/W {0 32 4 -1 roll widthshow} bind def +/WX {0 32 5 -1 roll widthshow 0.0 rmoveto} bind def +/RC {100.0 -100.0 scale +612.0 0.0 translate +-90.0 rotate +.01 -.01 scale} bind def +/URC {100.0 -100.0 scale +90.0 rotate +-612.0 0.0 translate +.01 -.01 scale} bind def +/RCC {100.0 -100.0 scale +0.0 -792.0 translate 90.0 rotate +.01 -.01 scale} bind def +/URCC {100.0 -100.0 scale +-90.0 rotate 0.0 792.0 translate +.01 -.01 scale} bind def +%%EndProlog +%%Page: 0 1 +BS +0 SI +20 /Times-Bold AF +18823 13788 MT +(Kerberos Installation Notes)SH +27156 15798 MT +(DRAFT)SH +16 /Times-Roman AF +27021 23502 MT +(Bill Bryant)SH +25557 25150 MT +(Jennifer Steiner)SH +27289 26798 MT +(John Kohl)SH +23957 30444 MT +(Project Athena, MIT)SH +/Times-Bold SF +19489 36042 MT +(Initial Release, January 24, 1989)SH +/Times-Italic SF +17558 37690 MT +(\050plus later patches through patchlevel 7\051)SH +11 /Times-Roman AF +7200 45644 MT +(The release consists of three parts.)SH +7200 47942 MT +(The first part consists of the core Kerberos system, which was developed at MIT and does not require)SH +7200 49138 MT +(additional licenses for us to distribute. Included in this part are the Kerberos authentication server, the)SH +7200 50334 MT +(Kerberos library, the)SH +/Times-Italic SF +16606 XM +(ndbm)SH +/Times-Roman SF +19325 XM +(database interface library, user programs, administration programs, manual)SH +7200 51530 MT +(pages, some applications which use Kerberos for authentication, and some utilities.)SH +7200 53828 MT +(The second part is the Data Encryption Standard \050DES\051 library, which we are distributing only within the)SH +7200 55024 MT +(United States.)SH +7200 57322 MT +(The third part contains Kerberos modifications to Sun's NFS, which we distribute as ``context diffs'' to)SH +7200 58518 MT +(the Sun NFS source code. Its distribution is controlled to provide an accounting of who has retrieved the)SH +7200 59714 MT +(patches, so that Project Athena can comply with its agreements with Sun regarding distribution of these)SH +7200 60910 MT +(changes.)SH +ES +%%Page: 1 2 +BS +0 SI +16 /Times-Bold AF +7200 8272 MT +(1. Organization) +400 W( of the Source Directory)SH +11 /Times-Roman AF +7200 10467 MT +(The Kerberos building and installation process, as described in this document, builds the binaries and)SH +7200 11663 MT +(executables from the files contained in the Kerberos source tree, and deposits them in a separate object)SH +7200 12859 MT +(tree. This) +275 W( is intended to easily support several different build trees from a single source tree \050this is useful)SH +7200 14055 MT +(if you support several machine architectures\051. We suggest that you copy the Kerberos sources into a)SH +/Times-Italic SF +7200 15251 MT +(/mit/kerberos/src)SH +/Times-Roman SF +14991 XM +(directory, and create as well a)SH +/Times-Italic SF +28396 XM +(/mit/kerberos/obj)SH +/Times-Roman SF +36249 XM +(directory in which to hold the)SH +7200 16447 MT +(executables. In) +275 W( the rest of this document, we'll refer to the Kerberos source and object directories as)SH +7200 17643 MT +([SOURCE_DIR] and [OBJ_DIR], respectively.)SH +7200 19941 MT +(Below is a brief overview of the organization of the complete source directory. More detailed)SH +7200 21137 MT +(descriptions follow.)SH +/Times-Bold SF +7200 23088 MT +(admin)SH +/Times-Roman SF +18200 XM +(utilities for the Kerberos administrator)SH +/Times-Bold SF +7200 24783 MT +(appl)SH +/Times-Roman SF +18200 XM +(applications that use Kerberos)SH +/Times-Bold SF +7200 26478 MT +(appl/bsd)SH +/Times-Roman SF +18200 XM +(Berkeley's rsh/rlogin suite, using Kerberos)SH +/Times-Bold SF +7200 28173 MT +(appl/knetd)SH +/Times-Roman SF +18200 XM +(\050old\051 software for inetd-like multiplexing of a single TCP listening port)SH +/Times-Bold SF +7200 29868 MT +(appl/sample)SH +/Times-Roman SF +18200 XM +(sample application servers and clients)SH +/Times-Bold SF +7200 31563 MT +(appl/tftp)SH +/Times-Roman SF +18200 XM +(Trivial File Transfer Protocol, using Kerberos)SH +/Times-Bold SF +7200 33258 MT +(include)SH +/Times-Roman SF +18200 XM +(include files)SH +/Times-Bold SF +7200 34953 MT +(kadmin)SH +/Times-Roman SF +18200 XM +(remote administrative interface to the Kerberos master database)SH +/Times-Bold SF +7200 36648 MT +(kuser)SH +/Times-Roman SF +18200 XM +(assorted user programs)SH +/Times-Bold SF +7200 38343 MT +(lib)SH +/Times-Roman SF +18200 XM +(libraries for use with/by Kerberos)SH +/Times-Bold SF +7200 40038 MT +(lib/acl)SH +/Times-Roman SF +18200 XM +(Access Control List library)SH +/Times-Bold SF +7200 41733 MT +(lib/des)SH +/Times-Roman SF +18200 XM +(Data Encryption Standard library \050US only\051)SH +/Times-Bold SF +7200 43428 MT +(lib/kadm)SH +/Times-Roman SF +18200 XM +(administrative interface library)SH +/Times-Bold SF +7200 45123 MT +(lib/kdb)SH +/Times-Roman SF +18200 XM +(Kerberos server library interface to)SH +/Times-Italic SF +33925 XM +(ndbm)SH +/Times-Bold SF +7200 46818 MT +(lib/knet)SH +/Times-Roman SF +18200 XM +(\050old\051 library for use with)SH +/Times-Bold SF +29349 XM +(knetd)SH +7200 48513 MT +(lib/krb)SH +/Times-Roman SF +18200 XM +(Kerberos library)SH +/Times-Bold SF +7200 50208 MT +(man)SH +/Times-Roman SF +18200 XM +(manual pages)SH +/Times-Bold SF +7200 51903 MT +(prototypes)SH +/Times-Roman SF +18200 XM +(sample configuration files)SH +/Times-Bold SF +7200 53598 MT +(server)SH +/Times-Roman SF +18200 XM +(the authentication server)SH +/Times-Bold SF +7200 55293 MT +(slave)SH +/Times-Roman SF +18200 XM +(Kerberos slave database propagation software)SH +/Times-Bold SF +7200 56988 MT +(tools)SH +/Times-Roman SF +18200 XM +(shell scripts for maintaining the source tree)SH +/Times-Bold SF +7200 58683 MT +(util)SH +/Times-Roman SF +18200 XM +(utilities)SH +/Times-Bold SF +7200 60378 MT +(util/imake)SH +/Times-Roman SF +18200 XM +(Imakefile-to-Makefile ``compilation'' tool)SH +/Times-Bold SF +7200 62073 MT +(util/ss)SH +/Times-Roman SF +18200 XM +(Sub-system library \050for command line subsystems\051)SH +/Times-Bold SF +7200 63768 MT +(util/et)SH +/Times-Roman SF +18200 XM +(Error-table library \050for independent, unique error codes\051)SH +/Times-Bold SF +7200 65463 MT +(util/makedepend)SH +/Times-Roman SF +18200 XM +(Makefile dependency generator tool)SH +10 SS +7200 75600 MT +(MIT Project Athena)SH +30350 XM +(1)SH +47890 XM +(4 January 1990)SH +ES +%%Page: 2 3 +BS +0 SI +14 /Times-Bold AF +7200 8167 MT +(1.1 The)350 W +/Times-BoldItalic SF +12334 XM +(admin)SH +/Times-Bold SF +16340 XM +(Directory)SH +11 /Times-Roman AF +7200 10362 MT +(This directory contains source for the Kerberos master database administration tools.)SH +/Times-Bold SF +7200 12313 MT +(kdb_init)SH +/Times-Roman SF +18200 XM +(This program creates and initializes the Kerberos master database. It prompts)SH +18200 13509 MT +(for a Kerberos realmname, and the Kerberos master password.)SH +/Times-Bold SF +7200 15204 MT +(kstash)SH +/Times-Roman SF +18200 XM +(This program ``stashes'' the master password in the file)SH +/Times-Italic SF +43033 XM +(/.k)SH +/Times-Roman SF +44377 XM +(so that the master)SH +18200 16400 MT +(server machine can restart the Kerberos server automatically after an unattended)SH +18200 17596 MT +(reboot. The) +275 W( hidden password is also available to administrative programs that)SH +18200 18792 MT +(have been set to run automatically.)SH +/Times-Bold SF +7200 20487 MT +(kdb_edit)SH +/Times-Roman SF +18200 XM +(This program is a low-level tool for editing the master database.)SH +/Times-Bold SF +7200 22182 MT +(kdb_destroy)SH +/Times-Roman SF +18200 XM +(This program deletes the master database.)SH +/Times-Bold SF +7200 23877 MT +(kdb_util)SH +/Times-Roman SF +18200 XM +(This program can be used to dump the master database into an ascii file, and can)SH +18200 25073 MT +(also be used to load the ascii file into the master database.)SH +/Times-Bold SF +7200 26768 MT +(ext_srvtab)SH +/Times-Roman SF +18200 XM +(This program extracts information from the master database and creates a host-)SH +18200 27964 MT +(dependent)SH +/Times-Italic SF +22995 XM +(srvtab)SH +/Times-Roman SF +26020 XM +(file. This) +275 W( file contains the Kerberos keys for the host's)SH +18200 29160 MT +(``Kerberized'' services. These services look up their keys in the)SH +/Times-Italic SF +46846 XM +(srvtab)SH +/Times-Roman SF +49871 XM +(file for)SH +18200 30356 MT +(use in the authentication process.)SH +14 /Times-Bold AF +7200 34203 MT +(1.2 The)350 W +/Times-BoldItalic SF +12334 XM +(kuser)SH +/Times-Bold SF +15874 XM +(Directory)SH +11 /Times-Roman AF +7200 36398 MT +(This directory contains the source code for several user-oriented programs.)SH +/Times-Bold SF +7200 38349 MT +(kinit)SH +/Times-Roman SF +18200 XM +(This program prompts users for their usernames and Kerberos passwords, then)SH +18200 39545 MT +(furnishes them with Kerberos ticket-granting tickets.)SH +/Times-Bold SF +7200 41240 MT +(kdestroy)SH +/Times-Roman SF +18200 XM +(This program destroys any active tickets. Users should use)SH +/Times-Italic SF +44563 XM +(kdestroy)SH +/Times-Roman SF +48564 XM +(before they)SH +18200 42436 MT +(log off their workstations.)SH +/Times-Bold SF +7200 44131 MT +(klist)SH +/Times-Roman SF +18200 XM +(This program lists a user's active tickets.)SH +/Times-Bold SF +7200 45826 MT +(ksrvtgt)SH +/Times-Roman SF +18200 XM +(This retrieves a ticket-granting ticket with a life time of five minutes, using a)SH +18200 47022 MT +(server's secret key in lieu of a password. It is primarily for use in shell scripts)SH +18200 48218 MT +(and other batch facilities.)SH +/Times-Bold SF +7200 49913 MT +(ksu)SH +/Times-Roman SF +18200 XM +(Substitute user id, using Kerberos to mediate attempts to change to ``root''.)SH +14 /Times-Bold AF +7200 53760 MT +(1.3 The)350 W +/Times-BoldItalic SF +12334 XM +(appl)SH +/Times-Bold SF +15173 XM +(Directory)SH +11 /Times-Roman AF +7200 55955 MT +(If your site has the appropriate BSD license, your Kerberos release provides certain Unix utilities The)SH +7200 57151 MT +(Berkeley programs that have been modified to use Kerberos authentication are found in the)SH +/Times-Italic SF +47640 XM +(appl/bsd)SH +/Times-Roman SF +7200 58347 MT +(directory. They) +275 W( include)SH +/Times-Italic SF +18043 XM +(login)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +20855 XM +(rlogin)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +24095 XM +(rsh)SH +/Times-Roman SF +(, and)SH +/Times-Italic SF +27914 XM +(rcp)SH +/Times-Roman SF +(, as well as the associated daemon programs)SH +/Times-Italic SF +49081 XM +(kshd)SH +/Times-Roman SF +51372 XM +(and)SH +/Times-Italic SF +7200 59543 MT +(klogind)SH +/Times-Roman SF +(. The)275 W +/Times-Italic SF +13310 XM +(login)SH +/Times-Roman SF +15847 XM +(program obtains ticket-granting tickets for users upon login; the other utilities provide)SH +7200 60739 MT +(authenticated Unix network services.)SH +7200 63037 MT +(The)SH +/Times-Italic SF +9185 XM +(appl)SH +/Times-Roman SF +11416 XM +(directory also contains samples Kerberos application client and server programs, an)SH +7200 64233 MT +(authenticated)SH +/Times-Italic SF +13339 XM +(tftp)SH +/Times-Roman SF +15082 XM +(program,)SH +/Times-Italic SF +19358 XM +(knetd)SH +/Times-Roman SF +(, an authenticated inet daemon.)SH +10 SS +7200 75600 MT +(MIT Project Athena)SH +30350 XM +(2)SH +47890 XM +(4 January 1990)SH +ES +%%Page: 3 4 +BS +0 SI +14 /Times-Bold AF +7200 8167 MT +(1.4 The)350 W +/Times-BoldItalic SF +12334 XM +(server)SH +/Times-Bold SF +16185 XM +(Directory)SH +11 /Times-Roman AF +7200 10362 MT +(The)SH +/Times-Italic SF +9185 XM +(server)SH +/Times-Roman SF +12208 XM +(directory contains the Kerberos KDC server, called)SH +/Times-Italic SF +35052 XM +(kerberos)SH +/Times-Roman SF +(. This) +275 W( program manages read-)SH +7200 11558 MT +(only requests made to the master database, distributing tickets and encryption keys to clients requesting)SH +7200 12754 MT +(authentication service.)SH +14 /Times-Bold AF +7200 16601 MT +(1.5 The)350 W +/Times-BoldItalic SF +12334 XM +(kadmin)SH +/Times-Bold SF +17040 XM +(Directory)SH +11 /Times-Roman AF +7200 18796 MT +(The)SH +/Times-Italic SF +9185 XM +(kadmin)SH +/Times-Roman SF +12698 XM +(directory contains the Kerberos administration server and associated client programs. The)SH +7200 19992 MT +(server accepts network requests from the user program)SH +/Times-Italic SF +31570 XM +(kpasswd)SH +/Times-Roman SF +35573 XM +(\050used to change a user's password\051, the)SH +7200 21188 MT +(Kerberos administration program)SH +/Times-Italic SF +22137 XM +(kadmin)SH +/Times-Roman SF +(, and the srvtab utility program)SH +/Times-Italic SF +39276 XM +(ksrvutil)SH +/Times-Roman SF +(. The) +275 W( administration)SH +7200 22384 MT +(server can make modifications to the master database.)SH +14 /Times-Bold AF +7200 26231 MT +(1.6 The)350 W +/Times-BoldItalic SF +12334 XM +(include)SH +/Times-Bold SF +16962 XM +(Directory)SH +11 /Times-Roman AF +7200 28426 MT +(This directory contains the)SH +/Times-Italic SF +19236 XM +(include)SH +/Times-Roman SF +22749 XM +(files needed to build the Kerberos system.)SH +14 /Times-Bold AF +7200 32273 MT +(1.7 The)350 W +/Times-BoldItalic SF +12334 XM +(lib)SH +/Times-Bold SF +14162 XM +(Directory)SH +11 /Times-Roman AF +7200 34468 MT +(The)SH +/Times-Italic SF +9185 XM +(lib)SH +/Times-Roman SF +10622 XM +(directory has six subdirectories:)SH +/Times-Italic SF +25193 XM +(acl)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +27087 XM +(des)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +29103 XM +(kadm)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +32035 XM +(kdb)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +34173 XM +(knet)SH +/Times-Roman SF +(, and)SH +/Times-Italic SF +38418 XM +(krb)SH +/Times-Roman SF +(. The)275 W +/Times-Italic SF +42694 XM +(des)SH +/Times-Roman SF +44435 XM +(directory contains)SH +7200 35664 MT +(source for the DES encryption library. The)SH +/Times-Italic SF +26595 XM +(kadm)SH +/Times-Roman SF +29252 XM +(directory contains source for the Kerberos)SH +7200 36860 MT +(administration server utility library. The)SH +/Times-Italic SF +25439 XM +(kdb)SH +/Times-Roman SF +27302 XM +(directory contains source for the Kerberos database routine)SH +7200 38056 MT +(library. The)275 W +/Times-Italic SF +12942 XM +(knet)SH +/Times-Roman SF +15049 XM +(directory contains source for a library used by clients of the)SH +/Times-Italic SF +41530 XM +(knetd)SH +/Times-Roman SF +44187 XM +(server. The)275 W +/Times-Italic SF +49683 XM +(krb)SH +/Times-Roman SF +7200 39252 MT +(directory contains source for the)SH +/Times-Italic SF +21707 XM +(libkrb.a)SH +/Times-Roman SF +25435 XM +(library. This) +275 W( library contains routines that are used by the)SH +7200 40448 MT +(Kerberos server program, and by applications programs that require authentication service.)SH +14 /Times-Bold AF +7200 44295 MT +(1.8 The)350 W +/Times-BoldItalic SF +12334 XM +(man)SH +/Times-Bold SF +15251 XM +(Directory)SH +11 /Times-Roman AF +7200 46490 MT +(This directory contains manual pages for Kerberos programs and library routines.)SH +14 /Times-Bold AF +7200 50337 MT +(1.9 The)350 W +/Times-BoldItalic SF +12334 XM +(prototypes)SH +/Times-Bold SF +18596 XM +(Directory)SH +11 /Times-Roman AF +7200 52532 MT +(This directory contains prototype)SH +/Times-Italic SF +22108 XM +(/etc/services)SH +/Times-Roman SF +27819 XM +(and)SH +/Times-Italic SF +29682 XM +(/etc/krb.conf)SH +/Times-Roman SF +35486 XM +(files. New) +275 W( entries must be added to the)SH +/Times-Italic SF +7200 53728 MT +(/etc/services)SH +/Times-Roman SF +12911 XM +(file for the Kerberos server, and possibly for Kerberized applications \050)SH +/Times-Italic SF +(services.append)SH +/Times-Roman SF +7200 54924 MT +(contains the entries used by the Athena-provided servers & applications, and is suitable for appending to)SH +7200 56120 MT +(your existing)SH +/Times-Italic SF +13250 XM +(/etc/services)SH +/Times-Roman SF +18961 XM +(file.\051. The)275 W +/Times-Italic SF +23878 XM +(/etc/krb.conf)SH +/Times-Roman SF +29682 XM +(file defines the local Kerberos realm for its host and)SH +7200 57316 MT +(lists Kerberos servers for given realms. The)SH +/Times-Italic SF +26961 XM +(/etc/krb.realms)SH +/Times-Roman SF +33865 XM +(file defines exceptions for mapping machine)SH +7200 58512 MT +(names to Kerberos realms.)SH +14 /Times-Bold AF +7200 62359 MT +(1.10 The)350 W +/Times-BoldItalic SF +13034 XM +(tools)SH +/Times-Bold SF +16107 XM +(Directory)SH +11 /Times-Roman AF +7200 64554 MT +(This directory contains a makefile to set up a directory tree for building the software in, and a shell script)SH +7200 65750 MT +(to format code in the style we use.)SH +10 SS +7200 75600 MT +(MIT Project Athena)SH +30350 XM +(3)SH +47890 XM +(4 January 1990)SH +ES +%%Page: 4 5 +BS +0 SI +14 /Times-Bold AF +7200 8167 MT +(1.11 The)350 W +/Times-BoldItalic SF +13034 XM +(util)SH +/Times-Bold SF +15329 XM +(Directory)SH +11 /Times-Roman AF +7200 10362 MT +(This directory contains several utility programs and libraries. Included are Larry Wall's)SH +/Times-Italic SF +46296 XM +(patch)SH +/Times-Roman SF +49015 XM +(program, a)SH +/Times-Italic SF +7200 11558 MT +(make)SH +/Times-Roman SF +9795 XM +(pre-processor program called)SH +/Times-Italic SF +22956 XM +(imake)SH +/Times-Roman SF +(, and a program for generating Makefile dependencies,)SH +/Times-Italic SF +7200 12754 MT +(makedepend)SH +/Times-Roman SF +(, as well as the Sub-system library and utilities \050)SH +/Times-Italic SF +(ss)SH +/Times-Roman SF +(\051, and the Error table library and utilities)SH +7200 13950 MT +(\050)SH +/Times-Italic SF +(et)SH +/Times-Roman SF +(\051.)SH +16 /Times-Bold AF +7200 18622 MT +(2. Preparing) +400 W( for Installation)SH +11 /Times-Roman AF +7200 20817 MT +(This document assumes that you will build the system on the machine on which you plan to install the)SH +7200 22013 MT +(Kerberos master server and its database. You'll need about 10 megabytes for source and executables.)SH +7200 24311 MT +(By default, there must be a)SH +/Times-Italic SF +19327 XM +(/kerberos)SH +/Times-Roman SF +23756 XM +(directory on the master server machine in which to store the)SH +7200 25507 MT +(Kerberos database files. If the master server machine does not have room on its root partition for these)SH +7200 26703 MT +(files, create a)SH +/Times-Italic SF +13306 XM +(/kerberos)SH +/Times-Roman SF +17735 XM +(symbolic link to another file system.)SH +16 /Times-Bold AF +7200 31375 MT +(3. Preparing) +400 W( for the Build)SH +11 /Times-Roman AF +7200 33570 MT +(Before you build the system, you have to choose a)SH +/Times-Bold SF +29653 XM +(realm name)SH +/Times-Roman SF +(, the name that specifies the system's)SH +7200 34766 MT +(administrative domain. Project Athena uses the internet domain name ATHENA.MIT.EDU to specify its)SH +7200 35962 MT +(Kerberos realm name. We recommend using a name of this form.)SH +/Times-Bold SF +36857 XM +(NOTE:)SH +/Times-Roman SF +40616 XM +(the realm-name is case)SH +7200 37158 MT +(sensitive; by convention, we suggest that you use your internet domain name, in capital letters.)SH +7200 39456 MT +(Edit the [SOURCE_DIR]/)SH +/Times-Italic SF +(include/krb.h)SH +/Times-Roman SF +24860 XM +(file and look for the following lines of code:)SH +10 SS +7200 75600 MT +(MIT Project Athena)SH +30350 XM +(4)SH +47890 XM +(4 January 1990)SH +ES +%%Page: 5 6 +BS +0 SI +11 /Courier AF +8520 7886 MT +(/*)SH +9180 9000 MT +(* Kerberos specific definitions)SH +9180 10114 MT +(*)SH +9180 11228 MT +(* KRBLOG is the log file for the kerberos master server.)SH +9180 12342 MT +(* KRB_CONF is the configuration file where different host)SH +9180 13456 MT +(* machines running master and slave servers can be found.)SH +9180 14570 MT +(* KRB_MASTER is the name of the machine with the master)SH +9180 15684 MT +(* database. The admin_server runs on this machine, and all)SH +9180 16798 MT +(* changes to the db \050as opposed to read-only requests, which)SH +9180 17912 MT +(* can go to slaves\051 must go to it.)SH +9180 19026 MT +(* KRB_HOST is the default machine when looking for a kerberos)SH +9180 20140 MT +(* slave server. Other possibilities are in the KRB_CONF file.)SH +9180 21254 MT +(* KRB_REALM is the name of the realm.)SH +9180 22368 MT +(*/)SH +8520 24596 MT +(#ifdef notdef)SH +8520 25710 MT +(this is server-only, does not belong here;)SH +8520 26824 MT +(#define KRBLOG) +3960 W( "/kerberos/kerberos.log")5940 W +8520 27938 MT +(are these used anyplace '?';)SH +8520 29052 MT +(#define VX_KRB_HSTFILE) +9240 W( "/etc/krbhst")660 W +8520 30166 MT +(#define PC_KRB_HSTFILE) +9240 W( "\134\134kerberos\134\134krbhst")660 W +8520 31280 MT +(#endif)SH +8520 33508 MT +(#define KRB_CONF) +9240 W( "/etc/krb.conf")4620 W +8520 34622 MT +(#define KRB_RLM_TRANS) +9240 W( "/etc/krb.realms")1320 W +8520 35736 MT +(#define KRB_MASTER) +9240 W( "kerberos")3300 W +8520 36850 MT +(#define KRB_HOST) +9240 W( KRB_MASTER)5280 W +8520 37964 MT +(#define KRB_REALM) +9240 W( "ATHENA.MIT.EDU")3960 W +/Times-Roman SF +7200 39559 MT +(Edit the last line as follows:)SH +9400 41510 MT +(1.)SH +10500 XM +(Change the KRB_REALM definition so that it specifies the realm name you have chosen)SH +10500 42706 MT +(for your Kerberos system. This is a default which is usually overridden by a configuration)SH +10500 43902 MT +(file on each machine; however, if that config file is absent, many programs will use this)SH +10500 45098 MT +("built-in" realm name.)SH +14 /Times-Bold AF +7200 48945 MT +(3.1 The)350 W +/Times-BoldItalic SF +12334 XM +(/etc/krb.conf)SH +/Times-Bold SF +19956 XM +(File)SH +11 /Times-Roman AF +7200 51140 MT +(Create a)SH +/Times-Italic SF +11108 XM +(/etc/krb.conf)SH +/Times-Roman SF +16912 XM +(file using the following format:)SH +/Times-BoldItalic SF +8520 52740 MT +(realm_name)SH +8520 53854 MT +(realm_name master_server_name)1045 W +/Courier SF +25594 XM +(admin server)SH +/Times-Roman SF +7200 55449 MT +(where)SH +/Times-Italic SF +10161 XM +(realm_name)SH +/Times-Roman SF +15934 XM +(specifies the system's realm name, and)SH +/Times-Italic SF +33375 XM +(master_server_name)SH +/Times-Roman SF +42874 XM +(specifies the machine)SH +7200 56645 MT +(name on which you will run the master server. The words 'admin server' must appear next to the name of)SH +7200 57841 MT +(the server on which you intend to run the administration server \050which must be a machine with access to)SH +7200 59037 MT +(the database\051.)SH +7200 61335 MT +(For example, if your realm name is)SH +/Times-Italic SF +22962 XM +(tim.edu)SH +/Times-Roman SF +26506 XM +(and your master server's name is)SH +/Times-Italic SF +41288 XM +(kerberos.tim.edu)SH +/Times-Roman SF +(, the file)SH +7200 62531 MT +(should have these contents:)SH +/Courier SF +8520 64057 MT +(tim.edu)SH +8520 65171 MT +(tim.edu kerberos.tim.edu) +660 W( admin server)SH +/Times-Roman SF +7200 67469 MT +(See the [SOURCE_DIR]/)SH +/Times-Italic SF +(prototypes/etc.krb.conf)SH +/Times-Roman SF +28921 XM +(file for an example)SH +/Times-Italic SF +37533 XM +(/etc/krb.conf)SH +/Times-Roman SF +43337 XM +(file. That) +275 W( file has)SH +10 SS +7200 75600 MT +(MIT Project Athena)SH +30350 XM +(5)SH +47890 XM +(4 January 1990)SH +ES +%%Page: 6 7 +BS +0 SI +11 /Times-Roman AF +7200 7955 MT +(examples of how to provide backup servers for a given realm \050additional lines with the same leading)SH +7200 9151 MT +(realm name\051 and how to designate servers for remote realms.)SH +14 /Times-Bold AF +7200 12998 MT +(3.2 The)350 W +/Times-BoldItalic SF +12334 XM +(/etc/krb.realms)SH +/Times-Bold SF +21280 XM +(File)SH +11 /Times-Roman AF +7200 15193 MT +(In many situations, the default realm in which a host operates will be identical to the domain portion its)SH +7200 16389 MT +(Internet domain name.)SH +7200 18687 MT +(If this is not the case, you will need to establish a translation from host name or domain name to realm)SH +7200 19883 MT +(name. This) +275 W( is accomplished with the)SH +/Times-Italic SF +23820 XM +(/etc/krb.realms)SH +/Times-Roman SF +30724 XM +(file.)SH +7200 22181 MT +(Each line of the translation file specifies either a hostname or domain name, and its associated realm:)SH +/Courier SF +8520 23707 MT +(.domain.name kerberos.realm1)SH +8520 24821 MT +(host.name kerberos.realm2)SH +/Times-Roman SF +7200 26416 MT +(For example, to map all hosts in the domain LSC.TIM.EDU to KRB.REALM1 but the host)SH +7200 27612 MT +(FILMS.LSC.TIM.EDU to KRB.REALM2 your file would read:)SH +/Courier SF +8520 29138 MT +(.LSC.TIM.EDU KRB.REALM1)SH +8520 30252 MT +(FILMS.LSC.TIM.EDU KRB.REALM2)SH +/Times-Roman SF +7200 31847 MT +(If a particular host matches both a domain and a host entry, the host entry takes precedence.)SH +16 /Times-Bold AF +7200 36519 MT +(4. Building) +400 W( the Software)SH +11 /Times-Roman AF +7200 38714 MT +(Before you build the software read the)SH +/Times-Bold SF +24395 XM +(README)SH +/Times-Roman SF +29558 XM +(file in [SOURCE_DIR]. What follows is a more)SH +7200 39910 MT +(detailed description of the instructions listed in README.)SH +9400 41861 MT +(1.)SH +10500 XM +(Create an [OBJ_DIR] directory to hold the tree of Kerberos object files you are about to)SH +10500 43057 MT +(build, for example,)SH +/Times-Italic SF +19145 XM +(/mit/kerberos/obj)SH +/Times-Roman SF +(.)SH +9400 44951 MT +(2.)SH +10500 XM +(Change directory to [OBJ_DIR]. The following command creates directories under)SH +10500 46147 MT +([OBJ_DIR] and installs Makefiles for the final build.)SH +/Courier SF +11820 47724 MT +(host%)SH +/Times-Bold SF +15780 XM +(make -f [SOURCE_DIR]/tools/makeconfig SRCDIR=[SOURCE_DIR])275 W +/Times-Roman SF +9400 49618 MT +(3.)SH +10500 XM +(Change directory to util/imake.includes. Read through config.Imakefile, turning on)SH +10500 50814 MT +(appropriate flags for your installation. Change SRCTOP so that it is set to the top level of)SH +10500 52010 MT +(your source directory.)SH +9400 53904 MT +(4.)SH +10500 XM +(Check that your machine type has a definition in include/osconf.h & related files in the)SH +10500 55100 MT +(source tree \050if it doesn't, then you may need to create your own; if you get successful)SH +10500 56296 MT +(results, please post to kerberos@athena.mit.edu\051)SH +9400 58190 MT +(5.)SH +10500 XM +(Change directory to [OBJ_DIR]. The next command generates new Makefiles based on the)SH +10500 59386 MT +(configuration you selected in config.Imakefile, then adds dependency information to the)SH +10500 60582 MT +(Makefiles, and finally builds the system:)SH +/Courier SF +11820 62159 MT +(host%)SH +/Times-Bold SF +15780 XM +(make world)275 W +/Times-Roman SF +10500 63754 MT +(This command takes a while to complete; you may wish to redirect the output onto a file)SH +10500 64950 MT +(and put the job in the background:)SH +/Courier SF +11820 66527 MT +(host%)SH +/Times-Bold SF +15780 XM +(make world) +275 W( >&WORLDLOG_891201 &)SH +/Times-Roman SF +10500 68122 MT +(If you need to rebuild the Kerberos programs and libraries after making a change, you can)SH +10 SS +7200 75600 MT +(MIT Project Athena)SH +30350 XM +(6)SH +47890 XM +(4 January 1990)SH +ES +%%Page: 7 8 +BS +0 SI +11 /Times-Roman AF +10500 7955 MT +(usually just type:)SH +/Courier SF +11820 9532 MT +(host%)SH +/Times-Bold SF +15780 XM +(make all)275 W +/Times-Roman SF +10500 11127 MT +(However, if you changed the configuration in config.Imakefile or modified the Imakefiles)SH +10500 12323 MT +(or Makefiles, you should run)SH +/Times-Italic SF +23514 XM +(make world)SH +/Times-Roman SF +28952 XM +(to re-build all the Makefiles and dependency lists.)SH +14 /Times-Bold AF +7200 16141 MT +(4.1 Testing) +350 W( the DES Library)SH +11 /Times-Roman AF +7200 18336 MT +(Use the)SH +/Times-Italic SF +10804 XM +(verify)SH +/Times-Roman SF +13583 XM +(command to test the DES library implementation:)SH +/Courier SF +8520 19913 MT +(host%)SH +/Times-Bold SF +12480 XM +([OBJ_DIR]/lib/des/verify)SH +/Times-Roman SF +7200 21508 MT +(The command should display the following:)SH +10 SS +7200 75600 MT +(MIT Project Athena)SH +30350 XM +(7)SH +47890 XM +(4 January 1990)SH +ES +%%Page: 8 9 +BS +0 SI +11 /Courier AF +8520 7886 MT +(Examples per FIPS publication 81, keys ivs and cipher)SH +8520 9000 MT +(in hex. These are the correct answers, see below for)SH +8520 10114 MT +(the actual answers.)SH +8520 12342 MT +(Examples per Davies and Price.)SH +8520 14570 MT +(EXAMPLE ECB) +SH( key) +2640 W( = 08192a3b4c5d6e7f)SH +13800 15684 MT +(clear = 0)SH +13800 16798 MT +(cipher = 25 dd ac 3e 96 17 64 67)SH +8520 17912 MT +(ACTUAL ECB)SH +13800 19026 MT +(clear "")SH +13800 20140 MT +(cipher =) +660 W( \050low to high bytes\051)SH +19080 21254 MT +(25 dd ac 3e 96 17 64 67)SH +8520 23482 MT +(EXAMPLE ECB) +SH( key) +2640 W( = 0123456789abcdef)SH +13800 24596 MT +(clear = "Now is the time for all ")SH +13800 25710 MT +(cipher = 3f a4 0e 8a 98 4d 48 15 ...)SH +8520 26824 MT +(ACTUAL ECB)SH +13800 27938 MT +(clear "Now is the time for all ")SH +13800 29052 MT +(cipher =) +660 W( \050low to high bytes\051)SH +19080 30166 MT +(3f a4 0e 8a 98 4d 48 15)SH +8520 32394 MT +(EXAMPLE CBC) +SH( key) +2640 W( = 0123456789abcdef iv = 1234567890abcdef)SH +13800 33508 MT +(clear = "Now is the time for all ")SH +13800 34622 MT +(cipher =) +SH( e5) +4620 W( c7 cd de 87 2b f2 7c)SH +24360 35736 MT +(43 e9 34 00 8c 38 9c 0f)SH +24360 36850 MT +(68 37 88 49 9a 7c 05 f6)SH +8520 37964 MT +(ACTUAL CBC)SH +13800 39078 MT +(clear "Now is the time for all ")SH +13800 40192 MT +(ciphertext = \050low to high bytes\051)SH +19080 41306 MT +(e5 c7 cd de 87 2b f2 7c)SH +19080 42420 MT +(43 e9 34 00 8c 38 9c 0f)SH +19080 43534 MT +(68 37 88 49 9a 7c 05 f6)SH +19080 44648 MT +(00 00 00 00 00 00 00 00)SH +19080 45762 MT +(00 00 00 00 00 00 00 00)SH +19080 46876 MT +(00 00 00 00 00 00 00 00)SH +19080 47990 MT +(00 00 00 00 00 00 00 00)SH +19080 49104 MT +(00 00 00 00 00 00 00 00)SH +13800 50218 MT +(decrypted clear_text = "Now is the time for all ")SH +8520 51332 MT +(EXAMPLE CBC checksum) +SH( key) +1980 W( = 0123456789abcdef iv = 1234567890abcdef)SH +13800 52446 MT +(clear =) +SH( "7654321) +5280 W( Now is the time for ")SH +13800 53560 MT +(checksum 58) +4620 W( d2 e7 7e 86 06 27 33 or some part thereof)SH +8520 54674 MT +(ACTUAL CBC checksum)SH +19080 55788 MT +(encrypted cksum = \050low to high bytes\051)SH +19080 56902 MT +(58 d2 e7 7e 86 06 27 33)SH +/Times-Roman SF +7200 59200 MT +(If the)SH +/Times-Italic SF +9826 XM +(verify)SH +/Times-Roman SF +12605 XM +(command fails to display this information as specified above, the implementation of DES for)SH +7200 60396 MT +(your hardware needs to be adjusted. Your Kerberos system cannot work properly if your DES library)SH +7200 61592 MT +(fails this test.)SH +7200 63890 MT +(When you have finished building the software, you will find the executables in the object tree as follows:)SH +/Times-Bold SF +7200 65841 MT +([OBJ_DIR]/admin)SH +/Times-Italic SF +18200 XM +(ext_srvtab)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +23332 XM +(kdb_destroy)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +29258 XM +(kdb_edit)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +33596 XM +(kdb_init)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +37752 XM +(kdb_util)SH +/Times-Roman SF +(, and)SH +/Times-Italic SF +43771 XM +(kstash)SH +/Times-Roman SF +(.)SH +/Times-Bold SF +7200 67536 MT +([OBJ_DIR]/kuser)SH +/Times-Italic SF +18200 XM +(kdestroy)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +22476 XM +(kinit)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +24982 XM +(klist)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +27366 XM +(ksrvtgt)SH +/Times-Roman SF +(, and)SH +/Times-Italic SF +32773 XM +(ksu)SH +/Times-Roman SF +(.)SH +10 SS +7200 75600 MT +(MIT Project Athena)SH +30350 XM +(8)SH +47890 XM +(4 January 1990)SH +ES +%%Page: 9 10 +BS +0 SI +11 /Times-Bold AF +7200 7955 MT +([OBJ_DIR]/server)SH +/Times-Italic SF +18200 XM +(kerberos)SH +/Times-Roman SF +(.)SH +/Times-Bold SF +7200 9650 MT +([OBJ_DIR]/appl/bsd)SH +/Times-Italic SF +18200 XM +(klogind)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +22050 XM +(kshd)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +24616 XM +(login.krb)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +29169 XM +(rcp)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +31185 XM +(rlogin)SH +/Times-Roman SF +(, and)SH +/Times-Italic SF +36288 XM +(rsh)SH +/Times-Roman SF +(.)SH +/Times-Bold SF +7200 11345 MT +([OBJ_DIR]/appl/knetd)SH +/Times-Italic SF +18200 XM +(knetd)SH +/Times-Roman SF +(.)SH +/Times-Bold SF +7200 13040 MT +([OBJ_DIR]/appl/sample)SH +/Times-Italic SF +18200 14236 MT +(sample_server)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +25164 XM +(sample_client)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +31824 XM +(simple_server)SH +/Times-Roman SF +(, and)SH +/Times-Italic SF +40407 XM +(simple_client)SH +/Times-Roman SF +(.)SH +/Times-Bold SF +7200 15931 MT +([OBJ_DIR]/appl/tftp)SH +/Times-Italic SF +18200 XM +(tcom)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +20888 XM +(tftpd)SH +/Times-Roman SF +(, and)SH +/Times-Italic SF +25319 XM +(tftp)SH +/Times-Roman SF +(.)SH +/Times-Bold SF +7200 17626 MT +([OBJ_DIR]/slave)SH +/Times-Italic SF +18200 XM +(kprop)SH +/Times-Roman SF +21041 XM +(and)SH +/Times-Italic SF +22904 XM +(kpropd)SH +/Times-Roman SF +(.)SH +16 /Times-Bold AF +7200 22298 MT +(5. Installing) +400 W( the Software)SH +11 /Times-Roman AF +7200 24493 MT +(To install the software, issue the)SH +/Times-Italic SF +21711 XM +(make install)SH +/Times-Roman SF +27333 XM +(command from the [OBJ_DIR] \050you need to be a privileged)SH +7200 25689 MT +(user in order to properly install the programs\051. Programs can either be installed in default directories, or)SH +7200 26885 MT +(under a given root directory, as described below.)SH +14 /Times-Bold AF +7200 30703 MT +(5.1 The) +350 W( ``Standard'' Places)SH +11 /Times-Roman AF +7200 32898 MT +(If you use the)SH +/Times-Italic SF +13492 XM +(make)SH +/Times-Roman SF +16087 XM +(command as follows:)SH +/Courier SF +8520 34475 MT +(host#)SH +/Times-Bold SF +12480 XM +(make install)275 W +/Times-Roman SF +7200 36070 MT +(the installation process will try to install the various parts of the system in ``standard'' directories. This)SH +7200 37266 MT +(process creates the ``standard'' directories as needed.)SH +7200 39564 MT +(The standard installation process copies things as follows:)SH +/Symbol SF +9169 41640 MT +(\267)SH +/Times-Roman SF +9950 XM +(The)SH +/Times-Italic SF +11935 XM +(include)SH +/Times-Roman SF +15448 XM +(files)SH +/Times-Italic SF +17617 XM +(krb.h)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +20458 XM +(des.h)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +23299 XM +(mit-copyright.h)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +30662 XM +(kadm.h)SH +/Times-Roman SF +34144 XM +(and)SH +/Times-Italic SF +36007 XM +(kadm_err.h)SH +/Times-Roman SF +41383 XM +(get copied to the)SH +/Times-Italic SF +9950 42836 MT +(/usr/include)SH +/Times-Roman SF +15481 XM +(directory.)SH +/Symbol SF +9169 44730 MT +(\267)SH +/Times-Roman SF +9950 XM +(The Kerberos libraries)SH +/Times-Italic SF +20119 XM +(libdes.a)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +24122 XM +(libkrb.a)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +28125 XM +(libkdb.a)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +32250 XM +(libkadm.a)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +37169 XM +(libknet.a)SH +/Times-Roman SF +(, and)SH +/Times-Italic SF +43401 XM +(libacl.a)SH +/Times-Roman SF +47007 XM +(get)SH +9950 45926 MT +(copied to the)SH +/Times-Italic SF +15907 XM +(/usr/athena/lib)SH +/Times-Roman SF +22662 XM +(\050or wherever you pointed LIBDIR in config.Imakefile\051)SH +9950 47122 MT +(directory.)SH +/Symbol SF +9169 49016 MT +(\267)SH +/Times-Roman SF +9950 XM +(The Kerberos master database utilities)SH +/Times-Italic SF +27085 XM +(kdb_init)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +31241 XM +(kdb_destroy)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +37167 XM +(kdb_edit)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +41505 XM +(kdb_util)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +45661 XM +(kstash)SH +/Times-Roman SF +(, and)SH +/Times-Italic SF +9950 50212 MT +(ext_srvtab)SH +/Times-Roman SF +14807 XM +(get copied to the)SH +/Times-Italic SF +22383 XM +(/usr/etc)SH +/Times-Roman SF +25958 XM +(\050DAEMDIR\051 directory.)SH +/Symbol SF +9169 52106 MT +(\267)SH +/Times-Roman SF +9950 XM +(The Kerberos user utilities)SH +/Times-Italic SF +21924 XM +(kinit)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +24430 XM +(kdestroy)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +28706 XM +(klist)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +31090 XM +(ksrvtgt)SH +/Times-Roman SF +34359 XM +(and)SH +/Times-Italic SF +36222 XM +(ksu)SH +/Times-Roman SF +37963 XM +(get copied to the)SH +/Times-Italic SF +45539 XM +(/usr/athena)SH +/Times-Roman SF +9950 53302 MT +(\050PROGDIR\051 directory.)SH +/Symbol SF +9169 55196 MT +(\267)SH +/Times-Roman SF +9950 XM +(The modified Berkeley utilities)SH +/Times-Italic SF +24004 XM +(rsh)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +25960 XM +(rlogin)SH +/Times-Roman SF +28925 XM +(get copied to the)SH +/Times-Italic SF +36501 XM +(/usr/ucb)SH +/Times-Roman SF +40382 XM +(\050UCBDIR\051 directory;)SH +/Times-Italic SF +9950 56392 MT +(rcp)SH +/Times-Roman SF +11691 XM +(gets copied to the)SH +/Times-Italic SF +19695 XM +(/bin)SH +/Times-Roman SF +21682 XM +(\050SLASHBINDIR\051 directory; and)SH +/Times-Italic SF +36375 XM +(rlogind)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +40165 XM +(rshd)SH +/Times-Roman SF +(, and)SH +/Times-Italic SF +44534 XM +(login.krb)SH +/Times-Roman SF +48812 XM +(get)SH +9950 57588 MT +(copied to the)SH +/Times-Italic SF +15907 XM +(/usr/etc)SH +/Times-Roman SF +19482 XM +(\050DAEMDIR\051 directory. The old copies of the user programs are)SH +9950 58784 MT +(renamed)SH +/Times-Italic SF +14011 XM +(rsh.ucb)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +17830 XM +(rlogin.ucb)SH +/Times-Roman SF +22658 XM +(and)SH +/Times-Italic SF +24521 XM +(rcp.ucb)SH +/Times-Roman SF +(, respectively. The Kerberos versions of these)SH +9950 59980 MT +(programs are designed to fall back and execute the original versions if something prevents)SH +9950 61176 MT +(the Kerberos versions from succeeding.)SH +/Symbol SF +9169 63070 MT +(\267)SH +/Times-Roman SF +9950 XM +(The Kerberos version of)SH +/Times-Italic SF +20944 XM +(tftp)SH +/Times-Roman SF +22687 XM +(and)SH +/Times-Italic SF +24550 XM +(tcom)SH +/Times-Roman SF +26963 XM +(get copied to the)SH +/Times-Italic SF +34539 XM +(/usr/athena)SH +/Times-Roman SF +39826 XM +(\050PROGDIR\051 directory;)SH +/Times-Italic SF +9950 64266 MT +(tftpd)SH +/Times-Roman SF +12243 XM +(gets copied to the)SH +/Times-Italic SF +20247 XM +(/etc)SH +/Times-Roman SF +22110 XM +(\050ETCDIR\051 directory.)SH +/Times-Italic SF +31884 XM +(tftp)SH +/Times-Roman SF +33627 XM +(and)SH +/Times-Italic SF +35490 XM +(tftpd)SH +/Times-Roman SF +37783 XM +(are installed set-uid to an)SH +9950 65462 MT +(unprivileged user \050user id of DEF_UID\051.)SH +/Symbol SF +9169 67356 MT +(\267)SH +/Times-Roman SF +9950 XM +(The)SH +/Times-Italic SF +11935 XM +(knetd)SH +/Times-Roman SF +14592 XM +(daemon gets copied to the)SH +/Times-Italic SF +26353 XM +(/usr/etc)SH +/Times-Roman SF +29928 XM +(\050DAEMDIR\051 directory.)SH +10 SS +7200 75600 MT +(MIT Project Athena)SH +30350 XM +(9)SH +47890 XM +(4 January 1990)SH +ES +%%Page: 10 11 +BS +0 SI +11 /Symbol AF +9169 8080 MT +(\267)SH +/Times-Roman SF +9950 XM +(The Kerberos server)SH +/Times-Italic SF +19201 XM +(kerberos)SH +/Times-Roman SF +(, the slave propagation software)SH +/Times-Italic SF +37343 XM +(kprop)SH +/Times-Roman SF +40184 XM +(and)SH +/Times-Italic SF +42047 XM +(kpropd)SH +/Times-Roman SF +(, and the)SH +9950 9276 MT +(administration server)SH +/Times-Italic SF +19542 XM +(kadmind)SH +/Times-Roman SF +23605 XM +(get copied to the)SH +/Times-Italic SF +31181 XM +(/usr/etc)SH +/Times-Roman SF +34756 XM +(\050SVRDIR, SVRDIR, and)SH +9950 10472 MT +(DAEMDIR\051 directory.)SH +/Symbol SF +9169 12366 MT +(\267)SH +/Times-Roman SF +9950 XM +(The remote administration tools)SH +/Times-Italic SF +24310 XM +(kpasswd)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +28588 XM +(ksrvutil)SH +/Times-Roman SF +32163 XM +(and)SH +/Times-Italic SF +34026 XM +(kadmin)SH +/Times-Roman SF +37539 XM +(get copied to the)SH +/Times-Italic SF +45115 XM +(/usr/athena)SH +/Times-Roman SF +9950 13562 MT +(\050PROGDIR\051 directory.)SH +/Symbol SF +9169 15456 MT +(\267)SH +/Times-Roman SF +9950 XM +(The Kerberos manual pages get installed in the appropriate)SH +/Times-Italic SF +36187 XM +(/usr/man)SH +/Times-Roman SF +40374 XM +(directories. Don't)275 W +9950 16652 MT +(forget to run)SH +/Times-Italic SF +15723 XM +(makewhatis)SH +/Times-Roman SF +21192 XM +(after installing the manual pages.)SH +14 /Times-Bold AF +7200 20470 MT +(5.2 ``Non-Standard'') +350 W( Installation)SH +11 /Times-Roman AF +7200 22665 MT +(If you'd rather install the software in a different location, you can use the)SH +/Times-Italic SF +39667 XM +(make)SH +/Times-Roman SF +42262 XM +(command as follows,)SH +7200 23861 MT +(where [DEST_DIR] specifies an alternate destination directory which will be used as the root for the)SH +7200 25057 MT +(installed programs, i.e. programs that would normally be installed in /usr/athena would be installed in)SH +7200 26253 MT +([DEST_DIR]/usr/athena.)SH +/Courier SF +8520 27830 MT +(host#)SH +/Times-Bold SF +12480 XM +(make install DESTDIR=[DEST_DIR])275 W +16 SS +7200 32502 MT +(6. Conclusion)400 W +11 /Times-Roman AF +7200 34697 MT +(Now that you have built and installed your Kerberos system, use the accompanying Kerberos Operation)SH +4030 50 44224 34897 UL +4398 50 48529 34897 UL +7200 35893 MT +(Notes to create a Kerberos Master database, install authenticated services, and start the Kerberos server.)SH +2566 50 7200 36093 UL +16 /Times-Bold AF +7200 40565 MT +(7. Acknowledgements)400 W +11 /Times-Roman AF +7200 42760 MT +(We'd like to thank Henry Mensch and Jon Rochlis for helping us debug this document.)SH +10 SS +7200 75600 MT +(MIT Project Athena)SH +30100 XM +(10)SH +47890 XM +(4 January 1990)SH +ES +%%Page: i 12 +BS +0 SI +14 /Times-Bold AF +25272 8138 MT +(Table of Contents)SH +13 SS +7200 9781 MT +(1. Organization) +325 W( of the Source Directory)SH +53350 XM +(1)SH +12 /Times-Roman AF +9000 11136 MT +(1.1 The)300 W +/Times-BoldItalic SF +13266 XM +(admin)SH +/Times-Roman SF +16701 XM +(Directory)SH +53400 XM +(2)SH +9000 12491 MT +(1.2 The)300 W +/Times-BoldItalic SF +13266 XM +(kuser)SH +/Times-Roman SF +16300 XM +(Directory)SH +53400 XM +(2)SH +9000 13846 MT +(1.3 The)300 W +/Times-BoldItalic SF +13266 XM +(appl)SH +/Times-Roman SF +15700 XM +(Directory)SH +53400 XM +(2)SH +9000 15201 MT +(1.4 The)300 W +/Times-BoldItalic SF +13266 XM +(server)SH +/Times-Roman SF +16566 XM +(Directory)SH +53400 XM +(3)SH +9000 16556 MT +(1.5 The)300 W +/Times-BoldItalic SF +13266 XM +(kadmin)SH +/Times-Roman SF +17301 XM +(Directory)SH +53400 XM +(3)SH +9000 17911 MT +(1.6 The)300 W +/Times-BoldItalic SF +13266 XM +(include)SH +/Times-Roman SF +17234 XM +(Directory)SH +53400 XM +(3)SH +9000 19266 MT +(1.7 The)300 W +/Times-BoldItalic SF +13266 XM +(lib)SH +/Times-Roman SF +14834 XM +(Directory)SH +53400 XM +(3)SH +9000 20621 MT +(1.8 The)300 W +/Times-BoldItalic SF +13266 XM +(man)SH +/Times-Roman SF +15767 XM +(Directory)SH +53400 XM +(3)SH +9000 21976 MT +(1.9 The)300 W +/Times-BoldItalic SF +13266 XM +(prototypes)SH +/Times-Roman SF +18634 XM +(Directory)SH +53400 XM +(3)SH +9000 23331 MT +(1.10 The)300 W +/Times-BoldItalic SF +13866 XM +(tools)SH +/Times-Roman SF +16501 XM +(Directory)SH +53400 XM +(3)SH +9000 24686 MT +(1.11 The)300 W +/Times-BoldItalic SF +13866 XM +(util)SH +/Times-Roman SF +15835 XM +(Directory)SH +53400 XM +(4)SH +13 /Times-Bold AF +7200 26329 MT +(2. Preparing) +325 W( for Installation)SH +53350 XM +(4)SH +7200 27972 MT +(3. Preparing) +325 W( for the Build)SH +53350 XM +(4)SH +12 /Times-Roman AF +9000 29327 MT +(3.1 The)300 W +/Times-BoldItalic SF +13266 XM +(/etc/krb.conf)SH +/Times-Roman SF +19801 XM +(File)SH +53400 XM +(5)SH +9000 30682 MT +(3.2 The)300 W +/Times-BoldItalic SF +13266 XM +(/etc/krb.realms)SH +/Times-Roman SF +20936 XM +(File)SH +53400 XM +(6)SH +13 /Times-Bold AF +7200 32325 MT +(4. Building) +325 W( the Software)SH +53350 XM +(6)SH +12 /Times-Roman AF +9000 33674 MT +(4.1 Testing) +300 W( the DES Library)SH +53400 XM +(7)SH +13 /Times-Bold AF +7200 35317 MT +(5. Installing) +325 W( the Software)SH +53350 XM +(9)SH +12 /Times-Roman AF +9000 36666 MT +(5.1 The) +300 W( ``Standard'' Places)SH +53400 XM +(9)SH +9000 38015 MT +(5.2 ``Non-Standard'') +300 W( Installation)SH +52800 XM +(10)SH +13 /Times-Bold AF +7200 39658 MT +(6. Conclusion)325 W +52700 XM +(10)SH +7200 41301 MT +(7. Acknowledgements)325 W +52700 XM +(10)SH +10 /Times-Roman AF +7200 75600 MT +(MIT Project Athena)SH +30461 XM +(i)SH +47890 XM +(4 January 1990)SH +ES +%%Trailer +%%Pages: 12 +%%DocumentFonts: Times-Roman Times-Bold Times-Italic Times-BoldItalic Courier Symbol diff --git a/doc/old-V4-docs/installation.mss b/doc/old-V4-docs/installation.mss new file mode 100644 index 0000000..0a2ae75 --- /dev/null +++ b/doc/old-V4-docs/installation.mss @@ -0,0 +1,681 @@ +@Comment[ $Source$] +@Comment[ $Author$] +@Comment[ $Id$] +@Comment[] +@device[postscript] +@make[report] +@comment[ +@DefineFont(HeadingFont, + P=<RawFont "NewCenturySchlbkBoldItalic">, + B=<RawFont "NewCenturySchlbkBold">, + I=<RawFont "NewCenturySchlbkBoldItalic">, + R=<RawFont "NewCenturySchlbkRoman">) +] +@DefineFont(HeadingFont, + P=<RawFont "TimesBoldItalic">, + B=<RawFont "TimesBold">, + I=<RawFont "TimesItalic">, + R=<RawFont "TimesRoman">) +@Counter(MajorPart,TitleEnv HD0,ContentsEnv tc0,Numbered [@I], + IncrementedBy Use,Announced) +@Counter(Chapter,TitleEnv HD1,ContentsEnv tc1,Numbered [@1. ], + IncrementedBy Use,Referenced [@1],Announced) +@Counter(Appendix,TitleEnv HD1,ContentsEnv tc1,Numbered [@A. ], + IncrementedBy,Referenced [@A],Announced,Alias Chapter) +@Counter(UnNumbered,TitleEnv HD1,ContentsEnv tc1,Announced,Alias + Chapter) +@Counter(Section,Within Chapter,TitleEnv HD2,ContentsEnv tc2, + Numbered [@#@:.@1 ],Referenced [@#@:.@1],IncrementedBy + Use,Announced) +@Counter(AppendixSection,Within Appendix,TitleEnv HD2, + ContentsEnv tc2, + Numbered [@#@:.@1 ],Referenced [@#@:.@1],IncrementedBy + Use,Announced) +@Counter(SubSection,Within Section,TitleEnv HD3,ContentsEnv tc3, + Numbered [@#@:.@1 ],IncrementedBy Use, + Referenced [@#@:.@1 ]) +@Counter(AppendixSubSection,Within AppendixSection,TitleEnv HD3, + ContentsEnv tc3, + Numbered [@#@:.@1 ],IncrementedBy Use, + Referenced [@#@:.@1 ]) +@Counter(Paragraph,Within SubSection,TitleEnv HD4,ContentsEnv tc4, + Numbered [@#@:.@1 ],Referenced [@#@:.@1], + IncrementedBy Use) +@modify(CopyrightNotice, Fixed -1 inch, Flushright) +@Modify(Titlebox, Fixed 3.0 inches) +@Modify(hd1, below .2 inch, facecode B, size 16, spaces kept, pagebreak off) +@Modify(hd2, below .2 inch, facecode B, size 14, spaces kept) +@Modify(hd3, below .2 inch, facecode B, size 12, spaces kept) +@Modify(Description, Leftmargin +20, Indent -20,below 1 line, above 1 line) +@Modify(Tc1, Above .5, Facecode B) +@Modify(Tc2, Above .25, Below .25, Facecode R) +@Modify(Tc3,Facecode R) +@Modify(Tc4,Facecode R) +@Modify(Itemize,Above 1line,Below 1line) +@Modify(Insert,LeftMargin +2, RightMargin +2) +@libraryfile[stable] +@comment[@Style(Font NewCenturySchoolBook, size 11)] +@Style(Font TimesRoman, size 11) +@Style(Spacing 1.1, indent 0) +@Style(leftmargin 1.0inch) +@Style(justification no) +@Style(BottomMargin 1.5inch) +@Style(ChangeBarLocation Right) +@Style(ChangeBars=off) +@pageheading[immediate] +@pagefooting[immediate, left = "MIT Project Athena", center = "@value(page)", +right = "@value(date)"] +@set[page = 0] +@blankspace[.5 inches] +@begin[group, size 20] +@begin(center) +@b[Kerberos Installation Notes] +@b[DRAFT] +@end[center] +@end(group) +@blankspace[.5 inches] +@begin[group, size 16] +@begin(center) +Bill Bryant +Jennifer Steiner +John Kohl +@blankspace[1 line] +Project Athena, MIT +@blankspace[.5 inches] +@b[Initial Release, January 24, 1989] +@i[(plus later patches through patchlevel 7)] +@end[center] +@end(group) +@begin[group, size 10] +@end[group] +@blankspace[.75 inches] + + +The release consists of three parts. + +The first part consists of the core Kerberos system, which was developed +at MIT and does not require additional licenses for us to distribute. +Included in this part are the Kerberos authentication server, the +Kerberos library, the +@i[ndbm] +database interface library, user programs, administration programs, +manual pages, some applications which use Kerberos for authentication, +and some utilities. + +The second part is the Data Encryption Standard (DES) library, which we +are distributing only within the United States. + +The third part contains Kerberos modifications to Sun's NFS, which we +distribute as ``context diffs'' to the Sun NFS source code. Its +distribution is controlled to provide an accounting of who has retrieved +the patches, so that Project Athena can comply with its agreements with +Sun regarding distribution of these changes. + +@newpage() +@chapter[Organization of the Source Directory] + +The Kerberos building and installation process, +as described in this document, +builds the binaries and executables from the files contained in the Kerberos +source tree, and deposits them in a separate object tree. +This is intended to easily support several different build trees from a +single source tree (this is useful if you support several machine +architectures). +We suggest that you copy the Kerberos sources into a +@i[/mit/kerberos/src] directory, +and create as well a @i[/mit/kerberos/obj] directory in which +to hold the executables. +In the rest of this document, we'll refer to the Kerberos +source and object directories as [SOURCE_DIR] +and [OBJ_DIR], respectively. + +Below is a brief overview of the organization of the complete +source directory. +More detailed descriptions follow. + +@begin[description] + +@b[admin]@\utilities for the Kerberos administrator + +@b[appl]@\applications that use Kerberos + +@b[appl/bsd]@\Berkeley's rsh/rlogin suite, using Kerberos + +@b[appl/knetd]@\(old) software for inetd-like multiplexing of a single +TCP listening port + +@b[appl/sample]@\sample application servers and clients + +@b[appl/tftp]@\Trivial File Transfer Protocol, using Kerberos + +@b[include]@\include files + +@b[kadmin]@\remote administrative interface to the Kerberos master database + +@b[kuser]@\assorted user programs + +@b[lib]@\libraries for use with/by Kerberos + +@b[lib/acl]@\Access Control List library + +@b[lib/des]@\Data Encryption Standard library (US only) + +@b[lib/kadm]@\administrative interface library + +@b[lib/kdb]@\Kerberos server library interface to @i[ndbm] + +@b[lib/knet]@\(old) library for use with @b[knetd] + +@b[lib/krb]@\Kerberos library + +@b[man]@\manual pages + +@b[prototypes]@\sample configuration files + +@b[server]@\the authentication server + +@b[slave]@\Kerberos slave database propagation software + +@b[tools]@\shell scripts for maintaining the source tree + +@b[util]@\utilities + +@b[util/imake]@\Imakefile-to-Makefile ``compilation'' tool + +@b[util/ss]@\Sub-system library (for command line subsystems) + +@b[util/et]@\Error-table library (for independent, unique error codes) + +@b[util/makedepend]@\Makefile dependency generator tool + +@end[description] + +@section[The @p(admin) Directory] + +This directory contains source for +the Kerberos master database administration tools. +@begin[description] +@b[kdb_init]@\This program creates and initializes the +Kerberos master database. +It prompts for a Kerberos realmname, and the Kerberos master password. + +@b[kstash]@\This program ``stashes'' the master password in the file +@i[/.k] so that the master server machine can restart the Kerberos +server automatically after an unattended reboot. +The hidden password is also available to administrative programs +that have been set to run automatically. + +@b[kdb_edit]@\This program is a low-level tool for editing +the master database. + +@b[kdb_destroy]@\This program deletes the master database. + +@b[kdb_util]@\This program can be used to dump the master database +into an ascii file, and can also be used to load the ascii file +into the master database. + +@b[ext_srvtab]@\This program extracts information from the master +database and creates a host-dependent @i[srvtab] file. +This file contains the Kerberos keys for the host's +``Kerberized'' services. +These services look up their keys in the @i[srvtab] file +for use in the authentication process. +@end[description] + +@section[The @p(kuser) Directory] + +This directory contains the source code for several user-oriented +programs. +@begin[description] +@b[kinit]@\This program prompts users for their usernames and +Kerberos passwords, then furnishes them with Kerberos ticket-granting +tickets. + +@b[kdestroy]@\This program destroys any active tickets. +Users should use @i[kdestroy] before they log off their workstations. + +@b[klist]@\This program lists a user's active tickets. + +@b[ksrvtgt]@\This retrieves a ticket-granting ticket with a life time +of five minutes, using a server's secret key in lieu of a password. It +is primarily for use in shell scripts and other batch facilities. + +@b[ksu]@\Substitute user id, using Kerberos to mediate attempts to +change to ``root''. +@end[description] + +@section[The @p(appl) Directory] + +If your site has the appropriate BSD license, +your Kerberos release provides certain Unix utilities +The Berkeley programs that have been modified to use Kerberos +authentication are found in the @i[appl/bsd] directory. +They include @i[login], @i[rlogin], @i[rsh], and @i[rcp], as well as the +associated daemon programs @i[kshd] and @i[klogind]. +The @i[login] program obtains ticket-granting tickets for users +upon login; the other utilities provide authenticated +Unix network services. + +The @i[appl] directory also contains samples Kerberos application +client and server programs, an authenticated @i[tftp] program, +@i[knetd], an authenticated inet daemon. + +@section[The @p(server) Directory] + +The @i[server] directory contains the Kerberos KDC server, called +@i[kerberos]. +This program manages read-only requests made to the +master database, +distributing tickets and encryption keys to clients requesting +authentication service. + +@section[The @p(kadmin) Directory] + +The @i[kadmin] directory contains the Kerberos administration server and +associated client programs. +The server accepts network requests from the +user program @i[kpasswd] (used to change a user's password), the +Kerberos administration program @i(kadmin), and the srvtab utility +program @i[ksrvutil]. +The administration server can make modifications to the master database. + +@section[The @p(include) Directory] + +This directory contains the @i[include] files needed to +build the Kerberos system. + +@section[The @p(lib) Directory] + +The @i[lib] directory has six subdirectories: +@i[acl], @i[des], @i[kadm], @i[kdb], @i[knet], and @i[krb]. +The @i[des] directory contains source for the DES encryption library. +The @i[kadm] directory contains source for the Kerberos administration +server utility library. +The @i[kdb] directory contains source for the Kerberos database +routine library. +The @i[knet] directory contains source for a library used by clients of +the @i[knetd] server. +The @i[krb] directory contains source for the @i[libkrb.a] +library. +This library contains routines that are used by the Kerberos server program, +and by applications programs that require authentication service. + +@section[The @p(man) Directory] + +This directory contains manual pages for Kerberos programs and +library routines. + +@section[The @p(prototypes) Directory] + +This directory contains prototype +@i[/etc/services] and @i[/etc/krb.conf] files. +New entries must be added to the @i[/etc/services] file for +the Kerberos server, and possibly for Kerberized applications +(@i[services.append] contains the entries used by the Athena-provided +servers & applications, and is suitable for appending to your existing +@i[/etc/services] file.). +The @i[/etc/krb.conf] file defines the local Kerberos realm +for its host and lists Kerberos servers for given realms. +The @i[/etc/krb.realms] file defines exceptions for mapping machine +names to Kerberos realms. + +@section[The @p(tools) Directory] + +This directory contains +a makefile to set up a directory tree +for building the software in, and +a shell script to format code in the +style we use. + + +@section[The @p(util) Directory] + +This directory contains several utility programs and libraries. +Included are Larry Wall's @i[patch] program, a @i[make] pre-processor +program called +@i[imake], and a program for generating Makefile dependencies, +@i[makedepend], as well as the Sub-system library and +utilities (@i[ss]), and the Error table library and utilities (@i[et]). + +@chapter[Preparing for Installation] + +This document assumes that you will build the system +on the machine on which you plan to install +the Kerberos master server and its database. +You'll need about 10 megabytes for source and executables. + +By default, there must be +a @i[/kerberos] directory on the master server machine +in which to store the Kerberos +database files. +If the master server machine does not have room on its root partition +for these files, +create a @i[/kerberos] symbolic link to another file system. + +@chapter[Preparing for the Build] + +Before you build the system, +you have to choose a @b[realm name], +the name that specifies the system's administrative domain. +Project Athena uses the internet domain name ATHENA.MIT.EDU +to specify its Kerberos realm name. +We recommend using a name of this form. +@b[NOTE:] the realm-name is case sensitive; by convention, we suggest +that you use your internet domain name, in capital letters. + +Edit the [SOURCE_DIR]/@i[include/krb.h] file and look for the following +lines of code: +@begin[example] +/* + * Kerberos specific definitions + * + * KRBLOG is the log file for the kerberos master server. + * KRB_CONF is the configuration file where different host + * machines running master and slave servers can be found. + * KRB_MASTER is the name of the machine with the master + * database. The admin_server runs on this machine, and all + * changes to the db (as opposed to read-only requests, which + * can go to slaves) must go to it. + * KRB_HOST is the default machine when looking for a kerberos + * slave server. Other possibilities are in the KRB_CONF file. + * KRB_REALM is the name of the realm. + */ + +#ifdef notdef +this is server-only, does not belong here; +#define KRBLOG "/kerberos/kerberos.log" +are these used anyplace '?'; +#define VX_KRB_HSTFILE "/etc/krbhst" +#define PC_KRB_HSTFILE "\\kerberos\\krbhst" +#endif + +#define KRB_CONF "/etc/krb.conf" +#define KRB_RLM_TRANS "/etc/krb.realms" +#define KRB_MASTER "kerberos" +#define KRB_HOST KRB_MASTER +#define KRB_REALM "ATHENA.MIT.EDU" +@end[example] +Edit the last line as follows: +@begin[enumerate] +Change the KRB_REALM definition so that it specifies the realm name +you have chosen for your Kerberos system. This is a default which is +usually overridden by a configuration file on each machine; however, if +that config file is absent, many programs will use this "built-in" realm +name. +@end[enumerate] + +@section[The @p(/etc/krb.conf) File] + +Create a @i[/etc/krb.conf] file using the following format: +@begin[example] +@p[realm_name] +@p[realm_name] @p[master_server_name] admin server +@end[example] +where @i[realm_name] specifies the system's realm name, +and @i[master_server_name] specifies the machine name on +which you will run the master server. The words 'admin server' must +appear next to the name of the server on which you intend to run the +administration server (which must be a machine with access to the database). + +For example, +if your realm name is @i[tim.edu] and your master server's name is +@i[kerberos.tim.edu], the file should have these contents: +@begin[example] +tim.edu +tim.edu kerberos.tim.edu admin server +@end[example] + +See the [SOURCE_DIR]/@i[prototypes/etc.krb.conf] file for an +example @i[/etc/krb.conf] file. That file has examples of how to +provide backup servers for a given realm (additional lines with the same +leading realm name) and how to designate servers for remote realms. + +@section[The @p(/etc/krb.realms) File] + +In many situations, the default realm in which a host operates will be +identical to the domain portion its Internet domain name. + +If this is not the case, you will need to establish a translation from +host name or domain name to realm name. This is accomplished with the +@i(/etc/krb.realms) file. + +Each line of the translation file specifies either a hostname or domain +name, and its associated realm: +@begin[example] +.domain.name kerberos.realm1 +host.name kerberos.realm2 +@end[example] +For example, to map all hosts in the domain LSC.TIM.EDU to KRB.REALM1 +but the host FILMS.LSC.TIM.EDU to KRB.REALM2 your file would read: +@begin[example] +.LSC.TIM.EDU KRB.REALM1 +FILMS.LSC.TIM.EDU KRB.REALM2 +@end[example] +If a particular host matches both a domain and a host entry, the host +entry takes precedence. + +@chapter[Building the Software] + +Before you build the software +read the @b[README] file in [SOURCE_DIR]. +What follows is a more detailed description of the instructions +listed in README. +@begin[enumerate] +Create an [OBJ_DIR] directory to hold the tree of Kerberos object files you +are about to build, for example, +@i[/mit/kerberos/obj]. + +Change directory to [OBJ_DIR]. +The following command creates directories under [OBJ_DIR] +and installs Makefiles for the final build. +@begin[example, rightmargin -7] +host% @b(make -f [SOURCE_DIR]/tools/makeconfig SRCDIR=[SOURCE_DIR]) +@end[example] + + + +Change directory to util/imake.includes. Read through config.Imakefile, +turning on appropriate flags for your installation. Change SRCTOP so +that it is set to the top level of your source directory. + +Check that your machine type has a definition in include/osconf.h & +related files in the source tree (if it doesn't, then you may need to +create your own; if you get successful results, please post to +kerberos@@athena.mit.edu) + +Change directory to [OBJ_DIR]. The next command generates new Makefiles +based on the configuration you selected in config.Imakefile, then adds +dependency information to the Makefiles, and finally builds the system: +@begin[example, rightmargin -7] +host% @b(make world) +@end[example] +This command takes a while to complete; you may wish to redirect the +output onto a file and put the job in the background: +@begin[example, rightmargin -7] +host% @b(make world >&WORLDLOG_891201 &) +@end[example] +If you need to rebuild the Kerberos programs and libraries after making +a change, you can usually just type: +@begin[example, rightmargin -7] +host% @b(make all) +@end[example] +However, if you changed the configuration in config.Imakefile or modified +the Imakefiles or Makefiles, you should run @i[make world] to re-build +all the Makefiles and dependency lists. +@end(enumerate) + +@section[Testing the DES Library] + +Use the @i[verify] command to test the DES library +implementation: +@begin[example] +host% @b([OBJ_DIR]/lib/des/verify) +@end[example] +The command should display the following: +@begin[example, rightmargin -10] +Examples per FIPS publication 81, keys ivs and cipher +in hex. These are the correct answers, see below for +the actual answers. + +Examples per Davies and Price. + +EXAMPLE ECB key = 08192a3b4c5d6e7f + clear = 0 + cipher = 25 dd ac 3e 96 17 64 67 +ACTUAL ECB + clear "" + cipher = (low to high bytes) + 25 dd ac 3e 96 17 64 67 + +EXAMPLE ECB key = 0123456789abcdef + clear = "Now is the time for all " + cipher = 3f a4 0e 8a 98 4d 48 15 ... +ACTUAL ECB + clear "Now is the time for all " + cipher = (low to high bytes) + 3f a4 0e 8a 98 4d 48 15 + +EXAMPLE CBC key = 0123456789abcdef iv = 1234567890abcdef + clear = "Now is the time for all " + cipher = e5 c7 cd de 87 2b f2 7c + 43 e9 34 00 8c 38 9c 0f + 68 37 88 49 9a 7c 05 f6 +ACTUAL CBC + clear "Now is the time for all " + ciphertext = (low to high bytes) + e5 c7 cd de 87 2b f2 7c + 43 e9 34 00 8c 38 9c 0f + 68 37 88 49 9a 7c 05 f6 + 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 + decrypted clear_text = "Now is the time for all " +EXAMPLE CBC checksum key = 0123456789abcdef iv = 1234567890abcdef + clear = "7654321 Now is the time for " + checksum 58 d2 e7 7e 86 06 27 33 or some part thereof +ACTUAL CBC checksum + encrypted cksum = (low to high bytes) + 58 d2 e7 7e 86 06 27 33 +@end[example] + +If the @i[verify] command fails to display this information as specified +above, the implementation of DES for your hardware needs to +be adjusted. +Your Kerberos system cannot work properly if your DES library +fails this test. + +When you have finished building the software, +you will find the executables in the object tree as follows: +@begin[description] +@b([OBJ_DIR]/admin)@\@i[ext_srvtab], @i[kdb_destroy], +@i[kdb_edit], @i[kdb_init], @i[kdb_util], and @i[kstash]. + +@b([OBJ_DIR]/kuser)@\@i[kdestroy], @i[kinit], @i[klist], @i[ksrvtgt], +and @i[ksu]. + +@b([OBJ_DIR]/server)@\@i[kerberos]. + +@b([OBJ_DIR]/appl/bsd)@\@i[klogind], @i[kshd], @i[login.krb], @i[rcp], +@i[rlogin], and @i[rsh]. + +@b([OBJ_DIR]/appl/knetd)@\@i[knetd]. + +@b([OBJ_DIR]/appl/sample)@\@i[sample_server], @i[sample_client], +@i[simple_server], and @i[simple_client]. + +@b([OBJ_DIR]/appl/tftp)@\@i[tcom], @i[tftpd], and @i[tftp]. + +@b([OBJ_DIR]/slave)@\@i[kprop] and @i[kpropd]. +@end[description] + +@chapter[Installing the Software] + +To install the software, issue the @i[make install] command from +the [OBJ_DIR] (you need to be a privileged user in order to +properly install the programs). +Programs can either be installed in default directories, or under +a given root directory, as described below. + +@section[The ``Standard'' Places] + +If you use the @i[make] command as follows: +@begin[example] +host# @b(make install) +@end[example] +the installation process will try to install the various parts of the +system in ``standard'' directories. +This process creates the ``standard'' directories as needed. + +The standard installation process copies things as follows: +@begin[itemize] +The @i[include] files @i[krb.h], @i[des.h], @i[mit-copyright.h], +@i[kadm.h] and @i[kadm_err.h] get copied to the +@i[/usr/include] directory. + +The Kerberos libraries @i[libdes.a], @i[libkrb.a], @i[libkdb.a], +@i[libkadm.a], @i[libknet.a], and @i[libacl.a] get copied +to the @i[/usr/athena/lib] (or wherever you pointed LIBDIR in +config.Imakefile) directory. + +The Kerberos master database utilities @i[kdb_init], @i[kdb_destroy], +@i[kdb_edit], @i[kdb_util], @i[kstash], and @i[ext_srvtab] get copied to +the @i[/usr/etc] (DAEMDIR) directory. + +The Kerberos user utilities @i[kinit], @i[kdestroy], @i[klist], +@i[ksrvtgt] and @i[ksu] get copied to the @i[/usr/athena] (PROGDIR) +directory. + +The modified Berkeley utilities @i[rsh], @i[rlogin] get copied to the +@i[/usr/ucb] (UCBDIR) directory; @i[rcp] gets copied to the @i[/bin] +(SLASHBINDIR) directory; and @i[rlogind], @i[rshd], and @i[login.krb] +get copied to the @i[/usr/etc] (DAEMDIR) directory. The old copies of +the user programs are renamed @i(rsh.ucb), @i(rlogin.ucb) and +@i(rcp.ucb), respectively. The Kerberos versions of these programs are +designed to fall back and execute the original versions if something +prevents the Kerberos versions from succeeding. + +The Kerberos version of @i[tftp] and @i[tcom] get copied to the +@i[/usr/athena] (PROGDIR) directory; @i[tftpd] gets copied to the +@i[/etc] (ETCDIR) directory. @i[tftp] and @i[tftpd] are installed +set-uid to an unprivileged user (user id of DEF_UID). + +The @i[knetd] daemon gets copied to the @i[/usr/etc] (DAEMDIR) directory. + +The Kerberos server @i[kerberos], the slave propagation software +@i[kprop] and @i[kpropd], and the administration server @i[kadmind] get +copied to the @i[/usr/etc] (SVRDIR, SVRDIR, and DAEMDIR) directory. + +The remote administration tools @i[kpasswd], @i[ksrvutil] and @i[kadmin] +get copied to the @i[/usr/athena] (PROGDIR) directory. + +The Kerberos manual pages get installed in the appropriate +@i[/usr/man] directories. Don't forget to run @i[makewhatis] +after installing the manual pages. + +@end[itemize] + +@section[``Non-Standard'' Installation] + +If you'd rather install the software in a different location, +you can use the @i[make] command as follows, +where [DEST_DIR] specifies an alternate destination directory +which will be used as the root for the installed programs, i.e. programs +that would normally be installed in /usr/athena would be installed in +[DEST_DIR]/usr/athena. +@begin[example] +host# @b(make install DESTDIR=[DEST_DIR]) +@end[example] + +@chapter[Conclusion] + +Now that you have built and installed your Kerberos system, +use the accompanying @u[Kerberos Operation Notes] +to create a Kerberos Master database, install authenticated services, +and start the Kerberos server. + +@chapter [Acknowledgements] + +We'd like to thank Henry Mensch and Jon Rochlis for helping us debug +this document. diff --git a/doc/old-V4-docs/operation.PS b/doc/old-V4-docs/operation.PS new file mode 100644 index 0000000..3afb8cf --- /dev/null +++ b/doc/old-V4-docs/operation.PS @@ -0,0 +1,2669 @@ +%!PS-Adobe-2.0 +%%Title: operation.mss +%%DocumentFonts: (atend) +%%Creator: John T Kohl,,E40-351M,31510,6176432831 and Scribe 7(1700) +%%CreationDate: 4 January 1990 11:55 +%%Pages: (atend) +%%EndComments +% PostScript Prelude for Scribe. +/BS {/SV save def 0.0 792.0 translate .01 -.01 scale} bind def +/ES {showpage SV restore} bind def +/SC {setrgbcolor} bind def +/FMTX matrix def +/RDF {WFT SLT 0.0 eq + {SSZ 0.0 0.0 SSZ neg 0.0 0.0 FMTX astore} + {SSZ 0.0 SLT neg sin SLT cos div SSZ mul SSZ neg 0.0 0.0 FMTX astore} + ifelse makefont setfont} bind def +/SLT 0.0 def +/SI { /SLT exch cvr def RDF} bind def +/WFT /Courier findfont def +/SF { /WFT exch findfont def RDF} bind def +/SSZ 1000.0 def +/SS { /SSZ exch 100.0 mul def RDF} bind def +/AF { /WFT exch findfont def /SSZ exch 100.0 mul def RDF} bind def +/MT /moveto load def +/XM {currentpoint exch pop moveto} bind def +/UL {gsave newpath moveto dup 2.0 div 0.0 exch rmoveto + setlinewidth 0.0 rlineto stroke grestore} bind def +/LH {gsave newpath moveto setlinewidth + 0.0 rlineto + gsave stroke grestore} bind def +/LV {gsave newpath moveto setlinewidth + 0.0 exch rlineto + gsave stroke grestore} bind def +/BX {gsave newpath moveto setlinewidth + exch + dup 0.0 rlineto + exch 0.0 exch neg rlineto + neg 0.0 rlineto + closepath + gsave stroke grestore} bind def +/BX1 {grestore} bind def +/BX2 {setlinewidth 1 setgray stroke grestore} bind def +/PB {/PV save def newpath translate + 100.0 -100.0 scale pop /showpage {} def} bind def +/PE {PV restore} bind def +/GB {/PV save def newpath translate rotate + div dup scale 100.0 -100.0 scale /showpage {} def} bind def +/GE {PV restore} bind def +/FB {dict dup /FontMapDict exch def begin} bind def +/FM {cvn exch cvn exch def} bind def +/FE {end /original-findfont /findfont load def /findfont + {dup FontMapDict exch known{FontMapDict exch get} if + original-findfont} def} bind def +/BC {gsave moveto dup 0 exch rlineto exch 0 rlineto neg 0 exch rlineto closepath clip} bind def +/EC /grestore load def +/SH /show load def +/MX {exch show 0.0 rmoveto} bind def +/W {0 32 4 -1 roll widthshow} bind def +/WX {0 32 5 -1 roll widthshow 0.0 rmoveto} bind def +/RC {100.0 -100.0 scale +612.0 0.0 translate +-90.0 rotate +.01 -.01 scale} bind def +/URC {100.0 -100.0 scale +90.0 rotate +-612.0 0.0 translate +.01 -.01 scale} bind def +/RCC {100.0 -100.0 scale +0.0 -792.0 translate 90.0 rotate +.01 -.01 scale} bind def +/URCC {100.0 -100.0 scale +-90.0 rotate 0.0 792.0 translate +.01 -.01 scale} bind def +%%EndProlog +%%Page: 0 1 +BS +0 SI +20 /Times-Bold AF +19324 13788 MT +(Kerberos Operation Notes)SH +27156 15798 MT +(DRAFT)SH +16 /Times-Roman AF +27021 23502 MT +(Bill Bryant)SH +27289 25150 MT +(John Kohl)SH +23957 26798 MT +(Project Athena, MIT)SH +/Times-Bold SF +19489 32396 MT +(Initial Release, January 24, 1989)SH +/Times-Italic SF +17558 34044 MT +(\050plus later patches through patchlevel 7\051)SH +11 /Times-Roman AF +7200 43798 MT +(These notes assume that you have used the)SH +/Times-Italic SF +26322 XM +(Kerberos Installation Notes)SH +/Times-Roman SF +38821 XM +(to build and install your Kerberos)SH +7200 44994 MT +(system. As) +275 W( in that document, we refer to the directory that contains the built Kerberos binaries as)SH +7200 46190 MT +([OBJ_DIR].)SH +7200 48488 MT +(This document assumes that you are a Unix system manager.)SH +ES +%%Page: 1 2 +BS +0 SI +16 /Times-Bold AF +7200 8272 MT +(1. How) +400 W( Kerberos Works: A Schematic Description)SH +11 /Times-Roman AF +7200 10467 MT +(This section provides a simplified description of a general user's interaction with the Kerberos system.)SH +7200 11663 MT +(This interaction happens transparently--users don't need to know and probably don't care about what's)SH +7200 12859 MT +(going on--but Kerberos administrators might find a schematic description of the process useful. The)SH +7200 14055 MT +(description glosses over a lot of details; for more information, see)SH +/Times-Italic SF +36404 XM +(Kerberos: An Authentication Service)SH +7200 15251 MT +(for Open Network Systems)SH +/Times-Roman SF +(, a paper presented at Winter USENIX 1988, in Dallas, Texas.)SH +14 /Times-Bold AF +7200 19069 MT +(1.1 Network) +350 W( Services and Their Client Programs)SH +11 /Times-Roman AF +7200 21264 MT +(In an environment that provides network services, you use)SH +/Times-Italic SF +33164 XM +(client)SH +/Times-Roman SF +35883 XM +(programs to request service from)SH +/Times-Italic SF +50696 XM +(server)SH +/Times-Roman SF +7200 22460 MT +(programs that are somewhere on the network. Suppose you have logged in to a workstation and you want)SH +7200 23656 MT +(to)SH +/Times-Italic SF +8331 XM +(rlogin)SH +/Times-Roman SF +11296 XM +(to another machine. You use the local)SH +/Times-Italic SF +28493 XM +(rlogin)SH +/Times-Roman SF +31458 XM +(client program to contact the remote machine's)SH +/Times-Italic SF +7200 24852 MT +(rlogin)SH +/Times-Roman SF +10165 XM +(service daemon.)SH +14 /Times-Bold AF +7200 28670 MT +(1.2 Kerberos) +350 W( Tickets)SH +11 /Times-Roman AF +7200 30865 MT +(Under Kerberos, the)SH +/Times-Italic SF +16422 XM +(rlogin)SH +/Times-Roman SF +19387 XM +(service program allows a client to login to a remote machine if it can provide)SH +7200 32061 MT +(a Kerberos)SH +/Times-Bold SF +12268 XM +(ticket)SH +/Times-Roman SF +15169 XM +(for the request. This ticket proves the identity of the person who has used the client)SH +7200 33257 MT +(program to access the server program.)SH +14 /Times-Bold AF +7200 37075 MT +(1.3 The) +350 W( Kerberos Master Database)SH +11 /Times-Roman AF +7200 39270 MT +(Kerberos will give you tickets only if you have an entry in the Kerberos server's)SH +/Times-Bold SF +42845 XM +(master database)SH +/Times-Roman SF +(. Your)275 W +7200 40466 MT +(database entry includes your Kerberos username \050often referred to as your Kerberos)SH +/Times-Bold SF +44394 XM +(principal)SH +/Times-Roman SF +48949 XM +(name\051, and)SH +7200 41662 MT +(your Kerberos password. Every Kerberos user must have an entry in this database.)SH +14 /Times-Bold AF +7200 45480 MT +(1.4 The) +350 W( Ticket-Granting Ticket)SH +11 /Times-Roman AF +7200 47675 MT +(The)SH +/Times-Italic SF +9185 XM +(kinit)SH +/Times-Roman SF +11416 XM +(command prompts for your Kerberos username and password, and if you enter them)SH +7200 48871 MT +(successfully, you will obtain a Kerberos)SH +/Times-Italic SF +25131 XM +(ticket-granting ticket)SH +/Times-Roman SF +(. As) +275 W( illustrated below, client programs use)SH +7200 50067 MT +(this ticket to get other Kerberos tickets as needed.)SH +14 /Times-Bold AF +7200 53885 MT +(1.5 Network) +350 W( Services and the Master Database)SH +11 /Times-Roman AF +7200 56080 MT +(The master database also contains entries for all network services that require Kerberos authentication.)SH +7200 57276 MT +(Suppose for instance that your site has a machine)SH +/Times-Italic SF +29163 XM +(laughter)SH +/Times-Roman SF +33166 XM +(that requires Kerberos authentication from)SH +7200 58472 MT +(anyone who wants to)SH +/Times-Italic SF +16792 XM +(rlogin)SH +/Times-Roman SF +19757 XM +(to it. This service must be registered in the master database. Its entry)SH +7200 59668 MT +(includes the service's principal name, and its)SH +/Times-Bold SF +27238 XM +(instance)SH +/Times-Roman SF +(.)SH +7200 61966 MT +(The)SH +/Times-Italic SF +9185 XM +(instance)SH +/Times-Roman SF +13126 XM +(is the name of the service's machine; in this case, the service's instance is the name)SH +/Times-Italic SF +7200 63162 MT +(laughter)SH +/Times-Roman SF +(. The) +275 W( instance provides a means for Kerberos to distinguish between machines that provide the)SH +7200 64358 MT +(same service. Your site is likely to have more than one machine that provides)SH +/Times-Italic SF +41840 XM +(rlogin)SH +/Times-Roman SF +44805 XM +(service.)SH +10 SS +7200 75600 MT +(MIT Project Athena)SH +30350 XM +(1)SH +47890 XM +(4 January 1990)SH +ES +%%Page: 2 3 +BS +0 SI +14 /Times-Bold AF +7200 8138 MT +(1.6 The) +350 W( User-Kerberos Interaction)SH +11 /Times-Roman AF +7200 10333 MT +(Suppose that you \050in the guise of a general user\051 walk up to a workstation intending to login to it, and)SH +7200 11529 MT +(then)SH +/Times-Italic SF +9369 XM +(rlogin)SH +/Times-Roman SF +12334 XM +(to the machine)SH +/Times-Italic SF +19085 XM +(laughter)SH +/Times-Roman SF +(. Here's) +275 W( what happens.)SH +9400 13480 MT +(1.)SH +10500 XM +(You login to the workstation and use the)SH +/Times-Italic SF +28648 XM +(kinit)SH +/Times-Roman SF +30879 XM +(command to to get a ticket-granting ticket.)SH +10500 14676 MT +(This command prompts you for your username \050your Kerberos Principal Name\051, and your)SH +10500 15872 MT +(Kerberos password [on some systems which use the new version of)SH +/Times-Italic SF +40465 XM +(/bin/login)SH +/Times-Roman SF +(, this may be)SH +10500 17068 MT +(done as part of the login process, not requiring the user to run a separate program].)SH +12762 19019 MT +(a.)SH +13800 XM +(The)SH +/Times-Italic SF +15785 XM +(kinit)SH +/Times-Roman SF +18016 XM +(command sends your request to the Kerberos master server machine. The)SH +13800 20215 MT +(server software looks for your principal name's entry in the Kerberos)SH +/Times-Bold SF +44555 XM +(master)SH +13800 21411 MT +(database)SH +/Times-Roman SF +(.)SH +12700 23305 MT +(b.)SH +13800 XM +(If this entry exists, the Kerberos server creates and returns a)SH +/Times-Italic SF +40430 XM +(ticket-granting ticket)SH +/Times-Roman SF +(,)SH +13800 24501 MT +(encrypted in your password. If)SH +/Times-Italic SF +27819 XM +(kinit)SH +/Times-Roman SF +30050 XM +(can decrypt the Kerberos reply using the)SH +13800 25697 MT +(password you provide, it stores this ticket in a)SH +/Times-Bold SF +34270 XM +(ticket file)SH +/Times-Roman SF +38912 XM +(on your local machine for)SH +13800 26893 MT +(later use. The ticket file to be used can be specified in the)SH +/Times-Bold SF +39609 XM +(KRBTKFILE)SH +/Times-Roman SF +13800 28089 MT +(environment variable. If this variable is not set, the name of the file will be)SH +/Times-Italic SF +13800 29285 MT +(/tmp/tkt)SH +/Times-BoldItalic SF +(uid)SH +/Times-Roman SF +(, where)SH +/Times-BoldItalic SF +22141 XM +(uid)SH +/Times-Roman SF +23884 XM +(is the UNIX user-id, represented in decimal.)SH +9400 31236 MT +(2.)SH +10500 XM +(Now you use the)SH +/Times-Italic SF +18198 XM +(rlogin)SH +/Times-Roman SF +21163 XM +(client to try to access the machine)SH +/Times-Italic SF +36344 XM +(laughter)SH +/Times-Roman SF +(.)SH +/Courier SF +11820 32813 MT +(host%)SH +/Times-Bold SF +15780 XM +(rlogin laughter)275 W +/Times-Roman SF +12762 34764 MT +(a.)SH +13800 XM +(The)SH +/Times-Italic SF +15785 XM +(rlogin)SH +/Times-Roman SF +18750 XM +(client checks your ticket file to see if you have a ticket for)SH +/Times-Italic SF +44559 XM +(laughter)SH +/Times-Roman SF +('s)SH +/Times-Italic SF +13800 35960 MT +(rcmd)SH +/Times-Roman SF +16335 XM +(service \050the rlogin program uses the)SH +/Times-Italic SF +32401 XM +(rcmd)SH +/Times-Roman SF +34936 XM +(service name, mostly for historical)SH +13800 37156 MT +(reasons\051. You) +275 W( don't, so)SH +/Times-Italic SF +24583 XM +(rlogin)SH +/Times-Roman SF +27548 XM +(uses the ticket file's)SH +/Times-Italic SF +36590 XM +(ticket-granting ticket)SH +/Times-Roman SF +46060 XM +(to make a)SH +13800 38352 MT +(request to the master server's ticket-granting service.)SH +12700 40246 MT +(b.)SH +13800 XM +(This ticket-granting service receives the)SH +/Times-Italic SF +31667 XM +(rcmd-laughter)SH +/Times-Roman SF +38296 XM +(request and looks in the)SH +13800 41442 MT +(master database for an)SH +/Times-Italic SF +23938 XM +(rcmd-laughter)SH +/Times-Roman SF +30567 XM +(entry. If) +275 W( that entry exists, the ticket-granting)SH +13800 42638 MT +(service issues you a ticket for that service. That ticket is also cached in your ticket)SH +13800 43834 MT +(file.)SH +12762 45728 MT +(c.)SH +13800 XM +(The)SH +/Times-Italic SF +15785 XM +(rlogin)SH +/Times-Roman SF +18750 XM +(client now uses that ticket to request service from the)SH +/Times-Italic SF +42454 XM +(laughter rlogin)SH +/Times-Roman SF +13800 46924 MT +(service program. The service program lets you)SH +/Times-Italic SF +34843 XM +(rlogin)SH +/Times-Roman SF +37808 XM +(if the ticket is valid.)SH +16 /Times-Bold AF +7200 51596 MT +(2. Setting) +400 W( Up and Testing the Kerberos Server)SH +11 /Times-Roman AF +7200 53791 MT +(The procedure for setting up and testing a Kerberos server is as follows:)SH +9400 55742 MT +(1.)SH +10500 XM +(Use the)SH +/Times-Italic SF +14104 XM +(kdb_init)SH +/Times-Roman SF +17985 XM +(command to create and initialize the master database.)SH +9400 57636 MT +(2.)SH +10500 XM +(Use the)SH +/Times-Italic SF +14104 XM +(kdb_edit)SH +/Times-Roman SF +18167 XM +(utility to add your username to the master database.)SH +9400 59530 MT +(3.)SH +10500 XM +(Start the Kerberos server.)SH +9400 61424 MT +(4.)SH +10500 XM +(Use the)SH +/Times-Italic SF +14104 XM +(kinit)SH +/Times-Roman SF +16335 XM +(command to obtain a Kerberos ticket-granting ticket.)SH +9400 63318 MT +(5.)SH +10500 XM +(Use the)SH +/Times-Italic SF +14104 XM +(klist)SH +/Times-Roman SF +16213 XM +(command to verify that the)SH +/Times-Italic SF +28402 XM +(kinit)SH +/Times-Roman SF +30633 XM +(command authenticated you successfully.)SH +10 SS +7200 75600 MT +(MIT Project Athena)SH +30350 XM +(2)SH +47890 XM +(4 January 1990)SH +ES +%%Page: 3 4 +BS +0 SI +14 /Times-Bold AF +7200 8138 MT +(2.1 Creating) +350 W( and Initializing the Master Database)SH +11 /Times-Roman AF +7200 10333 MT +(Login to the Kerberos master server machine, and use the)SH +/Times-Bold SF +32825 XM +(su)SH +/Times-Roman SF +34140 XM +(command to become root. If you installed)SH +7200 11529 MT +(the Kerberos administration tools with the)SH +/Times-Italic SF +26020 XM +(make install)SH +/Times-Roman SF +31642 XM +(command and the default pathnames, they should)SH +7200 12725 MT +(be in the)SH +/Times-Italic SF +11263 XM +(/usr/etc)SH +/Times-Roman SF +14838 XM +(directory. If) +275 W( you installed the tools in a different directory, hopefully you know what it)SH +7200 13921 MT +(is. From) +275 W( now on, we will refer to this directory as [ADMIN_DIR].)SH +7200 16219 MT +(The)SH +/Times-Italic SF +9185 XM +(kdb_init)SH +/Times-Roman SF +13066 XM +(command creates and initializes the master database. It asks you to enter the system's realm)SH +7200 17415 MT +(name and the database's master password. Do not forget this password. If you do, the database becomes)SH +7200 18611 MT +(useless. \050Your) +275 W( realm name should be substituted for [REALMNAME] below.\051)SH +7200 20909 MT +(Use)SH +/Times-Italic SF +9185 XM +(kdb_init)SH +/Times-Roman SF +13066 XM +(as follows:)SH +/Courier SF +8520 22486 MT +(host#)SH +/Times-Bold SF +12480 XM +([ADMIN_DIR]/kdb_init)SH +/Courier SF +8520 23600 MT +(Realm name \050default XXX\051:)SH +/Times-Bold SF +25680 XM +([REALMNAME])SH +39600 XM +(<--)SH +/Times-BoldItalic SF +41619 XM +(Enter your system's realm name.)SH +/Courier SF +8520 24714 MT +(You will be prompted for the database Master Password.)SH +8520 25828 MT +(It is important that you NOT FORGET this password.)SH +8520 28056 MT +(Enter Kerberos master key:)SH +/Times-Bold SF +28800 XM +(<--)SH +/Times-BoldItalic SF +30819 XM +(Enter the master password.)SH +14 /Times-Bold AF +7200 32988 MT +(2.2 Storing) +350 W( the Master Password)SH +11 /Times-Roman AF +7200 35183 MT +(The)SH +/Times-Italic SF +9185 XM +(kstash)SH +/Times-Roman SF +12210 XM +(command ``stashes'' the master password in the file)SH +/Times-Italic SF +35424 XM +(/.k)SH +/Times-Roman SF +36768 XM +(so that the Kerberos server can be)SH +7200 36379 MT +(started automatically during an unattended reboot of the master server. Other administrative programs)SH +7200 37575 MT +(use this hidden password so that they can access the master database without someone having to manually)SH +7200 38771 MT +(provide the master password. This command is an optional one; if you'd rather enter the master password)SH +7200 39967 MT +(each time you start the Kerberos server, don't use)SH +/Times-Italic SF +29312 XM +(kstash)SH +/Times-Roman SF +(.)SH +7200 42265 MT +(One the one hand, if you use)SH +/Times-Italic SF +20090 XM +(kstash)SH +/Times-Roman SF +(, a copy of the master key will reside on disk which may not be)SH +7200 43461 MT +(acceptable; on the other hand, if you don't use)SH +/Times-Italic SF +27848 XM +(kstash)SH +/Times-Roman SF +(, the server cannot be started unless someone is)SH +7200 44657 MT +(around to type the password in manually.)SH +7200 46955 MT +(The command prompts you twice for the master password:)SH +/Courier SF +8520 48532 MT +(host#)SH +/Times-Bold SF +12480 XM +([ADMIN_DIR]/kstash)SH +/Courier SF +8520 50760 MT +(Enter Kerberos master key:)SH +/Times-Bold SF +28800 XM +(<--)SH +/Times-BoldItalic SF +30819 XM +(Enter the master password.)SH +/Courier SF +8520 51874 MT +(Current Kerberos master key version is 1.)SH +8520 54102 MT +(Master key entered) +SH( BEWARE!)1320 W +/Times-Roman SF +7200 56400 MT +(A note about the Kerberos database master key: if your master key is compromised and the database is)SH +7200 57596 MT +(obtained, the security of your entire authentication system is compromised. The master key must be a)SH +7200 58792 MT +(carefully kept secret. If you keep backups, you must guard all the master keys you use, in case someone)SH +7200 59988 MT +(has stolen an old backup and wants to attack users' whose passwords haven't changed since the backup)SH +7200 61184 MT +(was stolen. This is why we provide the option not to store it on disk.)SH +10 SS +7200 75600 MT +(MIT Project Athena)SH +30350 XM +(3)SH +47890 XM +(4 January 1990)SH +ES +%%Page: 4 5 +BS +0 SI +14 /Times-Bold AF +7200 8167 MT +(2.3 Using)350 W +/Times-BoldItalic SF +13423 XM +(kdb_edit)SH +/Times-Bold SF +18673 XM +(to Add Users to the Master Database)SH +11 /Times-Roman AF +7200 10362 MT +(The)SH +/Times-Italic SF +9185 XM +(kdb_edit)SH +/Times-Roman SF +13248 XM +(program is used to add new users and services to the master database, and to modify)SH +7200 11558 MT +(existing database information. The program prompts you to enter a principal's)SH +/Times-Bold SF +42177 XM +(name)SH +/Times-Roman SF +45018 XM +(and)SH +/Times-Bold SF +46881 XM +(instance)SH +/Times-Roman SF +(.)SH +7200 13856 MT +(A principal name is typically a username or a service program's name. An instance further qualifies the)SH +7200 15052 MT +(principal. If) +275 W( the principal is a service, the instance is used to specify the name of the machine on which)SH +7200 16248 MT +(that service runs. If the principal is a username that has general user privileges, the instance is usually set)SH +7200 17444 MT +(to null.)SH +7200 19742 MT +(The following example shows how to use)SH +/Times-Italic SF +25805 XM +(kdb_edit)SH +/Times-Roman SF +29868 XM +(to add the user)SH +/Times-Italic SF +36588 XM +(wave)SH +/Times-Roman SF +39123 XM +(to the Kerberos database.)SH +/Courier SF +8520 21319 MT +(host#)SH +/Times-Bold SF +12480 XM +([ADMIN_DIR]/kdb_edit)SH +/Courier SF +8520 23547 MT +(Opening database...)SH +8520 25775 MT +(Enter Kerberos master key:)SH +8520 26889 MT +(Verifying, please re-enter)SH +8520 28003 MT +(Enter Kerberos master key:)SH +8520 29117 MT +(Current Kerberos master key version is 1)SH +8520 31345 MT +(Master key entered. BEWARE!)SH +8520 32459 MT +(Previous or default values are in [brackets] ,)SH +8520 33573 MT +(enter return to leave the same, or new value.)SH +8520 35801 MT +(Principal name:)SH +/Times-Bold SF +19080 XM +(wave)SH +28800 XM +(<--)SH +/Times-BoldItalic SF +30819 XM +(Enter the username.)SH +/Courier SF +8520 36915 MT +(Instance:)SH +/Times-BoldItalic SF +28800 XM +(<-- Enter a null instance.)SH +/Courier SF +8520 39143 MT +(<Not found>, Create [y] ?)SH +/Times-Bold SF +25680 XM +(y)SH +28800 XM +(<--)SH +/Times-BoldItalic SF +30819 XM +(The user-instance does not exist.)SH +30450 40257 MT +(Enter y to create the user-instance.)SH +/Courier SF +8520 41371 MT +(Principal: wave Instance: m_key_v: 1)SH +8520 42485 MT +(New Password:)SH +/Times-BoldItalic SF +28800 XM +(<-- Enter the user-instance's password.)SH +/Courier SF +8520 43599 MT +(Verifying, please re-enter)SH +8520 44713 MT +(New Password:)SH +8520 45827 MT +(Principal's new key version = 1)SH +8520 46941 MT +(Expiration date \050enter dd-mm-yy\051 [ 12/31/99 ] ?)SH +/Times-Bold SF +39600 XM +(<--)SH +/Times-BoldItalic SF +41619 XM +(Enter newlines)SH +/Courier SF +8520 48055 MT +(Max ticket lifetime \050*5 minutes\051 [ 255 ] ?)SH +/Times-Bold SF +39600 XM +(<--)SH +/Times-BoldItalic SF +41619 XM +(to get the)SH +/Courier SF +8520 49169 MT +(Attributes [ 0 ] ?)SH +/Times-Bold SF +30120 XM +(<--)SH +/Times-BoldItalic SF +32139 XM +(default values.)SH +/Courier SF +8520 50283 MT +(Edit O.K.)SH +8520 52511 MT +(Principal name:)SH +/Times-BoldItalic SF +28800 XM +(<-- Enter a newline to exit the program.)SH +/Times-Roman SF +7200 54809 MT +(Use the)SH +/Times-Italic SF +10804 XM +(kdb_edit)SH +/Times-Roman SF +14867 XM +(utility to add your username to the master database.)SH +14 /Times-Bold AF +7200 58627 MT +(2.4 Starting) +350 W( the Kerberos Server)SH +11 /Times-Roman AF +7200 60822 MT +(Change directories to the directory in which you have installed the server program)SH +/Times-Italic SF +43701 XM +(kerberos)SH +/Times-Roman SF +47824 XM +(\050the default)SH +7200 62018 MT +(directory is)SH +/Times-Italic SF +12454 XM +(/usr/etc)SH +/Times-Roman SF +(\051, and start the program as a background process:)SH +/Courier SF +8520 63595 MT +(host#)SH +/Times-Bold SF +12480 XM +(./kerberos &)SH +/Times-Roman SF +7200 65190 MT +(If you have used the)SH +/Times-Italic SF +16393 XM +(kstash)SH +/Times-Roman SF +19418 XM +(command to store the master database password, the server will start)SH +7200 66386 MT +(automatically. If) +275 W( you did not use)SH +/Times-Italic SF +22048 XM +(kstash)SH +/Times-Roman SF +(, use the following command:)SH +/Courier SF +8520 67963 MT +(host#)SH +/Times-Bold SF +12480 XM +(./kerberos -m)SH +10 /Times-Roman AF +7200 75600 MT +(MIT Project Athena)SH +30350 XM +(4)SH +47890 XM +(4 January 1990)SH +ES +%%Page: 5 6 +BS +0 SI +11 /Times-Roman AF +7200 7955 MT +(The server will prompt you to enter the master password before actually starting itself.)SH +14 /Times-Bold AF +7200 11773 MT +(2.5 Testing) +350 W( the Kerberos Server)SH +11 /Times-Roman AF +7200 13968 MT +(Exit the root account and use the)SH +/Times-Italic SF +21893 XM +(kinit)SH +/Times-Roman SF +24124 XM +(command obtain a Kerberos ticket-granting ticket. This command)SH +7200 15164 MT +(creates your ticket file and stores the ticket-granting ticket in it.)SH +7200 17462 MT +(If you used the default)SH +/Times-Italic SF +17371 XM +(make install)SH +/Times-Roman SF +22993 XM +(command and directories to install the Kerberos user utilities,)SH +/Times-Italic SF +50365 XM +(kinit)SH +/Times-Roman SF +7200 18658 MT +(will be in the)SH +/Times-Italic SF +13250 XM +(/usr/athena)SH +/Times-Roman SF +18537 XM +(directory. From now on, we'll refer to the Kerberos user commands directory as)SH +7200 19854 MT +([K_USER].)SH +7200 22152 MT +(Use)SH +/Times-Italic SF +9185 XM +(kinit)SH +/Times-Roman SF +11416 XM +(as follows:)SH +/Courier SF +8520 23729 MT +(host%)SH +/Times-Bold SF +12480 XM +([K_USER]/kinit)SH +/Courier SF +8520 24843 MT +(MIT Project Athena, \050ariadne\051)SH +8520 25957 MT +(Kerberos Initialization)SH +8520 27071 MT +(Kerberos name:)SH +/Times-BoldItalic SF +18420 XM +(yourusername)SH +/Times-Bold SF +28800 XM +(<--)SH +/Times-BoldItalic SF +30819 XM +(Enter your Kerberos username.)SH +/Courier SF +8520 28185 MT +(Password:)SH +/Times-Bold SF +28800 XM +(<--)SH +/Times-BoldItalic SF +30819 XM +(Enter your Kerberos password.)SH +/Times-Roman SF +7200 30483 MT +(Use the)SH +/Times-Italic SF +10804 XM +(klist)SH +/Times-Roman SF +12913 XM +(program to list the contents of your ticket file.)SH +/Courier SF +8520 32060 MT +(host%)SH +/Times-Bold SF +12480 XM +([K_USER]/klist)SH +/Times-Roman SF +7200 33655 MT +(The command should display something like the following:)SH +/Courier SF +8520 35181 MT +(Ticket file:) +SH( /tmp/tkt5555)1980 W +8520 36295 MT +(Principal: yourusername@REALMNAME)3300 W +9840 38523 MT +(Issued Expires) +6600 W( Principal)5940 W +8520 39637 MT +(May 6) +660 W( 10:15:23 May 6 18:15:23 krbtgt.REALMNAME@REALMNAME)SH +/Times-Roman SF +7200 41935 MT +(If you have any problems, you can examine the log file)SH +/Times-Italic SF +31758 XM +(/kerberos/kerberos.log)SH +/Times-Roman SF +42022 XM +(on the Kerberos server)SH +7200 43131 MT +(machine to see if there was some sort of error.)SH +16 /Times-Bold AF +7200 47803 MT +(3. Setting) +400 W( up and testing the Administration server)SH +11 /Times-Roman AF +7200 49998 MT +(The procedure for setting up and testing the Kerberos administration server is as follows:)SH +9400 51949 MT +(1.)SH +10500 XM +(Use the)SH +/Times-Italic SF +14104 XM +(kdb_edit)SH +/Times-Roman SF +18167 XM +(utility to add your username with an administration instance to the master)SH +10500 53145 MT +(database.)SH +9400 55039 MT +(2.)SH +10500 XM +(Edit the access control lists for the administration server)SH +9400 56933 MT +(3.)SH +10500 XM +(Start the Kerberos administration server.)SH +9400 58827 MT +(4.)SH +10500 XM +(Use the)SH +/Times-Italic SF +14104 XM +(kpasswd)SH +/Times-Roman SF +18107 XM +(command to change your password.)SH +9400 60721 MT +(5.)SH +10500 XM +(Use the)SH +/Times-Italic SF +14104 XM +(kadmin)SH +/Times-Roman SF +17617 XM +(command to add new entries to the database.)SH +9400 62615 MT +(6.)SH +10500 XM +(Use the)SH +/Times-Italic SF +14104 XM +(kinit)SH +/Times-Roman SF +16335 XM +(command to verify that the)SH +/Times-Italic SF +28524 XM +(kadmin)SH +/Times-Roman SF +32037 XM +(command correctly added new entries to)SH +10500 63811 MT +(the database.)SH +10 SS +7200 75600 MT +(MIT Project Athena)SH +30350 XM +(5)SH +47890 XM +(4 January 1990)SH +ES +%%Page: 6 7 +BS +0 SI +14 /Times-Bold AF +7200 8138 MT +(3.1 Adding) +350 W( an administration instance for the administrator)SH +11 /Times-Roman AF +7200 10333 MT +(Login to the Kerberos master server machine, and use the)SH +/Times-Bold SF +32825 XM +(su)SH +/Times-Roman SF +34140 XM +(command to become root. Use the)SH +/Times-Italic SF +49780 XM +(kdb_edit)SH +/Times-Roman SF +7200 11529 MT +(program to create an entry for each administrator with the instance ``)SH +/Times-BoldItalic SF +(admin)SH +/Times-Roman SF +(''.)SH +/Courier SF +8520 13106 MT +(host#)SH +/Times-Bold SF +12480 XM +([ADMIN_DIR]/kdb_edit)SH +/Courier SF +8520 15334 MT +(Opening database...)SH +8520 17562 MT +(Enter Kerberos master key:)SH +8520 18676 MT +(Verifying, please re-enter)SH +8520 19790 MT +(Enter Kerberos master key:)SH +8520 20904 MT +(Current Kerberos master key version is 1)SH +8520 23132 MT +(Master key entered. BEWARE!)SH +8520 24246 MT +(Previous or default values are in [brackets] ,)SH +8520 25360 MT +(enter return to leave the same, or new value.)SH +8520 27588 MT +(Principal name:)SH +/Times-Bold SF +19080 XM +(wave)SH +28800 XM +(<--)SH +/Times-BoldItalic SF +30819 XM +(Enter the username.)SH +/Courier SF +8520 28702 MT +(Instance:)SH +/Times-Bold SF +(admin)SH +28800 XM +(<--)SH +/Times-BoldItalic SF +30819 XM +(Enter ``admin''.)SH +/Courier SF +8520 30930 MT +(<Not found>, Create [y] ?)SH +/Times-Bold SF +25680 XM +(y)SH +28800 XM +(<--)SH +/Times-BoldItalic SF +30819 XM +(The user-instance does not exist.)SH +30450 32044 MT +(Enter y to create the user-instance.)SH +/Courier SF +8520 33158 MT +(Principal: wave Instance: admin m_key_v: 1)SH +8520 34272 MT +(New Password:)SH +/Times-BoldItalic SF +28800 XM +(<-- Enter the user-instance's password.)SH +/Courier SF +8520 35386 MT +(Verifying, please re-enter)SH +8520 36500 MT +(New Password:)SH +8520 37614 MT +(Principal's new key version = 1)SH +8520 38728 MT +(Expiration date \050enter dd-mm-yy\051 [ 12/31/99 ] ?)SH +/Times-Bold SF +39600 XM +(<--)SH +/Times-BoldItalic SF +41619 XM +(Enter newlines)SH +/Courier SF +8520 39842 MT +(Max ticket lifetime \050*5 minutes\051 [ 255 ] ?)SH +/Times-Bold SF +39600 XM +(<--)SH +/Times-BoldItalic SF +41619 XM +(to get the)SH +/Courier SF +8520 40956 MT +(Attributes [ 0 ] ?)SH +/Times-Bold SF +30120 XM +(<--)SH +/Times-BoldItalic SF +32139 XM +(default values.)SH +/Courier SF +8520 42070 MT +(Edit O.K.)SH +8520 44298 MT +(Principal name:)SH +/Times-BoldItalic SF +28800 XM +(<-- Enter a newline to exit the program.)SH +14 /Times-Bold AF +7200 48116 MT +(3.2 The) +350 W( Access Control Lists)SH +11 /Times-Roman AF +7200 50311 MT +(The Kerberos administration server uses three access control lists to determine who is authorized to make)SH +7200 51507 MT +(certain requests. The access control lists are stored on the master Kerberos server in the same directory as)SH +7200 52703 MT +(the principal database,)SH +/Times-Italic SF +17340 XM +(/kerberos)SH +/Times-Roman SF +(. The) +275 W( access control lists are simple ASCII text files, with each line)SH +7200 53899 MT +(specifying the name of one principal who is allowed the particular function. To allow several people to)SH +7200 55095 MT +(perform the same function, put their principal names on separate lines in the same file.)SH +7200 57393 MT +(The first list,)SH +/Times-Italic SF +13128 XM +(/kerberos/admin_acl.mod)SH +/Times-Roman SF +(, is a list of principals which are authorized to change entries in the)SH +7200 58589 MT +(database. To) +275 W( allow the administrator `)SH +/Times-Bold SF +(wave)SH +/Times-Roman SF +(' to modify entries in the database for the realm `)SH +/Times-Bold SF +(TIM.EDU)SH +/Times-Roman SF +(',)SH +7200 59785 MT +(you would put the following line into the file)SH +/Times-Italic SF +27275 XM +(/kerberos/admin_acl.mod)SH +/Times-Roman SF +(:)SH +/Courier SF +8520 61311 MT +(wave.admin@TIM.EDU)SH +/Times-Roman SF +7200 63609 MT +(The second list,)SH +/Times-Italic SF +14410 XM +(/kerberos/admin_acl.get)SH +/Times-Roman SF +(, is a list of principals which are authorized to retrieve entries)SH +7200 64805 MT +(from the database.)SH +7200 67103 MT +(The third list,)SH +/Times-Italic SF +13434 XM +(/kerberos/admin_acl.add)SH +/Times-Roman SF +(, is a list of principals which are authorized to add new entries to)SH +7200 68299 MT +(the database.)SH +10 SS +7200 75600 MT +(MIT Project Athena)SH +30350 XM +(6)SH +47890 XM +(4 January 1990)SH +ES +%%Page: 7 8 +BS +0 SI +14 /Times-Bold AF +7200 8138 MT +(3.3 Starting) +350 W( the administration server)SH +11 /Times-Roman AF +7200 10333 MT +(Change directories to the directory in which you have installed the administration server program)SH +/Times-Italic SF +7200 11529 MT +(kadmind)SH +/Times-Roman SF +11263 XM +(\050the default directory is)SH +/Times-Italic SF +21831 XM +(/usr/etc)SH +/Times-Roman SF +(\051, and start the program as a background process:)SH +/Courier SF +8520 13106 MT +(host#)SH +/Times-Bold SF +12480 XM +(./kadmind -n&)SH +/Times-Roman SF +7200 14701 MT +(If you have used the)SH +/Times-Italic SF +16393 XM +(kstash)SH +/Times-Roman SF +19418 XM +(command to store the master database password, the server will start)SH +7200 15897 MT +(automatically. If) +275 W( you did not use)SH +/Times-Italic SF +22048 XM +(kstash)SH +/Times-Roman SF +(, use the following command:)SH +/Courier SF +8520 17474 MT +(host#)SH +/Times-Bold SF +12480 XM +(./kadmind)SH +/Times-Roman SF +7200 19069 MT +(The server will prompt you to enter the master password before actually starting itself; after it starts, you)SH +7200 20265 MT +(should suspend it and put it in the background \050usually this is done by typing control-Z and then)SH +/Times-Bold SF +49792 XM +(bg)SH +/Times-Roman SF +(\051.)SH +14 /Times-Bold AF +7200 24112 MT +(3.4 Testing)350 W +/Times-BoldItalic SF +14434 XM +(kpasswd)SH +11 /Times-Roman AF +7200 26307 MT +(To test the administration server, you should try changing your password with the)SH +/Times-Italic SF +43494 XM +(kpasswd)SH +/Times-Roman SF +47497 XM +(command, and)SH +7200 27503 MT +(you should try adding new users with the)SH +/Times-Italic SF +25592 XM +(kadmin)SH +/Times-Roman SF +29105 XM +(command \050both commands are installed into)SH +/Times-Italic SF +48963 XM +(/usr/athena)SH +/Times-Roman SF +7200 28699 MT +(by default\051.)SH +7200 30997 MT +(Before testing, you should exit the root account.)SH +7200 33295 MT +(To change your password, run the)SH +/Times-Italic SF +22441 XM +(kpasswd)SH +/Times-Roman SF +26444 XM +(command:)SH +/Courier SF +8520 34872 MT +(host%)SH +/Times-Bold SF +12480 XM +([K_USER]/kpasswd)SH +/Courier SF +8520 35986 MT +(Old password for wave@TIM.EDU:)SH +/Times-Bold SF +28800 XM +(<--)SH +/Times-BoldItalic SF +(Enter your password)SH +/Courier SF +8520 37100 MT +(New Password for wave@TIM.EDU:)SH +/Times-Bold SF +28800 XM +(<--)SH +/Times-BoldItalic SF +(Enter a new password)SH +/Courier SF +8520 38214 MT +(Verifying, please re-enter New Password for wave@TIM.EDU:)SH +/Times-Bold SF +28800 39328 MT +(<--)SH +/Times-BoldItalic SF +(Enter new password again)SH +/Courier SF +8520 40442 MT +(Password changed.)SH +/Times-Roman SF +7200 42037 MT +(Once you have changed your password, use the)SH +/Times-Italic SF +28365 XM +(kinit)SH +/Times-Roman SF +30596 XM +(program as shown above to verify that the password)SH +7200 43233 MT +(was properly changed.)SH +14 /Times-Bold AF +7200 47080 MT +(3.5 Testing)350 W +/Times-BoldItalic SF +14434 XM +(kadmin)SH +11 /Times-Roman AF +7200 49275 MT +(You should also test the function of the)SH +/Times-Italic SF +24798 XM +(kadmin)SH +/Times-Roman SF +28311 XM +(program, by adding a new user \050here named)SH +7200 50471 MT +(``)SH +/Courier SF +(username)SH +/Times-Roman SF +(''\051:)SH +/Courier SF +8520 52048 MT +(host%)SH +/Times-Bold SF +12480 XM +([K_USER]/kadmin)SH +/Courier SF +8520 53162 MT +(Welcome to the Kerberos Administration Program, version 2)SH +8520 54276 MT +(Type "help" if you need it.)SH +8520 55390 MT +(admin:)SH +/Times-Bold SF +13800 XM +(ank username)SH +/Times-BoldItalic SF +28800 XM +(`ank' stands for Add New Key)SH +/Courier SF +8520 56504 MT +(Admin password:)SH +/Times-Bold SF +28800 XM +(<--)SH +/Times-BoldItalic SF +(enter the password)SH +28800 57618 MT +(you chose above for wave.admin)SH +/Courier SF +8520 58732 MT +(Password for username:)SH +/Times-Bold SF +28800 XM +(<--)SH +/Times-BoldItalic SF +(Enter the user's initial password)SH +/Courier SF +8520 59846 MT +(Verifying, please re-enter Password for username:)SH +/Times-Bold SF +40920 XM +(<--)SH +/Times-BoldItalic SF +(enter it again)SH +/Courier SF +8520 60960 MT +(username added to database.)SH +8520 63188 MT +(admin: quit)660 W +8520 64302 MT +(Cleaning up and exiting.)SH +10 /Times-Roman AF +7200 75600 MT +(MIT Project Athena)SH +30350 XM +(7)SH +47890 XM +(4 January 1990)SH +ES +%%Page: 8 9 +BS +0 SI +14 /Times-Bold AF +7200 8167 MT +(3.6 Verifying) +350 W( with)SH +/Times-BoldItalic SF +18671 XM +(kinit)SH +11 /Times-Roman AF +7200 10362 MT +(Once you've added a new user, you should test to make sure it was added properly by using)SH +/Times-Italic SF +47917 XM +(kinit)SH +/Times-Roman SF +(, and)SH +7200 11558 MT +(trying to get tickets for that user:)SH +/Courier SF +8520 13135 MT +(host%)SH +/Times-Bold SF +12480 XM +([K_USER]/kinit username)SH +/Courier SF +8520 14249 MT +(MIT Project Athena \050ariadne\051)SH +8520 15363 MT +(Kerberos Initialization for "username@TIM.EDU")SH +8520 16477 MT +(Password:)SH +/Times-Bold SF +15120 XM +(<--)SH +/Times-BoldItalic SF +(Enter the user's password you used above)SH +/Courier SF +8520 17591 MT +(host%)SH +/Times-Bold SF +12480 XM +([K_USER]/klist)SH +/Courier SF +8520 18705 MT +(Ticket file:) +SH( /tmp/tkt_5509_spare1)1980 W +8520 19819 MT +(Principal: username@TIM.MIT.EDU)3300 W +9840 22047 MT +(Issued Expires) +6600 W( Principal)5940 W +8520 23161 MT +(Nov 20 15:58:52 Nov 20 23:58:52 krbtgt.TIM.EDU@TIM.EDU)SH +/Times-Roman SF +7200 25459 MT +(If you have any problems, you can examine the log files)SH +/Times-Italic SF +32186 XM +(/kerberos/kerberos.log)SH +/Times-Roman SF +42450 XM +(and)SH +/Times-Italic SF +7200 26655 MT +(/kerberos/admin_server.syslog)SH +/Times-Roman SF +21008 XM +(on the Kerberos server machine to see if there was some sort of error.)SH +16 /Times-Bold AF +7200 31327 MT +(4. Setting) +400 W( up and testing slave server\050s\051)SH +11 /Times-Roman AF +7200 33522 MT +([Unfortunately, this chapter is not yet ready. Sorry. -ed])SH +16 /Times-Bold AF +7200 38194 MT +(5. A) +400 W( Sample Application)SH +11 /Times-Roman AF +7200 40389 MT +(This release of Kerberos comes with a sample application server and a corresponding client program.)SH +7200 41585 MT +(You will find this software in the [OBJ_DIR])SH +/Times-Italic SF +(/appl/sample)SH +/Times-Roman SF +33170 XM +(directory. The) +275 W( file)SH +/Times-Italic SF +41691 XM +(sample_client)SH +/Times-Roman SF +48076 XM +(contains the)SH +7200 42781 MT +(client program's executable code, the file)SH +/Times-Italic SF +25677 XM +(sample_server)SH +/Times-Roman SF +32366 XM +(contains the server's executable.)SH +7200 45079 MT +(The programs are rudimentary. When they have been installed \050the installation procedure is described in)SH +7200 46275 MT +(detail later\051, they work as follows:)SH +/Symbol SF +9169 48351 MT +(\267)SH +/Times-Roman SF +9950 XM +(The user starts)SH +/Times-Italic SF +16639 XM +(sample_client)SH +/Times-Roman SF +23024 XM +(and provides as arguments to the command the name of the)SH +9950 49547 MT +(server machine and a checksum. For instance:)SH +/Courier SF +11270 51147 MT +(host%)SH +/Times-Bold SF +15230 XM +(sample_client)SH +/Times-BoldItalic SF +22966 XM +(servername 43)385 W +/Symbol SF +9169 53041 MT +(\267)SH +/Times-Italic SF +9950 XM +(Sample_client)SH +/Times-Roman SF +16457 XM +(contacts the server machine and authenticates the user to)SH +/Times-Italic SF +41654 XM +(sample_server)SH +/Times-Roman SF +(.)SH +/Symbol SF +9169 54935 MT +(\267)SH +/Times-Italic SF +9950 XM +(Sample_server)SH +/Times-Roman SF +16761 XM +(authenticates itself to)SH +/Times-Italic SF +26384 XM +(sample_client)SH +/Times-Roman SF +(, then returns a message to the client)SH +9950 56131 MT +(program. This) +275 W( message contains diagnostic information that includes the user's username,)SH +9950 57327 MT +(the Kerberos realm, and the user's workstation address.)SH +/Symbol SF +9169 59221 MT +(\267)SH +/Times-Italic SF +9950 XM +(Sample_client)SH +/Times-Roman SF +16457 XM +(displays the server's message on the user's terminal screen.)SH +14 /Times-Bold AF +7200 63039 MT +(5.1 The) +350 W( Installation Process)SH +11 /Times-Roman AF +7200 65234 MT +(In general, you use the following procedure to install a Kerberos-authenticated server-client system.)SH +9400 67185 MT +(1.)SH +10500 XM +(Add the appropriate entry to the Kerberos database using)SH +/Times-Italic SF +35881 XM +(kdb_edit)SH +/Times-Roman SF +39944 XM +(or)SH +/Times-Italic SF +41135 XM +(kadmin)SH +/Times-Roman SF +44648 XM +(\050described)SH +10500 68381 MT +(below\051.)SH +10 SS +7200 75600 MT +(MIT Project Athena)SH +30350 XM +(8)SH +47890 XM +(4 January 1990)SH +ES +%%Page: 9 10 +BS +0 SI +11 /Times-Roman AF +9400 7955 MT +(2.)SH +10500 XM +(Create a)SH +/Times-Italic SF +14408 XM +(/etc/srvtab)SH +/Times-Roman SF +19327 XM +(file for the server machine.)SH +9400 9849 MT +(3.)SH +10500 XM +(Install the service program and the)SH +/Times-Italic SF +26016 XM +(/etc/srvtab)SH +/Times-Roman SF +30935 XM +(file on the server machine.)SH +9400 11743 MT +(4.)SH +10500 XM +(Install the client program on the client machine.)SH +9400 13637 MT +(5.)SH +10500 XM +(Update the)SH +/Times-Italic SF +15570 XM +(/etc/services)SH +/Times-Roman SF +21281 XM +(file on the client and server machines.)SH +7200 15935 MT +(We will use the sample application as an example, although the procedure used to install)SH +/Times-Italic SF +46484 XM +(sample_server)SH +/Times-Roman SF +7200 17131 MT +(differs slightly from the general case because the)SH +/Times-Italic SF +29006 XM +(sample_server)SH +/Times-Roman SF +35695 XM +(takes requests via the)SH +/Times-Italic SF +45347 XM +(inetd)SH +/Times-Roman SF +47822 XM +(program.)SH +/Times-Italic SF +7200 18327 MT +(Inetd)SH +/Times-Roman SF +9735 XM +(starts)SH +/Times-Italic SF +12332 XM +(sample_server)SH +/Times-Roman SF +19021 XM +(each time a client process contacts the server machine.)SH +/Times-Italic SF +43606 XM +(Sample_server)SH +/Times-Roman SF +7200 19523 MT +(processes the request, terminiates, then is restarted when)SH +/Times-Italic SF +32368 XM +(inetd)SH +/Times-Roman SF +34843 XM +(receives another)SH +/Times-Italic SF +42293 XM +(sample_client)SH +/Times-Roman SF +48678 XM +(request.)SH +7200 20719 MT +(When you install the program on the server, you must add a)SH +/Times-Italic SF +33807 XM +(sample)SH +/Times-Roman SF +37198 XM +(entry to the server machine's)SH +/Times-Italic SF +7200 21915 MT +(/etc/inetd.conf)SH +/Times-Roman SF +13738 XM +(file.)SH +7200 24213 MT +(The following description assumes that you are installing)SH +/Times-Italic SF +32680 XM +(sample_server)SH +/Times-Roman SF +39369 XM +(on the machine)SH +/Times-Italic SF +46364 XM +(ariadne.tim.edu)SH +/Times-Roman SF +(.)SH +7200 25409 MT +(Here's the process, step by step:)SH +9400 27360 MT +(1.)SH +10500 XM +(Login as or)SH +/Times-Italic SF +15785 XM +(su)SH +/Times-Roman SF +17038 XM +(to root on the Kerberos server machine. Use the)SH +/Times-Italic SF +38631 XM +(kdb_edit)SH +/Times-Roman SF +42694 XM +(or)SH +/Times-Italic SF +43885 XM +(kadmin)SH +/Times-Roman SF +47398 XM +(program)SH +10500 28556 MT +(to create an entry for)SH +/Times-Italic SF +19935 XM +(sample)SH +/Times-Roman SF +23326 XM +(in the Kerberos database:)SH +/Courier SF +11820 30133 MT +(host#)SH +/Times-Bold SF +15780 XM +([ADMIN_DIR]/kdb_edit)SH +/Courier SF +11820 32361 MT +(Opening database...)SH +11820 34589 MT +(Enter Kerberos master key:)SH +11820 35703 MT +(Verifying, please re-enter)SH +11820 36817 MT +(master key entered. BEWARE!)SH +11820 37931 MT +(Previous or default values are in [brackets] ,)SH +11820 39045 MT +(enter return to leave the same, or new value.)SH +11820 41273 MT +(Principal name:)SH +/Times-Bold SF +22380 XM +(sample)SH +26220 XM +(<--)SH +/Times-BoldItalic SF +28239 XM +(Enter the principal name.)SH +/Courier SF +11820 42387 MT +(Instance:)SH +/Times-Bold SF +18420 XM +(ariadne)SH +26220 XM +(<--)SH +/Times-BoldItalic SF +28239 XM +(Instances cannot have periods in them.)SH +/Courier SF +11820 44615 MT +(<Not found>, Create [y] ?)SH +/Times-Bold SF +28980 XM +(y)SH +/Courier SF +11820 46843 MT +(Principal: sample_server Instance: ariadne m_key_v: 1)SH +11820 47957 MT +(New Password:)SH +/Times-Bold SF +26220 XM +(<--)SH +/Times-BoldItalic SF +28239 XM +(Enter ``RANDOM'' to get random password.)SH +/Courier SF +11820 49071 MT +(Verifying, please re-enter)SH +11820 50185 MT +(New Password:)SH +/Times-Bold SF +26220 XM +(<--)SH +/Times-BoldItalic SF +28239 XM +(Enter ``RANDOM'' again.)SH +/Courier SF +11820 51299 MT +(Random password [y] ?)SH +/Times-Bold SF +26340 XM +(y)SH +/Courier SF +11820 53527 MT +(Principal's new key version = 1)SH +11820 54641 MT +(Expiration date \050enter dd-mm-yy\051 [ 12/31/99 ] ?)SH +11820 55755 MT +(Max ticket lifetime \050*5 minutes\051 [ 255 ] ?)SH +11820 56869 MT +(Attributes [ 0 ] ?)SH +11820 57983 MT +(Edit O.K.)SH +11820 60211 MT +(Principal name:)SH +/Times-Bold SF +26220 XM +(<--)SH +/Times-BoldItalic SF +28239 XM +(Enter newline to exit kdb_edit.)SH +/Times-Roman SF +9400 62105 MT +(2.)SH +10500 XM +(Use the)SH +/Times-Italic SF +14104 XM +(ext_srvtab)SH +/Times-Roman SF +18961 XM +(program to create a)SH +/Times-Italic SF +27755 XM +(srvtab)SH +/Times-Roman SF +30780 XM +(file for)SH +/Times-Italic SF +34078 XM +(sample_server)SH +/Times-Roman SF +('s host machine:)SH +10 SS +7200 75600 MT +(MIT Project Athena)SH +30350 XM +(9)SH +47890 XM +(4 January 1990)SH +ES +%%Page: 10 11 +BS +0 SI +11 /Courier AF +11820 7937 MT +(host#)SH +/Times-Bold SF +15780 XM +([ADMIN_DIR]/ext_srvtab ariadne)275 W +/Courier SF +11820 10165 MT +(Enter Kerberos master key:)SH +11820 11279 MT +(Current Kerberos master key version is 1.)SH +11820 13507 MT +(Generating 'ariadne-new-srvtab'....)SH +/Times-Roman SF +10500 15102 MT +(Transfer the)SH +/Times-Italic SF +16118 XM +(ariadne-new-srvtab)SH +/Times-Roman SF +25069 XM +(file to)SH +/Times-Italic SF +27941 XM +(ariadne)SH +/Times-Roman SF +31638 XM +(and install it as)SH +/Times-Italic SF +38544 XM +(/etc/srvtab)SH +/Times-Roman SF +(. Note) +275 W( that this)SH +10500 16298 MT +(file is equivalent to the service's password and should be treated with care. For example, it)SH +10500 17494 MT +(could be transferred by removable media, but should not be sent over an open network in)SH +10500 18690 MT +(the clear. Once installed, this file should be readable only by root.)SH +9400 20584 MT +(3.)SH +10500 XM +(Add the following line to the)SH +/Times-Italic SF +23516 XM +(/etc/services)SH +/Times-Roman SF +29227 XM +(file on)SH +/Times-Italic SF +32343 XM +(ariadne)SH +/Times-Roman SF +(, and on all machines that will run)SH +10500 21780 MT +(the)SH +/Times-Italic SF +12119 XM +(sample_client)SH +/Times-Roman SF +18504 XM +(program:)SH +/Courier SF +11820 23306 MT +(sample 906/tcp) +2640 W( #) +3960 W( Kerberos sample app server)SH +/Times-Roman SF +9400 25200 MT +(4.)SH +10500 XM +(Add a line similar to the following line to the)SH +/Times-Italic SF +30666 XM +(/etc/inetd.conf)SH +/Times-Roman SF +37204 XM +(file on)SH +/Times-Italic SF +40320 XM +(sample_server)SH +/Times-Roman SF +('s)SH +10500 26396 MT +(machine:)SH +/Courier SF +11820 27922 MT +(sample stream tcp nowait switched root)1320 W +14460 29036 MT +([PATH]/sample_server sample_server)SH +/Times-Roman SF +10500 30631 MT +(where [PATH] should be substituted with the path to the)SH +/Times-Italic SF +35674 XM +(sample_server)SH +/Times-Roman SF +42363 XM +(program. \050This)275 W +/Times-Italic SF +10500 31827 MT +(inetd.conf)SH +/Times-Roman SF +15144 XM +(information should be placed on one line.\051 You should examine existing lines in)SH +/Times-Italic SF +10500 33023 MT +(/etc/inetd.conf)SH +/Times-Roman SF +17038 XM +(and use the same format used by other entries \050e.g. for telnet\051. Most systems)SH +10500 34219 MT +(do not have a column for the `switched' keyword, and some do not have a column for the)SH +10500 35415 MT +(username \050usually `root', as above\051.)SH +9400 37309 MT +(5.)SH +10500 XM +(Restart)SH +/Times-Italic SF +13891 XM +(inetd)SH +/Times-Roman SF +16366 XM +(by sending the current)SH +/Times-Italic SF +26446 XM +(inetd)SH +/Times-Roman SF +28921 XM +(process a hangup signal:)SH +/Courier SF +11820 38909 MT +(host#)SH +/Times-Bold SF +15780 XM +(kill -HUP)275 W +/Times-BoldItalic SF +21373 XM +(process_id_number)SH +/Times-Roman SF +9400 40803 MT +(6.)SH +10500 XM +(The)SH +/Times-Italic SF +12485 XM +(sample_server)SH +/Times-Roman SF +19174 XM +(is now ready to take)SH +/Times-Italic SF +28307 XM +(sample_client)SH +/Times-Roman SF +34692 XM +(requests.)SH +14 /Times-Bold AF +7200 44621 MT +(5.2 Testing) +350 W( the Sample Server)SH +11 /Times-Roman AF +7200 46816 MT +(Assume that you have installed)SH +/Times-Italic SF +21223 XM +(sample_server)SH +/Times-Roman SF +27912 XM +(on)SH +/Times-Italic SF +29287 XM +(ariadne)SH +/Times-Roman SF +(.)SH +7200 49114 MT +(Login to your workstation and use the)SH +/Times-Italic SF +24217 XM +(kinit)SH +/Times-Roman SF +26448 XM +(command to obtain a Kerberos ticket-granting ticket:)SH +/Courier SF +8520 50691 MT +(host%)SH +/Times-Bold SF +12480 XM +([K_USER]/kinit)SH +/Courier SF +8520 51805 MT +(MIT Project Athena, \050your_workstation\051)SH +8520 52919 MT +(Kerberos Initialization)SH +8520 54033 MT +(Kerberos name:)SH +/Times-BoldItalic SF +18420 XM +(yourusername)SH +/Times-Bold SF +28800 XM +(<--)SH +/Times-BoldItalic SF +30819 XM +(Enter your Kerberos username.)SH +/Courier SF +8520 55147 MT +(Password:)SH +/Times-Bold SF +28800 XM +(<--)SH +/Times-BoldItalic SF +30819 XM +(Enter your Kerberos password.)SH +/Times-Roman SF +7200 57445 MT +(Now use the)SH +/Times-Italic SF +12973 XM +(sample_client)SH +/Times-Roman SF +19358 XM +(program as follows:)SH +/Courier SF +8520 59022 MT +(host%)SH +/Times-Bold SF +12480 XM +([PATH]/sample_client ariadne)275 W +/Times-Roman SF +7200 60617 MT +(The command should display something like the following:)SH +/Courier SF +8520 62143 MT +(The server says:)SH +8520 63257 MT +(You are)SH +/Times-BoldItalic SF +13800 XM +(yourusername)SH +/Courier SF +(.@REALMNAME \050local name)SH +/Times-BoldItalic SF +36180 XM +(yourusername)SH +/Courier SF +(\051,)SH +9180 64371 MT +(at address)SH +/Times-BoldItalic SF +16440 XM +(yournetaddress)SH +/Courier SF +(, version VERSION9, cksum 997)SH +10 /Times-Roman AF +7200 75600 MT +(MIT Project Athena)SH +30100 XM +(10)SH +47890 XM +(4 January 1990)SH +ES +%%Page: 11 12 +BS +0 SI +16 /Times-Bold AF +7200 8272 MT +(6. Service) +400 W( names and other services)SH +14 SS +7200 12090 MT +(6.1 rlogin,) +350 W( rsh, rcp, tftp, and others)SH +11 /Times-Roman AF +7200 14285 MT +(Many services use a common principal name for authentication purposes.)SH +/Times-Italic SF +40128 XM +(rlogin)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +43368 XM +(rsh)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +45324 XM +(rcp)SH +/Times-Roman SF +(,)SH +/Times-Italic SF +47340 XM +(tftp)SH +/Times-Roman SF +49083 XM +(and others)SH +7200 15481 MT +(use the principal name ``)SH +/Courier SF +(rcmd)SH +/Times-Roman SF +(''. For) +275 W( example, to set up the machine)SH +/Times-Italic SF +38033 XM +(ariadne)SH +/Times-Roman SF +41730 XM +(to support Kerberos rlogin,)SH +7200 16677 MT +(it needs to have a service key for principal ``)SH +/Courier SF +(rcmd)SH +/Times-Roman SF +('', instance ``)SH +/Courier SF +(ariadne)SH +/Times-Roman SF +(''. You) +275 W( create this key in the)SH +7200 17873 MT +(same way as shown above for the sample service.)SH +7200 20171 MT +(After creating this key, you need to run the)SH +/Times-Italic SF +26382 XM +(ext_srvtab)SH +/Times-Roman SF +31239 XM +(program again to generate a new srvtab file for)SH +7200 21367 MT +(ariadne.)SH +14 /Times-Bold AF +7200 25185 MT +(6.2 NFS) +350 W( modifications)SH +11 /Times-Roman AF +7200 27380 MT +(The NFS modifications distributed separately use the service name ``)SH +/Courier SF +(rvdsrv)SH +/Times-Roman SF +('' with the instance set to)SH +7200 28576 MT +(the machine name \050as for the sample server and the rlogin, rsh, rcp and tftp services\051.)SH +14 /Times-Bold AF +7200 32394 MT +(6.3 inetd.conf) +350 W( entries)SH +11 /Times-Roman AF +7200 34589 MT +(The following are the)SH +/Times-Italic SF +16974 XM +(/etc/inetd.conf)SH +/Times-Roman SF +23512 XM +(entries necessary to support rlogin, encrypted rlogin, rsh, and rcp)SH +7200 35785 MT +(services on a server machine. As above, your)SH +/Times-Italic SF +27631 XM +(inetd.conf)SH +/Times-Roman SF +32275 XM +(may not support all the fields shown here.)SH +/Courier SF +8520 37311 MT +(eklogin stream) +660 W( tcp nowait unswitched root)1320 W +11160 38425 MT +([PATH]/klogind eklogind)1320 W +8520 39539 MT +(kshell stream tcp nowait unswitched root)1320 W +11160 40653 MT +([PATH]/kshd kshd)1320 W +8520 41767 MT +(klogin stream tcp nowait unswitched root)1320 W +11160 42881 MT +([PATH]/klogind klogind)1320 W +10 /Times-Roman AF +7200 75600 MT +(MIT Project Athena)SH +30100 XM +(11)SH +47890 XM +(4 January 1990)SH +ES +%%Page: i 13 +BS +0 SI +14 /Times-Bold AF +25272 8138 MT +(Table of Contents)SH +13 SS +7200 9781 MT +(1. How) +325 W( Kerberos Works: A Schematic Description)SH +53350 XM +(1)SH +12 /Times-Roman AF +9000 11130 MT +(1.1 Network) +300 W( Services and Their Client Programs)SH +53400 XM +(1)SH +9000 12479 MT +(1.2 Kerberos) +300 W( Tickets)SH +53400 XM +(1)SH +9000 13828 MT +(1.3 The) +300 W( Kerberos Master Database)SH +53400 XM +(1)SH +9000 15177 MT +(1.4 The) +300 W( Ticket-Granting Ticket)SH +53400 XM +(1)SH +9000 16526 MT +(1.5 Network) +300 W( Services and the Master Database)SH +53400 XM +(1)SH +9000 17875 MT +(1.6 The) +300 W( User-Kerberos Interaction)SH +53400 XM +(2)SH +13 /Times-Bold AF +7200 19518 MT +(2. Setting) +325 W( Up and Testing the Kerberos Server)SH +53350 XM +(2)SH +12 /Times-Roman AF +9000 20867 MT +(2.1 Creating) +300 W( and Initializing the Master Database)SH +53400 XM +(3)SH +9000 22216 MT +(2.2 Storing) +300 W( the Master Password)SH +53400 XM +(3)SH +9000 23571 MT +(2.3 Using)300 W +/Times-BoldItalic SF +14267 XM +(kdb_edit)SH +/Times-Roman SF +18768 XM +(to Add Users to the Master Database)SH +53400 XM +(4)SH +9000 24920 MT +(2.4 Starting) +300 W( the Kerberos Server)SH +53400 XM +(4)SH +9000 26269 MT +(2.5 Testing) +300 W( the Kerberos Server)SH +53400 XM +(5)SH +13 /Times-Bold AF +7200 27912 MT +(3. Setting) +325 W( up and testing the Administration server)SH +53350 XM +(5)SH +12 /Times-Roman AF +9000 29261 MT +(3.1 Adding) +300 W( an administration instance for the administrator)SH +53400 XM +(6)SH +9000 30610 MT +(3.2 The) +300 W( Access Control Lists)SH +53400 XM +(6)SH +9000 31959 MT +(3.3 Starting) +300 W( the administration server)SH +53400 XM +(7)SH +9000 33314 MT +(3.4 Testing)300 W +/Times-BoldItalic SF +15001 XM +(kpasswd)SH +/Times-Roman SF +53400 XM +(7)SH +9000 34669 MT +(3.5 Testing)300 W +/Times-BoldItalic SF +15001 XM +(kadmin)SH +/Times-Roman SF +53400 XM +(7)SH +9000 36024 MT +(3.6 Verifying) +300 W( with)SH +/Times-BoldItalic SF +18501 XM +(kinit)SH +/Times-Roman SF +53400 XM +(8)SH +13 /Times-Bold AF +7200 37667 MT +(4. Setting) +325 W( up and testing slave server\050s\051)SH +53350 XM +(8)SH +7200 39310 MT +(5. A) +325 W( Sample Application)SH +53350 XM +(8)SH +12 /Times-Roman AF +9000 40659 MT +(5.1 The) +300 W( Installation Process)SH +53400 XM +(8)SH +9000 42008 MT +(5.2 Testing) +300 W( the Sample Server)SH +52800 XM +(10)SH +13 /Times-Bold AF +7200 43651 MT +(6. Service) +325 W( names and other services)SH +52700 XM +(11)SH +12 /Times-Roman AF +9000 45000 MT +(6.1 rlogin,) +300 W( rsh, rcp, tftp, and others)SH +52800 XM +(11)SH +9000 46349 MT +(6.2 NFS) +300 W( modifications)SH +52800 XM +(11)SH +9000 47698 MT +(6.3 inetd.conf) +300 W( entries)SH +52800 XM +(11)SH +10 SS +7200 75600 MT +(MIT Project Athena)SH +30461 XM +(i)SH +47890 XM +(4 January 1990)SH +ES +%%Trailer +%%Pages: 13 +%%DocumentFonts: Times-Roman Times-Bold Times-Italic Times-BoldItalic Courier Symbol diff --git a/doc/old-V4-docs/operation.mss b/doc/old-V4-docs/operation.mss new file mode 100644 index 0000000..a35bb9f --- /dev/null +++ b/doc/old-V4-docs/operation.mss @@ -0,0 +1,799 @@ +@Comment[ $Source$] +@Comment[ $Author$] +@Comment[ $Id$] +@Comment[] +@device[postscript] +@make[report] +@comment[ +@DefineFont(HeadingFont, + P=<RawFont "NewCenturySchlbkBoldItalic">, + B=<RawFont "NewCenturySchlbkBold">, + I=<RawFont "NewCenturySchlbkBoldItalic">, + R=<RawFont "NewCenturySchlbkRoman">) +] +@DefineFont(HeadingFont, + P=<RawFont "TimesBoldItalic">, + B=<RawFont "TimesBold">, + I=<RawFont "TimesItalic">, + R=<RawFont "TimesRoman">) +@Counter(MajorPart,TitleEnv HD0,ContentsEnv tc0,Numbered [@I], + IncrementedBy Use,Announced) +@Counter(Chapter,TitleEnv HD1,ContentsEnv tc1,Numbered [@1. ], + IncrementedBy Use,Referenced [@1],Announced) +@Counter(Appendix,TitleEnv HD1,ContentsEnv tc1,Numbered [@A. ], + IncrementedBy,Referenced [@A],Announced,Alias Chapter) +@Counter(UnNumbered,TitleEnv HD1,ContentsEnv tc1,Announced,Alias + Chapter) +@Counter(Section,Within Chapter,TitleEnv HD2,ContentsEnv tc2, + Numbered [@#@:.@1 ],Referenced [@#@:.@1],IncrementedBy + Use,Announced) +@Counter(AppendixSection,Within Appendix,TitleEnv HD2, + ContentsEnv tc2, + Numbered [@#@:.@1 ],Referenced [@#@:.@1],IncrementedBy + Use,Announced) +@Counter(SubSection,Within Section,TitleEnv HD3,ContentsEnv tc3, + Numbered [@#@:.@1 ],IncrementedBy Use, + Referenced [@#@:.@1 ]) +@Counter(AppendixSubSection,Within AppendixSection,TitleEnv HD3, + ContentsEnv tc3, + Numbered [@#@:.@1 ],IncrementedBy Use, + Referenced [@#@:.@1 ]) +@Counter(Paragraph,Within SubSection,TitleEnv HD4,ContentsEnv tc4, + Numbered [@#@:.@1 ],Referenced [@#@:.@1], + IncrementedBy Use) +@modify(CopyrightNotice, Fixed -1 inch, Flushright) +@Modify(Titlebox, Fixed 3.0 inches) +@Modify(hd1, below .2 inch, facecode B, size 16, spaces kept, pagebreak off) +@Modify(hd2, below .2 inch, facecode B, size 14, spaces kept) +@Modify(hd3, below .2 inch, facecode B, size 12, spaces kept) +@Modify(Description, Leftmargin +20, Indent -20,below 1 line, above 1 line) +@Modify(Tc1, Above .5, Facecode B) +@Modify(Tc2, Above .25, Below .25, Facecode R) +@Modify(Tc3,Facecode R) +@Modify(Tc4,Facecode R) +@Modify(Itemize,Above 1line,Below 1line) +@Modify(Insert,LeftMargin +2, RightMargin +2) +@libraryfile[stable] +@comment[@Style(Font NewCenturySchoolBook, size 11)] +@Style(Font TimesRoman, size 11) +@Style(Spacing 1.1, indent 0) +@Style(leftmargin 1.0inch) +@Style(justification no) +@Style(BottomMargin 1.5inch) +@Style(ChangeBarLocation Right) +@Style(ChangeBars=off) +@pageheading[immediate] +@pagefooting[immediate, left = "MIT Project Athena", center = "@value(page)", +right = "@value(date)"] +@set[page = 0] +@blankspace[.5 inches] +@begin[group, size 20] +@begin(center) +@b[Kerberos Operation Notes] +@b[DRAFT] +@end[center] +@blankspace[.5 inches] +@end(group) +@begin[group, size 16] +@begin(center) +Bill Bryant +John Kohl +Project Athena, MIT +@blankspace[.5 inches] +@b[Initial Release, January 24, 1989] +@i[(plus later patches through patchlevel 7)] +@end[center] +@end(group) +@begin[group, size 10] +@end[group] +@blankspace[1inches] + +These notes assume that you have used the +@i[Kerberos Installation Notes] to build and install your +Kerberos system. +As in that document, we refer to the directory that contains +the built Kerberos binaries as [OBJ_DIR]. + +This document assumes that you are a Unix system manager. + +@newpage() +@chapter[How Kerberos Works: A Schematic Description] + +This section provides a simplified description of +a general user's interaction with the Kerberos system. +This interaction happens transparently--users don't need to know +and probably don't care about what's going on--but Kerberos administrators +might find a schematic description of the process useful. +The description glosses over a lot of details; +for more information, see @i[Kerberos: An Authentication +Service for Open Network Systems], +a paper presented at Winter USENIX 1988, in Dallas, Texas. + +@section[Network Services and Their Client Programs] + +In an environment that provides network services, +you use @i[client] programs to request service from +@i[server] programs that are somewhere on the network. +Suppose you have logged in to a workstation +and you want to @i[rlogin] to another machine. +You use the local @i[rlogin] client program to +contact the remote machine's @i[rlogin] service daemon. + +@section[Kerberos Tickets] + +Under Kerberos, the @i[rlogin] service program +allows a client to login to a remote machine if it +can provide +a Kerberos @b[ticket] for the request. +This ticket proves the identity of the person who has used +the client program to access the server program. + +@section[The Kerberos Master Database] + +Kerberos will give you tickets only if you +have an entry in the Kerberos server's +@b[master database]. +Your database entry includes your Kerberos username (often referred to +as your Kerberos @b[principal] name), and your Kerberos password. +Every Kerberos user must have an entry in this database. + +@section[The Ticket-Granting Ticket] + +The @i[kinit] command prompts for your Kerberos username and password, +and if you enter them successfully, you will obtain a Kerberos +@i[ticket-granting ticket]. +As illustrated below, +client programs use this ticket to get other Kerberos tickets as +needed. + +@section[Network Services and the Master Database] + +The master database also contains entries for all network services that +require Kerberos authentication. +Suppose for instance that your site has a machine @i[laughter] +that requires Kerberos authentication from anyone who wants +to @i[rlogin] to it. +This service must be registered in the master database. +Its entry includes the service's principal name, and its @b[instance]. + +The @i[instance] is the name of the service's machine; +in this case, the service's instance is the name @i[laughter]. +The instance provides a means for Kerberos to distinguish between +machines that provide the same service. +Your site is likely to have more than one machine that +provides @i[rlogin] service. + +@section[The User-Kerberos Interaction] + +Suppose that you (in the guise of a general user) walk up to a workstation +intending to login to it, and then @i[rlogin] to the machine @i[laughter]. +Here's what happens. +@begin[enumerate] +You login to the workstation and use the @i[kinit] command +to to get a ticket-granting ticket. +This command prompts you for your username (your Kerberos Principal Name), +and your Kerberos password [on some systems which use the new version of +@i{/bin/login}, this may be done as part of the login process, not +requiring the user to run a separate program]. +@begin[enumerate] +The @i[kinit] command sends your request to the Kerberos master server +machine. +The server software looks for your principal name's entry in the +Kerberos @b[master database]. + +If this entry exists, the +Kerberos server creates and returns a +@i[ticket-granting ticket], encrypted in your password. +If @i[kinit] can decrypt the Kerberos reply using the password you +provide, it stores this ticket in a @b[ticket file] on your +local machine for later use. +The ticket file to be used +can be specified in the @b[KRBTKFILE] environment +variable. If this variable is not set, the name of the file will be +@i[/tmp/tkt@p(uid)], where @p(uid) is the UNIX user-id, represented in decimal. +@end[enumerate] + +Now you use the @i[rlogin] client to try to access the machine @i[laughter]. +@begin[example] +host% @b[rlogin laughter] +@end[example] +@begin[enumerate] +The @i[rlogin] client checks your ticket file to see if you +have a ticket for @i[laughter]'s @i[rcmd] service (the rlogin program +uses the @i[rcmd] service name, mostly for historical reasons). +You don't, so @i[rlogin] uses the ticket file's @i[ticket-granting +ticket] to make a request to the master server's ticket-granting service. + +This ticket-granting service receives the @i[rcmd-laughter] request +and looks in the master database for an @i[rcmd-laughter] entry. +If that entry exists, the ticket-granting service issues you a ticket +for that service. +That ticket is also cached in your ticket file. + +The @i[rlogin] client now uses that ticket to request service from +the @i[laughter] @i[rlogin] service program. +The service program +lets you @i[rlogin] if the ticket is valid. +@end[enumerate] +@end[enumerate] + +@chapter[Setting Up and Testing the Kerberos Server] + +The procedure for setting up and testing a Kerberos server +is as follows: +@begin[enumerate] +Use the @i[kdb_init] command to create and initialize the master database. + +Use the @i[kdb_edit] utility to add your username to the +master database. + +Start the Kerberos server. + +Use the @i[kinit] command to obtain a Kerberos ticket-granting ticket. + +Use the @i[klist] command to verify that the @i[kinit] command +authenticated you successfully. +@end[enumerate] + +@section[Creating and Initializing the Master Database] + +Login to the Kerberos master server machine, +and use the @b[su] command to become root. +If you installed the Kerberos administration tools +with the @i[make install] command and the default pathnames, +they should be in the @i[/usr/etc] directory. +If you installed the tools in a different directory, +hopefully you know what it is. +From now on, we will refer to this directory as [ADMIN_DIR]. + +The @i[kdb_init] command creates and initializes the master database. +It asks you to enter the system's +realm name and the database's master password. +Do not forget this password. +If you do, the database becomes useless. +(Your realm name should be substituted for [REALMNAME] below.) + +Use @i[kdb_init] as follows: +@tabset[3inches, +1.5inches] +@begin[example, rightmargin -10] +host# @b([ADMIN_DIR]/kdb_init) +Realm name (default XXX): @b([REALMNAME])@\@b[<--] @p[Enter your system's realm name.] +You will be prompted for the database Master Password. +It is important that you NOT FORGET this password. + +Enter Kerberos master key: @\@b[<--] @p[Enter the master password.] +@comment(this needs to be re-fixed...: +Verifying, please re-enter +Enter Kerberos master key: @\@b[<--] @p[Re-enter it.] +) +@end[example] + +@section[Storing the Master Password] + +The @i[kstash] command ``stashes'' the master password in the file @i[/.k] +so that the Kerberos server can +be started automatically during an unattended reboot of the +master server. +Other administrative programs use this hidden password so that they +can access the master database without someone having to manually +provide the master password. +This command is an optional one; +if you'd rather enter the master password each time you +start the Kerberos server, don't use @i[kstash]. + +One the one hand, if you use @i[kstash], a copy of the master +key will reside +on disk which may not be acceptable; on the other hand, if you don't +use @i[kstash], the server cannot be started unless someone is around to +type the password in manually. + +The command prompts you twice for the master password: +@begin[example] +@tabset[3inches] +host# @b([ADMIN_DIR]/kstash) + +Enter Kerberos master key:@\@b[<--] @p[Enter the master password.] +Current Kerberos master key version is 1. + +Master key entered BEWARE! +@end[example] + +A note about the Kerberos database master key: +if your master key is compromised and the database is obtained, +the security of your entire authentication system is compromised. +The master key must be a carefully kept secret. If you keep backups, +you must guard all the master keys you use, in case someone has stolen +an old backup and wants to attack users' whose passwords haven't changed +since the backup was stolen. +This is why we provide the option not to store it on disk. + +@section[Using @p(kdb_edit) to Add Users to the Master Database] + +The @i[kdb_edit] program is used to add new users and services +to the master database, and to modify existing database information. +The program prompts you to enter a principal's @b[name] and @b[instance]. + +A principal name is typically a username or a service program's name. +An instance further qualifies the principal. +If the principal is a service, +the instance is used to specify the name of the machine on which that +service runs. +If the principal is a username that has general user privileges, +the instance is usually set to null. + +The following example shows how to use @i[kdb_edit] to +add the user @i[wave] to the Kerberos database. +@begin[example, rightmargin -10] +@tabset[3inches, +1.5inches] +host# @b([ADMIN_DIR]/kdb_edit) + +Opening database... + +Enter Kerberos master key: +Verifying, please re-enter +Enter Kerberos master key: +Current Kerberos master key version is 1 + +Master key entered. BEWARE! +Previous or default values are in [brackets] , +enter return to leave the same, or new value. + +Principal name: @b[wave]@\@b[<--] @p[Enter the username.] +Instance:@\@p[<-- Enter a null instance.] + +<Not found>, Create [y] ? @b[y]@\@b[<--] @p[The user-instance does not exist.] +@\@p[ Enter y to create the user-instance.] +Principal: wave Instance: m_key_v: 1 +New Password: @\@p[<-- Enter the user-instance's password.] +Verifying, please re-enter +New Password: +Principal's new key version = 1 +Expiration date (enter dd-mm-yy) [ 12/31/99 ] ?@\@b[<--] @p[Enter newlines] +Max ticket lifetime (*5 minutes) [ 255 ] ? @\@b[<--] @p[to get the] +Attributes [ 0 ] ? @\@\@b[<--] @p[default values.] +Edit O.K. + +Principal name:@\@p[<-- Enter a newline to exit the program.] +@end[example] + +Use the @i[kdb_edit] utility to add your username to the master database. + +@section[Starting the Kerberos Server] + +Change directories to the directory in which you have installed +the server program @i[kerberos] +(the default directory is @i[/usr/etc]), +and start the program as a background process: +@begin[example] +host# @b[./kerberos &] +@end[example] +If you have used the @i[kstash] command to store the master database password, +the server will start automatically. +If you did not use @i[kstash], +use the following command: +@begin[example] +host# @b[./kerberos -m] +@end[example] +The server will prompt you to enter the master password before actually +starting itself. + +@section[Testing the Kerberos Server] + +Exit the root account and use the @i[kinit] command obtain a Kerberos +ticket-granting ticket. +This command +creates your ticket file +and stores the ticket-granting ticket in it. + +If you used the default @i[make install] command and directories to +install the Kerberos user utilities, @i[kinit] will be in the +@i[/usr/athena] directory. From now on, we'll refer to the Kerberos user +commands directory as [K_USER]. + +Use @i[kinit] as follows: +@begin[example] +@tabset[3 inches] +host% @b([K_USER]/kinit) +MIT Project Athena, (ariadne) +Kerberos Initialization +Kerberos name: @p[yourusername]@\@b[<--] @p[Enter your Kerberos username.] +Password: @\@b[<--] @p[Enter your Kerberos password.] +@end[example] + +Use the @i[klist] program to list the contents of your ticket file. +@begin[example] +host% @b([K_USER]/klist) +@end[example] +The command should display something like the following: +@begin[example] +Ticket file: /tmp/tkt5555 +Principal: yourusername@@REALMNAME + + Issued Expires Principal +May 6 10:15:23 May 6 18:15:23 krbtgt.REALMNAME@@REALMNAME +@end[example] + +If you have any problems, you can examine the log file +@i[/kerberos/kerberos.log] on the Kerberos server machine to see if +there was some sort of error. + +@chapter[Setting up and testing the Administration server] + +The procedure for setting up and testing the Kerberos administration server +is as follows: +@begin[enumerate] +Use the @i[kdb_edit] utility to add your username with an administration +instance to the master database. + +Edit the access control lists for the administration server + +Start the Kerberos administration server. + +Use the @i[kpasswd] command to change your password. + +Use the @i[kadmin] command to add new entries to the database. + +Use the @i[kinit] command to verify that the @i[kadmin] command +correctly added new entries to the database. +@end(enumerate) + +@section[Adding an administration instance for the administrator] + +Login to the Kerberos master server machine, +and use the @b[su] command to become root. +Use the @i[kdb_edit] program to create an entry for each administrator +with the instance ``@p(admin)''. +@begin[example] +@tabset[3inches, +1.5inches] +host# @b([ADMIN_DIR]/kdb_edit) + +Opening database... + +Enter Kerberos master key: +Verifying, please re-enter +Enter Kerberos master key: +Current Kerberos master key version is 1 + +Master key entered. BEWARE! +Previous or default values are in [brackets] , +enter return to leave the same, or new value. + +Principal name: @b[wave]@\@b[<--] @p[Enter the username.] +Instance:@b[admin]@\@b[<--] @p[Enter ``admin''.] + +<Not found>, Create [y] ? @b[y]@\@b[<--] @p[The user-instance does not exist.] +@\@p[ Enter y to create the user-instance.] +Principal: wave Instance: admin m_key_v: 1 +New Password: @\@p[<-- Enter the user-instance's password.] +Verifying, please re-enter +New Password: +Principal's new key version = 1 +Expiration date (enter dd-mm-yy) [ 12/31/99 ] ?@\@b[<--] @p[Enter newlines] +Max ticket lifetime (*5 minutes) [ 255 ] ? @\@b[<--] @p[to get the] +Attributes [ 0 ] ? @\@\@b[<--] @p[default values.] +Edit O.K. + +Principal name:@\@p[<-- Enter a newline to exit the program.] +@end[example] + +@section[The Access Control Lists] +The Kerberos administration server uses three access control lists to +determine who is authorized to make certain requests. The access +control lists are stored on the master Kerberos server in the same +directory as the principal database, @i(/kerberos). The access control +lists are simple ASCII text files, with each line specifying the name of +one principal who is allowed the particular function. To allow several +people to perform the same function, put their principal names on +separate lines in the same file. + +The first list, @i(/kerberos/admin_acl.mod), is a list of principals +which are authorized to change entries in the database. To allow the +administrator `@b[wave]' to modify entries in the database for the realm +`@b[TIM.EDU]', you would put the following line into the file +@i(/kerberos/admin_acl.mod): +@begin(example) +wave.admin@@TIM.EDU +@end(example) + +The second list, @i(/kerberos/admin_acl.get), is a list of principals +which are authorized to retrieve entries from the database. + +The third list, @i(/kerberos/admin_acl.add), is a list of principals +which are authorized to add new entries to the database. + +@section(Starting the administration server) +Change directories to the directory in which you have installed +the administration server program @i[kadmind] +(the default directory is @i[/usr/etc]), +and start the program as a background process: +@begin[example] +host# @b[./kadmind -n&] +@end[example] +If you have used the @i[kstash] command to store the master database password, +the server will start automatically. +If you did not use @i[kstash], +use the following command: +@begin[example] +host# @b[./kadmind] +@end[example] +The server will prompt you to enter the master password before actually +starting itself; after it starts, you should suspend it and put it in +the background (usually this is done by typing control-Z and then @b(bg)). + +@section(Testing @p[kpasswd]) + +To test the administration server, you should try changing your password +with the @i[kpasswd] command, and you should try adding new users with +the @i[kadmin] command (both commands are installed into @i[/usr/athena] +by default). + +Before testing, you should exit the root account. + +To change your password, run the @i[kpasswd] command: +@begin(example) +@tabset[3inches, +1.5inches] +host% @b([K_USER]/kpasswd) +Old password for wave@@TIM.EDU:@\@b[<--]@p[Enter your password] +New Password for wave@@TIM.EDU:@\@b[<--]@p[Enter a new password] +Verifying, please re-enter New Password for wave@@TIM.EDU: +@\@b[<--]@p[Enter new password again] +Password changed. +@end(example) +Once you have changed your password, use the @i[kinit] program as shown +above to verify that the password was properly changed. + +@section(Testing @p[kadmin]) +You should also test the function of the @i[kadmin] program, by adding a +new user (here named ``@t[username]''): +@begin(example) +@tabset[3inches, +1.5inches] +host% @b([K_USER]/kadmin) +Welcome to the Kerberos Administration Program, version 2 +Type "help" if you need it. +admin: @b(ank username)@\@p[`ank' stands for Add New Key] +Admin password: @\@b[<--]@p[enter the password +@\you chose above for wave.admin] +Password for username:@\@b[<--]@p[Enter the user's initial password] +Verifying, please re-enter Password for username:@\@b[<--]@p[enter it again] +username added to database. + +admin: quit +Cleaning up and exiting. +@end[example] + +@section(Verifying with @p[kinit]) +Once you've added a new user, you should test to make sure it was added +properly by using @i[kinit], and trying to get tickets for that user: + +@begin[example] +@tabset[3inches, +1.5inches] +host% @b([K_USER]/kinit username) +MIT Project Athena (ariadne) +Kerberos Initialization for "username@@TIM.EDU" +Password: @b[<--]@p[Enter the user's password you used above] +host% @b([K_USER]/klist) +Ticket file: /tmp/tkt_5509_spare1 +Principal: username@@TIM.MIT.EDU + + Issued Expires Principal +Nov 20 15:58:52 Nov 20 23:58:52 krbtgt.TIM.EDU@@TIM.EDU +@end[example] + +If you have any problems, you can examine the log files +@i[/kerberos/kerberos.log] and @i[/kerberos/admin_server.syslog] on the +Kerberos server machine to see if there was some sort of error. + +@chapter[Setting up and testing slave server(s)] + +[Unfortunately, this chapter is not yet ready. Sorry. -ed] + +@chapter[A Sample Application] + +This release of Kerberos comes with a sample application +server and a corresponding client program. +You will find this software in the [OBJ_DIR]@i[/appl/sample] directory. +The file @i[sample_client] contains the client program's executable +code, the file @i[sample_server] contains the server's executable. + +The programs are rudimentary. +When they have been installed (the installation procedure is described +in detail later), they work as follows: +@begin[itemize] +The user starts @i[sample_client] and provides as arguments +to the command the name of the server machine and a checksum. +For instance: +@begin[example] +host% @b[sample_client] @p[servername] @p[43] +@end[example] + +@i[Sample_client] contacts the server machine and +authenticates the user to @i[sample_server]. + +@i[Sample_server] authenticates itself to @i[sample_client], +then returns a message to the client program. +This message contains diagnostic information +that includes the user's username, the Kerberos realm, +and the user's workstation address. + +@i[Sample_client] displays the server's message on the user's +terminal screen. +@end[itemize] + +@section[The Installation Process] + +In general, +you use the following procedure to install a Kerberos-authenticated +server-client system. +@begin[enumerate] +Add the appropriate entry to the Kerberos database using @i[kdb_edit] or +@i[kadmin] (described below). + +Create a @i[/etc/srvtab] file for the server machine. + +Install the service program and the @i[/etc/srvtab] +file on the server machine. + +Install the client program on the client machine. + +Update the @i[/etc/services] file on the client and server machines. +@end[enumerate] + +We will use the sample application as an example, although +the procedure used to install @i[sample_server] differs slightly +from the general case because the @i[sample_server] +takes requests via the +@i[inetd] program. +@i[Inetd] starts @i[sample_server] each time +a client process contacts the server machine. +@i[Sample_server] processes the request, +terminiates, then is restarted when @i[inetd] receives another +@i[sample_client] request. +When you install the program on the server, +you must add a @i[sample] entry to the server machine's +@i[/etc/inetd.conf] file. + +The following description assumes that you are installing +@i[sample_server] on the machine @i[ariadne.tim.edu]. +Here's the process, step by step: +@begin[enumerate] +Login as or @i[su] to root on the Kerberos server machine. +Use the @i[kdb_edit] or @i[kadmin] program to create an entry for +@i[sample] in the Kerberos database: +@begin[example, rightmargin -10] +@tabset[2.0inches, +.5inches] +host# @b([ADMIN_DIR]/kdb_edit) + +Opening database... + +Enter Kerberos master key: +Verifying, please re-enter +master key entered. BEWARE! +Previous or default values are in [brackets] , +enter return to leave the same, or new value. + +Principal name: @b[sample]@\@b[<--] @p[Enter the principal name.] +Instance: @b[ariadne]@\@b[<--] @p[Instances cannot have periods in them.] + +<Not found>, Create [y] ? @b[y] + +Principal: sample_server Instance: ariadne m_key_v: 1 +New Password:@\@b[<--] @p[Enter ``RANDOM'' to get random password.] +Verifying, please re-enter +New Password:@\@b[<--] @p[Enter ``RANDOM'' again.] +Random password [y] ? @b[y] + +Principal's new key version = 1 +Expiration date (enter dd-mm-yy) [ 12/31/99 ] ? +Max ticket lifetime (*5 minutes) [ 255 ] ? +Attributes [ 0 ] ? +Edit O.K. + +Principal name:@\@b[<--] @p[Enter newline to exit kdb_edit.] +@end[example] + +Use the @i[ext_srvtab] program to create a @i[srvtab] file +for @i[sample_server]'s host machine: +@begin[example] +host# @b([ADMIN_DIR]/ext_srvtab ariadne) + +Enter Kerberos master key: +Current Kerberos master key version is 1. + +Generating 'ariadne-new-srvtab'.... +@end[example] +Transfer the @i[ariadne-new-srvtab] file to @i[ariadne] and install it as +@i[/etc/srvtab]. +Note that this file is equivalent to the service's password and should +be treated with care. +For example, it could be transferred by removable media, but should +not be sent over an open network in the clear. +Once installed, this file should be readable only by root. + +Add the following line to the @i[/etc/services] file on +@i[ariadne], and on all machines that +will run the @i[sample_client] program: +@begin[example] +sample 906/tcp # Kerberos sample app server +@end[example] + +Add a line similar to the following line to the @i[/etc/inetd.conf] +file on @i[sample_server]'s machine: +@begin[example] +sample stream tcp nowait switched root + [PATH]/sample_server sample_server +@end[example] +where [PATH] should be substituted with +the path to the @i[sample_server] program. +(This @i[inetd.conf] information should be placed on one line.) +You should examine existing lines in @i[/etc/inetd.conf] and use the +same format used by other entries (e.g. for telnet). Most systems do +not have a column for the `switched' keyword, and some do not have a +column for the username (usually `root', as above). + +Restart @i[inetd] by sending the current @i[inetd] process +a hangup signal: +@begin[example] +host# @b[kill -HUP @p(process_id_number)] +@end[example] + +The @i[sample_server] is now ready to take @i[sample_client] requests. +@end[enumerate] + +@section[Testing the Sample Server] + +Assume that you have installed @i[sample_server] on @i[ariadne]. + +Login to your workstation and use the @i[kinit] command to +obtain a Kerberos ticket-granting ticket: +@begin[example] +@tabset[3 inches] +host% @b([K_USER]/kinit) +MIT Project Athena, (your_workstation) +Kerberos Initialization +Kerberos name: @p[yourusername]@\@b[<--] @p[Enter your Kerberos username.] +Password: @\@b[<--] @p[Enter your Kerberos password.] +@end[example] + +Now use the @i[sample_client] program as follows: +@begin[example] +host% @b([PATH]/sample_client ariadne) +@end[example] +The command should display something like the following: +@begin[example] +The server says: +You are @p[yourusername].@@REALMNAME (local name @p[yourusername]), + at address @p[yournetaddress], version VERSION9, cksum 997 +@end[example] + +@chapter[Service names and other services] + +@section(rlogin, rsh, rcp, tftp, and others) + +Many services use a common principal name for authentication purposes. +@i[rlogin], @i[rsh], @i[rcp], @i[tftp] and others use the principal name +``@t[rcmd]''. For example, to set up the machine @i[ariadne] to support +Kerberos rlogin, it needs to have a service key for principal +``@t[rcmd]'', instance ``@t[ariadne]''. You create this key in the same +way as shown above for the sample service. + +After creating this key, you need to run the @i[ext_srvtab] program +again to generate a new srvtab file for ariadne. + +@section(NFS modifications) + +The NFS modifications distributed separately use the service name +``@t[rvdsrv]'' with the instance set to the machine name (as for the +sample server and the rlogin, rsh, rcp and tftp services). + +@section(inetd.conf entries) +The following are the @i(/etc/inetd.conf) entries necessary to support +rlogin, encrypted rlogin, rsh, and rcp services on a server machine. As +above, your @i(inetd.conf) may not support all the fields shown here. +@begin[example] +eklogin stream tcp nowait unswitched root + [PATH]/klogind eklogind +kshell stream tcp nowait unswitched root + [PATH]/kshd kshd +klogin stream tcp nowait unswitched root + [PATH]/klogind klogind +@end[example] |