Release 0.0r

[heimdal.git] / doc / standardisation / draft-ietf-cat-kerberos-revisions-00.txt

INTERNET-DRAFT                               Clifford Neuman
                                                   John Kohl
                                               Theodore Ts'o
                                                11 July 1997



     The Kerberos  Network Authentication Service (V5)


STATUS OF THIS MEMO

     This document is  an  Internet-Draft.   Internet-Drafts
are working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups.  Note that  other
groups  may  also  distribute working documents as Internet-
Drafts.

     Internet-Drafts are draft documents valid for a maximum
of  six months and may be updated, replaced, or obsoleted by
other documents at any time.  It  is  inappropriate  to  use
Internet-Drafts  as reference material or to cite them other
than as "work in progress."

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

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

   krb-protocol@MIT.EDU

ABSTRACT


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

     This document is not intended to describe  Kerberos  to
__________________________
Project Athena, Athena, and Kerberos are trademarks  of
the  Massachusetts  Institute  of Technology (MIT).  No
commercial use of these trademarks may be made  without
prior written permission of MIT.



Overview                   - 1 -     Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


the  end  user,   system   administrator,   or   application
developer.   Higher level papers describing Version 5 of the
Kerberos system [1] and documenting  version  4   [23],  are
available elsewhere.

OVERVIEW

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

     The  motivations,  goals,  assumptions,  and  rationale
behind most design decisions are treated cursorily; they are
more fully described in a paper available in IEEE communica-
tions  [1] and earlier in the Kerberos portion of the Athena
Technical Plan [2].  The  protocols  have  been  a  proposed
standard  and are being considered for advancement for draft
standard through the IETF standard  process.   Comments  are
encouraged  on  the presentation, but only minor refinements
to the protocol as implemented or extensions that fit within
current protocol framework will be considered at this time.

     Requests for addition to an electronic mailing list for
discussion  of  Kerberos, kerberos@MIT.EDU, may be addressed
to kerberos-request@MIT.EDU.  This mailing list is gatewayed
onto   the  Usenet  as  the  group  comp.protocols.kerberos.
Requests for further information,  including  documents  and
code availability, may be sent to info-kerberos@MIT.EDU.

BACKGROUND

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

     Version 5 of the Kerberos protocol (described  in  this
document)  has  evolved from Version 4 based on new require-
ments and desires for features not available in  Version  4.
The  design of Version 5 of the Kerberos protocol was led by
Clifford Neuman and John Kohl with much input from the  com-
munity.  The development of the MIT reference implementation
was led at MIT by John Kohl and Theodore T'so, with help and
contributed  code  from  many others.  Reference implementa-
tions of both version 4 and version 5 of Kerberos  are  pub-
licly  available  and  commercial  implementations have been

Overview                   - 2 -     Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


developed and are widely used.

     Details on the differences between Kerberos Versions  4
and 5 can be found in [6].

1.  Introduction

     Kerberos provides a means of verifying  the  identities
of principals, (e.g. a workstation user or a network server)
on an open  (unprotected)  network.   This  is  accomplished
without  relying on assertions by the host operating system,
without basing trust on host  addresses,  without  requiring
physical security of all the hosts on the network, and under
the assumption that packets traveling along the network  can
be read, modified, and inserted at will[1].   Kerberos  per-
forms  authentication  under  these  conditions as a trusted
third-party authentication  service  by  using  conventional
(shared secret key[2])  cryptography.   Kerberos  extensions
have  been proposed and implemented that provide for the use
of public key cryptography  during  certain  phases  of  the
authentication   protocol.   These  extensions  provide  for
authentication of users registered with public key  certifi-
cation  authorities, and allow the system to provide certain
benefits of public key cryptography in situations where they
are needed.

     The basic Kerberos authentication process  proceeds  as
follows:  A  client  sends  a  request to the authentication
server (AS) requesting "credentials"  for  a  given  server.
The  AS  responds  with  these credentials, encrypted in the
client's key.  The credentials consist of 1) a "ticket"  for
the server and 2) a temporary encryption key (often called a
"session key").  The client transmits the ticket (which con-
tains  the  client's identity and a copy of the session key,
all encrypted in the server's key) to the server.  The  ses-
sion  key  (now  shared by the client and server) is used to
authenticate the client,  and  may  optionally  be  used  to
__________________________
[1] Note, however, that many applications use Kerberos'
functions  only  upon  the initiation of a stream-based
network connection.  Unless an application subsequently
provides  integrity protection for the data stream, the
identity verification applies only to the initiation of
the  connection, and does not guarantee that subsequent
messages on the  connection  originate  from  the  same
principal.
[2] Secret  and  private are often used interchangeably
in the literature.  In our  usage,  it  takes  two  (or
more)  to  share  a  secret, thus a shared DES key is a
secret key.  Something is only private when no one  but
its owner knows it.  Thus, in public key cryptosystems,
one has a public and a private key.



Section 1.                 - 3 -     Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


authenticate the server.  It may also  be  used  to  encrypt
further communication between the two parties or to exchange
a separate sub-session key to be  used  to  encrypt  further
communication.

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

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

     Once obtained, credentials may be used  to  verify  the
identity  of  the principals in a transaction, to ensure the
integrity of messages exchanged between them, or to preserve
privacy  of the messages.  The application is free to choose
whatever protection may be necessary.

     To verify the identities of the principals in  a  tran-
saction,  the client transmits the ticket to the application
server.  Since the ticket is sent "in the clear"  (parts  of
it are encrypted, but this encryption doesn't thwart replay)
and might be intercepted and reused by  an  attacker,  addi-
tional  information  is  sent to prove that the message ori-
ginated with the principal to whom the  ticket  was  issued.
This  information (called the authenticator) is encrypted in
the session key, and includes a  timestamp.   The  timestamp
proves  that the message was recently generated and is not a
replay.  Encrypting the authenticator  in  the  session  key
proves  that it was generated by a party possessing the ses-
sion key.  Since no one except the requesting principal  and


Section 1.                 - 4 -     Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


the  server  know the session key (it is never sent over the
network in the clear) this guarantees the  identity  of  the
client.

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

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

1.1.  Cross-Realm Operation

     The Kerberos protocol is  designed  to  operate  across
organizational boundaries.  A client in one organization can
be authenticated to a server in another.  Each  organization
wishing  to  run  a  Kerberos  server  establishes  its  own
"realm".  The name  of  the  realm  in  which  a  client  is
registered  is part of the client's name, and can be used by
the end-service to decide whether to honor a request.

     By establishing "inter-realm" keys, the  administrators
of  two realms can allow a client authenticated in the local
realm to prove its identity to servers in  other  realms[3].
The exchange of inter-realm keys (a separate key may be used
for each direction) registers the ticket-granting service of
each  realm  as a principal in the other realm.  A client is
then able to obtain a ticket-granting ticket for the  remote
realm's  ticket-granting service from its local realm.  When
that ticket-granting ticket  is  used,  the  remote  ticket-
granting  service  uses  the  inter-realm key (which usually
__________________________
[3] Of course, with appropriate permission  the  client
could  arrange registration of a separately-named prin-
cipal in a remote realm, and engage in normal exchanges
with  that  realm's  services.  However, for even small
numbers of clients this becomes  cumbersome,  and  more
automatic methods as described here are necessary.


Section 1.1.               - 5 -     Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


differs from its own normal TGS key) to decrypt the  ticket-
granting  ticket,  and is thus certain that it was issued by
the client's own TGS.  Tickets issued by the remote  ticket-
granting  service  will indicate to the end-service that the
client was authenticated from another realm.

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

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

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

1.2.  Authorization

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

     Such separate authorization methods may be  implemented
as  application specific access control functions and may be
based on  files  such  as  the  application  server,  or  on
separately  issued  authorization  credentials such as those
based on proxies [7] , or on other authorization services.

     Applications should  not  be  modified  to  accept  the
issuance of a service ticket by the Kerberos server (even by

Section 1.2.               - 6 -     Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


an modified Kerberos server) as granting  authority  to  use
the  service,  since such applications may become vulnerable
to the bypass of this authorization check in an  environment
where  they  interoperate  with  other  KDCs  or where other
options for application authentication (e.g. the PKTAPP pro-
posal) are provided.

1.3.  Environmental assumptions

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

+    "Denial of service" attacks are not  solved  with  Ker-
     beros.   There  are  places in these protocols where an
     intruder can prevent an application from  participating
     in  the  proper  authentication  steps.   Detection and
     solution of such attacks (some of which can  appear  to
     be  not-uncommon "normal" failure modes for the system)
     is usually best left to the  human  administrators  and
     users.

+    Principals must keep their secret keys secret.   If  an
     intruder  somehow  steals a principal's key, it will be
     able to masquerade as that principal or impersonate any
     server to the legitimate principal.

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

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

+    Principal identifiers are not recycled on a  short-term
     basis.   A  typical  mode  of  access  control will use
     access control lists (ACLs)  to  grant  permissions  to
     particular  principals.   If  a stale ACL entry remains
     for a deleted principal and the principal identifier is
     reused, the new principal will inherit rights specified
     in the stale ACL  entry.   By  not  re-using  principal
     identifiers,   the  danger  of  inadvertent  access  is
     removed.



Section 1.3.               - 7 -     Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


1.4.  Glossary of terms

Below is a list of terms used throughout this document.


Authentication      Verifying  the  claimed  identity  of  a
                    principal.


Authentication headerA record containing  a  Ticket  and  an
                    Authenticator   to  be  presented  to  a
                    server as  part  of  the  authentication
                    process.


Authentication path A sequence of intermediate realms  tran-
                    sited in the authentication process when
                    communicating from one realm to another.


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


Authorization       The process  of  determining  whether  a
                    client may use a service,  which objects
                    the client is allowed to access, and the
                    type of access allowed for each.


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


Ciphertext          The output of  an  encryption  function.
                    Encryption   transforms  plaintext  into
                    ciphertext.


Client              A process that makes use  of  a  network
                    service  on behalf of a user.  Note that
                    in some cases a Server may itself  be  a
                    client  of  some  other  server  (e.g. a
                    print server may be a client of  a  file
                    server).



Section 1.4.               - 8 -     Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


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


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


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


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


Principal           A  uniquely  named  client   or   server
                    instance  that participates in a network
                    communication.


Principal identifierThe name used to uniquely identify  each
                    different principal.


Seal                To encipher a record containing  several
                    fields  in  such  a  way that the fields
                    cannot be individually replaced  without
                    either  knowledge  of the encryption key
                    or leaving evidence of tampering.


Secret key          An encryption key shared by a  principal
                    and  the  KDC,  distributed  outside the
                    bounds of the system, with a long  life-
                    time.   In  the  case  of a human user's
                    principal, the  secret  key  is  derived


Section 1.4.               - 9 -     Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


                    from a password.


Server              A particular Principal which provides  a
                    resource to network clients.  The server
                    is sometimes refered to as the  Applica-
                    tion Server.


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


Session key         A temporary encryption key used  between
                    two  principals, with a lifetime limited
                    to the duration of a single login  "ses-
                    sion".


Sub-session key     A temporary encryption key used  between
                    two  principals,  selected and exchanged
                    by the principals using the session key,
                    and with a lifetime limited to the dura-
                    tion of a single association.


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

2.  Ticket flag uses and requests

Each Kerberos ticket contains a set of flags which are  used
to  indicate  various attributes of that ticket.  Most flags
may be requested by a client when the  ticket  is  obtained;
some  are  automatically  turned  on  and  off by a Kerberos
server as required.  The following sections explain what the
various  flags  mean,  and  gives examples of reasons to use
such a flag.

2.1.  Initial and pre-authenticated tickets

     The INITIAL flag indicates that  a  ticket  was  issued
using  the  AS  protocol  and  not issued based on a ticket-
granting ticket.  Application servers that want  to  require
the  demonstrated knowledge of a client's secret key (e.g. a
password-changing program) can insist that this flag be  set
in  any  tickets  they  accept, and thus be assured that the


Section 2.1.               - 10 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


client's key  was  recently  presented  to  the  application
client.

     The PRE-AUTHENT and HW-AUTHENT flags  provide  addition
information  about the initial authentication, regardless of
whether the current ticket was  issued  directly  (in  which
case  INITIAL  will also be set) or issued on the basis of a
ticket-granting ticket (in which case the  INITIAL  flag  is
clear,  but the PRE-AUTHENT and HW-AUTHENT flags are carried
forward from the ticket-granting ticket).

2.2.  Invalid tickets

     The INVALID flag indicates that a  ticket  is  invalid.
Application servers must reject tickets which have this flag
set.  A postdated ticket will  usually  be  issued  in  this
form.   Invalid  tickets must be validated by the KDC before
use, by presenting them to the KDC in a TGS request with the
VALIDATE option specified.  The KDC will only validate tick-
ets after their starttime has  passed.   The  validation  is
required  so  that  postdated tickets which have been stolen
before their starttime can be rendered  permanently  invalid
(through a hot-list mechanism) (see section 3.3.3.1).

2.3.  Renewable tickets

     Applications may desire to hold tickets  which  can  be
valid  for  long  periods of time.  However, this can expose
their  credentials  to  potential  theft  for  equally  long
periods,  and  those stolen credentials would be valid until
the expiration time of the ticket(s).  Simply  using  short-
lived  tickets  and  obtaining  new  ones periodically would
require the client to have long-term access  to  its  secret
key, an even greater risk.  Renewable tickets can be used to
mitigate the consequences of theft.  Renewable tickets  have
two  "expiration  times":  the  first  is  when  the current
instance of the ticket expires, and the second is the latest
permissible  value  for  an  individual expiration time.  An
application  client  must  periodically  (i.e.   before   it
expires)  present  a  renewable  ticket to the KDC, with the
RENEW option set in the KDC request.  The KDC will  issue  a
new  ticket  with  a  new session key and a later expiration
time.  All other fields of the ticket are left unmodified by
the renewal process.  When the latest permissible expiration
time arrives,  the  ticket  expires  permanently.   At  each
renewal,  the KDC may consult a hot-list to determine if the
ticket had been reported stolen since its last  renewal;  it
will  refuse  to  renew  such  stolen  tickets, and thus the
usable lifetime of stolen tickets is reduced.

     The RENEWABLE flag in a ticket is normally only  inter-
preted  by  the  ticket-granting service (discussed below in
section 3.3).  It can  usually  be  ignored  by  application
servers.   However,  some  particularly  careful application


Section 2.3.               - 11 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


servers may wish to disallow renewable tickets.

     If a renewable ticket is not renewed by its  expiration
time, the KDC will not renew the ticket.  The RENEWABLE flag
is reset by default, but a client may request it be  set  by
setting  the RENEWABLE option in the KRB_AS_REQ message.  If
it is set, then the renew-till field in the ticket  contains
the time after which the ticket may not be renewed.

2.4.  Postdated tickets

     Applications may occasionally need  to  obtain  tickets
for  use  much  later,  e.g. a batch submission system would
need tickets to be valid at the time the batch job  is  ser-
viced.   However, it is dangerous to hold valid tickets in a
batch queue, since they will  be  on-line  longer  and  more
prone  to  theft.  Postdated tickets provide a way to obtain
these tickets from the KDC at job submission  time,  but  to
leave  them "dormant" until they are activated and validated
by a further request of the KDC.  If  a  ticket  theft  were
reported  in  the  interim, the KDC would refuse to validate
the ticket, and the thief would be foiled.

     The MAY-POSTDATE flag in  a  ticket  is  normally  only
interpreted  by  the  ticket-granting  service.  It  can  be
ignored by application servers.  This flag must be set in  a
ticket-granting  ticket in order to issue a postdated ticket
based on the presented ticket.  It is reset by  default;  it
may  be  requested by a client by setting the ALLOW-POSTDATE
option in the KRB_AS_REQ message.  This flag does not  allow
a client to obtain a postdated ticket-granting ticket; post-
dated  ticket-granting  tickets  can  only  by  obtained  by
requesting  the  postdating  in the KRB_AS_REQ message.  The
life (endtime-starttime) of a postdated ticket will  be  the
remaining  life of the ticket-granting ticket at the time of
the request, unless the RENEWABLE option  is  also  set,  in
which  case  it  can be the full life (endtime-starttime) of
the ticket-granting ticket.  The KDC may limit  how  far  in
the future a ticket may be postdated.

     The POSTDATED flag indicates that  a  ticket  has  been
postdated.   The  application  server can check the authtime
field in the ticket to see when the original  authentication
occurred.   Some  services  may  choose  to reject postdated
tickets, or they may  only  accept  them  within  a  certain
period  after  the  original  authentication.   When the KDC
issues a  POSTDATED  ticket,  it  will  also  be  marked  as
INVALID,  so  that  the  application client must present the
ticket to the KDC to be validated before use.

2.5.  Proxiable and proxy tickets

     At times it may be necessary for a principal to allow a
service  to perform an operation on its behalf.  The service


Section 2.5.               - 12 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


must be able to take on the identity of the client, but only
for  a  particular purpose.  A principal can allow a service
to take on the principal's identity for a particular purpose
by granting it a proxy.

     The process of granting a proxy  using  the  proxy  and
proxiable  flags is used to provide credentials for use with
specific services.  Though conceptually also a proxy, user's
wishing  to delegate their identity for ANY purpose must use
the ticket forwarding mechanism described in the  next  sec-
tion to forward a ticket granting ticket.

     The PROXIABLE flag in a ticket is normally only  inter-
preted  by the ticket-granting service. It can be ignored by
application servers.  When set, this flag tells the  ticket-
granting server that it is OK to issue a new ticket (but not
a ticket-granting ticket) with a different  network  address
based  on this ticket.  This flag is set if requested by the
client on initial authentication.  By  default,  the  client
will  request that it be set when requesting a ticket grant-
ing ticket, and reset when requesting any other ticket.

     This flag allows a client to pass a proxy to  a  server
to perform a remote request on its behalf, e.g. a print ser-
vice client can give the print server a proxy to access  the
client's  files  on  a  particular  file  server in order to
satisfy a print request.

     In order to complicate the use of  stolen  credentials,
Kerberos  tickets  are usually valid from only those network
addresses specifically  included  in  the  ticket[4].   When
granting  a  proxy,  the client must specify the new network
address from which the proxy is to be used, or indicate that
the proxy is to be issued for use from any address.

     The PROXY flag is set in a ticket by the  TGS  when  it
issues  a  proxy ticket.  Application servers may check this
flag and at their option they may require additional authen-
tication  from  the  agent  presenting the proxy in order to
provide an audit trail.

2.6.  Forwardable tickets

     Authentication forwarding is an  instance  of  a  proxy
where  the  service  is granted complete use of the client's
identity.  An example where it might be used is when a  user
logs  in to a remote system and wants authentication to work
from that system as if the login were local.

     The FORWARDABLE flag  in  a  ticket  is  normally  only
__________________________
[4] Though it is permissible to request or issue  tick-
ets with no network addresses specified.


Section 2.6.               - 13 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


interpreted by  the  ticket-granting  service.   It  can  be
ignored by application servers.  The FORWARDABLE flag has an
interpretation similar to that of the PROXIABLE flag, except
ticket-granting  tickets  may  also be issued with different
network addresses.  This flag is reset by default, but users
may request that it be set by setting the FORWARDABLE option
in the AS request when they request  their  initial  ticket-
granting ticket.

     This flag allows for authentication forwarding  without
requiring  the  user to enter a password again.  If the flag
is not set, then authentication forwarding is not permitted,
but  the  same  result  can  still  be  achieved if the user
engages in the AS exchange specifying the requested  network
addresses and supplies a password.

     The FORWARDED flag is set by  the  TGS  when  a  client
presents a ticket with the FORWARDABLE flag set and requests
a forwarded ticket by specifying the  FORWARDED  KDC  option
and  supplying a set of addresses for the new ticket.  It is
also set in all tickets issued based  on  tickets  with  the
FORWARDED  flag set.  Application servers may choose to pro-
cess FORWARDED tickets differently than non-FORWARDED  tick-
ets.

2.7.  Other KDC options

     There are two additional options which may be set in  a
client's  request of the KDC.  The RENEWABLE-OK option indi-
cates that the client will accept a renewable  ticket  if  a
ticket with the requested life cannot otherwise be provided.
If a ticket with the requested life cannot be provided, then
the KDC may issue a renewable ticket with a renew-till equal
to the the requested endtime.  The value of  the  renew-till
field  may  still  be  adjusted by site-determined limits or
limits imposed by the individual principal or server.

     The ENC-TKT-IN-SKEY  option  is  honored  only  by  the
ticket-granting service.  It indicates that the ticket to be
issued for the end server is to be encrypted in the  session
key from the a additional second ticket-granting ticket pro-
vided with the request.   See  section  3.3.3  for  specific
details.

__________________________
[5] The password-changing request must not  be  honored
unless  the requester can provide the old password (the
user's current secret key).   Otherwise,  it  would  be
possible  for  someone to walk up to an unattended ses-
sion and change another user's password.
[6] To authenticate a user logging on to a  local  sys-
tem,  the  credentials  obtained in the AS exchange may
first be used in a TGS exchange to  obtain  credentials


Section 3.1.               - 14 -    Expires 11 January 1998
\f





            Version 5 - Specification Revision 6



3.  Message Exchanges

The following sections  describe  the  interactions  between
network  clients  and  servers  and the messages involved in
those exchanges.

3.1.  The Authentication Service Exchange

                          Summary
      Message direction       Message type    Section
      1. Client to Kerberos   KRB_AS_REQ      5.4.1
      2. Kerberos to client   KRB_AS_REP or   5.4.2
                              KRB_ERROR       5.9.1


     The Authentication Service (AS)  Exchange  between  the
client  and  the Kerberos Authentication Server is initiated
by a client when it wishes to obtain authentication  creden-
tials for a given server but currently holds no credentials.
In its basic form, the client's secret key is used  for  en-
cryption and decryption.  This exchange is typically used at
the initiation of a login session to obtain credentials  for
a  Ticket-Granting Server which will subsequently be used to
obtain credentials  for  other  servers  (see  section  3.3)
without  requiring  further  use of the client's secret key.
This exchange is also used to request credentials  for  ser-
vices which must not be mediated through the Ticket-Granting
Service, but rather require a principal's secret  key,  such
as the password-changing service[5].  This exchange does not
by  itself  provide any assurance of the the identity of the
user[6].

     The exchange consists of two messages: KRB_AS_REQ  from
the  client  to  Kerberos,  and  KRB_AS_REP  or KRB_ERROR in
reply.  The formats for these messages are described in sec-
tions 5.4.1, 5.4.2, and 5.9.1.

     In the request, the client sends (in cleartext) its own
identity  and  the  identity  of  the server for which it is
requesting credentials.  The response, KRB_AS_REP,  contains
a ticket for the client to present to the server, and a ses-
sion key that will be shared by the client and  the  server.
The  session key and additional information are encrypted in
the client's secret key.  The  KRB_AS_REP  message  contains
information  which  can  be  used  to detect replays, and to
associate it with the message to which it replies.   Various
errors  can  occur; these are indicated by an error response
(KRB_ERROR) instead of the KRB_AS_REP response.   The  error
__________________________
for  a  local  server.   Those credentials must then be
verified by a local server through  successful  comple-
tion of the Client/Server exchange.



Section 3.1.               - 15 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


message is not encrypted.  The  KRB_ERROR  message  contains
information  which can be used to associate it with the mes-
sage to which it replies.  The lack  of  encryption  in  the
KRB_ERROR  message  precludes the ability to detect replays,
fabrications, or modifications of such messages.

     Without  preautentication,  the  authentication  server
does  not  know whether the client is actually the principal
named in the request.  It simply sends a reply without know-
ing or caring whether they are the same.  This is acceptable
because nobody but the principal whose identity was given in
the  request  will  be  able  to use the reply. Its critical
information is encrypted in that principal's key.  The  ini-
tial  request supports an optional field that can be used to
pass additional information that might  be  needed  for  the
initial   exchange.    This  field  may  be  used  for  pre-
authentication as described in section <<sec preauth>>.

3.1.1.  Generation of KRB_AS_REQ message

     The client may specify a number of options in the  ini-
tial   request.    Among  these  options  are  whether  pre-
authentication is to be  performed;  whether  the  requested
ticket  is  to  be  renewable,  proxiable,  or  forwardable;
whether it  should  be  postdated  or  allow  postdating  of
derivative  tickets;  and whether a renewable ticket will be
accepted in lieu of a non-renewable ticket if the  requested
ticket  expiration  date  cannot  be  satisfied  by  a  non-
renewable ticket (due to configuration constraints; see sec-
tion 4).  See section A.1 for pseudocode.

     The client prepares the KRB_AS_REQ message and sends it
to the KDC.

3.1.2.  Receipt of KRB_AS_REQ message

     If all goes well,  processing  the  KRB_AS_REQ  message
will  result  in  the creation of a ticket for the client to
present to  the  server.   The  format  for  the  ticket  is
described  in section 5.3.1.  The contents of the ticket are
determined as follows.

3.1.3.  Generation of KRB_AS_REP message

     The authentication  server  looks  up  the  client  and
server  principals  named in the KRB_AS_REQ in its database,
extracting their respective keys.  If required,  the  server
pre-authenticates the request, and if the pre-authentication
check   fails,   an   error   message    with    the    code
KDC_ERR_PREAUTH_FAILED  is  returned.   If the server cannot
accommodate the requested encryption type, an error  message
with  code  KDC_ERR_ETYPE_NOSUPP  is returned.  Otherwise it
generates a "random" session key[7].
__________________________


Section 3.1.3.             - 16 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


     If there are multiple encryption keys registered for  a
client  in  the  Kerberos database (or if the key registered
supports multiple encryption  types;  e.g.  DES-CBC-CRC  and
DES-CBC-MD5),  then  the  etype field from the AS request is
used by the KDC to select the encryption method to  be  used
for encrypting the response to the client.  If there is more
than one supported, strong  encryption  type  in  the  etype
list,  the  first valid etype for which an encryption key is
available is used.  The encryption method used to respond to
a  TGS  request is taken from the keytype of the session key
found in the ticket granting ticket.

     When the etype field  is  present  in  a  KDC  request,
whether an AS or TGS request, the KDC will attempt to assign
the type of the random session key from the list of  methods
in  the  etype  field.   The KDC will select the appropriate
type using the list of methods provided together with infor-
mation  from  the  Kerberos  database  indicating acceptable
encryption methods for the application server.  The KDC will
not issue tickets with a weak session key encryption type.

     If the requested start time is absent, indicates a time
in  the  past,  or  is within the window of acceptable clock
skew for the KDC and the POSTDATE option has not been speci-
fied,  then  the  start  time  of  the  ticket is set to the
authentication server's current time.   If  it  indicates  a
time in the future beyond the acceptable clock skew, but the
POSTDATED option has  not  been  specified  then  the  error
KDC_ERR_CANNOT_POSTDATE    is   returned.    Otherwise   the
requested start time is checked against the  policy  of  the
local realm (the administrator might decide to prohibit cer-
tain types or ranges of postdated tickets), and  if  accept-
able,  the  ticket's  start time is set as requested and the
INVALID flag is set in the new ticket. The postdated  ticket
must  be  validated  before  use by presenting it to the KDC
after the start time has been reached.









__________________________
[7] "Random" means that, among other things, it  should
be  impossible  to  guess the next session key based on
knowledge of past  session  keys.   This  can  only  be
achieved  in  a pseudo-random number generator if it is
based on cryptographic principles.  It is  more  desir-
able  to  use  a truly random number generator, such as
one based on measurements of random physical phenomena.



Section 3.1.3.             - 17 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


The expiration time of the ticket will be set to the minimum
of the following:

+The expiration time (endtime) requested in  the  KRB_AS_REQ
 message.

+The ticket's start time plus the maximum allowable lifetime
 associated  with  the  client principal (the authentication
 server's database includes a maximum ticket lifetime  field
 in each principal's record; see section 4).

+The ticket's start time plus the maximum allowable lifetime
 associated with the server principal.

+The ticket's start time plus the maximum  lifetime  set  by
 the policy of the local realm.

     If the requested expiration time minus the  start  time
(as determined above) is less than a site-determined minimum
lifetime, an error message with code KDC_ERR_NEVER_VALID  is
returned.   If  the requested expiration time for the ticket
exceeds  what  was  determined  as   above,   and   if   the
"RENEWABLE-OK"  option  was  requested, then the "RENEWABLE"
flag is set in the new ticket, and the renew-till  value  is
set  as  if the "RENEWABLE" option were requested (the field
and option names are described fully in section 5.4.1).

If the  RENEWABLE  option  has  been  requested  or  if  the
RENEWABLE-OK  option  has been set and a renewable ticket is
to be issued, then  the  renew-till  field  is  set  to  the
minimum of:

+Its requested value.

+The start time of the ticket plus the minimum  of  the  two
 maximum renewable lifetimes associated with the principals'
 database entries.

+The start time of the ticket  plus  the  maximum  renewable
 lifetime set by the policy of the local realm.

     The flags field of the new ticket will have the follow-
ing  options set if they have been requested and if the pol-
icy of the local realm  allows:  FORWARDABLE,  MAY-POSTDATE,
POSTDATED,  PROXIABLE, RENEWABLE. If the new ticket is post-
dated (the start time is in the future),  its  INVALID  flag
will also be set.

     If all of the  above  succeed,  the  server  formats  a
KRB_AS_REP   message   (see   section  5.4.2),  copying  the
addresses in the request into the  caddr  of  the  response,
placing any required pre-authentication data into the padata
of the response, and encrypts the  ciphertext  part  in  the
client's  key  using  the  requested  encryption method, and


Section 3.1.3.             - 18 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


sends it to the client.  See section A.2 for pseudocode.

3.1.4.  Generation of KRB_ERROR message

     Several errors can occur, and the Authentication Server
responds  by  returning  an error message, KRB_ERROR, to the
client,  with  the  error-code  and  e-text  fields  set  to
appropriate  values.  The error message contents and details
are described in Section 5.9.1.

3.1.5.  Receipt of KRB_AS_REP message

     If the reply  message  type  is  KRB_AS_REP,  then  the
client  verifies  that  the  cname  and crealm fields in the
cleartext portion of the reply match what it requested.   If
any  padata  fields  are present, they may be used to derive
the proper secret key to decrypt the  message.   The  client
decrypts the encrypted part of the response using its secret
key, verifies that the nonce in the encrypted  part  matches
the  nonce  it  supplied in its request (to detect replays).
It also verifies that the sname and srealm in  the  response
match  those  in  the  request  (or  are  otherwise expected
values), and that the host address field  is  also  correct.
It then stores the ticket, session key, start and expiration
times, and  other  information  for  later  use.   The  key-
expiration field from the encrypted part of the response may
be checked to notify the user of  impending  key  expiration
(the client program could then suggest remedial action, such
as a password change).  See section A.3 for pseudocode.

     Proper decryption of the KRB_AS_REP message is not suf-
ficient  to verify the identity of the user; the user and an
attacker could cooperate to  generate  a  KRB_AS_REP  format
message  which  decrypts properly but is not from the proper
KDC.  If the host wishes to verify the identity of the user,
it  must require the user to present application credentials
which can be verified using a securely-stored secret key for
the  host.   If  those credentials can be verified, then the
identity of the user can be assured.

3.1.6.  Receipt of KRB_ERROR message

     If the reply message type is KRB_ERROR, then the client
interprets   it   as   an   error   and   performs  whatever
application-specific tasks are necessary to recover.

3.2.  The Client/Server Authentication Exchange

                             Summary
Message direction                         Message type    Section
Client to Application server              KRB_AP_REQ      5.5.1
[optional] Application server to client   KRB_AP_REP or   5.5.2
                                          KRB_ERROR       5.9.1



Section 3.2.               - 19 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


     The client/server authentication (CS) exchange is  used
by  network  applications  to authenticate the client to the
server  and  vice  versa.   The  client  must  have  already
acquired  credentials  for  the  server  using the AS or TGS
exchange.

3.2.1.  The KRB_AP_REQ message

     The  KRB_AP_REQ  contains  authentication   information
which  should  be  part of the first message in an authenti-
cated transaction.  It contains a ticket, an  authenticator,
and  some  additional  bookkeeping  information (see section
5.5.1 for the exact format).  The ticket by itself is insuf-
ficient  to  authenticate a client, since tickets are passed
across the network in cleartext[8], so the authenticator  is
used  to prevent invalid replay of tickets by proving to the
server that the client knows the session key of  the  ticket
and thus is entitled to use the ticket.  The KRB_AP_REQ mes-
sage  is  referred  to  elsewhere  as  the   "authentication
header."

3.2.2.  Generation of a KRB_AP_REQ message

     When a client wishes to initiate  authentication  to  a
server,  it obtains (either through a credentials cache, the
AS exchange, or the TGS exchange) a ticket and  session  key
for  the desired service.  The client may re-use any tickets
it holds until they expire.  To use a ticket the client con-
structs  a  new  Authenticator from the the system time, its
name, and optionally an application  specific  checksum,  an
initial  sequence  number to be used in KRB_SAFE or KRB_PRIV
messages, and/or a session subkey to be used in negotiations
for  a  session  key  unique  to  this  particular  session.
Authenticators may not be re-used and will  be  rejected  if
replayed to a server[9].  If a  sequence  number  is  to  be
included,  it  should  be randomly chosen so that even after
many messages have been exchanged it is not likely  to  col-
lide with other sequence numbers in use.

     The  client  may  indicate  a  requirement  of   mutual
__________________________
[8] Tickets contain both an encrypted  and  unencrypted
portion,  so  cleartext here refers to the entire unit,
which can be copied from one message  and  replayed  in
another without any cryptographic skill.
[9] Note  that  this can make applications based on un-
reliable transports difficult to code correctly. If the
transport  might  deliver duplicated messages, either a
new authenticator must be generated for each retry,  or
the  application server must match requests and replies
and replay the first reply in response  to  a  detected
duplicate.



Section 3.2.2.             - 20 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


authentication or the use of a session-key based  ticket  by
setting  the  appropriate flag(s) in the ap-options field of
the message.

     The Authenticator is encrypted in the session  key  and
combined  with  the  ticket  to  form the KRB_AP_REQ message
which is then sent to the end server along  with  any  addi-
tional  application-specific  information.   See section A.9
for pseudocode.

3.2.3.  Receipt of KRB_AP_REQ message

     Authentication is based on the server's current time of
day  (clocks  must be loosely synchronized), the authentica-
tor, and the ticket.  Several errors are  possible.   If  an
error  occurs, the server is expected to reply to the client
with a KRB_ERROR message.  This message may be  encapsulated
in the application protocol if its "raw" form is not accept-
able to the protocol.   The  format  of  error  messages  is
described in section 5.9.1.

     The algorithm for verifying authentication  information
is  as  follows.  If the message type is not KRB_AP_REQ, the
server returns the KRB_AP_ERR_MSG_TYPE error.   If  the  key
version indicated by the Ticket in the KRB_AP_REQ is not one
the server can use (e.g., it indicates an old key,  and  the
server  no  longer  possesses  a  copy  of the old key), the
KRB_AP_ERR_BADKEYVER  error  is  returned.   If   the   USE-
SESSION-KEY  flag  is  set in the ap-options field, it indi-
cates to the server that the ticket is encrypted in the ses-
sion  key  from  the  server's ticket-granting ticket rather
than its secret key[10].   Since  it  is  possible  for  the
server  to  be registered in multiple realms, with different
keys in each, the srealm field in the unencrypted portion of
the ticket in the KRB_AP_REQ is used to specify which secret
key the server should  use  to  decrypt  that  ticket.   The
KRB_AP_ERR_NOKEY  error  code  is  returned  if  the  server
doesn't have the proper key to decipher the ticket.

     The ticket  is  decrypted  using  the  version  of  the
server's  key  specified  by  the ticket.  If the decryption
routines detect a modification of the ticket  (each  encryp-
tion  system  must  provide  safeguards  to  detect modified
ciphertext; see  section  6),  the  KRB_AP_ERR_BAD_INTEGRITY
error is returned (chances are good that different keys were
used to encrypt and decrypt).

     The authenticator is decrypted using  the  session  key
extracted from the decrypted ticket.  If decryption shows it
to have been modified, the KRB_AP_ERR_BAD_INTEGRITY error is
__________________________
[10] This is used for  user-to-user  authentication  as
described in  [8].


Section 3.2.3.             - 21 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


returned.  The name and realm of the client from the  ticket
are  compared  against the same fields in the authenticator.
If  they  don't  match,  the  KRB_AP_ERR_BADMATCH  error  is
returned  (they  might  not match, for example, if the wrong
session key was used to  encrypt  the  authenticator).   The
addresses  in  the  ticket (if any) are then searched for an
address matching the operating-system  reported  address  of
the  client.   If no match is found or the server insists on
ticket addresses but none are present  in  the  ticket,  the
KRB_AP_ERR_BADADDR error is returned.

     If the local (server) time and the client time  in  the
authenticator  differ  by more than the allowable clock skew
(e.g., 5 minutes), the KRB_AP_ERR_SKEW  error  is  returned.
If  the  server  name,  along with the client name, time and
microsecond  fields  from  the   Authenticator   match   any
recently-seen  such  tuples,  the KRB_AP_ERR_REPEAT error is
returned[11].  The server must  remember  any  authenticator
presented  within the allowable clock skew, so that a replay
attempt is guaranteed to fail.  If a server loses  track  of
any authenticator presented within the allowable clock skew,
it must reject all requests until the  clock  skew  interval
has passed.  This assures that any lost or re-played authen-
ticators will fall outside the allowable clock skew and  can
no  longer be successfully replayed (If this is not done, an
attacker could conceivably record the ticket and authentica-
tor  sent  over  the  network  to a server, then disable the
client's host, pose as the disabled  host,  and  replay  the
ticket  and  authenticator  to subvert the authentication.).
If a sequence number is provided in the  authenticator,  the
server  saves it for later use in processing KRB_SAFE and/or
KRB_PRIV messages.  If  a  subkey  is  present,  the  server
either  saves  it  for later use or uses it to help generate
its own choice for a subkey to be returned in  a  KRB_AP_REP
message.

     The server  computes  the  age  of  the  ticket:  local
(server)  time  minus  the start time inside the Ticket.  If
the start time is later than the current time by  more  than
the  allowable  clock  skew or if the INVALID flag is set in
the ticket, the KRB_AP_ERR_TKT_NYV error is returned.   Oth-
erwise,  if  the current time is later than end time by more
than the allowable clock  skew,  the  KRB_AP_ERR_TKT_EXPIRED
error is returned.

     If all these  checks  succeed  without  an  error,  the
__________________________
[11] Note that the rejection here is restricted to  au-
thenticators  from  the  same  principal  to  the  same
server.  Other client principals communicating with the
same  server principal should not be have their authen-
ticators rejected if the time  and  microsecond  fields
happen to match some other client's authenticator.


Section 3.2.3.             - 22 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


server is assured that the client possesses the  credentials
of  the  principal  named in the ticket and thus, the client
has been authenticated to the server.  See section A.10  for
pseudocode.

     Passing these checks provides  only  authentication  of
the  named principal; it does not imply authorization to use
the  named  service.   Applications  must  make  a  separate
authorization decisions based upon the authenticated name of
the user,  the  requested  operation,  local  acces  control
information such as that contained in a .k5login or .k5users
file, and possibly a separate distributed authorization ser-
vice.

3.2.4.  Generation of a KRB_AP_REP message

     Typically, a client's request  will  include  both  the
authentication  information  and  its initial request in the
same message, and the server need not  explicitly  reply  to
the KRB_AP_REQ.  However, if mutual authentication (not only
authenticating the client to the server, but also the server
to  the  client)  is being performed, the KRB_AP_REQ message
will have MUTUAL-REQUIRED set in its ap-options field, and a
KRB_AP_REP  message  is  required  in response.  As with the
error message, this  message  may  be  encapsulated  in  the
application  protocol if its "raw" form is not acceptable to
the application's protocol.  The timestamp  and  microsecond
field  used  in the reply must be the client's timestamp and
microsecond field (as provided  in  the  authenticator)[12].
If  a  sequence  number is to be included, it should be ran-
domly chosen as described above for  the  authenticator.   A
subkey  may be included if the server desires to negotiate a
different subkey.  The KRB_AP_REP message  is  encrypted  in
the session key extracted from the ticket.  See section A.11
for pseudocode.

3.2.5.  Receipt of KRB_AP_REP message


     If a KRB_AP_REP message is returned,  the  client  uses
the  session  key  from  the  credentials  obtained  for the
server[13] to decrypt the message,  and  verifies  that  the
__________________________
[12] In the Kerberos version 4 protocol, the  timestamp
in the reply was the client's timestamp plus one.  This
is not necessary in version 5 because  version  5  mes-
sages are formatted in such a way that it is not possi-
ble to create the reply by  judicious  message  surgery
(even  in  encrypted form) without knowledge of the ap-
propriate encryption keys.
[13] Note that for encrypting the  KRB_AP_REP  message,
the sub-session key is not used, even if present in the
Authenticator.


Section 3.2.5.             - 23 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


timestamp and microsecond fields match those in the  Authen-
ticator  it  sent  to  the  server.  If they match, then the
client is assured that the server is genuine.  The  sequence
number  and  subkey (if present) are retained for later use.
See section A.12 for pseudocode.


3.2.6.  Using the encryption key

     After the KRB_AP_REQ/KRB_AP_REP exchange has  occurred,
the  client  and server share an encryption key which can be
used by the application.  The "true session key" to be  used
for  KRB_PRIV,  KRB_SAFE, or other application-specific uses
may be chosen by the application based on the subkeys in the
KRB_AP_REP  message  and  the  authenticator[14].   In  some
cases,  the  use of this session key will be implicit in the
protocol; in others the method of use must  be  chosen  from
several alternatives.  We leave the protocol negotiations of
how to use the key (e.g.  selecting an encryption or  check-
sum type) to the application programmer; the Kerberos proto-
col does not constrain the implementation  options,  but  an
example of how this might be done follows.

     One way that an application may choose to  negotiate  a
key  to  be used for subequent integrity and privacy protec-
tion is for the client to propose a key in the subkey  field
of  the  authenticator.   The  server  can then choose a key
using the proposed key from the client as  input,  returning
the new subkey in the subkey field of the application reply.
This key could then be used  for  subsequent  communication.
To make this example more concrete, if the encryption method
in use required a 56 bit key, and for whatever  reason,  one
of the parties was prevented from using a key with more than
40 unknown bits, this method would allow the the party which
is  prevented from using more than 40 bits to either propose
(if the client) an initial key with a known quantity for  16
of  those  bits,  or  to mask 16 of the bits (if the server)
with the known quantity.   The  application  implementor  is
warned,  however,  that this is only an example, and that an
analysis of the particular crytosystem to be used,  and  the
reasons  for  limiting  the  key length, must be made before
deciding whether it is acceptable to mask bits of the key.

     With  both  the  one-way  and   mutual   authentication
exchanges,  the peers should take care not to send sensitive
information to each other  without  proper  assurances.   In
particular,  applications  that require privacy or integrity
should use the KRB_AP_REP response from the server to client
__________________________
[14] Implementations of the protocol may wish  to  pro-
vide  routines  to choose subkeys based on session keys
and random numbers and to generate a negotiated key  to
be returned in the KRB_AP_REP message.


Section 3.2.6.             - 24 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


to assure both client and server of their  peer's  identity.
If an application protocol requires privacy of its messages,
it can use the KRB_PRIV message (section 3.5).  The KRB_SAFE
message (section 3.4) can be used to assure integrity.


3.3.  The Ticket-Granting Service (TGS) Exchange

                          Summary
      Message direction       Message type     Section
      1. Client to Kerberos   KRB_TGS_REQ      5.4.1
      2. Kerberos to client   KRB_TGS_REP or   5.4.2
                              KRB_ERROR        5.9.1


     The TGS exchange between  a  client  and  the  Kerberos
Ticket-Granting  Server  is  initiated  by  a client when it
wishes to obtain  authentication  credentials  for  a  given
server  (which  might be registered in a remote realm), when
it wishes to renew or validate an existing ticket,  or  when
it  wishes to obtain a proxy ticket.  In the first case, the
client must already have acquired a ticket for  the  Ticket-
Granting  Service using the AS exchange (the ticket-granting
ticket is usually obtained when a client initially authenti-
cates to the system, such as when a user logs in).  The mes-
sage format for the TGS exchange is almost identical to that
for the AS exchange.  The primary difference is that encryp-
tion and decryption in the TGS exchange does not take  place
under  the  client's key.  Instead, the session key from the
ticket-granting ticket or renewable ticket,  or  sub-session
key  from  an Authenticator is used.  As is the case for all
application servers, expired tickets are not accepted by the
TGS,  so once a renewable or ticket-granting ticket expires,
the client must use a  separate  exchange  to  obtain  valid
tickets.

     The TGS exchange consists of two  messages:  A  request
(KRB_TGS_REQ)  from  the  client  to  the  Kerberos  Ticket-
Granting Server, and a  reply  (KRB_TGS_REP  or  KRB_ERROR).
The  KRB_TGS_REQ message includes information authenticating
the client plus a request for credentials.  The  authentica-
tion  information  consists  of  the  authentication  header
(KRB_AP_REQ) which includes the client's previously obtained
ticket-granting,  renewable,  or  invalid  ticket.   In  the
ticket-granting ticket and  proxy  cases,  the  request  may
include  one or more of: a list of network addresses, a col-
lection of typed authorization data  to  be  sealed  in  the
ticket  for  authorization use by the application server, or
additional tickets (the use of which are  described  later).
The  TGS  reply (KRB_TGS_REP) contains the requested creden-
tials, encrypted in the session key from the ticket-granting
ticket  or  renewable  ticket,  or  if  present, in the sub-
session key from the Authenticator (part of the  authentica-
tion  header).  The KRB_ERROR message contains an error code


Section 3.3.               - 25 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


and text explaining what went wrong.  The KRB_ERROR  message
is not encrypted.  The KRB_TGS_REP message contains informa-
tion which can be used to detect replays, and  to  associate
it with the message to which it replies.  The KRB_ERROR mes-
sage also contains information which can be used to  associ-
ate it with the message to which it replies, but the lack of
encryption in the KRB_ERROR message precludes the ability to
detect replays or fabrications of such messages.

3.3.1.  Generation of KRB_TGS_REQ message

     Before sending a request to  the  ticket-granting  ser-
vice,  the client must determine in which realm the applica-
tion server is  registered[15].   If  the  client  does  not
already possess a ticket-granting ticket for the appropriate
realm, then one must be obtained.  This is  first  attempted
by  requesting  a ticket-granting ticket for the destination
realm from a Kerberos  server  for  which  the  client  does
posess  a ticket-granting ticket (using the KRB_TGS_REQ mes-
sage recursively).  The Kerberos server may return a TGT for
the  desired  realm in which case one can proceed.  Alterna-
tively, the Kerberos server may return a  TGT  for  a  realm
which  is  "closer"  to the desired realm (further along the
standard hierarchical path), in which case this step must be
repeated  with  a  Kerberos server in the realm specified in
the returned TGT.  If neither are returned, then the request
must be retried with a Kerberos server for a realm higher in
the hierarchy.  This request will itself require  a  ticket-
granting  ticket for the higher realm which must be obtained
by recursively applying these directions.


     Once the client obtains a  ticket-granting  ticket  for
the  appropriate realm, it determines which Kerberos servers
serve that realm, and  contacts  one.   The  list  might  be
obtained  through a configuration file or network service or
it may be generated from the name of the realm; as  long  as
the  secret  keys  exchanged by realms are kept secret, only
denial of  service  results  from  using  a  false  Kerberos
server.
__________________________
[15] This can be  accomplished  in  several  ways.   It
might  be  known beforehand (since the realm is part of
the principal identifier), it  might  be  stored  in  a
nameserver,  or  it might be obtained from a configura-
tion file.  If the realm to be used is obtained from  a
nameserver,  there  is a danger of being spoofed if the
nameservice providing the realm name is  not  authenti-
cated.   This  might result in the use of a realm which
has been compromised, and would result in an attacker's
ability  to compromise the authentication of the appli-
cation server to the client.



Section 3.3.1.             - 26 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


     As in the AS exchange, the client may specify a  number
of  options in the KRB_TGS_REQ message.  The client prepares
the KRB_TGS_REQ message, providing an authentication  header
as  an  element  of the padata field, and including the same
fields as used in the KRB_AS_REQ message along with  several
optional fields: the enc-authorization-data field for appli-
cation server use and additional tickets  required  by  some
options.

     In preparing the authentication header, the client  can
select  a  sub-session key under which the response from the
Kerberos server will be encrypted[16].  If  the  sub-session
key  is  not  specified,  the  session  key from the ticket-
granting ticket will be used.  If the enc-authorization-data
is  present, it must be encrypted in the sub-session key, if
present, from the authenticator portion of  the  authentica-
tion  header,  or if not present, using the session key from
the ticket-granting ticket.

     Once prepared, the message is sent to a Kerberos server
for the destination realm.  See section A.5 for pseudocode.

3.3.2.  Receipt of KRB_TGS_REQ message

     The KRB_TGS_REQ message is processed in a manner  simi-
lar to the KRB_AS_REQ message, but there are many additional
checks to be performed.  First,  the  Kerberos  server  must
determine which server the accompanying ticket is for and it
must select the appropriate key to decrypt it.  For a normal
KRB_TGS_REQ message, it will be for the ticket granting ser-
vice, and the TGS's key will be used.  If the TGT was issued
by  another realm, then the appropriate inter-realm key must
be used.  If the accompanying ticket is not a ticket  grant-
ing  ticket for the current realm, but is for an application
server in the current realm, the RENEW, VALIDATE,  or  PROXY
options  are  specified  in  the request, and the server for
which a ticket is requested  is  the  server  named  in  the
accompanying ticket, then the KDC will decrypt the ticket in
the authentication header using the key of  the  server  for
which  it  was  issued.   If  no  ticket can be found in the
padata  field,  the  KDC_ERR_PADATA_TYPE_NOSUPP   error   is
returned.

     Once the accompanying ticket has  been  decrypted,  the
user-supplied checksum in the Authenticator must be verified
against  the  contents  of  the  request,  and  the  message
rejected  if  the checksums do not match (with an error code
__________________________
[16] If the client selects a sub-session key, care must
be  taken to ensure the randomness of the selected sub-
session key.  One approach would be to generate a  ran-
dom  number  and  XOR  it with the session key from the
ticket-granting ticket.


Section 3.3.2.             - 27 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


of KRB_AP_ERR_MODIFIED) or if the checksum is not  keyed  or
not    collision-proof    (with    an    error    code    of
KRB_AP_ERR_INAPP_CKSUM).  If the checksum type is  not  sup-
ported,  the  KDC_ERR_SUMTYPE_NOSUPP  error is returned.  If
the authorization-data are present, they are decrypted using
the sub-session key from the Authenticator.

     If any of the  decryptions  indicate  failed  integrity
checks, the KRB_AP_ERR_BAD_INTEGRITY error is returned.

3.3.3.  Generation of KRB_TGS_REP message

     The KRB_TGS_REP message  shares  its  format  with  the
KRB_AS_REP  (KRB_KDC_REP),  but  with  its type field set to
KRB_TGS_REP.   The  detailed  specification  is  in  section
5.4.2.

     The response will include a ticket  for  the  requested
server.   The  Kerberos  database is queried to retrieve the
record for the requested  server  (including  the  key  with
which  the ticket will be encrypted).  If the request is for
a ticket granting ticket for a remote realm, and if  no  key
is shared with the requested realm, then the Kerberos server
will select the realm "closest" to the requested realm  with
which it does share a key, and use that realm instead.  This
is the only case where the response from the KDC will be for
a different server than that requested by the client.

     By default, the address field, the  client's  name  and
realm,  the  list  of  transited realms, the time of initial
authentication, the expiration time, and  the  authorization
data  of  the  newly-issued  ticket  will be copied from the
ticket-granting ticket (TGT) or renewable  ticket.   If  the
transited  field needs to be updated, but the transited type
is  not  supported,  the  KDC_ERR_TRTYPE_NOSUPP   error   is
returned.

     If the request specifies an endtime, then  the  endtime
of the new ticket is set to the minimum of (a) that request,
(b) the endtime from the TGT, and (c) the starttime  of  the
TGT plus the minimum of the maximum life for the application
server and the maximum life for the local realm (the maximum
life  for  the requesting principal was already applied when
the TGT was issued).  If the new ticket is to be a  renewal,
then the endtime above is replaced by the minimum of (a) the
value of the renew_till field of  the  ticket  and  (b)  the
starttime  for  the  new  ticket  plus  the  life  (endtime-
starttime) of the old ticket.

     If the FORWARDED option has been  requested,  then  the
resulting ticket will contain the addresses specified by the
client.  This option will only be honored if the FORWARDABLE
flag  is  set in the TGT.  The PROXY option is similar;  the
resulting ticket will contain the addresses specified by the


Section 3.3.3.             - 28 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


client.   It  will  be honored only if the PROXIABLE flag in
the TGT is set.  The PROXY option will  not  be  honored  on
requests for additional ticket-granting tickets.

     If the requested start time is absent, indicates a time
in  the  past,  or  is within the window of acceptable clock
skew for the KDC and the POSTDATE option has not been speci-
fied,  then  the  start  time  of  the  ticket is set to the
authentication server's current time.   If  it  indicates  a
time in the future beyond the acceptable clock skew, but the
POSTDATED option has not been specified or the  MAY-POSTDATE
flag   is   not   set   in   the   TGT,   then   the   error
KDC_ERR_CANNOT_POSTDATE  is  returned.   Otherwise,  if  the
ticket-granting  ticket  has the MAY-POSTDATE flag set, then
the resulting ticket will be  postdated  and  the  requested
starttime  is checked against the policy of the local realm.
If acceptable, the ticket's start time is set as  requested,
and  the  INVALID flag is set.  The postdated ticket must be
validated before use by presenting it to the KDC  after  the
starttime  has  been  reached.   However, in no case may the
starttime, endtime, or renew-till  time  of  a  newly-issued
postdated  ticket  extend  beyond the renew-till time of the
ticket-granting ticket.

     If the ENC-TKT-IN-SKEY option has been specified and an
additional  ticket has been included in the request, the KDC
will decrypt the additional ticket using  the  key  for  the
server  to which the additional ticket was issued and verify
that it is a ticket-granting ticket.  If  the  name  of  the
requested  server  is  missing from the request, the name of
the client in the additional ticket will be used.  Otherwise
the  name  of  the  requested server will be compared to the
name of the client in the  additional  ticket  and  if  dif-
ferent,  the  request  will  be  rejected.   If  the request
succeeds, the session key from the additional ticket will be
used  to  encrypt  the  new ticket that is issued instead of
using the key of the server for which the new ticket will be
used[17].

     If the name  of  the  server  in  the  ticket  that  is
presented to the KDC as part of the authentication header is
not that of the ticket-granting server itself, the server is
registered  in the realm of the KDC, and the RENEW option is
requested, then the KDC will verify that the RENEWABLE  flag
is  set  in  the ticket, that the INVALID flag is not set in
the ticket, and that the renew_till time  is  still  in  the
future.   If  the VALIDATE option is rqeuested, the KDC will
__________________________
[17] This allows easy  implementation  of  user-to-user
authentication  [8],  which uses ticket-granting ticket
session keys in lieu of secret server  keys  in  situa-
tions  where  such secret keys could be easily comprom-
ised.


Section 3.3.3.             - 29 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


check that the starttime has passed and the INVALID flag  is
set.   If  the  PROXY option is requested, then the KDC will
check that the PROXIABLE flag is set in the ticket.  If  the
tests  succeed,  and  the  ticket  passes  the hotlist check
described in the next paragraph,  the  KDC  will  issue  the
appropriate new ticket.


3.3.3.1.  Checking for revoked tickets

     Whenever a  request  is  made  to  the  ticket-granting
server,  the  presented  ticket(s) is(are) checked against a
hot-list of tickets which have been canceled.  This hot-list
might  be implemented by storing a range of issue timestamps
for "suspect tickets"; if a presented ticket had an authtime
in  that range, it would be rejected.  In this way, a stolen
ticket-granting ticket or renewable ticket cannot be used to
gain  additional  tickets  (renewals  or otherwise) once the
theft has been reported.  Any normal ticket obtained  before
it  was  reported  stolen  will still be valid (because they
require no interaction with the KDC), but only  until  their
normal expiration time.

     The ciphertext part of the response in the  KRB_TGS_REP
message is encrypted in the sub-session key from the Authen-
ticator, if  present,  or  the  session  key  key  from  the
ticket-granting  ticket.   It  is  not  encrypted  using the
client's  secret  key.   Furthermore,  the  client's   key's
expiration  date  and the key version number fields are left
out since these values are stored along  with  the  client's
database  record, and that record is not needed to satisfy a
request based on a ticket-granting ticket.  See section  A.6
for pseudocode.

3.3.3.2.  Encoding the transited field

     If the identity of  the  server  in  the  TGT  that  is
presented to the KDC as part of the authentication header is
that of the ticket-granting service, but the TGT was  issued
from another realm, the KDC will look up the inter-realm key
shared with that realm and  use  that  key  to  decrypt  the
ticket.  If the ticket is valid, then the KDC will honor the
request, subject to the constraints outlined  above  in  the
section  describing  the AS exchange.  The realm part of the
client's identity will be  taken  from  the  ticket-granting
ticket.   The  name  of  the  realm  that issued the ticket-
granting ticket will be added to the transited field of  the
ticket  to  be  issued.  This is accomplished by reading the
transited field from the ticket-granting  ticket  (which  is
treated  as an unordered set of realm names), adding the new
realm to the set, then  constructing  and  writing  out  its
encoded  (shorthand)  form (this may involve a rearrangement
of the existing encoding).



Section 3.3.3.2.           - 30 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


     Note that the ticket-granting service does not add  the
name  of  its  own realm.  Instead, its responsibility is to
add the name of the previous realm.  This prevents  a  mali-
cious Kerberos server from intentionally leaving out its own
name (it could, however, omit other realms' names).

     The  names  of  neither  the  local   realm   nor   the
principal's realm are to be included in the transited field.
They appear elsewhere in the ticket and both  are  known  to
have  taken part in authenticating the principal.  Since the
endpoints  are  not  included,  both  local  and  single-hop
inter-realm  authentication result in a transited field that
is empty.

     Because the name of each realm transited  is  added  to
this  field, it might potentially be very long.  To decrease
the length of this field, its  contents  are  encoded.   The
initially  supported  encoding  is  optimized for the normal
case of inter-realm communication: a  hierarchical  arrange-
ment  of  realms  using  either  domain or X.500 style realm
names.  This encoding (called DOMAIN-X500-COMPRESS)  is  now
described.

     Realm names in the transited field are separated  by  a
",".   The ",", "\", trailing "."s, and leading spaces (" ")
are special characters, and if they  are  part  of  a  realm
name,  they must be quoted in the transited field by preced-
ing them with a "\".

     A realm name ending with a "." is interpreted as  being
prepended to the previous realm.  For example, we can encode
traversal of EDU, MIT.EDU,  ATHENA.MIT.EDU,  WASHINGTON.EDU,
and CS.WASHINGTON.EDU as:

     "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".

Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were  end-
points,  that  they would not be included in this field, and
we would have:

     "EDU,MIT.,WASHINGTON.EDU"

A realm name beginning with a "/" is  interpreted  as  being
appended to the previous realm[18].  If it is  to  stand  by
itself,  then  it  should be preceded by a space (" ").  For
example, we can encode traversal of /COM/HP/APOLLO, /COM/HP,
/COM, and /COM/DEC as:

     "/COM,/HP,/APOLLO, /COM/DEC".
__________________________
[18] For the purpose of appending, the realm  preceding
the  first  listed  realm  is considered to be the null
realm ("").


Section 3.3.3.2.           - 31 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


Like the example above, if /COM/HP/APOLLO and  /COM/DEC  are
endpoints,  they  they  would not be included in this field,
and we would have:

     "/COM,/HP"


     A null subfield preceding or following a ","  indicates
that  all  realms  between  the  previous realm and the next
realm have been traversed[19].  Thus,  ","  means  that  all
realms along the path between the client and the server have
been traversed. ",EDU, /COM," means  that  that  all  realms
from the client's realm up to EDU (in a domain style hierar-
chy) have been traversed, and that everything from /COM down
to  the  server's  realm  in  an  X.500  style has also been
traversed.  This could occur if the EDU realm in one hierar-
chy  shares  an inter-realm key directly with the /COM realm
in another hierarchy.

3.3.4.  Receipt of KRB_TGS_REP message

When the KRB_TGS_REP is received by the client, it  is  pro-
cessed  in  the  same  manner  as  the KRB_AS_REP processing
described above.  The primary difference is that the cipher-
text  part  of the response must be decrypted using the ses-
sion key from the ticket-granting  ticket  rather  than  the
client's secret key.  See section A.7 for pseudocode.


3.4.  The KRB_SAFE Exchange

     The KRB_SAFE message may be used by  clients  requiring
the   ability  to  detect  modifications  of  messages  they
exchange.  It achieves this by including a keyed  collision-
proof  checksum  of  the user data and some control informa-
tion.  The checksum is keyed with an encryption key (usually
the  last  key negotiated via subkeys, or the session key if
no negotiation has occured).

3.4.1.  Generation of a KRB_SAFE message

When an application wishes to send a  KRB_SAFE  message,  it
collects  its  data  and the appropriate control information
and computes a checksum over them.  The  checksum  algorithm
should  be  a  keyed one-way hash function (such as the RSA-
MD5-DES checksum algorithm specified in  section  6.4.5,  or
the  DES  MAC),  generated  using  the  sub-session  key  if
present, or the session key.  Different  algorithms  may  be
__________________________
[19] For the purpose of  interpreting  null  subfields,
the  client's  realm  is considered to precede those in
the transited field, and the  server's  realm  is  con-
sidered to follow them.


Section 3.4.1.             - 32 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


selected by changing  the  checksum  type  in  the  message.
Unkeyed  or  non-collision-proof  checksums are not suitable
for this use.

     The  control  information  for  the  KRB_SAFE   message
includes  both  a  timestamp  and  a  sequence  number.  The
designer of an application using the KRB_SAFE  message  must
choose  at  least  one  of  the two mechanisms.  This choice
should be based on the needs of the application protocol.

     Sequence numbers are useful when all messages sent will
be  received  by  one's peer.  Connection state is presently
required to maintain the session  key,  so  maintaining  the
next  sequence number should not present an additional prob-
lem.

     If the application protocol  is  expected  to  tolerate
lost  messages  without  them  being  resent, the use of the
timestamp is the  appropriate  replay  detection  mechanism.
Using  timestamps  is  also  the  appropriate  mechanism for
multi-cast protocols where all of one's peers share a common
sub-session  key, but some messages will be sent to a subset
of one's peers.

     After computing the checksum, the client then transmits
the information and checksum to the recipient in the message
format specified in section 5.6.1.

3.4.2.  Receipt of KRB_SAFE message

When an application receives a KRB_SAFE message, it verifies
it  as  follows.   If  any  error  occurs,  an error code is
reported for use by the application.

     The message is first checked by verifying that the pro-
tocol  version and type fields match the current version and
KRB_SAFE,   respectively.    A    mismatch    generates    a
KRB_AP_ERR_BADVERSION  or  KRB_AP_ERR_MSG_TYPE  error.   The
application verifies that the checksum used is a  collision-
proof    keyed    checksum,    and   if   it   is   not,   a
KRB_AP_ERR_INAPP_CKSUM error is  generated.   The  recipient
verifies  that the operating system's report of the sender's
address matches the sender's address in the message, and (if
a  recipient  address is specified or the recipient requires
an address) that one of the recipient's addresses appears as
the  recipient's address in the message.  A failed match for
either case generates a KRB_AP_ERR_BADADDR error.  Then  the
timestamp  and  usec  and/or  the sequence number fields are
checked.   If  timestamp  and  usec  are  expected  and  not
present,   or   they   are  present  but  not  current,  the
KRB_AP_ERR_SKEW error is generated.   If  the  server  name,
along with the client name, time and microsecond fields from
the  Authenticator  match   any   recently-seen   (sent   or
received[20] ) such tuples, the KRB_AP_ERR_REPEAT  error  is
__________________________
[20] This means that a client and server running on the
\f





            Version 5 - Specification Revision 6


generated.  If an incorrect sequence number is included,  or
a   sequence   number  is  expected  but  not  present,  the
KRB_AP_ERR_BADORDER error is generated.  If neither a  time-
stamp   and   usec  or  a  sequence  number  is  present,  a
KRB_AP_ERR_MODIFIED error is generated.  Finally, the check-
sum  is  computed over the data and control information, and
if   it   doesn't   match   the   received    checksum,    a
KRB_AP_ERR_MODIFIED error is generated.

     If all the checks succeed, the application  is  assured
that the message was generated by its peer and was not modi-
fied in transit.

3.5.  The KRB_PRIV Exchange

     The KRB_PRIV message may be used by  clients  requiring
confidentiality  and  the ability to detect modifications of
exchanged messages.  It achieves this by encrypting the mes-
sages and adding control information.

3.5.1.  Generation of a KRB_PRIV message

When an application wishes to send a  KRB_PRIV  message,  it
collects  its  data  and the appropriate control information
(specified in section 5.7.1)  and  encrypts  them  under  an
encryption key (usually the last key negotiated via subkeys,
or the session key if no negotiation has occured).  As  part
of  the  control  information, the client must choose to use
either a timestamp or a sequence number (or both);  see  the
discussion  in section 3.4.1 for guidelines on which to use.
After the user data and control information  are  encrypted,
the  client  transmits  the  ciphertext  and some "envelope"
information to the recipient.

3.5.2.  Receipt of KRB_PRIV message

When an application receives a KRB_PRIV message, it verifies
it  as  follows.   If  any  error  occurs,  an error code is
reported for use by the application.

     The message is first checked by verifying that the pro-
tocol  version and type fields match the current version and
KRB_PRIV,   respectively.    A    mismatch    generates    a
KRB_AP_ERR_BADVERSION  or  KRB_AP_ERR_MSG_TYPE  error.   The
application then decrypts the ciphertext and  processes  the
resultant  plaintext.   If decryption shows the data to have
been modified,  a  KRB_AP_ERR_BAD_INTEGRITY  error  is  gen-
erated.   The recipient verifies that the operating system's
report of the sender's address matches the sender's  address
__________________________
same  host and communicating with one another using the
KRB_SAFE messages should  not  share  a  common  replay
cache to detect KRB_SAFE replays.



Section 3.5.2.             - 34 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


in the message, and (if a recipient address is specified  or
the   recipient   requires  an  address)  that  one  of  the
recipient's addresses appears as the recipient's address  in
the  message.   A  failed  match for either case generates a
KRB_AP_ERR_BADADDR  error.   Then  the  timestamp  and  usec
and/or the sequence number fields are checked.  If timestamp
and usec are expected and not present, or they  are  present
but  not current, the KRB_AP_ERR_SKEW error is generated. If
the server name,  along  with  the  client  name,  time  and
microsecond   fields   from   the  Authenticator  match  any
recently-seen such tuples, the  KRB_AP_ERR_REPEAT  error  is
generated.   If an incorrect sequence number is included, or
a  sequence  number  is  expected  but  not   present,   the
KRB_AP_ERR_BADORDER  error is generated.  If neither a time-
stamp  and  usec  or  a  sequence  number  is   present,   a
KRB_AP_ERR_MODIFIED error is generated.

     If all the checks succeed, the application  can  assume
the  message  was  generated  by  its peer, and was securely
transmitted (without intruders able to see  the  unencrypted
contents).

3.6.  The KRB_CRED Exchange

     The KRB_CRED message may be used by  clients  requiring
the  ability  to  send Kerberos credentials from one host to
another.  It achieves this by sending the  tickets  together
with  encrypted  data  containing the session keys and other
information associated with the tickets.

3.6.1.  Generation of a KRB_CRED message

When an application wishes to send  a  KRB_CRED  message  it
first (using the KRB_TGS exchange) obtains credentials to be
sent to the remote host.  It then constructs a KRB_CRED mes-
sage  using  the  ticket or tickets so obtained, placing the
session key needed to use each ticket in the  key  field  of
the corresponding KrbCredInfo sequence of the encrypted part
of the the KRB_CRED message.

     Other  information  associated  with  each  ticket  and
obtained  during  the KRB_TGS exchange is also placed in the
corresponding KrbCredInfo sequence in the encrypted part  of
the KRB_CRED message.  The current time and, if specifically
required by the application the  nonce,  s-address,  and  r-
address  fields,  are  placed  in  the encrypted part of the
KRB_CRED message which is then encrypted under an encryption
key previosuly exchanged in the KRB_AP exchange (usually the
last key negotiated via subkeys, or the session  key  if  no
negotiation has occured).

3.6.2.  Receipt of KRB_CRED message

When an application receives a KRB_CRED message, it verifies


Section 3.6.2.             - 35 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


it.   If any error occurs, an error code is reported for use
by the application.  The message  is  verified  by  checking
that  the protocol version and type fields match the current
version and KRB_CRED, respectively.  A mismatch generates  a
KRB_AP_ERR_BADVERSION  or  KRB_AP_ERR_MSG_TYPE  error.   The
application then decrypts the ciphertext and  processes  the
resultant  plaintext.   If decryption shows the data to have
been modified,  a  KRB_AP_ERR_BAD_INTEGRITY  error  is  gen-
erated.

     If present or required, the recipient verifies that the
operating  system's  report  of the sender's address matches
the sender's address in the message, and  that  one  of  the
recipient's  addresses appears as the recipient's address in
the message.  A failed match for  either  case  generates  a
KRB_AP_ERR_BADADDR  error.   The  timestamp  and usec fields
(and the nonce field if required) are checked next.  If  the
timestamp  and usec are not present, or they are present but
not current, the KRB_AP_ERR_SKEW error is generated.

     If all the checks succeed, the application stores  each
of  the  new  tickets  in its ticket cache together with the
session key  and  other  information  in  the  corresponding
KrbCredInfo sequence from the encrypted part of the KRB_CRED
message.

4.  The Kerberos Database

The Kerberos server must have access to a database  contain-
ing  the principal identifiers and secret keys of principals
to be authenticated[21].

4.1.  Database contents

A database entry  should  contain  at  least  the  following
fields:

Field                Value

name                 Principal's                    identif-
ier
key                  Principal's secret key
p_kvno               Principal's key version
max_life             Maximum lifetime for Tickets
__________________________
[21] The implementation of the Kerberos server need not
combine  the  database  and  the  server  on  the  same
machine; it is feasible to store the principal database
in, say, a network name service, as long as the entries
stored therein are protected  from  disclosure  to  and
modification  by  unauthorized  parties.   However,  we
recommend against such strategies,  as  they  can  make
system management and threat analysis quite complex.


Section 4.1.               - 36 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


max_renewable_life   Maximum total lifetime for renewable Tickets

The name field is an encoding of the principal's identifier.
The  key  field contains an encryption key.  This key is the
principal's secret key.  (The key can  be  encrypted  before
storage  under a Kerberos "master key" to protect it in case
the database is compromised but the master key is  not.   In
that case, an extra field must be added to indicate the mas-
ter key version used, see below.) The p_kvno  field  is  the
key  version  number  of  the  principal's  secret key.  The
max_life field contains the maximum allowable lifetime (end-
time  - starttime) for any Ticket issued for this principal.
The max_renewable_life field contains the maximum  allowable
total  lifetime  for  any  renewable  Ticket issued for this
principal.  (See section 3.1 for a description of how  these
lifetimes  are  used  in determining the lifetime of a given
Ticket.)

     A server may provide KDC service to several realms,  as
long  as the database representation provides a mechanism to
distinguish between principal records with identifiers which
differ only in the realm name.

     When an application server's key changes, if the change
is  routine  (i.e.  not  the result of disclosure of the old
key), the old key should be retained by the server until all
tickets  that  had  been issued using that key have expired.
Because of this, it is  possible  for  several  keys  to  be
active  for  a  single principal.  Ciphertext encrypted in a
principal's key is always tagged with the version of the key
that was used for encryption, to help the recipient find the
proper key for decryption.

     When more than one key is active for a particular prin-
cipal,  the  principal will have more than one record in the
Kerberos database.  The keys and key  version  numbers  will
differ  between  the  records (the rest of the fields may or
may not be the same). Whenever Kerberos issues a ticket,  or
responds  to  a request for initial authentication, the most
recent key (known by the Kerberos server) will be  used  for
encryption.   This  is  the key with the highest key version
number.

4.2.  Additional fields

Project Athena's KDC implementation uses  additional  fields
in its database:

Field        Value

K_kvno       Kerberos' key version
expiration   Expiration date for entry
attributes   Bit field of attributes
mod_date     Timestamp of last modification


Section 4.2.               - 37 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


mod_name     Modifying principal's identifier


The K_kvno field indicates the key version of  the  Kerberos
master  key  under  which  the  principal's  secret  key  is
encrypted.

     After an entry's expiration date has  passed,  the  KDC
will  return an error to any client attempting to gain tick-
ets as or for the principal.  (A database may want to  main-
tain  two  expiration  dates: one for the principal, and one
for the principal's current key.  This allows password aging
to  work  independently  of the principal's expiration date.
However, due to the limited space in the responses, the  KDC
must  combine  the  key  expiration and principal expiration
date into a single value called "key_exp", which is used  as
a hint to the user to take administrative action.)

     The attributes field is a bitfield used to  govern  the
operations  involving  the  principal.   This field might be
useful in conjunction with user registration procedures, for
site-specific   policy   implementations   (Project   Athena
currently uses it for their user registration  process  con-
trolled  by the system-wide database service, Moira [9]), to
identify whether a principal can play the role of  a  client
or  server  or both, to note whether a server is appropriate
trusted to recieve credentials delegated by a client, or  to
identify the "string to key" conversion algorithm used for a
principal's key[22].  Other bits are used to  indicate  that
certain  ticket  options  should  not  be allowed in tickets
encrypted under a principal's key (one bit each):   Disallow
issuing  postdated  tickets,  disallow  issuing  forwardable
tickets, disallow issuing tickets based on  TGT  authentica-
tion,  disallow  issuing renewable tickets, disallow issuing
proxiable tickets, and disallow issuing  tickets  for  which
the principal is the server.

     The mod_date field contains the time of last  modifica-
tion  of the entry, and the mod_name field contains the name
of the principal which last modified the entry.

4.3.  Frequently Changing Fields

     Some KDC implementations may wish to maintain the  last
time  that  a  request  was  made by a particular principal.
Information that might be maintained includes  the  time  of
the  last  request,  the  time  of  the  last  request for a
ticket-granting ticket, the  time  of  the  last  use  of  a
ticket-granting  ticket,  or  other times.  This information
can then be returned to the user in the last-req field  (see
__________________________
[22] See the discussion of the padata field in  section
5.4.2 for details on why this can be useful.


Section 4.3.               - 38 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


section 5.2).

     Other frequently changing information that can be main-
tained  is  the  latest expiration time for any tickets that
have been issued using each key.  This field would  be  used
to indicate how long old keys must remain valid to allow the
continued use of outstanding tickets.

4.4.  Site Constants

     The KDC implementation should have the following confi-
gurable  constants  or options, to allow an administrator to
make and enforce policy decisions:

+  The minimum supported lifetime (used to determine whether
   the  KDC_ERR_NEVER_VALID error should be returned).  This
   constant  should  reflect  reasonable   expectations   of
   round-trip  time  to the KDC, encryption/decryption time,
   and processing time by the client and target server,  and
   it should allow for a minimum "useful" lifetime.

+  The maximum allowable total  (renewable)  lifetime  of  a
   ticket (renew_till - starttime).

+  The maximum allowable lifetime of  a  ticket  (endtime  -
   starttime).

+  Whether to allow the issue of tickets with empty  address
   fields  (including the ability to specify that such tick-
   ets may only be issued  if  the  request  specifies  some
   authorization_data).

+  Whether proxiable, forwardable, renewable or post-datable
   tickets are to be issued.


5.  Message Specifications

     The following sections describe the exact contents  and
encoding  of  protocol messages and objects.  The ASN.1 base
definitions are presented  in  the  first  subsection.   The
remaining  subsections specify the protocol objects (tickets
and authenticators) and messages.  Specification of  encryp-
tion  and  checksum  techniques,  and  the fields related to
them, appear in section 6.

5.1.  ASN.1 Distinguished Encoding Representation

     All uses of  ASN.1  in  Kerberos  shall  use  the  Dis-
tinguished  Encoding  Representation of the data elements as
described in the X.509 specification, section 8.7  [10].





Section 5.1.               - 39 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


5.2.  ASN.1 Base Definitions

     The following ASN.1 base definitions are  used  in  the
rest  of this section.  Note that since the underscore char-
acter (_) is not permitted in ASN.1 names, the hyphen (-) is
used in its place for the purposes of ASN.1 names.

Realm ::=           GeneralString
PrincipalName ::=   SEQUENCE {
                    name-type[0]     INTEGER,
                    name-string[1]   SEQUENCE OF GeneralString
}


Kerberos realms are encoded as GeneralStrings.  Realms shall
not  contain  a  character  with the code 0 (the ASCII NUL).
Most realms  will  usually  consist  of  several  components
separated  by  periods  (.), in the style of Internet Domain
Names, or separated by slashes (/) in  the  style  of  X.500
names.   Acceptable  forms  for realm names are specified in
section 7.  A PrincipalName is  a  typed  sequence  of  com-
ponents consisting of the following sub-fields:

name-type This field specifies the type of  name  that  fol-
          lows.   Pre-defined  values  for  this  field  are
          specified in section 7.2.  The name-type should be
          treated as a hint.  Ignoring the name type, no two
          names can be the same (i.e. at least  one  of  the
          components,  or  the  realm,  must  be different).
          This constraint may be eliminated in the future.

name-stringThis field encodes a sequence of components  that
          form  a name, each component encoded as a General-
          String.  Taken together,  a  PrincipalName  and  a
          Realm  form  a principal identifier.  Most Princi-
          palNames will have only a  few  components  (typi-
          cally one or two).



        KerberosTime ::=   GeneralizedTime
                           -- Specifying UTC time zone (Z)


     The timestamps used in Kerberos are encoded as General-
izedTimes.   An encoding shall specify the UTC time zone (Z)
and  shall  not  include  any  fractional  portions  of  the
seconds.   It  further  shall  not  include  any separators.
Example: The only valid format for UTC time  6  minutes,  27
seconds after 9 pm on 6 November 1985 is 19851106210627Z.

 HostAddress ::=     SEQUENCE  {
                     addr-type[0]             INTEGER,
                     address[1]               OCTET STRING


Section 5.2.               - 40 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


 }

 HostAddresses ::=   SEQUENCE OF SEQUENCE {
                     addr-type[0]             INTEGER,
                     address[1]               OCTET STRING
 }


     The host adddress encodings consists of two fields:

addr-type This field  specifies the  type  of  address  that
          follows.   Pre-defined  values  for this field are
          specified in section 8.1.


address   This field encodes a single address of type  addr-
          type.

The two forms differ slightly. HostAddress contains  exactly
one  address;  HostAddresses contains a sequence of possibly
many addresses.

AuthorizationData ::=   SEQUENCE OF SEQUENCE {
                        ad-type[0]               INTEGER,
                        ad-data[1]               OCTET STRING
}


ad-data   This  field  contains  authorization  data  to  be
          interpreted   according   to   the  value  of  the
          corresponding ad-type field.

ad-type   This field specifies the format  for  the  ad-data
          subfield.   All  negative  values are reserved for
          local use.  Non-negative values are  reserved  for
          registered use.

                APOptions ::=   BIT STRING {
                                reserved(0),
                                use-session-key(1),
                                mutual-required(2)
                }


          TicketFlags ::=   BIT STRING {
                            reserved(0),
                            forwardable(1),
                            forwarded(2),
                            proxiable(3),
                            proxy(4),
                            may-postdate(5),
                            postdated(6),
                            invalid(7),
                            renewable(8),
                            initial(9),


Section 5.2.               - 41 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


                            pre-authent(10),
                            hw-authent(11),
                            transited-policy-checked(12),
                            ok-as-delegate(13)
          }


           KDCOptions ::=   BIT STRING {
                            reserved(0),
                            forwardable(1),
                            forwarded(2),
                            proxiable(3),
                            proxy(4),
                            allow-postdate(5),
                            postdated(6),
                            unused7(7),
                            renewable(8),
                            unused9(9),
                            unused10(10),
                            unused11(11),
                            unused12(12),
                            unused13(13),
                            disable-transited-check(26),
                            renewable-ok(27),
                            enc-tkt-in-skey(28),
                            renew(30),
                            validate(31)
           }

          ASN.1 Bit strings have a length and a value.  When
          used  in  Kerberos for the APOptions, TicketFlags,
          and KDCOptions, the length of the  bit  string  on
          generated  values  should be the smallest multiple
          of 32 bits needed to include the highest order bit
          that is set (1), but in no case less than 32 bits.
          Implementations  should  accept  values   of   bit
          strings of any length and treat the value of flags
          cooresponding to bits beyond the end  of  the  bit
          string as if the bit were reset (0).  Comparisonof
          bit strings of different length should  treat  the
          smaller  string  as  if  it were padded with zeros
          beyond the high order bits to the  length  of  the
          longer string[23].

__________________________
[23] Warning for implementations that unpack and repack
data  structures during the generation and verification
of embedded checksums: Because any checksums applied to
data  structures  must  be checked against the original
data the length of bit strings must be preserved within
a  data  structure  between the time that a checksum is
generated through transmission to  the  time  that  the
checksum is verified.



Section 5.2.               - 42 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


         LastReq ::=   SEQUENCE OF SEQUENCE {
                       lr-type[0]               INTEGER,
                       lr-value[1]              KerberosTime
         }


lr-type   This field indicates how  the  following  lr-value
          field is to be interpreted.  Negative values indi-
          cate that the information  pertains  only  to  the
          responding server.  Non-negative values pertain to
          all servers for the realm.

          If the lr-type field is zero (0), then no informa-
          tion is conveyed by the lr-value subfield.  If the
          absolute value of the lr-type field  is  one  (1),
          then  the  lr-value  subfield  is the time of last
          initial request for a TGT.  If it is two (2), then
          the  lr-value subfield is the time of last initial
          request.  If it is three (3),  then  the  lr-value
          subfield  is  the  time  of  issue  for the newest
          ticket-granting ticket used.  If it is  four  (4),
          then the lr-value subfield is the time of the last
          renewal.  If it is five  (5),  then  the  lr-value
          subfield  is  the  time  of  last  request (of any
          type).


lr-value  This field contains the time of the last  request.
          The time must be interpreted according to the con-
          tents of the accompanying lr-type subfield.

     See section 6 for the definitions of  Checksum,  Check-
sumType,  EncryptedData,  EncryptionKey, EncryptionType, and
KeyType.


5.3.  Tickets and Authenticators

     This section describes the format and encryption param-
eters  for  tickets  and  authenticators.   When a ticket or
authenticator is  included  in  a  protocol  message  it  is
treated as an opaque object.

5.3.1.  Tickets

     A ticket is a record that helps a  client  authenticate
to a service.  A Ticket contains the following information:

Ticket ::=                    [APPLICATION 1] SEQUENCE {
                              tkt-vno[0]                   INTEGER,
                              realm[1]                     Realm,
                              sname[2]                     PrincipalName,
                              enc-part[3]                  EncryptedData
}


Section 5.3.1.             - 43 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


-- Encrypted part of ticket
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
                  flags[0]                     TicketFlags,
                  key[1]                       EncryptionKey,
                  crealm[2]                    Realm,
                  cname[3]                     PrincipalName,
                  transited[4]                 TransitedEncoding,
                  authtime[5]                  KerberosTime,
                  starttime[6]                 KerberosTime OPTIONAL,
                  endtime[7]                   KerberosTime,
                  renew-till[8]                KerberosTime OPTIONAL,
                  caddr[9]                     HostAddresses OPTIONAL,
                  authorization-data[10]       AuthorizationData OPTIONAL
}
-- encoded Transited field
TransitedEncoding ::=   SEQUENCE {
                        tr-type[0]             INTEGER, -- must be registered
                        contents[1]            OCTET STRING
}

The encoding of EncTicketPart is encrypted in the key shared
by  Kerberos  and  the end server (the server's secret key).
See section 6 for the format of the ciphertext.

tkt-vno   This field specifies the version  number  for  the
          ticket  format.   This  document describes version
          number 5.


realm     This field  specifies  the  realm  that  issued  a
          ticket.  It also serves to identify the realm part
          of the server's  principal  identifier.   Since  a
          Kerberos server can only issue tickets for servers
          within its realm, the two will always  be  identi-
          cal.


sname     This field specifies the name part of the server's
          identity.


enc-part  This field holds the  encrypted  encoding  of  the
          EncTicketPart sequence.


flags     This field indicates which of various options were
          used  or requested when the ticket was issued.  It
          is a bit-field, where  the  selected  options  are
          indicated  by  the  bit  being  set  (1),  and the
          unselected options and reserved fields being reset
          (0).   Bit  0  is  the  most significant bit.  The
          encoding of the bits is specified in section  5.2.
          The  flags  are  described in more detail above in
          section 2.  The meanings of the flags are:


Section 5.3.1.             - 44 -    Expires 11 January 1998
\f




            Version 5 - Specification Revision 6


     Bit(s)      Name         Description

     0           RESERVED
                              Reserved for future  expansion  of  this
                              field.

     1           FORWARDABLE 
                              The FORWARDABLE flag  is  normally  only
                              interpreted  by  the  TGS,  and  can  be
                              ignored by end servers.  When set,  this
                              flag  tells  the  ticket-granting server
                              that it is OK to  issue  a  new  ticket-
                              granting ticket with a different network
                              address based on the presented ticket.

     2           FORWARDED   
                              When set, this flag indicates  that  the
                              ticket  has either been forwarded or was
                              issued based on authentication involving
                              a forwarded ticket-granting ticket.

     3           PROXIABLE   
                              The  PROXIABLE  flag  is  normally  only
                              interpreted  by  the  TGS,  and  can  be
                              ignored by end servers.   The  PROXIABLE
                              flag  has an interpretation identical to
                              that of  the  FORWARDABLE  flag,  except
                              that   the   PROXIABLE  flag  tells  the
                              ticket-granting server  that  only  non-
                              ticket-granting  tickets  may  be issued
                              with different network addresses.

     4           PROXY       
                              When set, this  flag  indicates  that  a
                              ticket is a proxy.

     5           MAY-POSTDATE 
                              The MAY-POSTDATE flag is  normally  only
                              interpreted  by  the  TGS,  and  can  be
                              ignored by end servers.  This flag tells
                              the  ticket-granting server that a post-
                              dated ticket may be issued based on this
                              ticket-granting ticket.

     6           POSTDATED    
                              This flag indicates that this ticket has
                              been  postdated.   The  end-service  can
                              check the authtime field to see when the
                              original authentication occurred.

     7           INVALID      
                              This flag indicates  that  a  ticket  is
                              invalid, and it must be validated by the
                              KDC  before  use.   Application  servers
                              must reject tickets which have this flag
                              set.








Section 5.3.1.             - 45 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


     8           RENEWABLE                        
                              The  RENEWABLE  flag  is  normally  only
                              interpreted  by the TGS, and can usually
                              be ignored by end servers (some particu-
                              larly careful servers may wish to disal-
                              low  renewable  tickets).   A  renewable
                              ticket  can be used to obtain a replace-
                              ment ticket  that  expires  at  a  later
                              date.

     9           INITIAL                    
                              This flag indicates that this ticket was
                              issued  using  the  AS protocol, and not
                              issued  based   on   a   ticket-granting
                              ticket.

     10          PRE-AUTHENT              
                              This flag indicates that during  initial
                              authentication, the client was authenti-
                              cated by the KDC  before  a  ticket  was
                              issued.    The   strength  of  the  pre-
                              authentication method is not  indicated,
                              but is acceptable to the KDC.

     11          HW-AUTHENT                    
                              This flag indicates  that  the  protocol
                              employed   for   initial  authentication
                              required the use of hardware expected to
                              be possessed solely by the named client.
                              The hardware  authentication  method  is
                              selected  by the KDC and the strength of
                              the method is not indicated.




Section 5.3.1.             - 46 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


     12           TRANSITED   This flag indicates that the KDC for the
             POLICY-CHECKED   realm has checked the transited field
                              against a realm defined policy for
                              trusted certifiers.  If this flag is
                              reset (0), then the application server
                              must check the transited field itself,
                              and if unable to do so it must reject
                              the authentication.  If the flag is set
                              (1) then the application server may skip
                              its own validation of the transited
                              field, relying on the validation
                              performed by the KDC.  At its option the
                              application server may still apply its
                              own validation based on a separate
                              policy for acceptance.

Section 5.3.1.             - 47 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


     13      OK-AS-DELEGATE   This flag indicates that the server (not
                              the client) specified in the ticket has
                              been determined by policy of the realm
                              to be a suitable recipient of
                              delegation.  A client can use the
                              presence of this flag to help it make a
                              decision whether to delegate credentials
                              (either grant a proxy or a forwarded
                              ticket granting ticket) to this server.
                              The client is free to ignore the value
                              of this flag.  When setting this flag,
                              an administrator should consider the
                              security and placement of the server on
                              which the service will run, as well as
                              whether the service requires the use of
                              delegated credentials.




Section 5.3.1.             - 48 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


     14          ANONYMOUS                
                              This flag indicates that  the  principal
                              named in the ticket is a generic princi-
                              pal for the realm and does not  identify
                              the  individual  using  the ticket.  The
                              purpose  of  the  ticket  is   only   to
                              securely  distribute  a session key, and
                              not to identify  the  user.   Subsequent
                              requests  using the same ticket and ses-
                              sion may be  considered  as  originating
                              from  the  same  user, but requests with
                              the same username but a different ticket
                              are  likely  to originate from different
                              users.

     15-31       RESERVED                
                              Reserved for future use.



key       This field  exists  in  the  ticket  and  the  KDC
          response  and is used to pass the session key from
          Kerberos to the application server and the client.
          The field's encoding is described in section 6.2.

crealm    This field contains the name of the realm in which
          the  client  is  registered  and  in which initial
          authentication took place.


cname     This field contains the name part of the  client's
          principal identifier.


transited This field lists the names of the Kerberos  realms
          that  took part in authenticating the user to whom
          this ticket was issued.  It does not  specify  the
          order  in  which  the  realms were transited.  See
          section 3.3.3.2 for  details  on  how  this  field
          encodes the traversed realms.


authtime  This field indicates the time of initial authenti-
          cation for the named principal.  It is the time of
          issue for the original ticket on which this ticket
          is based.  It is included in the ticket to provide
          additional information to the end service, and  to
          provide  the necessary information for implementa-
          tion of a `hot list' service at the KDC.   An  end
          service that is particularly paranoid could refuse
          to accept tickets for which the initial  authenti-
          cation occurred "too far" in the past.

          This  field  is  also  returned  as  part  of  the
          response  from  the KDC.  When returned as part of
          the    response    to    initial    authentication


Section 5.3.1.             - 49 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


          (KRB_AS_REP), this is the current time on the Ker-
          beros server[24].


starttime This field in the ticket specifies the time  after
          which the ticket is valid.  Together with endtime,
          this field specifies the life of the  ticket.   If
          it  is absent from the ticket, its value should be
          treated as that of the authtime field.


endtime   This field  contains  the  time  after  which  the
          ticket  will not be honored (its expiration time).
          Note that individual services may place their  own
          limits  on  the  life  of  a ticket and may reject
          tickets which have not yet expired.  As such, this
          is  really  an  upper bound on the expiration time
          for the ticket.


renew-tillThis field is only present in  tickets  that  have
          the  RENEWABLE  flag  set  in the flags field.  It
          indicates the maximum endtime that may be included
          in  a  renewal.  It can be thought of as the abso-
          lute expiration time for the ticket, including all
          renewals.


caddr     This field in a ticket contains zero (if  omitted)
          or  more  (if  present) host addresses.  These are
          the addresses from which the ticket can  be  used.
          If  there are no addresses, the ticket can be used
          from any location.  The decision  by  the  KDC  to
          issue  or by the end server to accept zero-address
          tickets is a policy decision and is  left  to  the
          Kerberos  and end-service administrators; they may
          refuse to issue or accept such tickets.  The  sug-
          gested  and  default policy, however, is that such
          tickets will only be issued or accepted when addi-
          tional  information  that  can be used to restrict
          the  use  of  the  ticket  is  included   in   the
          authorization_data  field.   Such  a  ticket  is a
          capability.

          Network addresses are included in  the  ticket  to
          make  it  harder  for  an  attacker  to use stolen
          credentials.  Because the session key is not  sent
          over  the  network in cleartext, credentials can't
__________________________
[24] It is NOT recommended that this time value be used
to adjust the workstation's clock since the workstation
cannot reliably determine that such a KRB_AS_REP  actu-
ally came from the proper KDC in a timely manner.


Section 5.3.1.             - 50 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


          be stolen simply by listening to the  network;  an
          attacker  has  to  gain  access to the session key
          (perhaps   through   operating   system   security
          breaches  or a careless user's unattended session)
          to make use of stolen tickets.

          It is important to note that the  network  address
          from  which  a  connection  is  received cannot be
          reliably determined.  Even  if  it  could  be,  an
          attacker who has compromised the client's worksta-
          tion  could  use  the  credentials   from   there.
          Including the network addresses only makes it more
          difficult, not impossible, for an attacker to walk
          off with stolen credentials and then use them from
          a "safe" location.


authorization-data
          The  authorization-data  field  is  used  to  pass
          authorization  data  from  the  principal on whose
          behalf a ticket was issued to the application ser-
          vice.   If no authorization data is included, this
          field will be left out.  Experience has shown that
          the  name  of  this field is confusing, and that a
          better name for this field would be  restrictions.
          Unfortunately,  it  is  not possible to change the
          name of this field at this time.

          This field contains restrictions on any  authority
          obtained  on the bases of authentication using the
          ticket.  It  is  possible  for  any  principal  in
          posession  of  credentials  to  add entries to the
          authorization  data  field  since  these   entries
          further restrict what can be done with the ticket.
          Such additions can be made by specifying the addi-
          tional  entries when a new ticket is obtained dur-
          ing the TGS exchange, or they may be added  during
          chained  delegation  using  the authorization data
          field of the authenticator.

          Because entries may be added to this field by  the
          holder of credentials, it is not allowable for the
          presence of an entry  in  the  authorization  data
          field  of  a  ticket to amplify the priveleges one
          would obtain from using a ticket.

          The data in this field may be specific to the  end
          service;  the field will contain the names of ser-
          vice specific objects, and  the  rights  to  those
          objects.   The  format for this field is described
          in section 5.2.  Although  Kerberos  is  not  con-
          cerned with the format of the contents of the sub-
          fields, it does carry type information (ad-type).



Section 5.3.1.             - 51 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


          By using the authorization_data field, a principal
          is  able  to  issue  a  proxy  that is valid for a
          specific purpose.  For example, a  client  wishing
          to  print a file can obtain a file server proxy to
          be passed to the print server.  By specifying  the
          name  of the file in the authorization_data field,
          the file server knows that the  print  server  can
          only  use  the  client's rights when accessing the
          particular file to be printed.

          A separate service providing providing  authoriza-
          tion  or  certifying group membership may be built
          using the authorization-data field.  In this case,
          the entity granting authorization (not the author-
          ized entity), obtains a ticket  in  its  own  name
          (e.g.  the  ticket  is  issued  in  the  name of a
          privelege server), and this entity  adds  restric-
          tions  on its own authority and delegates the res-
          tricted authority through a proxy to  the  client.
          The  client  would then present this authorization
          credential to the  application  server  separately
          from the authentication exchange.

          Similarly, if one specifies the authorization-data
          field  of  a  proxy  and leaves the host addresses
          blank, the resulting ticket and session key can be
          treated  as  a  capability.  See [7] for some sug-
          gested uses of this field.

          The authorization-data field is optional and  does
          not have to be included in a ticket.


5.3.2.  Authenticators

     An authenticator is a record sent with a  ticket  to  a
server  to  certify the client's knowledge of the encryption
key in the ticket, to help the server detect replays, and to
help  choose a "true session key" to use with the particular
session.  The encoding is encrypted in the ticket's  session
key shared by the client and the server:

-- Unencrypted authenticator
Authenticator ::= [APPLICATION 2] SEQUENCE  {
                  authenticator-vno[0]          INTEGER,
                  crealm[1]                     Realm,
                  cname[2]                      PrincipalName,
                  cksum[3]                      Checksum OPTIONAL,
                  cusec[4]                      INTEGER,
                  ctime[5]                      KerberosTime,
                  subkey[6]                     EncryptionKey OPTIONAL,
                  seq-number[7]                 INTEGER OPTIONAL,
                  authorization-data[8]         AuthorizationData OPTIONAL
}



Section 5.3.2.             - 52 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


authenticator-vno
          This field specifies the version  number  for  the
          format of the authenticator.  This document speci-
          fies version 5.


crealm and cname
          These fields are the same as those  described  for
          the ticket in section 5.3.1.


cksum     This field contains a checksum of the the applica-
          tion data that accompanies the KRB_AP_REQ.


cusec     This field contains the microsecond  part  of  the
          client's timestamp.  Its value (before encryption)
          ranges from 0 to 999999.  It often  appears  along
          with  ctime.   The two fields are used together to
          specify a reasonably accurate timestamp.


ctime     This  field  contains  the  current  time  on  the
          client's host.


subkey    This field contains the  client's  choice  for  an
          encryption key which is to be used to protect this
          specific application session.  Unless an  applica-
          tion  specifies  otherwise,  if this field is left
          out the session key from the ticket will be used.

seq-numberThis optional field includes the initial  sequence
          number to be used by the KRB_PRIV or KRB_SAFE mes-
          sages when sequence numbers  are  used  to  detect
          replays  (It  may  also  be  used  by  application
          specific messages).  When included in the  authen-
          ticator  this field specifies the initial sequence
          number for messages from the client to the server.
          When  included  in the AP-REP message, the initial
          sequence number is  that  for  messages  from  the
          server  to  the  client.  When used in KRB_PRIV or
          KRB_SAFE messages, it is incremented by one  after
          each message is sent.

          For sequence numbers  to  adequately  support  the
          detection of replays they should be non-repeating,
          even across connection  boundaries.   The  initial
          sequence  number  should  be  random and uniformly
          distributed across  the  full  space  of  possible
          sequence  numbers, so that it cannot be guessed by
          an attacker and so  that  it  and  the  successive
          sequence numbers do not repeat other sequences.



Section 5.3.2.             - 53 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


authorization-data
          This field is the same as described for the ticket
          in  section  5.3.1.   It is optional and will only
          appear when  additional  restrictions  are  to  be
          placed  on  the use of a ticket, beyond those car-
          ried in the ticket itself.

5.4.  Specifications for the AS and TGS exchanges

     This section specifies the format of the messages  used
in  the exchange between the client and the Kerberos server.
The format of possible error  messages  appears  in  section
5.9.1.

5.4.1.  KRB_KDC_REQ definition

     The  KRB_KDC_REQ  message  has  no  type  of  its  own.
Instead,  its  type  is  one  of  KRB_AS_REQ  or KRB_TGS_REQ
depending on whether the request is for an initial ticket or
an  additional  ticket.  In either case, the message is sent
from the client to  the  Authentication  Server  to  request
credentials for a service.

     The message fields are:

AS-REQ ::=         [APPLICATION 10] KDC-REQ
TGS-REQ ::=        [APPLICATION 12] KDC-REQ

KDC-REQ ::=        SEQUENCE {
                   pvno[1]            INTEGER,
                   msg-type[2]        INTEGER,
                   padata[3]          SEQUENCE OF PA-DATA OPTIONAL,
                   req-body[4]        KDC-REQ-BODY
}

PA-DATA ::=        SEQUENCE {
                   padata-type[1]     INTEGER,
                   padata-value[2]    OCTET STRING,
                                      -- might be encoded AP-REQ
}

KDC-REQ-BODY ::=   SEQUENCE {
                    kdc-options[0]         KDCOptions,
                    cname[1]               PrincipalName OPTIONAL,
                                           -- Used only in AS-REQ
                    realm[2]               Realm, -- Server's realm
                                           -- Also client's in AS-REQ
                    sname[3]               PrincipalName OPTIONAL,
                    from[4]                KerberosTime OPTIONAL,
                    till[5]                KerberosTime OPTIONAL,
                    rtime[6]               KerberosTime OPTIONAL,
                    nonce[7]               INTEGER,
                    etype[8]               SEQUENCE OF INTEGER, 
                                           -- EncryptionType,
                                           -- in preference order


Section 5.4.1.             - 54 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


                    addresses[9]           HostAddresses OPTIONAL,
                enc-authorization-data[10] EncryptedData OPTIONAL,
                                           -- Encrypted AuthorizationData 
                                           -- encoding
                    additional-tickets[11] SEQUENCE OF Ticket OPTIONAL
}

The fields in this message are:


pvno      This field is included in each message, and speci-
          fies  the  protocol version number.  This document
          specifies protocol version 5.


msg-type  This field indicates the type of a  protocol  mes-
          sage.   It  will  almost always be the same as the
          application identifier associated with a  message.
          It is included to make the identifier more readily
          accessible to the application.   For  the  KDC-REQ
          message,   this   type   will   be  KRB_AS_REQ  or
          KRB_TGS_REQ.


padata    The padata (pre-authentication  data)  field  con-
          tains  a  sequence  of  authentication information
          which may be  needed  before  credentials  can  be
          issued  or decrypted.  In the case of requests for
          additional tickets (KRB_TGS_REQ), this field  will
          include  an element with padata-type of PA-TGS-REQ
          and data  of  an  authentication  header  (ticket-
          granting  ticket and authenticator).  The checksum
          in the authenticator  (which  must  be  collision-
          proof)  is  to  be  computed over the KDC-REQ-BODY
          encoding.  In most requests for initial  authenti-
          cation  (KRB_AS_REQ)  and  most replies (KDC-REP),
          the padata field will be left out.

          This field may also contain information needed  by
          certain  extensions to the Kerberos protocol.  For
          example, it might be used to initially verify  the
          identity  of  a  client  before  any  response  is
          returned.  This  is  accomplished  with  a  padata
          field  with  padata-type equal to PA-ENC-TIMESTAMP
          and padata-value defined as follows:

padata-type     ::= PA-ENC-TIMESTAMP
padata-value    ::= EncryptedData -- PA-ENC-TS-ENC

PA-ENC-TS-ENC   ::= SEQUENCE {
                patimestamp[0]     KerberosTime, -- client's time
                pausec[1]          INTEGER OPTIONAL
}

          with patimestamp containing the client's time  and


Section 5.4.1.             - 55 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


          pausec  containing  the  microseconds which may be
          omitted if a client will not  generate  more  than
          one  request  per second.  The ciphertext (padata-
          value) consists  of  the  PA-ENC-TS-ENC  sequence,
          encrypted using the client's secret key.

          The padata  field  can  also  contain  information
          needed  to  help  the KDC or the client select the
          key  needed  for  generating  or  decrypting   the
          response.   This  form of the padata is useful for
          supporting the use of  certain  token  cards  with
          Kerberos.   The  details  of  such  extensions are
          specified in separate  documents.   See  [11]  for
          additional uses of this field.

padata-type
          The padata-type element of the padata field  indi-
          cates  the way that the padata-value element is to
          be interpreted.  Negative  values  of  padata-type
          are  reserved  for  unregistered use; non-negative
          values are used for a registered interpretation of
          the element type.


req-body  This field is a placeholder delimiting the  extent
          of  the  remaining fields.  If a checksum is to be
          calculated over the request, it is calculated over
          an  encoding of the KDC-REQ-BODY sequence which is
          enclosed within the req-body field.


kdc-options
          This  field  appears   in   the   KRB_AS_REQ   and
          KRB_TGS_REQ  requests to the KDC and indicates the
          flags that the client wants set on the tickets  as
          well  as  other  information that is to modify the
          behavior of the KDC.  Where appropriate, the  name
          of  an  option may be the same as the flag that is
          set by that option.  Although in  most  case,  the
          bit  in the options field will be the same as that
          in the flags field, this is not guaranteed, so  it
          is not acceptable to simply copy the options field
          to the flags field.  There are various checks that
          must be made before honoring an option anyway.

          The kdc_options field is a  bit-field,  where  the
          selected  options  are  indicated by the bit being
          set (1), and the unselected options  and  reserved
          fields  being reset (0).  The encoding of the bits
          is specified in  section  5.2.   The  options  are
          described  in more detail above in section 2.  The
          meanings of the options are:




Section 5.4.1.             - 56 -    Expires 11 January 1998
\f



            Version 5 - Specification Revision 6


   Bit(s)    Name                Description
    0        RESERVED
                                 Reserved for future  expansion  of  this
                                 field.

    1        FORWARDABLE
                                 The FORWARDABLE  option  indicates  that
                                 the  ticket  to be issued is to have its
                                 forwardable flag set.  It  may  only  be
                                 set on the initial request, or in a sub-
                                 sequent request if  the  ticket-granting
                                 ticket on which it is based is also for-
                                 wardable.

    2        FORWARDED
                                 The FORWARDED option is  only  specified
                                 in  a  request  to  the  ticket-granting
                                 server and will only be honored  if  the
                                 ticket-granting  ticket  in  the request
                                 has  its  FORWARDABLE  bit  set.    This
                                 option  indicates that this is a request
                                 for forwarding.  The address(es) of  the
                                 host  from which the resulting ticket is
                                 to  be  valid  are   included   in   the
                                 addresses field of the request.

    3        PROXIABLE
                                 The PROXIABLE option indicates that  the
                                 ticket to be issued is to have its prox-
                                 iable flag set.  It may only be  set  on
                                 the  initial request, or in a subsequent
                                 request if the ticket-granting ticket on
                                 which it is based is also proxiable.

    4        PROXY
                                 The PROXY option indicates that this  is
                                 a request for a proxy.  This option will
                                 only be honored if  the  ticket-granting
                                 ticket  in the request has its PROXIABLE
                                 bit set.  The address(es)  of  the  host
                                 from which the resulting ticket is to be
                                  valid  are  included  in  the  addresses
                                 field of the request.

    5        ALLOW-POSTDATE
                                 The ALLOW-POSTDATE option indicates that
                                 the  ticket  to be issued is to have its
                                 MAY-POSTDATE flag set.  It may  only  be
                                 set on the initial request, or in a sub-
                                 sequent request if  the  ticket-granting
                                 ticket on which it is based also has its
                                 MAY-POSTDATE flag set.







Section 5.4.1.             - 57 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


    6        POSTDATED
                                 The POSTDATED option indicates that this
                                 is  a  request  for  a postdated ticket.
                                 This option will only be honored if  the
                                 ticket-granting  ticket  on  which it is
                                 based has  its  MAY-POSTDATE  flag  set.
                                 The  resulting ticket will also have its
                                 INVALID flag set, and that flag  may  be
                                 reset by a subsequent request to the KDC
                                 after the starttime in  the  ticket  has
                                 been reached.

    7        UNUSED
                                 This option is presently unused.

    8        RENEWABLE
                                 The RENEWABLE option indicates that  the
                                 ticket  to  be  issued  is  to  have its
                                 RENEWABLE flag set.  It may only be  set
                                 on  the  initial  request,  or  when the
                                 ticket-granting  ticket  on  which   the
                                 request  is based is also renewable.  If
                                 this option is requested, then the rtime
                                 field   in   the  request  contains  the
                                 desired absolute expiration time for the
                                 ticket.

    9-13     UNUSED
                                 These options are presently unused.

    14       REQUEST-ANONYMOUS
                                 The REQUEST-ANONYMOUS  option  indicates
                                 that  the  ticket to be issued is not to
                                 identify  the  user  to  which  it   was
                                 issued.  Instead, the principal identif-
                                 ier is to be generic,  as  specified  by
                                 the  policy  of  the realm (e.g. usually
                                 anonymous@realm).  The  purpose  of  the
                                 ticket  is only to securely distribute a
                                 session key, and  not  to  identify  the
                                 user.   The ANONYMOUS flag on the ticket
                                 to be returned should be  set.   If  the
                                 local  realms  policy  does  not  permit
                                 anonymous credentials, the request is to
                                 be rejected.

    15-25    RESERVED
                                 Reserved for future use.

    26       DISABLE-TRANSITED-CHECK
                                 By default the KDC will check the
                                 transited field of a ticket-granting-
                                 ticket against the policy of the local
                                 realm before it will issue derivative
                                 tickets based on the ticket granting
                                 ticket.  If this flag is set in the
                                 request, checking of the transited field
                                 is disabled.  Tickets issued without the
                                 performance of this check will be noted
                                 by the reset (0) value of the
                                 TRANSITED-POLICY-CHECKED flag,
                                 indicating to the application server
                                 that the tranisted field must be checked
                                 locally.  KDC's are encouraged but not
                                 required to honor the
                                 DISABLE-TRANSITED-CHECK option.



Section 5.4.1.             - 58 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


    27       RENEWABLE-OK
                                 The RENEWABLE-OK option indicates that a
                                 renewable ticket will be acceptable if a
                                 ticket with the  requested  life  cannot
                                 otherwise be provided.  If a ticket with
                                 the requested life cannot  be  provided,
                                 then  a  renewable  ticket may be issued
                                 with  a  renew-till  equal  to  the  the
                                 requested  endtime.   The  value  of the
                                 renew-till field may still be limited by
                                 local  limits, or limits selected by the
                                 individual principal or server.

    28       ENC-TKT-IN-SKEY
                                 This option is used only by the  ticket-
                                 granting  service.   The ENC-TKT-IN-SKEY
                                 option indicates that the ticket for the
                                 end  server  is  to  be encrypted in the
                                 session key from the additional  ticket-
                                 granting ticket provided.

    29       RESERVED
                                 Reserved for future use.

    30       RENEW
                                 This option is used only by the  ticket-
                                 granting   service.   The  RENEW  option
                                 indicates that the  present  request  is
                                 for  a  renewal.  The ticket provided is
                                 encrypted in  the  secret  key  for  the
                                 server  on  which  it  is  valid.   This
                                 option  will  only  be  honored  if  the
                                 ticket  to  be renewed has its RENEWABLE
                                 flag set and if the time in  its  renew-
                                 till  field  has not passed.  The ticket
                                 to be renewed is passed  in  the  padata
                                 field  as  part  of  the  authentication
                                 header.

    31       VALIDATE
                                 This option is used only by the  ticket-
                                 granting  service.   The VALIDATE option
                                 indicates that the request is  to  vali-
                                 date  a  postdated ticket.  It will only
                                 be honored if the  ticket  presented  is
                                 postdated,  presently  has  its  INVALID
                                 flag set, and would be otherwise  usable
                                 at  this time.  A ticket cannot be vali-
                                 dated before its starttime.  The  ticket
                                 presented for validation is encrypted in
                                 the key of the server for  which  it  is
                                 valid  and is passed in the padata field
                                 as part of the authentication header.

cname and sname
          These fields are the same as those  described  for
          the  ticket  in  section 5.3.1.  sname may only be


Section 5.4.1.             - 59 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


          absent when the ENC-TKT-IN-SKEY option  is  speci-
          fied.   If absent, the name of the server is taken
          from the name of the client in the  ticket  passed
          as additional-tickets.


enc-authorization-data
          The enc-authorization-data, if present (and it can
          only be present in the TGS_REQ form), is an encod-
          ing of the  desired  authorization-data  encrypted
          under  the  sub-session  key  if  present  in  the
          Authenticator, or alternatively from  the  session
          key  in  the ticket-granting ticket, both from the
          padata field in the KRB_AP_REQ.


realm     This  field  specifies  the  realm  part  of   the
          server's   principal   identifier.    In   the  AS
          exchange, this is  also  the  realm  part  of  the
          client's principal identifier.


from      This field  is  included  in  the  KRB_AS_REQ  and
          KRB_TGS_REQ  ticket  requests  when  the requested
          ticket  is  to  be  postdated.  It  specifies  the
          desired start time for the requested ticket.



till      This field contains the expiration date  requested
          by  the  client in a ticket request.  It is option
          and if omitted the requested ticket is to have the
          maximum  endtime permitted according to KDC policy
          for the parties to the authentication exchange  as
          limited  by expiration date of the ticket granting
          ticket or other preauthentication credentials.


rtime     This field is the requested renew-till  time  sent
          from  a client to the KDC in a ticket request.  It
          is optional.


nonce     This  field  is  part  of  the  KDC  request   and
          response.   It it intended to hold a random number
          generated by the client.  If the  same  number  is
          included  in  the encrypted response from the KDC,
          it provides evidence that the  response  is  fresh
          and  has not been replayed by an attacker.  Nonces
          must never be re-used.  Ideally, it should be gen-
          erated randomly, but if the correct time is known,
          it may suffice[25].
__________________________
[25] Note, however, that if the time  is  used  as  the

Section 5.4.1.             - 60 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


etype     This field specifies the desired encryption  algo-
          rithm to be used in the response.


addresses This field is included in the initial request  for
          tickets,  and  optionally included in requests for
          additional  tickets   from   the   ticket-granting
          server.  It specifies the addresses from which the
          requested ticket is  to  be  valid.   Normally  it
          includes  the addresses for the client's host.  If
          a proxy is  requested,  this  field  will  contain
          other  addresses.   The contents of this field are
          usually copied by the KDC into the caddr field  of
          the resulting ticket.


additional-tickets
          Additional tickets may be optionally included in a
          request  to  the  ticket-granting  server.  If the
          ENC-TKT-IN-SKEY option has  been  specified,  then
          the session key from the additional ticket will be
          used in place of the server's key to  encrypt  the
          new   ticket.   If  more  than  one  option  which
          requires additional tickets  has  been  specified,
          then  the additional tickets are used in the order
          specified by the ordering of the options bits (see
          kdc-options, above).


     The application code will be either ten (10) or  twelve
(12)  depending  on  whether  the  request is for an initial
ticket (AS-REQ) or for an additional ticket (TGS-REQ).

     The optional fields (addresses, authorization-data  and
additional-tickets)  are  only included if necessary to per-
form the operation specified in the kdc-options field.

     It should be noted that in  KRB_TGS_REQ,  the  protocol
version number appears twice and two different message types
appear:  the KRB_TGS_REQ message contains  these  fields  as
does  the  authentication header (KRB_AP_REQ) that is passed
in the padata field.

5.4.2.  KRB_KDC_REP definition

     The KRB_KDC_REP message format is used  for  the  reply
from  the KDC for either an initial (AS) request or a subse-
quent  (TGS)  request.   There  is  no  message   type   for
__________________________
nonce,  one must make sure that the workstation time is
monotonically increasing.  If the time  is  ever  reset
backwards,  there  is  a small, but finite, probability
that a nonce will be reused.



Section 5.4.2.             - 61 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


KRB_KDC_REP.  Instead, the type will be either KRB_AS_REP or
KRB_TGS_REP.  The key used to encrypt the ciphertext part of
the reply depends on the message type.  For KRB_AS_REP,  the
ciphertext  is encrypted in the client's secret key, and the
client's key version number is included in the  key  version
number for the encrypted data.  For KRB_TGS_REP, the cipher-
text is encrypted in the sub-session key from the  Authenti-
cator,  or  if  absent,  the  session  key  from the ticket-
granting ticket used in the request.  In that case, no  ver-
sion number will be present in the EncryptedData sequence.

     The KRB_KDC_REP message contains the following fields:

AS-REP ::=    [APPLICATION 11] KDC-REP
TGS-REP ::=   [APPLICATION 13] KDC-REP

KDC-REP ::=   SEQUENCE {
              pvno[0]                    INTEGER,
              msg-type[1]                INTEGER,
              padata[2]                  SEQUENCE OF PA-DATA OPTIONAL,
              crealm[3]                  Realm,
              cname[4]                   PrincipalName,
              ticket[5]                  Ticket,
              enc-part[6]                EncryptedData
}


EncASRepPart ::=    [APPLICATION 25[27]] EncKDCRepPart
EncTGSRepPart ::=   [APPLICATION 26] EncKDCRepPart



EncKDCRepPart ::=   SEQUENCE {
                    key[0]               EncryptionKey,
                    last-req[1]          LastReq,
                    nonce[2]             INTEGER,
                    key-expiration[3]    KerberosTime OPTIONAL,
                    flags[4]             TicketFlags,
                    authtime[5]          KerberosTime,
                    starttime[6]         KerberosTime OPTIONAL,
                    endtime[7]           KerberosTime,
                    renew-till[8]        KerberosTime OPTIONAL,
                    srealm[9]            Realm,
                    sname[10]            PrincipalName,
                    caddr[11]            HostAddresses OPTIONAL
}


pvno and msg-type
          These fields are described above in section 5.4.1.
          msg-type is either KRB_AS_REP or KRB_TGS_REP.
__________________________
[27] An application code in the  encrypted  part  of  a
message  provides  an additional check that the message
was decrypted properly.


Section 5.4.2.             - 62 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


padata    This field  is  described  in  detail  in  section
          5.4.1.   One  possible  use  for  this field is to
          encode an alternate "mix-in"  string  to  be  used
          with   a   string-to-key  algorithm  (such  as  is
          described in section 6.3.2).  This ability is use-
          ful  to  ease transitions if a realm name needs to
          change (e.g. when a company is acquired); in  such
          a  case  all  existing password-derived entries in
          the KDC database would be  flagged  as  needing  a
          special  mix-in  string  until  the  next password
          change.


crealm, cname, srealm and sname
          These fields are the same as those  described  for
          the ticket in section 5.3.1.


ticket    The newly-issued ticket, from section 5.3.1.


enc-part  This field is a place holder  for  the  ciphertext
          and  related  information that forms the encrypted
          part  of  a  message.   The  description  of   the
          encrypted part of the message follows each appear-
          ance of this field.  The encrypted part is encoded
          as described in section 6.1.


key       This field is the same as described for the ticket
          in section 5.3.1.


last-req  This field is returned by the  KDC  and  specifies
          the  time(s)  of  the last request by a principal.
          Depending on what information is  available,  this
          might  be  the  last  time  that  a  request for a
          ticket-granting ticket was made, or the last  time
          that  a  request based on a ticket-granting ticket
          was successful.  It also might cover  all  servers
          for  a realm, or just the particular server.  Some
          implementations may display  this  information  to
          the user to aid in discovering unauthorized use of
          one's identity.  It is similar in  spirit  to  the
          last   login  time  displayed  when  logging  into
          timesharing systems.


nonce     This field is described above in section 5.4.1.


key-expiration
          The key-expiration field is part of  the  response
          from  the  KDC  and  specifies  the  time that the


Section 5.4.2.             - 63 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


          client's secret key is due to expire.  The expira-
          tion  might  be the result of password aging or an
          account expiration.  This field  will  usually  be
          left  out  of  the TGS reply since the response to
          the TGS request is encrypted in a session key  and
          no  client  information need be retrieved from the
          KDC database.  It is up to the application  client
          (usually  the  login  program) to take appropriate
          action (such as notifying the user) if the expira-
          tion time is imminent.


flags, authtime, starttime, endtime, renew-till and caddr
          These fields are duplicates of those found in  the
          encrypted portion of the attached ticket (see sec-
          tion 5.3.1), provided so  the  client  may  verify
          they  match  the intended request and to assist in
          proper ticket caching.  If the message is of  type
          KRB_TGS_REP,  the  caddr field will only be filled
          in if the request was for  a  proxy  or  forwarded
          ticket, or if the user is substituting a subset of
          the addresses from the ticket granting ticket.  If
          the  client-requested addresses are not present or
          not used, then  the  addresses  contained  in  the
          ticket  will  be the same as those included in the
          ticket-granting ticket.


5.5.  Client/Server (CS) message specifications

     This section specifies the format of the messages  used
for  the  authentication  of  the  client to the application
server.

5.5.1.  KRB_AP_REQ definition

     The KRB_AP_REQ message contains the  Kerberos  protocol
version  number,  the  message  type  KRB_AP_REQ, an options
field to indicate any options in use,  and  the  ticket  and
authenticator  themselves.   The KRB_AP_REQ message is often
referred to as the "authentication header".

AP-REQ ::=      [APPLICATION 14] SEQUENCE {
                pvno[0]                       INTEGER,
                msg-type[1]                   INTEGER,
                ap-options[2]                 APOptions,
                ticket[3]                     Ticket,
                authenticator[4]              EncryptedData
}

APOptions ::=   BIT STRING {
                reserved(0),
                use-session-key(1),
                mutual-required(2)


Section 5.5.1.             - 64 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


}


pvno and msg-type
          These fields are described above in section 5.4.1.
          msg-type is KRB_AP_REQ.


ap-optionsThis field  appears  in  the  application  request
          (KRB_AP_REQ)  and  affects  the way the request is
          processed.  It is a bit-field, where the  selected
          options  are  indicated  by the bit being set (1),
          and the unselected  options  and  reserved  fields
          being  reset  (0).   The  encoding  of the bits is
          specified in section 5.2.   The  meanings  of  the
          options are:

          Bit(s)   Name              Description

          0        RESERVED
                                     Reserved for future  expansion  of  this
                                     field.

          1        USE-SESSION-KEY
                                     The  USE-SESSION-KEY  option   indicates
                                     that the ticket the client is presenting
                                     to a server is encrypted in the  session
                                     key  from  the  server's ticket-granting
                                     ticket.  When this option is not  speci-
                                     fied,  the  ticket  is  encrypted in the
                                     server's secret key.

          2        MUTUAL-REQUIRED
                                     The  MUTUAL-REQUIRED  option  tells  the
                                     server  that  the client requires mutual
                                     authentication, and that it must respond
                                     with a KRB_AP_REP message.

          3-31     RESERVED
                                     Reserved for future use.



ticket    This field is a ticket authenticating  the  client
          to the server.


authenticator
          This contains the  authenticator,  which  includes
          the  client's choice of a subkey.  Its encoding is
          described in section 5.3.2.

5.5.2.  KRB_AP_REP definition

     The KRB_AP_REP message contains the  Kerberos  protocol
version  number,  the  message  type, and an encrypted time-
stamp.  The message is sent in in response to an application
request  (KRB_AP_REQ) where the mutual authentication option


Section 5.5.2.             - 65 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


has been selected in the ap-options field.

AP-REP ::=         [APPLICATION 15] SEQUENCE {
                   pvno[0]                           INTEGER,
                   msg-type[1]                       INTEGER,
                   enc-part[2]                       EncryptedData
}

EncAPRepPart ::=   [APPLICATION 27[29]] SEQUENCE {
                   ctime[0]                          KerberosTime,
                   cusec[1]                          INTEGER,
                   subkey[2]                         EncryptionKey OPTIONAL,
                   seq-number[3]                     INTEGER OPTIONAL
}

The encoded EncAPRepPart is encrypted in the shared  session
key of the ticket.  The optional subkey field can be used in
an application-arranged negotiation to choose a per associa-
tion session key.


pvno and msg-type
          These fields are described above in section 5.4.1.
          msg-type is KRB_AP_REP.


enc-part  This field is described above in section 5.4.2.


ctime     This  field  contains  the  current  time  on  the
          client's host.


cusec     This field contains the microsecond  part  of  the
          client's timestamp.


subkey    This field contains an encryption key which is  to
          be  used to protect this specific application ses-
          sion.  See section 3.2.6 for specifics on how this
          field  is  used  to  negotiate  a  key.  Unless an
          application specifies otherwise, if this field  is
          left out, the sub-session key from the authentica-
          tor, or if also left out, the session key from the
          ticket will be used.



__________________________
[29] An application code in the  encrypted  part  of  a
message  provides  an additional check that the message
was decrypted properly.



Section 5.5.2.             - 66 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


5.5.3.  Error message reply

     If an error occurs  while  processing  the  application
request,  the  KRB_ERROR  message  will be sent in response.
See section 5.9.1 for the format of the error message.   The
cname and crealm fields may be left out if the server cannot
determine their appropriate values  from  the  corresponding
KRB_AP_REQ  message.  If the authenticator was decipherable,
the ctime and cusec fields will contain the values from it.

5.6.  KRB_SAFE message specification

     This section specifies the format of a message that can
be  used by either side (client or server) of an application
to send a tamper-proof message to  its  peer.   It  presumes
that  a session key has previously been exchanged (for exam-
ple, by using the KRB_AP_REQ/KRB_AP_REP messages).

5.6.1.  KRB_SAFE definition

     The KRB_SAFE message contains user data  along  with  a
collision-proof  checksum keyed with the last encryption key
negotiated via subkeys, or the session key if no negotiation
has occured.  The message fields are:

KRB-SAFE ::=        [APPLICATION 20] SEQUENCE {
                    pvno[0]                       INTEGER,
                    msg-type[1]                   INTEGER,
                    safe-body[2]                  KRB-SAFE-BODY,
                    cksum[3]                      Checksum
}

KRB-SAFE-BODY ::=   SEQUENCE {
                    user-data[0]                  OCTET STRING,
                    timestamp[1]                  KerberosTime OPTIONAL,
                    usec[2]                       INTEGER OPTIONAL,
                    seq-number[3]                 INTEGER OPTIONAL,
                    s-address[4]                  HostAddress OPTIONAL,
                    r-address[5]                  HostAddress OPTIONAL
}




pvno and msg-type
          These fields are described above in section 5.4.1.
          msg-type is KRB_SAFE.


safe-body This field is a placeholder for the  body  of  the
          KRB-SAFE  message.  It is to be encoded separately
          and then have the checksum computed over  it,  for
          use in the cksum field.



Section 5.6.1.             - 67 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


cksum     This field contains the checksum of  the  applica-
          tion data.  Checksum details are described in sec-
          tion 6.4.   The  checksum  is  computed  over  the
          encoding of the KRB-SAFE-BODY sequence.


user-data This field is part of the  KRB_SAFE  and  KRB_PRIV
          messages and contain the application specific data
          that is being passed from the sender to the  reci-
          pient.


timestamp This field is part of the  KRB_SAFE  and  KRB_PRIV
          messages.   Its  contents  are the current time as
          known by the sender of the message.   By  checking
          the  timestamp,  the  recipient  of the message is
          able to make sure that it was recently  generated,
          and is not a replay.


usec      This field is part of the  KRB_SAFE  and  KRB_PRIV
          headers.   It contains the microsecond part of the
          timestamp.


seq-number
          This field is described above in section 5.3.2.


s-address This field specifies the address  in  use  by  the
          sender of the message.


r-address This field specifies the address  in  use  by  the
          recipient  of  the message.  It may be omitted for
          some uses (such as broadcast protocols),  but  the
          recipient  may  arbitrarily  reject such messages.
          This field along with s-address  can  be  used  to
          help  detect  messages which have been incorrectly
          or maliciously delivered to the wrong recipient.

5.7.  KRB_PRIV message specification

     This section specifies the format of a message that can
be  used by either side (client or server) of an application
to securely and privately send a message to  its  peer.   It
presumes  that  a  session key has previously been exchanged
(for example, by using the KRB_AP_REQ/KRB_AP_REP messages).

5.7.1.  KRB_PRIV definition

     The KRB_PRIV message contains user  data  encrypted  in
the Session Key.  The message fields are:

__________________________
[31] An application code in the  encrypted  part  of  a


\f



            Version 5 - Specification Revision 6



KRB-PRIV ::=         [APPLICATION 21] SEQUENCE {
                     pvno[0]                           INTEGER,
                     msg-type[1]                       INTEGER,
                     enc-part[3]                       EncryptedData
}

EncKrbPrivPart ::=   [APPLICATION 28[31]] SEQUENCE {
                     user-data[0]        OCTET STRING,
                     timestamp[1]        KerberosTime OPTIONAL,
                     usec[2]             INTEGER OPTIONAL,
                     seq-number[3]       INTEGER OPTIONAL,
                     s-address[4]        HostAddress OPTIONAL, -- sender's addr
                     r-address[5]        HostAddress OPTIONAL -- recip's addr
}



pvno and msg-type
          These fields are described above in section 5.4.1.
          msg-type is KRB_PRIV.


enc-part  This field holds an encoding of the EncKrbPrivPart
          sequence  encrypted  under  the  session  key[32].
          This  encrypted  encoding is used for the enc-part
          field of the KRB-PRIV message.  See section 6  for
          the format of the ciphertext.


user-data, timestamp, usec, s-address and r-address
          These fields are described above in section 5.6.1.


seq-number
          This field is described above in section 5.3.2.

5.8.  KRB_CRED message specification

     This section specifies the format of a message that can
be  used  to send Kerberos credentials from one principal to
__________________________
message  provides  an additional check that the message
was decrypted properly.
[32] If  supported  by the encryption method in use, an
initialization vector may be passed to  the  encryption
procedure,  in order to achieve proper cipher chaining.
The initialization vector  might  come  from  the  last
block of the ciphertext from the previous KRB_PRIV mes-
sage, but it is the application's choice whether or not
to use such an initialization vector.  If left out, the
default initialization vector for the encryption  algo-
rithm will be used.


Section 5.8.               - 69 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


another.  It is presented here to encourage a common mechan-
ism  to  be  used by applications when forwarding tickets or
providing proxies to subordinate servers.  It presumes  that
a  session  key  has already been exchanged perhaps by using
the KRB_AP_REQ/KRB_AP_REP messages.

5.8.1.  KRB_CRED definition

     The KRB_CRED message contains a sequence of tickets  to
be sent and information needed to use the tickets, including
the session key from each.  The information  needed  to  use
the  tickets is encrypted under an encryption key previously
exchanged or transferred  alongside  the  KRB_CRED  message.
The message fields are:

KRB-CRED         ::= [APPLICATION 22]   SEQUENCE {
                 pvno[0]                INTEGER,
                 msg-type[1]            INTEGER, -- KRB_CRED
                 tickets[2]             SEQUENCE OF Ticket,
                 enc-part[3]            EncryptedData
}

EncKrbCredPart   ::= [APPLICATION 29]   SEQUENCE {
                 ticket-info[0]         SEQUENCE OF KrbCredInfo,
                 nonce[1]               INTEGER OPTIONAL,
                 timestamp[2]           KerberosTime OPTIONAL,
                 usec[3]                INTEGER OPTIONAL,
                 s-address[4]           HostAddress OPTIONAL,
                 r-address[5]           HostAddress OPTIONAL
}

KrbCredInfo      ::=                    SEQUENCE {
                 key[0]                 EncryptionKey,
                 prealm[1]              Realm OPTIONAL,
                 pname[2]               PrincipalName OPTIONAL,
                 flags[3]               TicketFlags OPTIONAL,
                 authtime[4]            KerberosTime OPTIONAL,
                 starttime[5]           KerberosTime OPTIONAL,
                 endtime[6]             KerberosTime OPTIONAL
                 renew-till[7]          KerberosTime OPTIONAL,
                 srealm[8]              Realm OPTIONAL,
                 sname[9]               PrincipalName OPTIONAL,
                 caddr[10]              HostAddresses OPTIONAL
}





pvno and msg-type
          These fields are described above in section 5.4.1.
          msg-type is KRB_CRED.




Section 5.8.1.             - 70 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


tickets
          These  are  the  tickets  obtained  from  the  KDC
          specifically  for  use  by the intended recipient.
          Successive tickets are paired with the correspond-
          ing  KrbCredInfo sequence from the enc-part of the
          KRB-CRED message.


enc-part  This field holds an encoding of the EncKrbCredPart
          sequence  encrypted  under  the session key shared
          between the sender  and  the  intended  recipient.
          This  encrypted  encoding is used for the enc-part
          field of the KRB-CRED message.  See section 6  for
          the format of the ciphertext.


nonce     If  practical,  an  application  may  require  the
          inclusion of a nonce generated by the recipient of
          the message.  If the same value is included as the
          nonce  in  the  message, it provides evidence that
          the message is fresh and has not been replayed  by
          an  attacker.   A  nonce must never be re-used; it
          should be generated randomly by the  recipient  of
          the message and provided to the sender of the mes-
          sage in an application specific manner.


timestamp and usec

          These fields specify the time  that  the  KRB-CRED
          message  was  generated.  The time is used to pro-
          vide assurance that the message is fresh.


s-address and r-address
          These fields are described above in section 5.6.1.
          They  are  used  optionally  to provide additional
          assurance of the integrity of  the  KRB-CRED  mes-
          sage.


key       This field  exists  in  the  corresponding  ticket
          passed by the KRB-CRED message and is used to pass
          the session key from the sender  to  the  intended
          recipient.   The  field's encoding is described in
          section 6.2.

     The following fields are optional.   If  present,  they
can  be associated with the credentials in the remote ticket
file.  If left out, then it is assumed that the recipient of
the credentials already knows their value.


prealm and pname


Section 5.8.1.             - 71 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


          The name and  realm  of  the  delegated  principal
          identity.


flags, authtime,  starttime,  endtime,  renew-till,  srealm,
          sname, and caddr
          These fields contain the values of the correspond-
          ing  fields  from  the  ticket found in the ticket
          field.  Descriptions of the fields  are  identical
          to the descriptions in the KDC-REP message.

5.9.  Error message specification

     This section specifies the  format  for  the  KRB_ERROR
message.  The fields included in the message are intended to
return as much information as possible about an  error.   It
is  not  expected  that  all the information required by the
fields will be available for all types of  errors.   If  the
appropriate information is not available when the message is
composed, the corresponding field will be left  out  of  the
message.

     Note that since the KRB_ERROR message is not  protected
by  any  encryption, it is quite possible for an intruder to
synthesize or modify such a message.   In  particular,  this
means that the client should not use any fields in this mes-
sage for security-critical purposes, such as setting a  sys-
tem  clock or generating a fresh authenticator.  The message
can be useful, however, for advising a user  on  the  reason
for some failure.

5.9.1.  KRB_ERROR definition

     The KRB_ERROR message consists of the following fields:

KRB-ERROR ::=   [APPLICATION 30] SEQUENCE {
                pvno[0]                       INTEGER,
                msg-type[1]                   INTEGER,
                ctime[2]                      KerberosTime OPTIONAL,
                cusec[3]                      INTEGER OPTIONAL,
                stime[4]                      KerberosTime,
                susec[5]                      INTEGER,
                error-code[6]                 INTEGER,
                crealm[7]                     Realm OPTIONAL,
                cname[8]                      PrincipalName OPTIONAL,
                realm[9]                      Realm, -- Correct realm
                sname[10]                     PrincipalName, -- Correct name
                e-text[11]                    GeneralString OPTIONAL,
                e-data[12]                    OCTET STRING OPTIONAL,
                e-cksum[13]                   Checksum OPTIONAL
}





Section 5.9.1.             - 72 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


pvno and msg-type
          These fields are described above in section 5.4.1.
          msg-type is KRB_ERROR.


ctime     This field is described above in section 5.4.1.



cusec     This field is described above in section 5.5.2.


stime     This  field  contains  the  current  time  on  the
          server.  It is of type KerberosTime.


susec     This field contains the microsecond  part  of  the
          server's  timestamp.   Its  value ranges from 0 to
          999999.  It appears  along  with  stime.  The  two
          fields  are  used in conjunction to specify a rea-
          sonably accurate timestamp.


error-codeThis field contains the  error  code  returned  by
          Kerberos  or  the server when a request fails.  To
          interpret the value of this field see the list  of
          error  codes  in  section  8.  Implementations are
          encouraged to provide for national  language  sup-
          port in the display of error messages.


crealm, cname, srealm and sname
          These fields are described above in section 5.3.1.


e-text    This  field  contains  additional  text  to   help
          explain  the error code associated with the failed
          request (for example, it might include a principal
          name which was unknown).


e-data     This field contains  additional  data  about  the
          error  for  use  by  the  application  to  help it
          recover from or handle the error.  If  the  error-
          code  is KDC_ERR_PREAUTH_REQUIRED, then the e-data
          field will contain an encoding of  a  sequence  of
          padata fields, each corresponding to an acceptable
          pre-authentication method and optionally  contain-
          ing data for the method:


e-cksum   This field contains an optional checksum  for  the
          KRB-ERROR  message.   The  checksum  is calculated
          over the Kerberos ASN.1 encoding of the  KRB-ERROR


Section 5.9.1.             - 73 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


          message with the checksum absent.  The checksum is
          then added to the KRB-ERROR structure and the mes-
          sage is re-encoded.  The Checksum should be calcu-
          lated using the session key from the ticket grant-
          ing ticket or service ticket, where available.  If
          the error is in response to a TGS or  AP  request,
          the  checksum  should  be  calculated uing the the
          session key from  the  client's  ticket.   If  the
          error  is  in  response to an AS request, then the
          checksum should be calulated  using  the  client's
          secret  key ONLY if there has been suitable preau-
          thentication to prove knowledge of the secret  key
          by the client[33].  If a checksum can not be  com-
          puted because the key to be used is not available,
          no checksum will be included.

               METHOD-DATA ::=   SEQUENCE of PA-DATA


          If the error-code is KRB_AP_ERR_METHOD,  then  the
          e-data  field will contain an encoding of the fol-
          lowing sequence:

       METHOD-DATA ::=   SEQUENCE {
                         method-type[0]   INTEGER,
                         method-data[1]   OCTET STRING OPTIONAL
       }

          method-type will indicate the  required  alternate
          method;  method-data  will  contain  any  required
          additional information.



6.  Encryption and Checksum Specifications

The  Kerberos  protocols  described  in  this  document  are
designed  to  use  stream  encryption  ciphers, which can be
simulated using commonly available block encryption ciphers,
such  as  the  Data Encryption Standard, [12] in conjunction
with block chaining and checksum methods  [13].   Encryption
is used to prove the identities of the network entities par-
ticipating  in  message  exchanges.   The  Key  Distribution
Center   for   each  realm  is  trusted  by  all  principals
registered in that realm to store a  secret  key  in  confi-
dence.   Proof  of  knowledge  of this secret key is used to
verify the authenticity of a principal.

     The KDC uses the principal's  secret  key  (in  the  AS
__________________________
[33] This prevents an attacker  who  generates  an  in-
correct  AS request from obtaining verifiable plaintext
for use in an off-line password guessing attack.


Section 6.                 - 74 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


exchange) or a shared session key (in the TGS  exchange)  to
encrypt  responses to ticket requests; the ability to obtain
the secret key or session key implies the knowledge  of  the
appropriate  keys  and the identity of the KDC.  The ability
of a principal to decrypt the KDC  response  and  present  a
Ticket  and  a properly formed Authenticator (generated with
the session key from the KDC response) to a service verifies
the  identity  of the principal; likewise the ability of the
service to extract the session key from the Ticket and prove
its knowledge thereof in a response verifies the identity of
the service.

     The  Kerberos  protocols  generally  assume  that   the
encryption  used  is  secure from cryptanalysis; however, in
some cases, the order of fields in the encrypted portions of
messages  are  arranged  to  minimize  the effects of poorly
chosen keys.  It is still important to choose good keys.  If
keys  are derived from user-typed passwords, those passwords
need to be well chosen to make brute force attacks more dif-
ficult.   Poorly  chosen  keys  still  make easy targets for
intruders.

     The  following  sections  specify  the  encryption  and
checksum  mechanisms  currently  defined  for Kerberos.  The
encodings, chaining, and padding requirements for  each  are
described.  For encryption methods, it is often desirable to
place random information (often referred to as a confounder)
at  the  start  of the message.  The requirements for a con-
founder are specified with each encryption mechanism.

     Some encryption systems use a block-chaining method  to
improve  the the security characteristics of the ciphertext.
However, these  chaining  methods  often  don't  provide  an
integrity  check upon decryption.  Such systems (such as DES
in CBC mode) must be augmented with a checksum of the plain-
text  which can be verified at decryption and used to detect
any tampering or damage.  Such checksums should be  good  at
detecting  burst  errors  in  the  input.   If any damage is
detected, the decryption routine is expected  to  return  an
error  indicating  the  failure of an integrity check.  Each
encryption  type  is  expected  to  provide  and  verify  an
appropriate  checksum.  The specification of each encryption
method sets out its checksum requirements.

     Finally, where a key is to be  derived  from  a  user's
password,  an algorithm for converting the password to a key
of the appropriate type is included.  It  is  desirable  for
the  string  to key function to be one-way, and for the map-
ping to be different in different realms.  This is important
because users who are registered in more than one realm will
often use the same password in each,  and  it  is  desirable
that  an  attacker  compromising  the Kerberos server in one
realm not obtain or derive the user's key in another.



Section 6.                 - 75 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


     For an discussion of the integrity  characteristics  of
the candidate encryption and checksum methods considered for
Kerberos, the the reader is referred to [14].

6.1.  Encryption Specifications

     The following ASN.1 definition describes all  encrypted
messages.   The  enc-part  field  which appears in the unen-
crypted part of messages in section 5 is a sequence consist-
ing  of  an encryption type, an optional key version number,
and the ciphertext.


EncryptedData ::=   SEQUENCE {
                    etype[0]     INTEGER, -- EncryptionType
                    kvno[1]      INTEGER OPTIONAL,
                    cipher[2]    OCTET STRING -- ciphertext
}


etype     This field identifies which  encryption  algorithm
          was used to encipher the cipher.  Detailed specif-
          ications  for  selected  encryption  types  appear
          later in this section.


kvno      This field contains the version number of the  key
          under which data is encrypted.  It is only present
          in messages encrypted  under  long  lasting  keys,
          such as principals' secret keys.


cipher    This field contains the enciphered  text,  encoded
          as an OCTET STRING.


     The cipher field is generated by applying the specified
encryption  algorithm  to  data  composed of the message and
algorithm-specific inputs.   Encryption  mechanisms  defined
for  use  with  Kerberos  must  take  sufficient measures to
guarantee the integrity of the plaintext, and  we  recommend
they  also take measures to protect against precomputed dic-
tionary attacks.  If the encryption algorithm is not  itself
capable  of  doing so, the protections can often be enhanced
by adding a checksum and a confounder.

     The suggested format  for  the  data  to  be  encrypted
includes  a  confounder,  a checksum, the encoded plaintext,
and any necessary padding.  The msg-seq field  contains  the
part of the protocol message described in section 5 which is
to be encrypted.  The confounder, checksum, and padding  are
all untagged and untyped, and their length is exactly suffi-
cient to hold the appropriate item.  The type and length  is
implicit  and  specified  by  the particular encryption type


Section 6.1.               - 76 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


being used (etype).  The format for the data to be encrypted
is described in the following diagram:

      +-----------+----------+-------------+-----+
      |confounder |   check  |   msg-seq   | pad |
      +-----------+----------+-------------+-----+

The format cannot be described in ASN.1, but for  those  who
prefer an ASN.1-like notation:

CipherText ::=   ENCRYPTED       SEQUENCE {
            confounder[0]   UNTAGGED[35] OCTET STRING(conf_length) OPTIONAL,
            check[1]        UNTAGGED OCTET STRING(checksum_length) OPTIONAL,
            msg-seq[2]      MsgSequence,
            pad             UNTAGGED OCTET STRING(pad_length) OPTIONAL
}


     One generates a random confounder  of  the  appropriate
length,  placing  it in confounder; zeroes out check; calcu-
lates the appropriate checksum over confounder,  check,  and
msg-seq,  placing  the  result  in check; adds the necessary
padding; then encrypts using the specified  encryption  type
and the appropriate key.

     Unless otherwise specified, a definition of an  encryp-
tion  algorithm  that specifies a checksum, a length for the
confounder field, or an octet boundary for padding uses this
ciphertext format[36].  Those fields which are not specified
will be omitted.

     In the interest of allowing all implementations using a
__________________________
[35] In  the  above   specification,   UNTAGGED   OCTET
STRING(length) is the notation for an octet string with
its tag and length removed.  It is not  a  valid  ASN.1
type.  The tag bits and length must be removed from the
confounder since the purpose of the  confounder  is  so
that  the  message starts with random data, but the tag
and its length are fixed.  For other fields, the length
and  tag  would  be redundant if they were included be-
cause they are specified by the encryption type.
[36] The  ordering  of  the fields in the CipherText is
important.  Additionally, messages encoded in this for-
mat must include a length as part of the msg-seq field.
This allows the recipient to verify  that  the  message
has  not been truncated.  Without a length, an attacker
could use a chosen plaintext attack to generate a  mes-
sage which could be truncated, while leaving the check-
sum intact.  Note that if the msg-seq is an encoding of
an  ASN.1  SEQUENCE or OCTET STRING, then the length is
part of that encoding.



Section 6.1.               - 77 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


particular encryption type to communicate  with  all  others
using  that  type,  the  specification of an encryption type
defines any checksum that is needed as part of  the  encryp-
tion  process.   If an alternative checksum is to be used, a
new encryption type must be defined.

     Some  cryptosystems  require   additional   information
beyond  the  key and the data to be encrypted.  For example,
DES, when used in cipher-block-chaining  mode,  requires  an
initialization  vector.   If  required,  the description for
each encryption type must specify the source of  such  addi-
tional information.

6.2.  Encryption Keys

     The sequence below shows the encoding of an  encryption
key:

       EncryptionKey ::=   SEQUENCE {
                           keytype[0]    INTEGER,
                           keyvalue[1]   OCTET STRING
       }


keytype   This field specifies the type  of  encryption  key
          that  follows  in  the  keyvalue  field.   It will
          almost always correspond to the  encryption  algo-
          rithm  used  to generate the EncryptedData, though
          more than one algorithm may use the same  type  of
          key (the mapping is many to one).  This might hap-
          pen, for example, if the encryption algorithm uses
          an  alternate  checksum algorithm for an integrity
          check, or a different chaining mechanism.


keyvalue  This field contains the key itself, encoded as  an
          octet string.

     All negative values for the  encryption  key  type  are
reserved   for  local  use.   All  non-negative  values  are
reserved for officially assigned type fields and interpreta-
tions.

6.3.  Encryption Systems

6.3.1.  The NULL Encryption System (null)

     If no encryption is in use, the  encryption  system  is
said  to be the NULL encryption system.  In the NULL encryp-
tion system there is no  checksum,  confounder  or  padding.
The  ciphertext  is  simply  the plaintext.  The NULL Key is
used by the null encryption system and  is  zero  octets  in
length, with keytype zero (0).



Section 6.3.1.             - 78 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


6.3.2.  DES in CBC mode with a CRC-32 checksum (des-cbc-crc)

     The des-cbc-crc encryption  mode  encrypts  information
under  the  Data  Encryption Standard  [12] using the cipher
block chaining mode [13].  A CRC-32 checksum  (described  in
ISO  3309  [15])  is  applied  to the confounder and message
sequence (msg-seq) and  placed  in  the  cksum  field.   DES
blocks  are  8 bytes.  As a result, the data to be encrypted
(the concatenation of  confounder,  checksum,  and  message)
must be padded to an 8 byte boundary before encryption.  The
details of the encryption of  this  data  are  identical  to
those for the des-cbc-md5 encryption mode.

     Note that, since the CRC-32 checksum is not  collision-
proof,   an  attacker  could  use  a  probabilistic  chosen-
plaintext attack to generate a valid message even if a  con-
founder is used  [14].  The use of collision-proof checksums
is recommended for environments where such attacks represent
a significant threat.  The use of the CRC-32 as the checksum
for ticket or authenticator is  no  longer  mandated  as  an
interoperability requirement for Kerberos Version 5 Specifi-
cation 1 (See section 9.1 for specific details).


6.3.3.  DES in CBC mode with an MD4 checksum (des-cbc-md4)

     The des-cbc-md4 encryption  mode  encrypts  information
under  the  Data  Encryption Standard  [12] using the cipher
block chaining mode [13].  An  MD4  checksum  (described  in
[16])  is  applied  to  the  confounder and message sequence
(msg-seq) and placed in the cksum field.  DES blocks  are  8
bytes.   As a result, the data to be encrypted (the concate-
nation of confounder, checksum, and message) must be  padded
to an 8 byte boundary before encryption.  The details of the
encryption of this data are identical to those for the  des-
cbc-md5 encryption mode.


6.3.4.  DES in CBC mode with an MD5 checksum (des-cbc-md5)

     The des-cbc-md5 encryption  mode  encrypts  information
under  the  Data  Encryption Standard  [12] using the cipher
block chaining mode [13].  An MD5  checksum   (described  in
[17].)  is  applied  to  the confounder and message sequence
(msg-seq) and placed in the cksum field.  DES blocks  are  8
bytes.   As a result, the data to be encrypted (the concate-
nation of confounder, checksum, and message) must be  padded
to an 8 byte boundary before encryption.

     Plaintext and DES ciphtertext are  encoded  as  8-octet
blocks  which are concatenated to make the 64-bit inputs for
the DES algorithms.  The first octet  supplies  the  8  most
significant  bits  (with  the  octet's MSbit used as the DES
input block's MSbit, etc.), the  second  octet  the  next  8


Section 6.3.4.             - 79 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


bits,  ..., and the eighth octet supplies the 8 least signi-
ficant bits.

     Encryption  under  DES  using  cipher  block   chaining
requires  an  additional input in the form of an initializa-
tion vector.  Unless otherwise  specified,  zero  should  be
used  as  the  initialization  vector.  Kerberos' use of DES
requires an 8-octet confounder.

     The DES specifications identify some "weak" and  "semi-
weak" keys; those keys shall not be used for encrypting mes-
sages for use in Kerberos.  Additionally, because of the way
that  keys are derived for the encryption of checksums, keys
shall not be used that yield "weak" or "semi-weak" keys when
eXclusive-ORed with the constant F0F0F0F0F0F0F0F0.

     A DES key is 8 octets of data, with  keytype  one  (1).
This  consists of 56 bits of key, and 8 parity bits (one per
octet).  The key is encoded as a series of 8 octets  written
in  MSB-first  order.   The  bits  within  the  key are also
encoded in MSB order.  For example, if the encryption key is
(B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8)
where B1,B2,...,B56 are the  key  bits  in  MSB  order,  and
P1,P2,...,P8 are the parity bits, the first octet of the key
would be B1,B2,...,B7,P1 (with B1 as the MSbit).   [See  the
FIPS 81 introduction for reference.]

     To generate a DES key from a  text  string  (password),
the  text  string normally must have the realm and each com-
ponent of the principal's  name  appended[37],  then  padded
with ASCII nulls to an 8 byte boundary.  This string is then
fan-folded and eXclusive-ORed with itself to form an 8  byte
DES key.  The parity is corrected on the key, and it is used
to generate a DES CBC checksum on the initial  string  (with
the  realm and name appended).  Next, parity is corrected on
the CBC checksum.  If the result matches a "weak" or  "semi-
weak"  key  as  described  in  the  DES specification, it is
eXclusive-ORed with the constant 00000000000000F0.  Finally,
the result is returned as the key.  Pseudocode follows:

     string_to_key(string,realm,name) {
          odd = 1;
          s = string + realm;
          for(each component in name) {
               s = s + component;
          }
          tempkey = NULL;
          pad(s); /* with nulls to 8 byte boundary */
          for(8byteblock in s) {
__________________________
[37] In some cases, it may be necessary to use  a  dif-
ferent  "mix-in"  string for compatibility reasons; see
the discussion of padata in section 5.4.2.


Section 6.3.4.             - 80 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


               if(odd == 0)  {
                   odd = 1;
                   reverse(8byteblock)
               }
               else odd = 0;
               tempkey = tempkey XOR 8byteblock;
          }
          fixparity(tempkey);
          key = DES-CBC-check(s,tempkey);
          fixparity(key);
          if(is_weak_key_key(key))
               key = key XOR 0xF0;
          return(key);
     }

6.3.5.  Triple DES EDE in outer CBC mode with an SHA1 check-
sum (des3-cbc-sha1)

     The des3-cbc-sha1 encryption encodes information  using
three  Data  Encryption  Standard transformations with three
DES keys.  The first key  is  used  to  perform  a  DES  ECB
encryption  on an eight-octet data block using the first DES
key, followed by a DES ECB decryption of  the  result  using
the  second  DES key, and a DES ECB encryption of the result
using the third DES key.  Because DES blocks  are  8  bytes,
the  data  to be encrypted (the concatenation of confounder,
checksum, and message) must first be padded  to  an  8  byte
boundary  before encryption.  To support the outer CBC mode,
the input is padded an eight-octet boundary.   The  first  8
octets  of  the  data  to  be  encrypted (the confounder) is
exclusive-ored with an initialization  vector  of  zero  and
then  ECB  encrypted  using  triple  DES as described above.
Subsequent blocks of 8 octets are  exclusive-ored  with  the
ciphertext  produced by the encryption on the previous block
before ECB encryption.

     An HMAC-SHA1 checksum  (described in  [18].) is applied
to  the confounder and message sequence (msg-seq) and placed
in the cksum field.

     Plaintext  are encoded as 8-octet blocks which are con-
catenated  to make the 64-bit inputs for the DES algorithms.
The first octet supplies the 8 most significant  bits  (with
the  octet's  MSbit  used  as  the  DES input block's MSbit,
etc.), the second octet the next 8 bits, ..., and the eighth
octet supplies the 8 least significant bits.

     Encryption under Triple DES using cipher block chaining
requires  an  additional input in the form of an initializa-
tion vector.  Unless otherwise  specified,  zero  should  be
used  as  the  initialization  vector.  Kerberos' use of DES
requires an 8-octet confounder.

     The DES specifications identify some "weak" and  "semi-


Section 6.3.5.             - 81 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


weak" keys; those keys shall not be used for encrypting mes-
sages for use in Kerberos.  Additionally, because of the way
that  keys are derived for the encryption of checksums, keys
shall not be used that yield "weak" or "semi-weak" keys when
eXclusive-ORed with the constant F0F0F0F0F0F0F0F0.

     A Triple DES key is 24 octets  of  data,  with  keytype
seven  (7).  This consists of 168 bits of key, and 24 parity
bits (one per octet).  The key is encoded as a series of  24
octets  written  in MSB-first order, with the first 8 octets
treated as the first DES key, the second  8  octets  as  the
second  key,  and the third 8 octets the third DES key.  The
bits within each key are also encoded  in  MSB  order.   For
example,       if       the      encryption      key      is
(B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8)
where  B1,B2,...,B56  are  the  key  bits  in MSB order, and
P1,P2,...,P8 are the parity bits, the first octet of the key
would  be  B1,B2,...,B7,P1 (with B1 as the MSbit).  [See the
FIPS 81 introduction for reference.]

     To generate a DES key from a  text  string  (password),
the  text  string normally must have the realm and each com-
ponent of the principal's name appended[38],

     The input string (with any salt data appended to it) is
n-folded  into  a  24  octet  (192 bit) string.  To n-fold a
number X, replicate the input value to a length that is  the
least common multiple of n and the length of X.  Before each
repetition, the input X is rotated to the right  by  13  bit
positions.   The  successive n-bit chunks are added together
using  1's-complement  addition  (addition  with  end-around
carry)  to  yield  a  n-bit result. (This transformation was
proposed by Richard Basch)

     Each successive set of 8 octets is taken as a DES  key,
and  its parity is adjusted in the same manner as previously
described.  If any of the three sets of  8  octets  match  a
"weak" or "semi-weak" key as described in the DES specifica-
tion,  that  chunk  is  eXclusive-ORed  with  the   constant
00000000000000F0.   The  resulting DES keys are then used in
sequence to perform a Triple-DES CBC encryption  of  the  n-
folded  input  string (appended with any salt data), using a
zero initial vector.  Parity, weak, and semi-weak  keys  are
once  again  corrected  and the result is returned as the 24
octet key.

     Pseudocode follows:

     string_to_key(string,realm,name) {
__________________________
[38] In some cases, it may be necessary to use  a  dif-
ferent  "mix-in"  string for compatibility reasons; see
the discussion of padata in section 5.4.2.


Section 6.3.5.             - 82 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


          s = string + realm;
          for(each component in name) {
               s = s + component;
          }
          tkey[24] = fold(s);
          fixparity(tkey);
          if(isweak(tkey[0-7])) tkey[0-7] = tkey[0-7] XOR 0xF0;
          if(isweak(tkey[8-15])) tkey[8-15] = tkey[8-15] XOR 0xF0;
          if(is_weak(tkey[16-23])) tkey[16-23] = tkey[16-23] XOR 0xF0;
          key[24] = 3DES-CBC(data=fold(s),key=tkey,iv=0);
          fixparity(key);
          if(is_weak(key[0-7])) key[0-7] = key[0-7] XOR 0xF0;
          if(is_weak(key[8-15])) key[8-15] = key[8-15] XOR 0xF0;
          if(is_weak(key[16-23])) key[16-23] = key[16-23] XOR 0xF0;
          return(key);
     }

6.4.  Checksums

     The following is the ASN.1 definition used for a check-
sum:

         Checksum ::=   SEQUENCE {
                        cksumtype[0]   INTEGER,
                        checksum[1]    OCTET STRING
         }


cksumtype This field indicates the algorithm  used  to  gen-
          erate the accompanying checksum.

checksum  This field contains the checksum  itself,  encoded
          as an octet string.

     Detailed  specification  of  selected  checksum   types
appear  later  in  this  section.   Negative  values for the
checksum type are reserved for local use.  All  non-negative
values  are reserved for officially assigned type fields and
interpretations.

     Checksums used by Kerberos can  be  classified  by  two
properties:   whether  they are collision-proof, and whether
they are keyed.  It is infeasible  to  find  two  plaintexts
which generate the same checksum value for a collision-proof
checksum.  A key is required to perturb  or  initialize  the
algorithm  in  a  keyed checksum.  To prevent message-stream
modification by an active attacker, unkeyed checksums should
only  be  used  when the checksum and message will be subse-
quently encrypted (e.g. the checksums defined as part of the
encryption algorithms covered earlier in this section).

     Collision-proof checksums can be made  tamper-proof  if
the  checksum  value is encrypted before inclusion in a mes-
sage.  In such cases, the composition of  the  checksum  and


Section 6.4.               - 83 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


the  encryption  algorithm  must  be  considered  a separate
checksum algorithm (e.g. RSA-MD5 encrypted using  DES  is  a
new checksum algorithm of type RSA-MD5-DES).  For most keyed
checksums, as well as for the  encrypted  forms  of  unkeyed
collision-proof  checksums,  Kerberos  prepends a confounder
before the checksum is calculated.

6.4.1.  The CRC-32 Checksum (crc32)

     The CRC-32 checksum calculates a checksum  based  on  a
cyclic  redundancy check as described in ISO 3309 [15].  The
resulting checksum is four (4) octets in length.  The CRC-32
is  neither  keyed  nor  collision-proof.   The  use of this
checksum is not recommended.  An  attacker  using  a  proba-
bilistic  chosen-plaintext attack as described in [14] might
be able to generate an alternative  message  that  satisfies
the  checksum.   The  use  of  collision-proof  checksums is
recommended for environments where such attacks represent  a
significant threat.

6.4.2.  The RSA MD4 Checksum (rsa-md4)

     The RSA-MD4 checksum calculates a  checksum  using  the
RSA  MD4  algorithm  [16].   The algorithm takes as input an
input message of arbitrary length and produces as  output  a
128-bit  (16  octet)  checksum.   RSA-MD4  is believed to be
collision-proof.

6.4.3.  RSA MD4 Cryptographic Checksum Using  DES  (rsa-md4-
des)

     The RSA-MD4-DES checksum calculates a keyed  collision-
proof  checksum  by  prepending an 8 octet confounder before
the text, applying  the  RSA  MD4  checksum  algorithm,  and
encrypting  the  confounder  and  the  checksum using DES in
cipher-block-chaining (CBC) mode using a variant of the key,
where  the  variant  is  computed by eXclusive-ORing the key
with the constant F0F0F0F0F0F0F0F0[39].  The  initialization
vector  should be zero.  The resulting checksum is 24 octets
long (8 octets of which are redundant).   This  checksum  is
tamper-proof and believed to be collision-proof.

     The DES specifications identify some  "weak  keys"  and
__________________________
[39] A variant of the key is used to limit the use of a
key  to a particular function, separating the functions
of generating a checksum  from  other  encryption  per-
formed   using   the   session   key.    The   constant
F0F0F0F0F0F0F0F0 was chosen because  it  maintains  key
parity.  The properties of DES precluded the use of the
complement.  The same constant is used for similar pur-
pose  in  the  Message  Integrity  Check in the Privacy
Enhanced Mail standard.


Section 6.4.3.             - 84 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


"semi-weak keys"; those keys shall not be used for  generat-
ing RSA-MD4 checksums for use in Kerberos.

     The format for the checksum is described in the follow-
ing diagram:

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  des-cbc(confounder   +   rsa-md4(confounder+msg),key=var(key),iv=0)  |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The format cannot be described in ASN.1, but for  those  who
prefer an ASN.1-like notation:

rsa-md4-des-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
                           confounder[0]   UNTAGGED OCTET STRING(8),
                           check[1]        UNTAGGED OCTET STRING(16)
}



6.4.4.  The RSA MD5 Checksum (rsa-md5)

     The RSA-MD5 checksum calculates a  checksum  using  the
RSA  MD5  algorithm.  [17].  The algorithm takes as input an
input message of arbitrary length and produces as  output  a
128-bit  (16  octet)  checksum.   RSA-MD5  is believed to be
collision-proof.

6.4.5.  RSA MD5 Cryptographic Checksum Using  DES  (rsa-md5-
des)

     The RSA-MD5-DES checksum calculates a keyed  collision-
proof  checksum  by  prepending an 8 octet confounder before
the text, applying  the  RSA  MD5  checksum  algorithm,  and
encrypting  the  confounder  and  the  checksum using DES in
cipher-block-chaining (CBC) mode using a variant of the key,
where  the  variant  is  computed by eXclusive-ORing the key
with the constant F0F0F0F0F0F0F0F0.  The initialization vec-
tor  should  be  zero.   The resulting checksum is 24 octets
long (8 octets of which are redundant).   This  checksum  is
tamper-proof and believed to be collision-proof.

     The DES specifications identify some  "weak  keys"  and
"semi-weak  keys"; those keys shall not be used for encrypt-
ing RSA-MD5 checksums for use in Kerberos.

     The format for the checksum is described in the follow-
ing diagram:

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  des-cbc(confounder   +   rsa-md5(confounder+msg),key=var(key),iv=0)  |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The format cannot be described in ASN.1, but for  those  who


Section 6.4.5.             - 85 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


prefer an ASN.1-like notation:

rsa-md5-des-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
                           confounder[0]   UNTAGGED OCTET STRING(8),
                           check[1]        UNTAGGED OCTET STRING(16)
}


6.4.6.  DES cipher-block chained checksum (des-mac)

     The DES-MAC checksum is computed  by  prepending  an  8
octet confounder to the plaintext, performing a DES CBC-mode
encryption on the result using the key and an initialization
vector  of  zero,  taking  the last block of the ciphertext,
prepending the same confounder and encrypting the pair using
DES in cipher-block-chaining (CBC) mode using a a variant of
the key, where the variant is  computed  by  eXclusive-ORing
the key with the constant F0F0F0F0F0F0F0F0.  The initializa-
tion vector should be zero.  The resulting checksum  is  128
bits (16 octets) long, 64 bits of which are redundant.  This
checksum is tamper-proof and collision-proof.

     The format for the checksum is described in the follow-
ing diagram:

+--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
|   des-cbc(confounder  + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) |
+--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+

The format cannot be described in ASN.1, but for  those  who
prefer an ASN.1-like notation:

des-mac-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
                       confounder[0]   UNTAGGED OCTET STRING(8),
                       check[1]        UNTAGGED OCTET STRING(8)
}


     The DES specifications identify some "weak" and  "semi-
weak"  keys;  those  keys  shall  not be used for generating
DES-MAC checksums for use in Kerberos, nor shall  a  key  be
used whose variant is "weak" or "semi-weak".

6.4.7.  RSA MD4 Cryptographic Checksum Using DES alternative
(rsa-md4-des-k)

     The   RSA-MD4-DES-K   checksum   calculates   a   keyed
collision-proof  checksum  by  applying the RSA MD4 checksum
algorithm and encrypting the results using  DES  in  cipher-
block-chaining  (CBC)  mode  using a DES key as both key and
initialization vector.  The resulting checksum is 16  octets
long.   This  checksum  is  tamper-proof  and believed to be
collision-proof.  Note that this checksum type  is  the  old
method  for  encoding  the RSA-MD4-DES checksum and it is no


Section 6.4.7.             - 86 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


longer recommended.

6.4.8.  DES cipher-block chained checksum alternative  (des-
mac-k)

     The DES-MAC-K checksum is computed by performing a  DES
CBC-mode  encryption  of  the  plaintext, and using the last
block of the ciphertext as the checksum value.  It is  keyed
with  an  encryption  key  and an initialization vector; any
uses which do not specify an additional initialization  vec-
tor  will use the key as both key and initialization vector.
The resulting checksum is 64 bits  (8  octets)  long.   This
checksum  is  tamper-proof  and  collision-proof.  Note that
this checksum type is the old method for encoding  the  DES-
MAC checksum and it is no longer recommended.

     The DES specifications identify some  "weak  keys"  and
"semi-weak  keys"; those keys shall not be used for generat-
ing DES-MAC checksums for use in Kerberos.

7.  Naming Constraints


7.1.  Realm Names

     Although realm names are encoded as GeneralStrings  and
although a realm can technically select any name it chooses,
interoperability across realm boundaries requires  agreement
on  how realm names are to be assigned, and what information
they imply.

     To enforce these conventions, each realm  must  conform
to  the  conventions  itself,  and  it must require that any
realms with which inter-realm keys are shared  also  conform
to the conventions and require the same from its neighbors.

     Kerberos realm names are case sensitive.   Realm  names
that  differ  only  in  the  case  of the characters are not
equivalent.  There are presently four styles of realm names:
domain,  X500,  other, and reserved.  Examples of each style
follow:

     domain:   ATHENA.MIT.EDU (example)
       X500:   C=US/O=OSF (example)
      other:   NAMETYPE:rest/of.name=without-restrictions (example)
   reserved:   reserved, but will not conflict with above


Domain names must look like domain names:  they  consist  of
components separated by periods (.) and they contain neither
colons (:) nor slashes (/).  Domain names must be  converted
to upper case when used as realm names.

     X.500 names contain an equal (=) and cannot  contain  a


Section 7.1.               - 87 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


colon (:) before the equal.  The realm names for X.500 names
will be string representations of the names with  components
separated by slashes.  Leading and trailing slashes will not
be included.

     Names that fall into the other category must begin with
a  prefix  that  contains no equal (=) or period (.) and the
prefix must be followed by a colon (:) and the rest  of  the
name.   All  prefixes  must  be  assigned before they may be
used.  Presently none are assigned.

     The reserved category includes  strings  which  do  not
fall  into  the  first  three categories.  All names in this
category are reserved.  It is unlikely that  names  will  be
assigned  to  this  category  unless  there is a very strong
argument for not using the "other" category.

     These rules guarantee that there will be  no  conflicts
between  the  various name styles.  The following additional
constraints apply to the assignment of realm  names  in  the
domain  and  X.500  categories:  the name of a realm for the
domain or X.500 formats must either be used by the organiza-
tion  owning  (to  whom  it was assigned) an Internet domain
name or X.500 name, or in the case that no  such  names  are
registered,  authority  to  use  a realm name may be derived
from the authority of the  parent  realm.  For  example,  if
there  is  no domain name for E40.MIT.EDU, then the adminis-
trator of the MIT.EDU realm can authorize the creation of  a
realm with that name.

     This is acceptable because the  organization  to  which
the  parent  is  assigned  is  presumably  the  organization
authorized to assign names to its children in the X.500  and
domain  name systems as well.  If the parent assigns a realm
name without also registering it in the domain name or X.500
hierarchy,  it  is  the parent's responsibility to make sure
that there will not in the future exists a name identical to
the  realm  name  of  the child unless it is assigned to the
same entity as the realm name.


7.2.  Principal Names

     As was the case for realm names, conventions are needed
to ensure that all agree on what information is implied by a
principal name.  The name-type field that  is  part  of  the
principal  name indicates the kind of information implied by
the name.  The  name-type  should  be  treated  as  a  hint.
Ignoring  the  name type, no two names can be the same (i.e.
at least one of the components, or the realm, must  be  dif-
ferent).   This  constraint may be eliminated in the future.
The following name types are defined:

                    name-type      value   meaning


Section 7.2.               - 88 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


   NT-UNKNOWN     0   Name type not known
   NT-PRINCIPAL   1   General principal name (e.g. username, or DCE principal)
   NT-SRV-INST    2   Service and other unique instance (krbtgt)
   NT-SRV-HST     3   Service with host name as instance (telnet, rcommands)
   NT-SRV-XHST    4   Service with slash-separated host name components
   NT-UID         5   Unique ID


When a name implies no information other than its uniqueness
at a particular time the name type PRINCIPAL should be used.
The principal name type should be used  for  users,  and  it
might  also  be  used for a unique server.  If the name is a
unique machine generated ID that is guaranteed never  to  be
reassigned  then  the  name type of UID should be used (note
that it is generally a bad idea to  reassign  names  of  any
type  since  stale  entries  might  remain in access control
lists).

     If the first component of a name identifies  a  service
and  the  remaining  components  identify an instance of the
service in a server specified manner, then the name type  of
SRV-INST  should  be  used.  An example of this name type is
the Kerberos ticket-granting service whose name has a  first
component  of  krbtgt and a second component identifying the
realm for which the ticket is valid.

     If instance is a single component following the service
name  and  the  instance  identifies  the  host on which the
server is running, then the  name  type  SRV-HST  should  be
used.   This  type  is  typically used for Internet services
such as telnet and the Berkeley R commands.  If the separate
components  of the host name appear as successive components
following the name of the service, then the name  type  SRV-
XHST  should  be  used.  This type might be used to identify
servers on hosts with X.500 names where the slash (/)  might
otherwise be ambiguous.

     A name type of UNKNOWN should be used when the form  of
the name is not known.  When comparing names, a name of type
UNKNOWN will match principals authenticated  with  names  of
any  type.   A  principal  authenticated with a name of type
UNKNOWN, however, will only match other names of  type  UNK-
NOWN.

     Names of any type with an initial component of "krbtgt"
are  reserved for the Kerberos ticket granting service.  See
section 8.2.3 for the form of such names.

7.2.1.  Name of server principals

     The principal identifier for a server on  a  host  will
generally be composed of two parts: (1) the realm of the KDC
with which the server is registered, and (2) a two-component


Section 7.2.1.             - 89 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


name  of  type  NT-SRV-HST  if  the host name is an Internet
domain name or a multi-component name of type NT-SRV-XHST if
the  name of the host is of a form such as X.500 that allows
slash (/) separators.  The first component of  the  two-  or
multi-component  name  will  identify  the  service  and the
latter components will identify the host.  Where the name of
the  host  is not case sensitive (for example, with Internet
domain names) the name of the host must be lower  case.   If
specified  by  the application protocol for services such as
telnet and the Berkeley R commands  which  run  with  system
privileges,  the  first  component  may be the string "host"
instead of a service specific identifier.  When a  host  has
an  official name and one or more aliases, the official name
of the host must be used when constructing the name  of  the
server principal.

8.  Constants and other defined values


8.1.  Host address types

     All negative values  for  the  host  address  type  are
reserved   for  local  use.   All  non-negative  values  are
reserved for officially assigned type fields and interpreta-
tions.

     The values of the types for the following addresses are
chosen  to match the defined address family constants in the
Berkeley Standard Distributions of Unix.  They can be  found
in  <sys/socket.h>  with symbolic names AF_xxx (where xxx is
an abbreviation of the address family name).


Internet addresses

     Internet addresses  are  32-bit  (4-octet)  quantities,
encoded in MSB order.  The type of internet addresses is two
(2).

CHAOSnet addresses

     CHAOSnet addresses  are  16-bit  (2-octet)  quantities,
encoded  in  MSB  order.   The type of CHAOSnet addresses is
five (5).

ISO addresses

     ISO addresses are variable-length.   The  type  of  ISO
addresses is seven (7).

Xerox Network Services (XNS) addresses

     XNS addresses are 48-bit (6-octet) quantities,  encoded
in MSB order.  The type of XNS addresses is six (6).


Section 8.1.               - 90 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


AppleTalk Datagram Delivery Protocol (DDP) addresses

     AppleTalk DDP addresses consist of an 8-bit node number
and a 16-bit network number.  The first octet of the address
is the node number; the remaining two octets encode the net-
work  number  in  MSB  order.   The  type  of  AppleTalk DDP
addresses is sixteen (16).

DECnet Phase IV addresses

     DECnet Phase IV addresses are 16-bit addresses, encoded
in  LSB  order.   The  type  of DECnet Phase IV addresses is
twelve (12).

8.2.  KDC messages

8.2.1.  IP transport

     When  contacting  a  Kerberos  server   (KDC)   for   a
KRB_KDC_REQ request using UDP IP transport, the client shall
send a UDP datagram  containing  only  an  encoding  of  the
request  to  port  88 (decimal) at the KDC's IP address; the
KDC will respond with a reply datagram  containing  only  an
encoding  of  the  reply  message  (either  a KRB_ERROR or a
KRB_KDC_REP) to the sending port at the sender's IP address.

     Kerberos servers supporting IP  transport  must  accept
UDP  requests on port 88 (decimal).  Servers may also accept
TCP requests on port 88  (decimal).   When  the  KRB_KDC_REQ
message  is sent to the KDC by TCP, a new connection will be
established  for  each  authentication  exchange   and   the
KRB_KDC_REP  or  KRB_ERROR  message  will be returned to the
client on the  TCP  stream  that  was  established  for  the
request.   The connection will be broken after the reply has
been received (or upon time-out).  Care  must  be  taken  in
managing  TCP/IP  connections with the KDC to prevent denial
of service attacks based on the number of TCP/IP connections
with the KDC that remain open.

8.2.2.  OSI transport

     During authentication  of  an  OSI  client  to  an  OSI
server, the mutual authentication of an OSI server to an OSI
client, the transfer of credentials from an OSI client to an
OSI  server,  or  during  exchange  of  private or integrity
checked messages, Kerberos protocol messages may be  treated
as opaque objects and the type of the authentication mechan-
ism will be:

OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), security(5),
                       kerberosv5(2)} 

Depending on the situation, the opaque  object  will  be  an
authentication  header (KRB_AP_REQ), an authentication reply
(KRB_AP_REP), a safe message (KRB_SAFE), a  private  message


Section 8.2.2.             - 91 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


(KRB_PRIV), or a credentials message (KRB_CRED).  The opaque
data contains an application code as specified in the  ASN.1
description  for  each message.  The application code may be
used by Kerberos to determine the message type.

8.2.3.  Name of the TGS

     The principal identifier of the ticket-granting service
shall  be  composed of three parts: (1) the realm of the KDC
issuing the TGS ticket (2) a two-part name of  type  NT-SRV-
INST,  with  the first part "krbtgt" and the second part the
name of the realm  which  will  accept  the  ticket-granting
ticket.  For example, a ticket-granting ticket issued by the
ATHENA.MIT.EDU realm to be used  to  get  tickets  from  the
ATHENA.MIT.EDU   KDC   has   a   principal   identifier   of
"ATHENA.MIT.EDU"   (realm),   ("krbtgt",   "ATHENA.MIT.EDU")
(name).     A   ticket-granting   ticket   issued   by   the
ATHENA.MIT.EDU realm to be used  to  get  tickets  from  the
MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU"
(realm), ("krbtgt", "MIT.EDU") (name).


8.3.  Protocol constants and associated values

The following tables list constants used in the protocol and defines their
meanings.

Encryption type  etype value  block size    minimum pad size  confounder size
NULL              0            1                 0                 0
des-cbc-crc       1            8                 4                 8
des-cbc-md4       2            8                 0                 8
des-cbc-md5       3            8                 0                 8
<reserved>        4
des3-cbc-md5      5            8                 0                 8
<reserved>        6
des3-cbc-sha1     7            8                 0                 8
sign-dsa-generate 8                                   (pkinit)
encrypt-rsa-priv  9                                   (pkinit)
encrypt-rsa-pub  10                                   (pkinit)
ENCTYPE_PK_CROSS 48                                   (reserved for pkcross)
<reserved>       0x8003

Checksum type              sumtype value       checksum size
CRC32                      1                   4
rsa-md4                    2                   16
rsa-md4-des                3                   24
des-mac                    4                   16
des-mac-k                  5                   8
rsa-md4-des-k              6                   16
rsa-md5                    7                   16
rsa-md5-des                8                   24
rsa-md5-des3               9                   24
hmac-sha1-des3             10                  20  (I had this as 10, is it 12)


Section 8.3.               - 92 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


padata type                     padata-type value

PA-TGS-REQ                      1
PA-ENC-TIMESTAMP                2
PA-PW-SALT                      3
<reserved>                      4
PA-ENC-UNIX-TIME                5
PA-SANDIA-SECUREID              6
PA-SESAME                       7
PA-OSF-DCE                      8
PA-CYBERSAFE-SECUREID           9
PA-AFS3-SALT                    10
PA-ETYPE-INFO                   11
SAM-CHALLENGE                   12                  (sam/otp)
SAM-RESPONSE                    13                  (sam/otp)
PA-PK-AS-REQ                    14                  (pkinit)
PA-PK-AS-REP                    15                  (pkinit)
PA-PK-AS-SIGN                   16                  (pkinit)
PA-PK-KEY-REQ                   17                  (pkinit)
PA-PK-KEY-REP                   18                  (pkinit)

authorization data type         ad-type value
reserved values                 0-63
OSF-DCE                         64
SESAME                          65

alternate authentication type   method-type value
reserved values                 0-63
ATT-CHALLENGE-RESPONSE          64

transited encoding type         tr-type value
DOMAIN-X500-COMPRESS            1
reserved values                 all others



Label               Value   Meaning or MIT code

pvno                    5   current Kerberos protocol version number

message types

KRB_AS_REQ             10   Request for initial authentication
KRB_AS_REP             11   Response to KRB_AS_REQ request
KRB_TGS_REQ            12   Request for authentication based on TGT
KRB_TGS_REP            13   Response to KRB_TGS_REQ request
KRB_AP_REQ             14   application request to server
KRB_AP_REP             15   Response to KRB_AP_REQ_MUTUAL
KRB_SAFE               20   Safe (checksummed) application message
KRB_PRIV               21   Private (encrypted) application message
KRB_CRED               22   Private (encrypted) message to forward credentials
KRB_ERROR              30   Error response


Section 8.3.               - 93 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


name types

KRB_NT_UNKNOWN       0   Name type not known
KRB_NT_PRINCIPAL     1   Just the name of the principal as in DCE, or for users
KRB_NT_SRV_INST      2   Service and other unique instance (krbtgt)
KRB_NT_SRV_HST       3   Service with host name as instance (telnet, rcommands)
KRB_NT_SRV_XHST      4   Service with host as remaining components
KRB_NT_UID           5   Unique ID

error codes

KDC_ERR_NONE                    0   No error
KDC_ERR_NAME_EXP                1   Client's entry in database has expired
KDC_ERR_SERVICE_EXP             2   Server's entry in database has expired
KDC_ERR_BAD_PVNO                3   Requested protocol version number not supported
KDC_ERR_C_OLD_MAST_KVNO         4   Client's key encrypted in old master key
KDC_ERR_S_OLD_MAST_KVNO         5   Server's key encrypted in old master key
KDC_ERR_C_PRINCIPAL_UNKNOWN     6   Client not found in Kerberos database
KDC_ERR_S_PRINCIPAL_UNKNOWN     7   Server not found in Kerberos database
KDC_ERR_PRINCIPAL_NOT_UNIQUE    8   Multiple principal entries in database
KDC_ERR_NULL_KEY                9   The client or server has a null key
KDC_ERR_CANNOT_POSTDATE        10   Ticket not eligible for postdating
KDC_ERR_NEVER_VALID            11   Requested start time is later than end time
KDC_ERR_POLICY                 12   KDC policy rejects request
KDC_ERR_BADOPTION              13   KDC cannot accommodate requested option
KDC_ERR_ETYPE_NOSUPP           14   KDC has no support for encryption type
KDC_ERR_SUMTYPE_NOSUPP         15   KDC has no support for checksum type
KDC_ERR_PADATA_TYPE_NOSUPP     16   KDC has no support for padata type
KDC_ERR_TRTYPE_NOSUPP          17   KDC has no support for transited type
KDC_ERR_CLIENT_REVOKED         18   Clients credentials have been revoked
KDC_ERR_SERVICE_REVOKED        19   Credentials for server have been revoked
KDC_ERR_TGT_REVOKED            20   TGT has been revoked
KDC_ERR_CLIENT_NOTYET          21   Client not yet valid - try again later
KDC_ERR_SERVICE_NOTYET         22   Server not yet valid - try again later
KDC_ERR_KEY_EXPIRED            23   Password has expired - change password to reset
KDC_ERR_PREAUTH_FAILED         24   Pre-authentication information was invalid
KDC_ERR_PREAUTH_REQUIRED       25   Additional pre-authenticationrequired-
KDC_ERR_SERVER_NOMATCH         26   Requested server and ticket don't match
KDC_ERR_MUST_USE_USER2USER     27   Server principal valid for user2user only
KDC_ERR_PATH_NOT_ACCPETED      28   KDC Policy rejects transited path
KRB_AP_ERR_BAD_INTEGRITY       31   Integrity check on decrypted field failed
KRB_AP_ERR_TKT_EXPIRED         32   Ticket expired
KRB_AP_ERR_TKT_NYV             33   Ticket not yet valid
KRB_AP_ERR_REPEAT              34   Request is a replay
KRB_AP_ERR_NOT_US              35   The ticket isn't for us
KRB_AP_ERR_BADMATCH            36   Ticket and authenticator don't match
KRB_AP_ERR_SKEW                37   Clock skew too great
KRB_AP_ERR_BADADDR             38   Incorrect net address
KRB_AP_ERR_BADVERSION          39   Protocol version mismatch
KRB_AP_ERR_MSG_TYPE            40   Invalid msg type
KRB_AP_ERR_MODIFIED            41   Message stream modified
KRB_AP_ERR_BADORDER            42   Message out of order
KRB_AP_ERR_BADKEYVER           44   Specified version of key is not available
KRB_AP_ERR_NOKEY               45   Service key not available
KRB_AP_ERR_MUT_FAIL            46   Mutual authentication failed
KRB_AP_ERR_BADDIRECTION        47   Incorrect message direction
KRB_AP_ERR_METHOD              48   Alternative authentication method required
KRB_AP_ERR_BADSEQ              49   Incorrect sequence number in message



Section 8.3.               - 94 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


KRB_AP_ERR_INAPP_CKSUM         50   Inappropriate type of checksum in message
KRB_ERR_GENERIC                60   Generic error (description in e-text)
KRB_ERR_FIELD_TOOLONG          61   Field is too long for this implementation
KDC_ERROR_CLIENT_NOT_TRUSTED   62   (pkinit)
KDC_ERROR_KDC_NOT_TRUSTED      63   (pkinit)
KDC_ERROR_INVALID_SIG          64   (pkinit)
KDC_ERR_KEY_TOO_WEAK           65   (pkinit)


9.  Interoperability requirements

     Version 5 of the Kerberos protocol supports a myriad of
options.   Among  these are multiple encryption and checksum
types, alternative encoding schemes for the transited field,
optional  mechanisms for pre-authentication, the handling of
tickets with no addresses, options  for  mutual  authentica-
tion, user to user authentication, support for proxies, for-
warding, postdating, and renewing  tickets,  the  format  of
realm names, and the handling of authorization data.

     In order to ensure the interoperability of  realms,  it
is necessary to define a minimal configuration which must be
supported by all implementations.  This  minimal  configura-
tion  is subject to change as technology does.  For example,
if at some later date it  is  discovered  that  one  of  the
required encryption or checksum algorithms is not secure, it
will be replaced.

9.1.  Specification 1

     This section defines the first specification  of  these
options.   Implementations  which are configured in this way
can be said to support Kerberos Version  5  Specification  1
(5.1).

Encryption and checksum methods

The following encryption and  checksum  mechanisms  must  be
supported.   Implementations may support other mechanisms as
well, but the additional mechanisms may only  be  used  when
communicating with principals known to also support them:
This list is to be determined.
Encryption: DES-CBC-MD5
Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5


__________________________
- This error carries additional information in  the  e-
data  field.  The contents of the e-data field for this
message is described in section 5.9.1.



Section 9.1.               - 95 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


Realm Names

All implementations must understand hierarchical  realms  in
both the Internet Domain and the X.500 style.  When a ticket
granting ticket for an unknown realm is requested,  the  KDC
must  be  able  to  determine  the names of the intermediate
realms between the KDCs realm and the requested realm.

Transited field encoding

DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must  be
supported.  Alternative encodings may be supported, but they
may be used only when that  encoding  is  supported  by  ALL
intermediate realms.

Pre-authentication methods

The TGS-REQ method must be supported.  The TGS-REQ method is
not  used  on  the  initial  request.   The PA-ENC-TIMESTAMP
method must be  supported  by  clients  but  whether  it  is
enabled  by  default  may  be determined on a realm by realm
basis.  If not used in the initial  request  and  the  error
KDC_ERR_PREAUTH_REQUIRED   is  returned  specifying  PA-ENC-
TIMESTAMP as an acceptable method, the client  should  retry
the   initial   request   using  the  PA-ENC-TIMESTAMP  pre-
authentication method.  Servers need  not  support  the  PA-
ENC-TIMESTAMP method, but if not supported the server should
ignore the presence of  PA-ENC-TIMESTAMP  pre-authentication
in a request.

Mutual authentication

Mutual authentication (via the KRB_AP_REP message)  must  be
supported.


Ticket addresses and flags

All KDC's must pass on tickets that carry no addresses (i.e.
if  a TGT contains no addresses, the KDC will return deriva-
tive tickets), but each realm may set  its  own  policy  for
issuing  such  tickets, and each application server will set
its own policy with respect to accepting them.

     Proxies and forwarded tickets must be supported.  Indi-
vidual realms and application servers can set their own pol-
icy on when such tickets will be accepted.

     All implementations must recognize renewable and  post-
dated  tickets,  but  need  not actually implement them.  If
these options are not supported, the starttime  and  endtime
in  the  ticket shall specify a ticket's entire useful life.
When a postdated ticket is decoded by a server,  all  imple-
mentations  shall  make  the  presence of the postdated flag


Section 9.1.               - 96 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


visible to the calling server.

User-to-user authentication

Support for user to user authentication  (via  the  ENC-TKT-
IN-SKEY KDC option) must be provided by implementations, but
individual realms may decide as a matter of policy to reject
such requests on a per-principal or realm-wide basis.

Authorization data

Implementations must pass all authorization  data  subfields
from  ticket-granting  tickets  to  any  derivative  tickets
unless directed to suppress a subfield as part of the defin-
ition   of  that  registered  subfield  type  (it  is  never
incorrect to pass on a subfield, and no registered  subfield
types presently specify suppression at the KDC).

     Implementations must make the contents of any  authori-
zation  data subfields available to the server when a ticket
is used.  Implementations are not required to allow  clients
to specify the contents of the authorization data fields.

9.2.  Recommended KDC values

Following is a list of recommended values for a  KDC  imple-
mentation, based on the list of suggested configuration con-
stants (see section 4.4).

minimum lifetime    5 minutes

maximum renewable lifetime1 week

maximum ticket lifetime1 day

empty addresses     only when suitable  restrictions  appear
                    in authorization data

proxiable, etc.     Allowed.

















Section 9.2.               - 97 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


10.  REFERENCES



1.   B. Clifford Neuman and Theodore Y. Ts'o, "An  Authenti-
     cation  Service for Computer Networks," IEEE Communica-
     tions Magazine, Vol. 32(9), pp. 33-38 (September 1994).

2.   S. P. Miller, B. C. Neuman, J. I. Schiller, and  J.  H.
     Saltzer,  Section  E.2.1:  Kerberos  Authentication and
     Authorization System, M.I.T. Project Athena, Cambridge,
     Massachusetts (December 21, 1987).

3.   J. G. Steiner, B. C. Neuman, and J. I. Schiller,  "Ker-
     beros:  An Authentication Service for Open Network Sys-
     tems," pp. 191-202 in  Usenix  Conference  Proceedings,
     Dallas, Texas (February, 1988).

4.   Roger M.  Needham  and  Michael  D.  Schroeder,  "Using
     Encryption for Authentication in Large Networks of Com-
     puters,"  Communications  of  the  ACM,  Vol.   21(12),
     pp. 993-999 (December, 1978).

5.   Dorothy E. Denning and  Giovanni  Maria  Sacco,  "Time-
     stamps  in  Key Distribution Protocols," Communications
     of the ACM, Vol. 24(8), pp. 533-536 (August 1981).

6.   John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o,
     "The Evolution of the Kerberos Authentication Service,"
     in an IEEE Computer Society Text soon to  be  published
     (June 1992).

7.   B.  Clifford  Neuman,  "Proxy-Based  Authorization  and
     Accounting  for Distributed Systems," in Proceedings of
     the 13th International Conference on  Distributed  Com-
     puting Systems, Pittsburgh, PA (May, 1993).

8.   Don Davis and Ralph Swick,  "Workstation  Services  and
     Kerberos  Authentication  at Project Athena," Technical
     Memorandum TM-424,  MIT Laboratory for Computer Science
     (February 1990).

9.   P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E.  Som-
     merfeld,  and  K. Raeburn, Section E.1: Service Manage-
     ment System, M.I.T.  Project  Athena,  Cambridge,  Mas-
     sachusetts (1987).

10.  CCITT, Recommendation X.509: The Directory  Authentica-
     tion Framework, December 1988.

11.  J. Pato, Using  Pre-Authentication  to  Avoid  Password
     Guessing  Attacks, Open Software Foundation DCE Request
     for Comments 26 (December 1992).



Section 10.                - 98 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


12.  National Bureau of Standards, U.S. Department  of  Com-
     merce,  "Data Encryption Standard," Federal Information
     Processing Standards Publication  46,   Washington,  DC
     (1977).

13.  National Bureau of Standards, U.S. Department  of  Com-
     merce,  "DES  Modes  of Operation," Federal Information
     Processing Standards Publication 81,   Springfield,  VA
     (December 1980).

14.  Stuart G. Stubblebine and Virgil D. Gligor, "On Message
     Integrity  in  Cryptographic Protocols," in Proceedings
     of the IEEE  Symposium  on  Research  in  Security  and
     Privacy, Oakland, California (May 1992).

15.  International Organization  for  Standardization,  "ISO
     Information  Processing  Systems - Data Communication -
     High-Level Data Link Control Procedure -  Frame  Struc-
     ture," IS 3309 (October 1984).  3rd Edition.

16.  R. Rivest, "The  MD4  Message  Digest  Algorithm,"  RFC
     1320,   MIT  Laboratory  for  Computer  Science  (April
     1992).

17.  R. Rivest, "The  MD5  Message  Digest  Algorithm,"  RFC
     1321,   MIT  Laboratory  for  Computer  Science  (April
     1992).

18.  H. Krawczyk, M. Bellare, and R. Canetti, "HMAC:  Keyed-
     Hashing  for  Message  Authentication,"  Working  Draft
     draft-ietf-ipsec-hmac-md5-01.txt,   (August 1996).

























Section 10.                - 99 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


A.  Pseudo-code for protocol processing

     This appendix provides pseudo-code describing  how  the
messages  are  to  be constructed and interpreted by clients
and servers.

A.1.  KRB_AS_REQ generation
        request.pvno := protocol version; /* pvno = 5 */
        request.msg-type := message type; /* type = KRB_AS_REQ */

        if(pa_enc_timestamp_required) then
                request.padata.padata-type = PA-ENC-TIMESTAMP;
                get system_time;
                padata-body.patimestamp,pausec = system_time;
                encrypt padata-body into request.padata.padata-value
                        using client.key; /* derived from password */
        endif

        body.kdc-options := users's preferences;
        body.cname := user's name;
        body.realm := user's realm;
        body.sname := service's name; /* usually "krbtgt",  "localrealm" */
        if (body.kdc-options.POSTDATED is set) then
                body.from := requested starting time;
        else
                omit body.from;
        endif
        body.till := requested end time;
        if (body.kdc-options.RENEWABLE is set) then
                body.rtime := requested final renewal time;
        endif
        body.nonce := random_nonce();
        body.etype := requested etypes;
        if (user supplied addresses) then
                body.addresses := user's addresses;
        else
                omit body.addresses;
        endif
        omit body.enc-authorization-data;
        request.req-body := body;

        kerberos := lookup(name of local kerberos server (or servers));
        send(packet,kerberos);

        wait(for response);
        if (timed_out) then
                retry or use alternate server;
        endif

A.2.  KRB_AS_REQ verification and KRB_AS_REP generation
        decode message into req;

        client := lookup(req.cname,req.realm);
        server := lookup(req.sname,req.realm);


Section A.2.              - 100 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6



        get system_time;
        kdc_time := system_time.seconds;

        if (!client) then
                /* no client in Database */
                error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN);
        endif
        if (!server) then
                /* no server in Database */
                error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
        endif

        if(client.pa_enc_timestamp_required and
           pa_enc_timestamp not present) then
                error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP));
        endif

        if(pa_enc_timestamp present) then
                decrypt req.padata-value into decrypted_enc_timestamp
                        using client.key;
                        using auth_hdr.authenticator.subkey;
                if (decrypt_error()) then
                        error_out(KRB_AP_ERR_BAD_INTEGRITY);
                if(decrypted_enc_timestamp is not within allowable skew) then
                        error_out(KDC_ERR_PREAUTH_FAILED);
                endif
                if(decrypted_enc_timestamp and usec is replay)
                        error_out(KDC_ERR_PREAUTH_FAILED);
                endif
                add decrypted_enc_timestamp and usec to replay cache;
        endif

        use_etype := first supported etype in req.etypes;

        if (no support for req.etypes) then
                error_out(KDC_ERR_ETYPE_NOSUPP);
        endif

        new_tkt.vno := ticket version; /* = 5 */
        new_tkt.sname := req.sname;
        new_tkt.srealm := req.srealm;
        reset all flags in new_tkt.flags;

        /* It should be noted that local policy may affect the  */
        /* processing of any of these flags.  For example, some */
        /* realms may refuse to issue renewable tickets         */

        if (req.kdc-options.FORWARDABLE is set) then
                set new_tkt.flags.FORWARDABLE;
        endif
        if (req.kdc-options.PROXIABLE is set) then
                set new_tkt.flags.PROXIABLE;
        endif


Section A.2.              - 101 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


        if (req.kdc-options.ALLOW-POSTDATE is set) then
                set new_tkt.flags.MAY-POSTDATE;
        endif
        if ((req.kdc-options.RENEW is set) or
            (req.kdc-options.VALIDATE is set) or
            (req.kdc-options.PROXY is set) or
            (req.kdc-options.FORWARDED is set) or
            (req.kdc-options.ENC-TKT-IN-SKEY is set)) then
                error_out(KDC_ERR_BADOPTION);
        endif

        new_tkt.session := random_session_key();
        new_tkt.cname := req.cname;
        new_tkt.crealm := req.crealm;
        new_tkt.transited := empty_transited_field();

        new_tkt.authtime := kdc_time;

        if (req.kdc-options.POSTDATED is set) then
           if (against_postdate_policy(req.from)) then
                error_out(KDC_ERR_POLICY);
           endif
           set new_tkt.flags.POSTDATED;
           set new_tkt.flags.INVALID;
           new_tkt.starttime := req.from;
        else
           omit new_tkt.starttime; /* treated as authtime when omitted */
        endif
        if (req.till = 0) then
                till := infinity;
        else
                till := req.till;
        endif

        new_tkt.endtime := min(till,
                              new_tkt.starttime+client.max_life,
                              new_tkt.starttime+server.max_life,
                              new_tkt.starttime+max_life_for_realm);

        if ((req.kdc-options.RENEWABLE-OK is set) and
            (new_tkt.endtime < req.till)) then
                /* we set the RENEWABLE option for later processing */
                set req.kdc-options.RENEWABLE;
                req.rtime := req.till;
        endif

        if (req.rtime = 0) then
                rtime := infinity;
        else
                rtime := req.rtime;
        endif

        if (req.kdc-options.RENEWABLE is set) then
                set new_tkt.flags.RENEWABLE;


Section A.2.              - 102 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


                new_tkt.renew-till := min(rtime,
                                          new_tkt.starttime+client.max_rlife,
                                          new_tkt.starttime+server.max_rlife,
                                          new_tkt.starttime+max_rlife_for_realm);
        else
                omit new_tkt.renew-till; /* only present if RENEWABLE */
        endif

        if (req.addresses) then
                new_tkt.caddr := req.addresses;
        else
                omit new_tkt.caddr;
        endif

        new_tkt.authorization_data := empty_authorization_data();

        encode to-be-encrypted part of ticket into OCTET STRING;
        new_tkt.enc-part := encrypt OCTET STRING
                using etype_for_key(server.key), server.key, server.p_kvno;


        /* Start processing the response */

        resp.pvno := 5;
        resp.msg-type := KRB_AS_REP;
        resp.cname := req.cname;
        resp.crealm := req.realm;
        resp.ticket := new_tkt;

        resp.key := new_tkt.session;
        resp.last-req := fetch_last_request_info(client);
        resp.nonce := req.nonce;
        resp.key-expiration := client.expiration;
        resp.flags := new_tkt.flags;

        resp.authtime := new_tkt.authtime;
        resp.starttime := new_tkt.starttime;
        resp.endtime := new_tkt.endtime;

        if (new_tkt.flags.RENEWABLE) then
                resp.renew-till := new_tkt.renew-till;
        endif

        resp.realm := new_tkt.realm;
        resp.sname := new_tkt.sname;

        resp.caddr := new_tkt.caddr;

        encode body of reply into OCTET STRING;

        resp.enc-part := encrypt OCTET STRING
                         using use_etype, client.key, client.p_kvno;
        send(resp);



Section A.2.              - 103 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


A.3.  KRB_AS_REP verification
        decode response into resp;

        if (resp.msg-type = KRB_ERROR) then
                if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) then
                        set pa_enc_timestamp_required;
                        goto KRB_AS_REQ;
                endif
                process_error(resp);
                return;
        endif

        /* On error, discard the response, and zero the session key */
        /* from the response immediately */

        key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype,
                                 resp.padata);
        unencrypted part of resp := decode of decrypt of resp.enc-part
                                using resp.enc-part.etype and key;
        zero(key);

        if (common_as_rep_tgs_rep_checks fail) then
                destroy resp.key;
                return error;
        endif

        if near(resp.princ_exp) then
                print(warning message);
        endif
        save_for_later(ticket,session,client,server,times,flags);

A.4.  KRB_AS_REP and KRB_TGS_REP common checks
        if (decryption_error() or
            (req.cname != resp.cname) or
            (req.realm != resp.crealm) or
            (req.sname != resp.sname) or
            (req.realm != resp.realm) or
            (req.nonce != resp.nonce) or
            (req.addresses != resp.caddr)) then
                destroy resp.key;
                return KRB_AP_ERR_MODIFIED;
        endif

        /* make sure no flags are set that shouldn't be, and that all that */
        /* should be are set                                               */
        if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then
                destroy resp.key;
                return KRB_AP_ERR_MODIFIED;
        endif

        if ((req.from = 0) and
            (resp.starttime is not within allowable skew)) then
                destroy resp.key;
                return KRB_AP_ERR_SKEW;


Section A.4.              - 104 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


        endif
        if ((req.from != 0) and (req.from != resp.starttime)) then
                destroy resp.key;
                return KRB_AP_ERR_MODIFIED;
        endif
        if ((req.till != 0) and (resp.endtime > req.till)) then
                destroy resp.key;
                return KRB_AP_ERR_MODIFIED;
        endif

        if ((req.kdc-options.RENEWABLE is set) and
            (req.rtime != 0) and (resp.renew-till > req.rtime)) then
                destroy resp.key;
                return KRB_AP_ERR_MODIFIED;
        endif
        if ((req.kdc-options.RENEWABLE-OK is set) and
            (resp.flags.RENEWABLE) and
            (req.till != 0) and
            (resp.renew-till > req.till)) then
                destroy resp.key;
                return KRB_AP_ERR_MODIFIED;
        endif

A.5.  KRB_TGS_REQ generation
        /* Note that make_application_request might have to recursivly     */
        /* call this routine to get the appropriate ticket-granting ticket */

        request.pvno := protocol version; /* pvno = 5 */
        request.msg-type := message type; /* type = KRB_TGS_REQ */

        body.kdc-options := users's preferences;
        /* If the TGT is not for the realm of the end-server  */
        /* then the sname will be for a TGT for the end-realm */
        /* and the realm of the requested ticket (body.realm) */
        /* will be that of the TGS to which the TGT we are    */
        /* sending applies                                    */
        body.sname := service's name;
        body.realm := service's realm;

        if (body.kdc-options.POSTDATED is set) then
                body.from := requested starting time;
        else
                omit body.from;
        endif
        body.till := requested end time;
        if (body.kdc-options.RENEWABLE is set) then
                body.rtime := requested final renewal time;
        endif
        body.nonce := random_nonce();
        body.etype := requested etypes;
        if (user supplied addresses) then
                body.addresses := user's addresses;
        else
                omit body.addresses;


Section A.5.              - 105 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


        endif

        body.enc-authorization-data := user-supplied data;
        if (body.kdc-options.ENC-TKT-IN-SKEY) then
                body.additional-tickets_ticket := second TGT;
        endif

        request.req-body := body;
        check := generate_checksum (req.body,checksumtype);

        request.padata[0].padata-type := PA-TGS-REQ;
        request.padata[0].padata-value := create a KRB_AP_REQ using
                                      the TGT and checksum

        /* add in any other padata as required/supplied */

        kerberos := lookup(name of local kerberose server (or servers));
        send(packet,kerberos);

        wait(for response);
        if (timed_out) then
                retry or use alternate server;
        endif

A.6.  KRB_TGS_REQ verification and KRB_TGS_REP generation
        /* note that reading the application request requires first
        determining the server for which a ticket was issued, and choosing the
        correct key for decryption.  The name of the server appears in the
        plaintext part of the ticket. */

        if (no KRB_AP_REQ in req.padata) then
                error_out(KDC_ERR_PADATA_TYPE_NOSUPP);
        endif
        verify KRB_AP_REQ in req.padata;

        /* Note that the realm in which the Kerberos server is operating is
        determined by the instance from the ticket-granting ticket.  The realm
        in the ticket-granting ticket is the realm under which the ticket
        granting ticket was issued.  It is possible for a single Kerberos
        server to support more than one realm. */

        auth_hdr := KRB_AP_REQ;
        tgt := auth_hdr.ticket;

        if (tgt.sname is not a TGT for local realm and is not req.sname) then
                error_out(KRB_AP_ERR_NOT_US);

        realm := realm_tgt_is_for(tgt);

        decode remainder of request;

        if (auth_hdr.authenticator.cksum is missing) then
                error_out(KRB_AP_ERR_INAPP_CKSUM);
        endif


Section A.6.              - 106 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


        if (auth_hdr.authenticator.cksum type is not supported) then
                error_out(KDC_ERR_SUMTYPE_NOSUPP);
        endif
        if (auth_hdr.authenticator.cksum is not both collision-proof and keyed) then
                error_out(KRB_AP_ERR_INAPP_CKSUM);
        endif

        set computed_checksum := checksum(req);
        if (computed_checksum != auth_hdr.authenticatory.cksum) then
                error_out(KRB_AP_ERR_MODIFIED);
        endif

        server := lookup(req.sname,realm);

        if (!server) then
                if (is_foreign_tgt_name(server)) then
                        server := best_intermediate_tgs(server);
                else
                        /* no server in Database */
                        error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
                endif
        endif

        session := generate_random_session_key();


        use_etype := first supported etype in req.etypes;

        if (no support for req.etypes) then
                error_out(KDC_ERR_ETYPE_NOSUPP);
        endif

        new_tkt.vno := ticket version; /* = 5 */
        new_tkt.sname := req.sname;
        new_tkt.srealm := realm;
        reset all flags in new_tkt.flags;

        /* It should be noted that local policy may affect the  */
        /* processing of any of these flags.  For example, some */
        /* realms may refuse to issue renewable tickets         */

        new_tkt.caddr := tgt.caddr;
        resp.caddr := NULL; /* We only include this if they change */
        if (req.kdc-options.FORWARDABLE is set) then
                if (tgt.flags.FORWARDABLE is reset) then
                        error_out(KDC_ERR_BADOPTION);
                endif
                set new_tkt.flags.FORWARDABLE;
        endif
        if (req.kdc-options.FORWARDED is set) then
                if (tgt.flags.FORWARDABLE is reset) then
                        error_out(KDC_ERR_BADOPTION);
                endif
                set new_tkt.flags.FORWARDED;


Section A.6.              - 107 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


                new_tkt.caddr := req.addresses;
                resp.caddr := req.addresses;
        endif
        if (tgt.flags.FORWARDED is set) then
                set new_tkt.flags.FORWARDED;
        endif

        if (req.kdc-options.PROXIABLE is set) then
                if (tgt.flags.PROXIABLE is reset)
                        error_out(KDC_ERR_BADOPTION);
                endif
                set new_tkt.flags.PROXIABLE;
        endif
        if (req.kdc-options.PROXY is set) then
                if (tgt.flags.PROXIABLE is reset) then
                        error_out(KDC_ERR_BADOPTION);
                endif
                set new_tkt.flags.PROXY;
                new_tkt.caddr := req.addresses;
                resp.caddr := req.addresses;
        endif

        if (req.kdc-options.ALLOW-POSTDATE is set) then
                if (tgt.flags.MAY-POSTDATE is reset)
                        error_out(KDC_ERR_BADOPTION);
                endif
                set new_tkt.flags.MAY-POSTDATE;
        endif
        if (req.kdc-options.POSTDATED is set) then
                if (tgt.flags.MAY-POSTDATE is reset) then
                        error_out(KDC_ERR_BADOPTION);
                endif
                set new_tkt.flags.POSTDATED;
                set new_tkt.flags.INVALID;
                if (against_postdate_policy(req.from)) then
                        error_out(KDC_ERR_POLICY);
                endif
                new_tkt.starttime := req.from;
        endif


        if (req.kdc-options.VALIDATE is set) then
                if (tgt.flags.INVALID is reset) then
                        error_out(KDC_ERR_POLICY);
                endif
                if (tgt.starttime > kdc_time) then
                        error_out(KRB_AP_ERR_NYV);
                endif
                if (check_hot_list(tgt)) then
                        error_out(KRB_AP_ERR_REPEAT);
                endif
                tkt := tgt;
                reset new_tkt.flags.INVALID;
        endif


Section A.6.              - 108 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


        if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW,
                             and those already processed) is set) then
                error_out(KDC_ERR_BADOPTION);
        endif

        new_tkt.authtime := tgt.authtime;

        if (req.kdc-options.RENEW is set) then
          /* Note that if the endtime has already passed, the ticket would  */
          /* have been rejected in the initial authentication stage, so     */
          /* there is no need to check again here                           */
                if (tgt.flags.RENEWABLE is reset) then
                        error_out(KDC_ERR_BADOPTION);
                endif
                if (tgt.renew-till >= kdc_time) then
                        error_out(KRB_AP_ERR_TKT_EXPIRED);
                endif
                tkt := tgt;
                new_tkt.starttime := kdc_time;
                old_life := tgt.endttime - tgt.starttime;
                new_tkt.endtime := min(tgt.renew-till,
                                       new_tkt.starttime + old_life);
        else
                new_tkt.starttime := kdc_time;
                if (req.till = 0) then
                        till := infinity;
                else
                        till := req.till;
                endif
                new_tkt.endtime := min(till,
                                       new_tkt.starttime+client.max_life,
                                       new_tkt.starttime+server.max_life,
                                       new_tkt.starttime+max_life_for_realm,
                                       tgt.endtime);

                if ((req.kdc-options.RENEWABLE-OK is set) and
                    (new_tkt.endtime < req.till) and
                    (tgt.flags.RENEWABLE is set) then
                        /* we set the RENEWABLE option for later processing */
                        set req.kdc-options.RENEWABLE;
                        req.rtime := min(req.till, tgt.renew-till);
                endif
        endif

        if (req.rtime = 0) then
                rtime := infinity;
        else
                rtime := req.rtime;
        endif

        if ((req.kdc-options.RENEWABLE is set) and
            (tgt.flags.RENEWABLE is set)) then
                set new_tkt.flags.RENEWABLE;
                new_tkt.renew-till := min(rtime,


Section A.6.              - 109 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


                                          new_tkt.starttime+client.max_rlife,
                                          new_tkt.starttime+server.max_rlife,
                                          new_tkt.starttime+max_rlife_for_realm,
                                          tgt.renew-till);
        else
                new_tkt.renew-till := OMIT; /* leave the renew-till field out */
        endif
        if (req.enc-authorization-data is present) then
                decrypt req.enc-authorization-data into decrypted_authorization_data
                        using auth_hdr.authenticator.subkey;
                if (decrypt_error()) then
                        error_out(KRB_AP_ERR_BAD_INTEGRITY);
                endif
        endif
        new_tkt.authorization_data := req.auth_hdr.ticket.authorization_data +
                                 decrypted_authorization_data;

        new_tkt.key := session;
        new_tkt.crealm := tgt.crealm;
        new_tkt.cname := req.auth_hdr.ticket.cname;

        if (realm_tgt_is_for(tgt) := tgt.realm) then
                /* tgt issued by local realm */
                new_tkt.transited := tgt.transited;
        else
                /* was issued for this realm by some other realm */
                if (tgt.transited.tr-type not supported) then
                        error_out(KDC_ERR_TRTYPE_NOSUPP);
                endif
                new_tkt.transited := compress_transited(tgt.transited + tgt.realm)
        endif

        encode encrypted part of new_tkt into OCTET STRING;
        if (req.kdc-options.ENC-TKT-IN-SKEY is set) then
                if (server not specified) then
                        server = req.second_ticket.client;
                endif
                if ((req.second_ticket is not a TGT) or
                    (req.second_ticket.client != server)) then
                        error_out(KDC_ERR_POLICY);
                endif

                new_tkt.enc-part := encrypt OCTET STRING using
                        using etype_for_key(second-ticket.key), second-ticket.key;
        else
                new_tkt.enc-part := encrypt OCTET STRING
                        using etype_for_key(server.key), server.key, server.p_kvno;
        endif

        resp.pvno := 5;
        resp.msg-type := KRB_TGS_REP;
        resp.crealm := tgt.crealm;
        resp.cname := tgt.cname;



Section A.6.              - 110 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


        resp.ticket := new_tkt;

        resp.key := session;
        resp.nonce := req.nonce;
        resp.last-req := fetch_last_request_info(client);
        resp.flags := new_tkt.flags;

        resp.authtime := new_tkt.authtime;
        resp.starttime := new_tkt.starttime;
        resp.endtime := new_tkt.endtime;

        omit resp.key-expiration;

        resp.sname := new_tkt.sname;
        resp.realm := new_tkt.realm;

        if (new_tkt.flags.RENEWABLE) then
                resp.renew-till := new_tkt.renew-till;
        endif


        encode body of reply into OCTET STRING;

        if (req.padata.authenticator.subkey)
                resp.enc-part := encrypt OCTET STRING using use_etype,
                        req.padata.authenticator.subkey;
        else resp.enc-part := encrypt OCTET STRING using use_etype, tgt.key;

        send(resp);

A.7.  KRB_TGS_REP verification
        decode response into resp;

        if (resp.msg-type = KRB_ERROR) then
                process_error(resp);
                return;
        endif

        /* On error, discard the response, and zero the session key from
        the response immediately */

        if (req.padata.authenticator.subkey)
                unencrypted part of resp := decode of decrypt of resp.enc-part
                        using resp.enc-part.etype and subkey;
        else unencrypted part of resp := decode of decrypt of resp.enc-part
                                using resp.enc-part.etype and tgt's session key;
        if (common_as_rep_tgs_rep_checks fail) then
                destroy resp.key;
                return error;
        endif

        check authorization_data as necessary;
        save_for_later(ticket,session,client,server,times,flags);



Section A.7.              - 111 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


A.8.  Authenticator generation
        body.authenticator-vno := authenticator vno; /* = 5 */
        body.cname, body.crealm := client name;
        if (supplying checksum) then
                body.cksum := checksum;
        endif
        get system_time;
        body.ctime, body.cusec := system_time;
        if (selecting sub-session key) then
                select sub-session key;
                body.subkey := sub-session key;
        endif
        if (using sequence numbers) then
                select initial sequence number;
                body.seq-number := initial sequence;
        endif

A.9.  KRB_AP_REQ generation
        obtain ticket and session_key from cache;

        packet.pvno := protocol version; /* 5 */
        packet.msg-type := message type; /* KRB_AP_REQ */

        if (desired(MUTUAL_AUTHENTICATION)) then
                set packet.ap-options.MUTUAL-REQUIRED;
        else
                reset packet.ap-options.MUTUAL-REQUIRED;
        endif
        if (using session key for ticket) then
                set packet.ap-options.USE-SESSION-KEY;
        else
                reset packet.ap-options.USE-SESSION-KEY;
        endif
        packet.ticket := ticket; /* ticket */
        generate authenticator;
        encode authenticator into OCTET STRING;
        encrypt OCTET STRING into packet.authenticator using session_key;

A.10.  KRB_AP_REQ verification
        receive packet;
        if (packet.pvno != 5) then
                either process using other protocol spec
                or error_out(KRB_AP_ERR_BADVERSION);
        endif
        if (packet.msg-type != KRB_AP_REQ) then
                error_out(KRB_AP_ERR_MSG_TYPE);
        endif
        if (packet.ticket.tkt_vno != 5) then
                either process using other protocol spec
                or error_out(KRB_AP_ERR_BADVERSION);
        endif
        if (packet.ap_options.USE-SESSION-KEY is set) then
                retrieve session key from ticket-granting ticket for
                 packet.ticket.{sname,srealm,enc-part.etype};


Section A.10.             - 112 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


        else
                retrieve service key for
                 packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno};
        endif
        if (no_key_available) then
                if (cannot_find_specified_skvno) then
                        error_out(KRB_AP_ERR_BADKEYVER);
                else
                        error_out(KRB_AP_ERR_NOKEY);
                endif
        endif
        decrypt packet.ticket.enc-part into decr_ticket using retrieved key;
        if (decryption_error()) then
                error_out(KRB_AP_ERR_BAD_INTEGRITY);
        endif
        decrypt packet.authenticator into decr_authenticator
                using decr_ticket.key;
        if (decryption_error()) then
                error_out(KRB_AP_ERR_BAD_INTEGRITY);
        endif
        if (decr_authenticator.{cname,crealm} !=
            decr_ticket.{cname,crealm}) then
                error_out(KRB_AP_ERR_BADMATCH);
        endif
        if (decr_ticket.caddr is present) then
                if (sender_address(packet) is not in decr_ticket.caddr) then
                        error_out(KRB_AP_ERR_BADADDR);
                endif
        elseif (application requires addresses) then
                error_out(KRB_AP_ERR_BADADDR);
        endif
        if (not in_clock_skew(decr_authenticator.ctime,
                              decr_authenticator.cusec)) then
                error_out(KRB_AP_ERR_SKEW);
        endif
        if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then
                error_out(KRB_AP_ERR_REPEAT);
        endif
        save_identifier(decr_authenticator.{ctime,cusec,cname,crealm});
        get system_time;
        if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or
            (decr_ticket.flags.INVALID is set)) then
                /* it hasn't yet become valid */
                error_out(KRB_AP_ERR_TKT_NYV);
        endif
        if (system_time-decr_ticket.endtime > CLOCK_SKEW) then
                error_out(KRB_AP_ERR_TKT_EXPIRED);
        endif
        /* caller must check decr_ticket.flags for any pertinent details */
        return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED);

A.11.  KRB_AP_REP generation
        packet.pvno := protocol version; /* 5 */
        packet.msg-type := message type; /* KRB_AP_REP */


Section A.11.             - 113 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


        body.ctime := packet.ctime;
        body.cusec := packet.cusec;
        if (selecting sub-session key) then
                select sub-session key;
                body.subkey := sub-session key;
        endif
        if (using sequence numbers) then
                select initial sequence number;
                body.seq-number := initial sequence;
        endif

        encode body into OCTET STRING;

        select encryption type;
        encrypt OCTET STRING into packet.enc-part;

A.12.  KRB_AP_REP verification
        receive packet;
        if (packet.pvno != 5) then
                either process using other protocol spec
                or error_out(KRB_AP_ERR_BADVERSION);
        endif
        if (packet.msg-type != KRB_AP_REP) then
                error_out(KRB_AP_ERR_MSG_TYPE);
        endif
        cleartext := decrypt(packet.enc-part) using ticket's session key;
        if (decryption_error()) then
                error_out(KRB_AP_ERR_BAD_INTEGRITY);
        endif
        if (cleartext.ctime != authenticator.ctime) then
                error_out(KRB_AP_ERR_MUT_FAIL);
        endif
        if (cleartext.cusec != authenticator.cusec) then
                error_out(KRB_AP_ERR_MUT_FAIL);
        endif
        if (cleartext.subkey is present) then
                save cleartext.subkey for future use;
        endif
        if (cleartext.seq-number is present) then
                save cleartext.seq-number for future verifications;
        endif
        return(AUTHENTICATION_SUCCEEDED);

A.13.  KRB_SAFE generation
        collect user data in buffer;

        /* assemble packet: */
        packet.pvno := protocol version; /* 5 */
        packet.msg-type := message type; /* KRB_SAFE */

        body.user-data := buffer; /* DATA */
        if (using timestamp) then
                get system_time;
                body.timestamp, body.usec := system_time;


Section A.13.             - 114 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


        endif
        if (using sequence numbers) then
                body.seq-number := sequence number;
        endif
        body.s-address := sender host addresses;
        if (only one recipient) then
                body.r-address := recipient host address;
        endif
        checksum.cksumtype := checksum type;
        compute checksum over body;
        checksum.checksum := checksum value; /* checksum.checksum */
        packet.cksum := checksum;
        packet.safe-body := body;

A.14.  KRB_SAFE verification
        receive packet;
        if (packet.pvno != 5) then
                either process using other protocol spec
                or error_out(KRB_AP_ERR_BADVERSION);
        endif
        if (packet.msg-type != KRB_SAFE) then
                error_out(KRB_AP_ERR_MSG_TYPE);
        endif
        if (packet.checksum.cksumtype is not both collision-proof and keyed) then
                error_out(KRB_AP_ERR_INAPP_CKSUM);
        endif
        if (safe_priv_common_checks_ok(packet)) then
                set computed_checksum := checksum(packet.body);
                if (computed_checksum != packet.checksum) then
                        error_out(KRB_AP_ERR_MODIFIED);
                endif
                return (packet, PACKET_IS_GENUINE);
        else
                return common_checks_error;
        endif

A.15.  KRB_SAFE and KRB_PRIV common checks
        if (packet.s-address != O/S_sender(packet)) then
                /* O/S report of sender not who claims to have sent it */
                error_out(KRB_AP_ERR_BADADDR);
        endif
        if ((packet.r-address is present) and
            (packet.r-address != local_host_address)) then
                /* was not sent to proper place */
                error_out(KRB_AP_ERR_BADADDR);
        endif
        if (((packet.timestamp is present) and
             (not in_clock_skew(packet.timestamp,packet.usec))) or
            (packet.timestamp is not present and timestamp expected)) then
                error_out(KRB_AP_ERR_SKEW);
        endif
        if (repeated(packet.timestamp,packet.usec,packet.s-address)) then
                error_out(KRB_AP_ERR_REPEAT);
        endif


Section A.15.             - 115 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


        if (((packet.seq-number is present) and
             ((not in_sequence(packet.seq-number)))) or
            (packet.seq-number is not present and sequence expected)) then
                error_out(KRB_AP_ERR_BADORDER);
        endif
        if (packet.timestamp not present and packet.seq-number not present) then
                error_out(KRB_AP_ERR_MODIFIED);
        endif

        save_identifier(packet.{timestamp,usec,s-address},
                        sender_principal(packet));

        return PACKET_IS_OK;

A.16.  KRB_PRIV generation
        collect user data in buffer;

        /* assemble packet: */
        packet.pvno := protocol version; /* 5 */
        packet.msg-type := message type; /* KRB_PRIV */

        packet.enc-part.etype := encryption type;

        body.user-data := buffer;
        if (using timestamp) then
                get system_time;
                body.timestamp, body.usec := system_time;
        endif
        if (using sequence numbers) then
                body.seq-number := sequence number;
        endif
        body.s-address := sender host addresses;
        if (only one recipient) then
                body.r-address := recipient host address;
        endif

        encode body into OCTET STRING;

        select encryption type;
        encrypt OCTET STRING into packet.enc-part.cipher;


A.17.  KRB_PRIV verification
        receive packet;
        if (packet.pvno != 5) then
                either process using other protocol spec
                or error_out(KRB_AP_ERR_BADVERSION);
        endif
        if (packet.msg-type != KRB_PRIV) then
                error_out(KRB_AP_ERR_MSG_TYPE);
        endif

        cleartext := decrypt(packet.enc-part) using negotiated key;
        if (decryption_error()) then


Section A.17.             - 116 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


                error_out(KRB_AP_ERR_BAD_INTEGRITY);
        endif

        if (safe_priv_common_checks_ok(cleartext)) then
                return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED);
        else
                return common_checks_error;
        endif

A.18.  KRB_CRED generation
        invoke KRB_TGS; /* obtain tickets to be provided to peer */

        /* assemble packet: */
        packet.pvno := protocol version; /* 5 */
        packet.msg-type := message type; /* KRB_CRED */

        for (tickets[n] in tickets to be forwarded) do
                packet.tickets[n] = tickets[n].ticket;
        done

        packet.enc-part.etype := encryption type;

        for (ticket[n] in tickets to be forwarded) do
                body.ticket-info[n].key = tickets[n].session;
                body.ticket-info[n].prealm = tickets[n].crealm;
                body.ticket-info[n].pname = tickets[n].cname;
                body.ticket-info[n].flags = tickets[n].flags;
                body.ticket-info[n].authtime = tickets[n].authtime;
                body.ticket-info[n].starttime = tickets[n].starttime;
                body.ticket-info[n].endtime = tickets[n].endtime;
                body.ticket-info[n].renew-till = tickets[n].renew-till;
                body.ticket-info[n].srealm = tickets[n].srealm;
                body.ticket-info[n].sname = tickets[n].sname;
                body.ticket-info[n].caddr = tickets[n].caddr;
        done

        get system_time;
        body.timestamp, body.usec := system_time;

        if (using nonce) then
                body.nonce := nonce;
        endif

        if (using s-address) then
                body.s-address := sender host addresses;
        endif
        if (limited recipients) then
                body.r-address := recipient host address;
        endif

        encode body into OCTET STRING;

        select encryption type;
        encrypt OCTET STRING into packet.enc-part.cipher


Section A.18.             - 117 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


               using negotiated encryption key;


A.19.  KRB_CRED verification
        receive packet;
        if (packet.pvno != 5) then
                either process using other protocol spec
                or error_out(KRB_AP_ERR_BADVERSION);
        endif
        if (packet.msg-type != KRB_CRED) then
                error_out(KRB_AP_ERR_MSG_TYPE);
        endif

        cleartext := decrypt(packet.enc-part) using negotiated key;
        if (decryption_error()) then
                error_out(KRB_AP_ERR_BAD_INTEGRITY);
        endif
        if ((packet.r-address is present or required) and
           (packet.s-address != O/S_sender(packet)) then
                /* O/S report of sender not who claims to have sent it */
                error_out(KRB_AP_ERR_BADADDR);
        endif
        if ((packet.r-address is present) and
            (packet.r-address != local_host_address)) then
                /* was not sent to proper place */
                error_out(KRB_AP_ERR_BADADDR);
        endif
        if (not in_clock_skew(packet.timestamp,packet.usec)) then
                error_out(KRB_AP_ERR_SKEW);
        endif
        if (repeated(packet.timestamp,packet.usec,packet.s-address)) then
                error_out(KRB_AP_ERR_REPEAT);
        endif
        if (packet.nonce is required or present) and
           (packet.nonce != expected-nonce) then
                error_out(KRB_AP_ERR_MODIFIED);
        endif

        for (ticket[n] in tickets that were forwarded) do
                save_for_later(ticket[n],key[n],principal[n],
                               server[n],times[n],flags[n]);
        return

A.20.  KRB_ERROR generation

        /* assemble packet: */
        packet.pvno := protocol version; /* 5 */
        packet.msg-type := message type; /* KRB_ERROR */

        get system_time;
        packet.stime, packet.susec := system_time;
        packet.realm, packet.sname := server name;

        if (client time available) then


Section A.20.             - 118 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


                packet.ctime, packet.cusec := client_time;
        endif
        packet.error-code := error code;
        if (client name available) then
                packet.cname, packet.crealm := client name;
        endif
        if (error text available) then
                packet.e-text := error text;
        endif
        if (error data available) then
                packet.e-data := error data;
        endif












































                          - 119 -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


























































                          - cxx -    Expires 11 January 1998
\f









                     Table of Contents




Overview ..............................................    2

Background ............................................    2

1. Introduction .......................................    3

1.1. Cross-Realm Operation ............................    5

1.2. Authorization ....................................    6

1.3. Environmental assumptions ........................    7

1.4. Glossary of terms ................................    8

2. Ticket flag uses and requests ......................   10

2.1. Initial and pre-authenticated tickets ............   10

2.2. Invalid tickets ..................................   11

2.3. Renewable tickets ................................   11

2.4. Postdated tickets ................................   12

2.5. Proxiable and proxy tickets ......................   12

2.6. Forwardable tickets ..............................   13

2.7. Other KDC options ................................   14

3. Message Exchanges ..................................   14

3.1. The Authentication Service Exchange ..............   14

3.1.1. Generation of KRB_AS_REQ message ...............   16

3.1.2. Receipt of KRB_AS_REQ message ..................   16

3.1.3. Generation of KRB_AS_REP message ...............   16

3.1.4. Generation of KRB_ERROR message ................   19

3.1.5. Receipt of KRB_AS_REP message ..................   19

3.1.6. Receipt of KRB_ERROR message ...................   19

3.2. The Client/Server Authentication Exchange ........   19

3.2.1. The KRB_AP_REQ message .........................   20


                           - i -     Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


3.2.2. Generation of a KRB_AP_REQ message .............   20

3.2.3. Receipt of KRB_AP_REQ message ..................   21

3.2.4. Generation of a KRB_AP_REP message .............   23

3.2.5. Receipt of KRB_AP_REP message ..................   23

3.2.6. Using the encryption key .......................   24

3.3. The Ticket-Granting Service (TGS) Exchange .......   25

3.3.1. Generation of KRB_TGS_REQ message ..............   26

3.3.2. Receipt of KRB_TGS_REQ message .................   27

3.3.3. Generation of KRB_TGS_REP message ..............   28

3.3.3.1. Checking for revoked tickets .................   30

3.3.3.2. Encoding the transited field .................   30

3.3.4. Receipt of KRB_TGS_REP message .................   32

3.4. The KRB_SAFE Exchange ............................   32

3.4.1. Generation of a KRB_SAFE message ...............   32

3.4.2. Receipt of KRB_SAFE message ....................   33

3.5. The KRB_PRIV Exchange ............................   34

3.5.1. Generation of a KRB_PRIV message ...............   34

3.5.2. Receipt of KRB_PRIV message ....................   34

3.6. The KRB_CRED Exchange ............................   35

3.6.1. Generation of a KRB_CRED message ...............   35

3.6.2. Receipt of KRB_CRED message ....................   35

4. The Kerberos Database ..............................   36

4.1. Database contents ................................   36

4.2. Additional fields ................................   37

4.3. Frequently Changing Fields .......................   38

4.4. Site Constants ...................................   39

5. Message Specifications .............................   39



                           - ii -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


5.1. ASN.1 Distinguished Encoding Representation ......   39

5.2. ASN.1 Base Definitions ...........................   40

5.3. Tickets and Authenticators .......................   43

5.3.1. Tickets ........................................   43

5.3.2. Authenticators .................................   52

5.4. Specifications for the AS and TGS exchanges ......   54

5.4.1. KRB_KDC_REQ definition .........................   54

5.4.2. KRB_KDC_REP definition .........................   61

5.5. Client/Server (CS) message specifications ........   64

5.5.1. KRB_AP_REQ definition ..........................   64

5.5.2. KRB_AP_REP definition ..........................   65

5.5.3. Error message reply ............................   67

5.6. KRB_SAFE message specification ...................   67

5.6.1. KRB_SAFE definition ............................   67

5.7. KRB_PRIV message specification ...................   68

5.7.1. KRB_PRIV definition ............................   68

5.8. KRB_CRED message specification ...................   69

5.8.1. KRB_CRED definition ............................   70

5.9. Error message specification ......................   72

5.9.1. KRB_ERROR definition ...........................   72

6. Encryption and Checksum Specifications .............   74

6.1. Encryption Specifications ........................   76

6.2. Encryption Keys ..................................   78

6.3. Encryption Systems ...............................   78

6.3.1. The NULL Encryption System (null) ..............   78

6.3.2. DES in CBC mode with a CRC-32 checksum (des-
cbc-crc) ..............................................   79

6.3.3. DES in CBC mode with an MD4 checksum (des-


                          - iii -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


cbc-md4) ..............................................   79

6.3.4. DES in CBC mode with an MD5 checksum (des-
cbc-md5) ..............................................   79

6.3.5. Triple DES EDE in outer CBC mode with an SHA1
checksum (des3-cbc-sha1) ..............................   81

6.4. Checksums ........................................   83

6.4.1. The CRC-32 Checksum (crc32) ....................   84

6.4.2. The RSA MD4 Checksum (rsa-md4) .................   84

6.4.3. RSA MD4 Cryptographic Checksum Using DES
(rsa-md4-des) .........................................   84

6.4.4. The RSA MD5 Checksum (rsa-md5) .................   85

6.4.5. RSA MD5 Cryptographic Checksum Using DES
(rsa-md5-des) .........................................   85

6.4.6. DES cipher-block chained checksum (des-mac)

6.4.7. RSA MD4 Cryptographic Checksum Using DES
alternative (rsa-md4-des-k) ...........................   86

6.4.8. DES cipher-block chained checksum alternative
(des-mac-k) ...........................................   87

7. Naming Constraints .................................   87

7.1. Realm Names ......................................   87

7.2. Principal Names ..................................   88

7.2.1. Name of server principals ......................   89

8. Constants and other defined values .................   90

8.1. Host address types ...............................   90

8.2. KDC messages .....................................   91

8.2.1. IP transport ...................................   91

8.2.2. OSI transport ..................................   91

8.2.3. Name of the TGS ................................   92

8.3. Protocol constants and associated values .........   92

9. Interoperability requirements ......................   95



                           - iv -    Expires 11 January 1998
\f






            Version 5 - Specification Revision 6


9.1. Specification 1 ..................................   95

9.2. Recommended KDC values ...........................   97

10. REFERENCES ........................................   98

A. Pseudo-code for protocol processing ................  100

A.1. KRB_AS_REQ generation ............................  100

A.2. KRB_AS_REQ verification and KRB_AS_REP genera-
tion ..................................................  100

A.3. KRB_AS_REP verification ..........................  104

A.4. KRB_AS_REP and KRB_TGS_REP common checks .........  104

A.5. KRB_TGS_REQ generation ...........................  105

A.6. KRB_TGS_REQ verification and KRB_TGS_REP gen-
eration ...............................................  106

A.7. KRB_TGS_REP verification .........................  111

A.8. Authenticator generation .........................  112

A.9. KRB_AP_REQ generation ............................  112

A.10. KRB_AP_REQ verification .........................  112

A.11. KRB_AP_REP generation ...........................  113

A.12. KRB_AP_REP verification .........................  114

A.13. KRB_SAFE generation .............................  114

A.14. KRB_SAFE verification ...........................  115

A.15. KRB_SAFE and KRB_PRIV common checks .............  115

A.16. KRB_PRIV generation .............................  116

A.17. KRB_PRIV verification ...........................  116

A.18. KRB_CRED generation .............................  117

A.19. KRB_CRED verification ...........................  118

A.20. KRB_ERROR generation ............................  118







                           - v -     Expires 11 January 1998