Subject: Section 5 Kerberos Revisions for comment

From: Clifford Neuman <[email-masked]>
Date: Wed, 13 Sep 2000 00:26:51 -0700 (PDT)

<H3>5.  Message Specifications</H3>

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

<H4>Optional field in ASN.1 sequences</H4>

For optional integer value and date fields in ASN.1 sequences where a
default value has been specified, certain default values will not be
allowed in the encoding because these values will always be represented
through defaulting by the absence of the optional field.  For example,
one will not send a microsecond zero value because one must make sure
that there is only one way to encode this value. 

<H4>Additional fields in ASN.1 sequences</H4>

Implementations receiving Kerberos messages with additional fields
present in ASN.1 sequences should carry those fields through,
unmodified, when the message is forwarded.  Implementations should not
drop such fields if the sequence is re-encoded.

<H3>5.1.  ASN.1 Distinguished Encoding Representation</H3>

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

<H3>5.2.  ASN.1 Base Definitions</H3>

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

<PRE><B>
Realm ::=           GeneralString
PrincipalName ::=   SEQUENCE {
                    name-type[0]     INTEGER,
                    name-string[1]   SEQUENCE OF GeneralString
}
</B></PRE>

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 components
consisting of the following sub-fields:

<DL>

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

<DT>name-string <DD>This field encodes a sequence of components that
form a name, each component encoded as a GeneralString.  Taken
together, a PrincipalName and a Realm form a principal identifier.
Most PrincipalNames will have only a few components (typically one or
two).

</DL>

<PRE><B>
KerberosTime ::=   GeneralizedTime
                   -- Specifying UTC time zone (Z)
</B></PRE>

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

<PRE><B>
HostAddress ::=     SEQUENCE  {
                    addr-type[0]             INTEGER,
                    address[1]               OCTET STRING
}

HostAddresses ::=   SEQUENCE OF HostAddress

</B></PRE>

The host address encodings consists of two fields:

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

<DT>address <DD>This field encodes a single address of type  addr-type.

</DL>

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

<PRE><B>
AuthorizationData ::=   SEQUENCE OF SEQUENCE {
                        ad-type[0]               INTEGER,
                        ad-data[1]               OCTET STRING
}
</B></PRE>

<DL>

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

<DT>ad-type <DD>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.

</DL>

Each sequence of type and data is referred to as an authorization
element.  Elements may be application specific, however, there is a
common set of recursive elements that should be understood by all
implementations.  These elements contain other elements embedded
within them, and the interpretation of the encapsulating element
determines which of the embedded elements must be interpreted, and
which may be ignored.  Definitions for these common elements may be
found in <A HREF="#ap_adata">Appendix B</A>.

<PRE><B>

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

</B> </PRE>

<DL>

<DT>te-data <DD>This field contains opaque data that must be carried
with the ticket to support extensions to the Kerberos protocol
including but not limited to some forms of inter-realm key exchange
and plaintext authorization data.  See appendix C for some common uses
of this field.

<DT>te-type <DD>This field specifies the format for the te-data
subfield.  All negative values are reserved for local use.
Non-negative values are reserved for registered use.

</DL>

<PRE><B>
APOptions ::=   BIT STRING 
                  -- reserved(0),
                  -- use-session-key(1),
                  -- mutual-required(2)

TicketFlags ::= BIT STRING 
                  -- reserved(0),
                  -- forwardable(1),
                  -- forwarded(2),
                  -- proxiable(3),
                  -- proxy(4),
                  -- may-postdate(5),
                  -- postdated(6),
                  -- invalid(7),
                  -- renewable(8),
                  -- initial(9),
                  -- pre-authent(10),
                  -- hw-authent(11),
                  -- transited-policy-checked(12),
                  -- ok-as-delegate(13)

KDCOptions ::=   BIT STRING io
                  -- 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),
                  -- requestanonymous(14), 
                  -- canonicalize(15), 
                  -- disable-transited-check(26),
                  -- renewable-ok(27),
                  -- enc-tkt-in-skey(28),
                  -- renew(30),
                  -- validate(31)
</B></PRE>

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 number of bits needed to
include the highest order bit that is set (1), but in no case less than
32 bits.  The ASN.1 representation of the bit strings uses unnamed bits,
with the meaning of the individual bits defined by the comments in the
specification above.  Implementations should accept values of bit
strings of any length and treat the value of flags corresponding to bits
beyond the end of the bit string as if the bit were reset (0).
Comparison of 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]. 

<PRE><B>
LastReq ::=   SEQUENCE OF SEQUENCE {
               lr-type[0]               INTEGER,
               lr-value[1]              KerberosTime
}
</B></PRE>

<DL>
<DT>lr-type <DD>This field indicates how the following lr-value field
is to be interpreted.  Negative values indicate that the information
pertains only to the responding server.  Non-negative values pertain
to all servers for the realm.

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

<DT>lr-value <DD>This field contains the time of the last  request.
the time must be interpreted according to the contents of the
accompanying lr-type subfield. 

</DL>

See section 6 for the definitions of Checksum, ChecksumType,
EncryptedData, EncryptionKey, EncryptionType, and KeyType.

<H3>5.3.  Tickets and Authenticators</H3>

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

<H4>5.3.1.  Tickets</H4>

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

<PRE><B>
Ticket ::=        [APPLICATION 1] SEQUENCE {
                  tkt-vno[0]                   INTEGER,
                  realm[1]                     Realm,
                  sname[2]                     PrincipalName,
                  enc-part[3]                  EncryptedData, -- EncTicketPart
		  extensions[4]		       TicketExtensions OPTIONAL
}

-- 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
}
</B></PRE>

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.

<DL>

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

<DT>realm <DD>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 identical.

<DT>sname <DD>This field specifies all components of the name part
of the server's identity, including those parts that identify a
specific instance of a service.

<DT>enc-part <DD>This field holds the  encrypted  encoding  of  the
EncTicketPart sequence.

<DT>extensions <DD>This optional field contains a sequence of extensions
that may be used to carry information that must be carried with the
ticket to support several extensions, including but not limited to
plaintext authorization data, tokens for exchanging inter-realm keys,
and other information that must be associated with a ticket for use by
the application server.  See Appendix C for definitions of common
extensions.

<P>

Note that some older versions of Kerberos did not support this field.
Because this is an optional field it will not break older clients, but
older clients might strip this field from the ticket before sending it
to the application server.  This limits the usefulness of this ticket
field to environments where the ticket will not be parsed and
reconstructed by these older Kerberos clients. 

<P>

If it is known that the client will strip this field from the ticket,
as an interim measure the KDC may append this field to the end of the
enc-part of the ticket and append a trailer indicating the length of
the appended extensions field.  

<DT>flags <DD>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:

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

     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.

     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.

     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.

     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.
</PRE>

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

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

<DT>cname <DD>This field contains the name part of the  client's
principal identifier.

<DT>transited <DD>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.  When the names of CA's are to be embedded in the transited field
(as specified for some extensions to the protocol), the X.500 names of
the CA's should be mapped into items in the transited field using the
mapping defined by RFC2253.

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

This field is also returned as part of the response from the KDC.
When returned as part of the response to initial authentication
(KRB_AS_REP), this is the current time on the Kerberos server[24].

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

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

<DT>renew-till <DD>This field is only present in tickets that have the
RENEWABLE flag set in the flags field.  It indicates the maximum
endtime that may be included in a renewal.  It can be thought of as
the absolute expiration time for the ticket, including all renewals.

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

<P>

Network addresses are included in the ticket to make it harder for an
attacker to use stolen credentials.  Because the session key is not
sent over the network in cleartext, credentials can't be stolen simply
by listening to the network; an attacker has to gain access to the
session key (perhaps through operating system security breaches or a
careless user's unattended session) to make use of stolen tickets.

<P>

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

<DT>authorization-data <DD> The authorization-data field is used to
pass authorization data from the principal on whose behalf a ticket
was issued to the application service.  If no authorization data is
included, this field will be left out.  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.  

<P>

This field contains restrictions on any authority obtained on the
basis 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
additional entries when a new ticket is obtained during the TGS
exchange, or they may be added during chained delegation using the
authorization data field of the authenticator.

<P>

Because entries may be added to this field by the holder of
credentials, except when an entry is separately authenticated by
encapsulation in the kdc-issued element, it is not allowable for the
presence of an entry in the authorization data field of a ticket to
amplify the privileges one would obtain from using a ticket.

<P>

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

<P>

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.

<P>

A separate service providing authorization or certifying group
membership may be built using the authorization-data field.  In this
case, the entity granting authorization (not the authorized entity),
may obtain a ticket in its own name (e.g.  the ticket is issued in the
name of a privilege server), and this entity adds restrictions on its
own authority and delegates the restricted authority through a proxy
to the client.  The client would then present this authorization
credential to the application server separately from the
authentication exchange.  Alternatively, such authorization
credentials may be embedded in the ticket authenticating the
authorized entity, when the authorization is separately authenticated
using the kdc-issued authorization data element (see B.4).

<P>

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 [Neu93] for some suggested uses
of this field.

<P>

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

</DL>

<H4>5.3.2.  Authenticators</H4>

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:

<PRE><B>
-- 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
}
</B> </PRE>

<DL>
<DT>authenticator-vno <DD> This field specifies the version number for
the format of the authenticator.  This document specifies version 5.

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

<DT>cksum <DD>This field contains a checksum of the the application
data that accompanies the KRB_AP_REQ.

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

<DT>ctime <DD>This  field  contains  the  current  time  on  the
client's host.

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

<DT>seq-number <DD>This optional field includes the initial sequence
number to be used by the KRB_PRIV or KRB_SAFE messages when sequence
numbers are used to detect replays (It may also be used by application
specific messages).  When included in the authenticator this field
specifies the initial sequence number for messages from the client to
the server.  When included in the AP-REP message, the initial sequence
number is that for messages from the server to the client.  When used
in KRB_PRIV or KRB_SAFE messages, it is incremented by one after each
message is sent.  Sequence numbers fall in the range of 0 through
2^32 - 1 and wrap to zero following the value 2^32 - 1.

<P>

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.

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

</DL>

<H3>5.4.  Specifications for the AS and TGS exchanges</H3>

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.

<H4>5.4.1.  KRB_KDC_REQ definition</H4>

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.

<P>

The message fields are:

<PRE><B>

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
                    addresses[9]           HostAddresses OPTIONAL,
                enc-authorization-data[10] EncryptedData OPTIONAL,
                                           -- Encrypted AuthorizationData 
                                           -- encoding
                    additional-tickets[11] SEQUENCE OF Ticket OPTIONAL
}

</B></PRE>

The fields in this message are:

<DL>

<DT>pvno <DD>This field is included in each message, and specifies the
protocol version number.  This document specifies protocol version 5.

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

<DT>padata <DD>The padata (pre-authentication data) field contains 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
authentication (KRB_AS_REQ) and most replies (KDC-REP), the padata
field will be left out.
<P>
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.  When
this field is used to authenticate or pre-authenticate a request, it
should contain a keyed checksum over the KDC-REQ-BODY to bind the
pre-authentication data to rest of the request.  The KDC, as a matter
of policy, may decide whether to honor a KDC-REQ which includes any
pre-authentication data that does not contain the checksum field.
<P>     
PA-ENC-TIMESTAMP defines a pre-authentication data type that is used
for authenticating a client by way of an encrypted timestamp.  This is
accomplished with a padata field with padata-type equal to
PA-ENC-TIMESTAMP and padata-value defined as follows (query: the
checksum is new in this definition.  If the optional field will break
things we can keep the old PA-ENC-TS-ENC, and define a new alternate
form that includes the checksum).  :

<PRE><B>
     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, 
                     pachecksum[2]      checksum OPTIONAL 
                                        -- keyed checksum of KDC-REQ-BODY 
     } 
</B></PRE>

with patimestamp containing the client's time and pausec containing
the microseconds which may be omitted if a client will not generate
more than one request per second.  The ciphertext (padata-value)
consists of the PA-ENC-TS-ENC sequence, encrypted using the client's
secret key.
<P>
It may also be used by the client to specify the version of a key that
is being used for accompanying preauthentication, and/or which should
be used to encrypt the reply from the KDC.

<PRE><B>
     padata-type     ::= PA-USE-SPECIFIED-KVNO 
     padata-value    ::= Integer
     } 
</B></PRE>

The KDC should only accept and abide by the value of the
use-specified-kvno preauthentication data field when the specified key
is still valid and until use of a new key is confirmed.  This
situation is likely to occur primarily during the period during which
an updated key is propagating to other KDC's in a realm.
<P>
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 [Pat92] for additional uses of this
field.

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

<DT>req-body <DD>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.

<DT>kdc-options <DD>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.
<P>
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:

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

    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       RESERVED             
                                 Reserved for PK-Cross

    10-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      CANONICALIZE         
                                 The CANONICALIZE option indicates that
                                 the client will accept the return of a 
                                 true server name instead of the name
                                 specified in the request. In addition
                                 the client will be able to process
                                 any TGT referrals that will direct
                                 the client to another realm to locate
                                 the requested server. If a KDC does
                                 not support name- canonicalization,
                                 the option is ignored and the
                                 appropriate
                                 KDC_ERR_C_PRINCIPAL_UNKNOWN or
                                 KDC_ERR_S_PRINCIPAL_UNKNOWN error is
                                 returned. [JBrezak]

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

    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.
</PRE>

<DT>cname and sname <DD> These fields are the same as those described
for the ticket in section 5.3.1.  sname may only be absent when the
ENC-TKT-IN-SKEY option is specified.  If absent, the name of the
server is taken from the name of the client in the ticket passed as
additional-tickets.

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

<DT>realm <DD>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.  If the CANONICALIZE option is
set, the realm is used as a hint to the KDC for its database lookup.

<DT>from <DD>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.  If this
field is omitted then the KDC should use the current time instead.

<DT>till <DD>This field contains the expiration date requested by the
client in a ticket request.  It is optional 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.

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

<DT>nonce <DD>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
generated randomly, but if the correct time is known, it may
suffice[25].

<DT>etype <DD>This field specifies the desired encryption algorithm to
be used in the response.

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

<DT>additional-tickets <DD>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.  When he ENC-TKT-IN-SKEY option is used for
user-to-user authentication, this addional ticket may be a TGT issued
by the local realm or an inter-realm TGT issued for the current KDC's
realm by a remote KDC.  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).

</DL>

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

<P>

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

<P>

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.

<H4>5.4.2.  KRB_KDC_REP definition</H4>

The KRB_KDC_REP message format is used for the reply from the KDC for
either an initial (AS) request or a subsequent (TGS) request.  There
is no message type for KRB_KDC_REP.  Instead, the type will be either
KRB_AS_REP or KRB_TGS_REP.  The key used to encrypt the ciphertext
part of the reply depends on the message type.  For KRB_AS_REP, the
ciphertext is encrypted in the client's secret key, and the client's
key version number is included in the key version number for the
encrypted data.  For KRB_TGS_REP, the ciphertext is encrypted in the
sub-session key from the Authenticator, or if absent, the session key
from the ticket-granting ticket used in the request.  In that case, no
version number will be present in the EncryptedData sequence.

<P>

The KRB_KDC_REP message contains the following fields:

<PRE><B>
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 or EncTGSReoOart
}

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
}

</B></PRE>

<DL>
<DT>pvno and msg-type <DD>These fields are described above in section 5.4.1.
msg-type is either KRB_AS_REP or KRB_TGS_REP.

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

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

<DT>ticket <DD>The newly-issued ticket, from section 5.3.1.

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

<DT>key <DD>This field is the same as described for the ticket
in section 5.3.1.

<DT>last-req <DD>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.

<DT>nonce <DD>This field is described above in section 5.4.1.

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

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

</DL>

<H3>5.5.  Client/Server (CS) message specifications</H3>

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

<H4>5.5.1.  KRB_AP_REQ definition</H4>

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

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

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

</B> </PRE>

<DL>
<DT>pvno and msg-type <DD>
These fields are described above in section 5.4.1.
msg-type is KRB_AP_REQ.

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

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

</PRE>

<DT>ticket <DD>This field is a ticket authenticating the client to the
server.

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

</DL>

<H4>5.5.2.  KRB_AP_REP definition</H4>

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 has been selected in the ap-options field.

<PRE><B>

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

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

</B></PRE>

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

<DL>
<DT>pvno and msg-type <DD>These fields are described above in section 5.4.1.
msg-type is KRB_AP_REP.

<DT>enc-part <DD>This field is described above in section 5.4.2.

<DT>ctime <DD>This  field  contains  the  current  time  on  the
client's host.

<DT>cusec <DD>This field contains the microsecond  part  of  the
client's timestamp.

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

<DT>seq-number <DD>This field is described above in section 5.3.2.

</DL>

<H4>5.5.3.  Error message reply</H4>

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.

<H4>5.6.  KRB_SAFE message specification</H4>

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

<H4>5.6.1.  KRB_SAFE definition</H4>

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 occurred.  The message fields
are:

<PRE><B>
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
}

</B></PRE>

<DL>
<DT>pvno and msg-type <DD>These fields are described above in section 5.4.1.
msg-type is KRB_SAFE.

<DT>safe-body <DD>This field is a placeholder for the body of the
KRB-SAFE message. 

<DT>cksum <DD>This field contains the checksum of the application
data.  Checksum details are described in section 6.4.  The checksum is
computed over the encoding of the KRB-SAFE sequence.  First, the cksum
is zeroed and the checksum is computed over the encoding of the
KRB-SAFE sequence, then the checksum is set to the result of that
computation, and finally the KRB-SAFE sequence is encoded again.

<DT>user-data <DD>This field is part of the KRB_SAFE and KRB_PRIV
messages and contain the application specific data that is being
passed from the sender to the recipient.

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

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

<DT>seq-number <DD>This field is described above in section 5.3.2.

<DT>s-address <DD>This field specifies the address in use by the
sender of the message.  It may be omitted if not required by the
application protocol.  The application designer considering omission
of this field is warned, that the inclusion of this address prevents
some kinds of replay attacks (e.g., reflection attacks) and that it is
only acceptable to omit this address if there is sufficient
information in the integrity protected part of the application message
for the recipient to unambiguously determine if it was the intended
recipient. 

<DT>r-address <DD>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.

</DL>

<H3>5.7.  KRB_PRIV message specification</H3>

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

<H4>5.7.1.  KRB_PRIV definition</H4>

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

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

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
}
</B></PRE>

<DL>
<DT>pvno and msg-type <DD> These fields are described above in section
5.4.1.  msg-type is KRB_PRIV.

<DT>enc-part <DD>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.

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

<DT>seq-number <DD>This field is described above in section 5.3.2.

</DL>

<H3>5.8.  KRB_CRED message specification</H3>

This section specifies the format of a message that can be used to
send Kerberos credentials from one principal to another.  It is
presented here to encourage a common mechanism to be used by
applications when forwarding tickets or providing proxies to
subordinate servers.  It presumes that a session key has already been
exchanged perhaps by using the KRB_AP_REQ/KRB_AP_REP messages.

<H4>5.8.1.  KRB_CRED definition</H4>

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:

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

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
}

</B></PRE>

<DL>

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

<DT>tickets <DD>These are the tickets obtained from the KDC
specifically for use by the intended recipient.  Successive tickets
are paired with the corresponding KrbCredInfo sequence from the
enc-part of the KRB-CRED message.

<DT>enc-part <DD>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.

<DT>nonce <DD>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 message in
an application specific manner.

<DT>timestamp and usec <DD> These fields specify the time that the
KRB-CRED message was generated.  The time is used to provide assurance
that the message is fresh.

<DT>s-address and r-address <DD> These fields are described above in
section 5.6.1.  They are used optionally to provide additional
assurance of the integrity of the KRB-CRED message.

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

</DL>

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.

<DL>

<DT>prealm and pname <DD> The name and realm of the delegated
principal identity.

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

</DL>

<H3>5.9.  Error message specification</H3>

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.

<P>

Note that since the KRB_ERROR message is only optionally integrity
protected, it is quite possible for an intruder to synthesize or
modify such a message.  In particular, this means that unless
appropriate integrity protection mechanisms have been applied to the
KRB_ERROR message, the client should not use any fields in this
message for security-critical purposes, such as setting a system clock
or generating a fresh authenticator.  The message can be useful,
however, for advising a user on the reason for some failure.

<H4>5.9.1.  KRB_ERROR definition</H4>

The KRB_ERROR message consists of the following fields:
<PRE><B>
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,
}

</B> </PRE>

<DL>

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

<DT>ctime <DD>This field is described above in section 5.4.1.

<DT>cusec <DD>This field is described above in section 5.5.2.

<DT>stime <DD>This  field  contains  the  current  time  on  the
server.  It is of type KerberosTime.

<DT>susec <DD>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 reasonably
accurate timestamp.

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

<DT>crealm, cname, srealm and sname <DD>These fields are described
above in section 5.3.1.

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

<DT>e-data <DD>This field contains additional data about the error for
use by the application to help it recover from or handle the error.
If present, this field will contain the encoding of a sequence of
TypedData (TYPED-DATA below), unless the errorcode is
KDC_ERR_PREAUTH_REQUIRED, in which case it will contain the encoding
of a sequence of of padata fields (METHOD-DATA below), each
corresponding to an acceptable pre-authentication method and
optionally containing data for the method:

<PRE><B>
TYPED-DATA   ::=   SEQUENCE of TypeData
METHOD-DATA  ::=   SEQUENCE of PA-DATA

TypedData ::=   SEQUENCE {
                    data-type[0]   INTEGER,
                    data-value[1]  OCTET STRING OPTIONAL
}

</B></PRE> 

Note that the padata-type field in the PA-DATA structure and the
data-type field in the TypedData structure share a common range of
allocated values which are coordinated to avoid conflicts.  One
Kerberos error message, KDC_ERR_PREAUTH_REQUIRED, embeds elements of
type PA-DATA, while all other error messages embed TypedData.  
<P>

While preauthentication methods of type PA-DATA should be encapsulated
within a TypedData element of type TD-PADATA, for compatibility with
old clients, the KDC should include PA-DATA types below 22 directly as
method-data.  All new implementations interpreting the METHOD-DATA
field for the KDC_ERR_PREAUTH_REQUIRED message must accept a type of
TD-PADATA, extract the typed data field and interpret the use any
elements encapsulated in the TD-PADATA elements as if they were
present in the METHOD-DATA sequence.

<DT>e-cksum <DD>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 message with the checksum absent.  The
checksum is then added to the KRB-ERROR structure and the message is
re-encoded.  The Checksum should be calculated using the session key
from the ticket granting ticket or service ticket, where available.
If the error is in response to a TGS or AP request, the checksum
should be calculated using 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 preauthentication to prove knowledge of the
secret key by the client[33].  If a checksum can not be computed
because the key to be used is not available, no checksum will be
included.

---
Commentary:

A statement regarding the carrying of unrecognized additional fields
in ASN.1 encoding through in tickets was added (still waiting on some
better text regarding this).  

Ticket flags and KDC options were added
to support the new functions described elsewhere in this document.  The
encoding of the options flags are now described to be no less than 32
bits, and the smallest number of bits beyond 32 needed to encode any
set bits.  It also describes the encoding of the bitstring as using
"unnamed" bits.  

An optional ticket extensions field was added to support the carrying
of auxiliary data that allows the passing of auxiliary that is to
accompany a ticket to the verifier.  

(I would like to drop the part about optionally appending it of the
opaque part of the ciphertext.  We are still waiting on some text
regarding how to assure backward compatibility).

(Still pending, Tom Yu's request to change the application codes on
KDC message to indicate which minor rev of the protocol - I think this
might break things, but am not sure).

Definition of the PA-USE-SPECIFIED-KVNO preauthentication data field
was added.

The optional e-cksum field was added to the KRB-ERROR message and the
e-data filed was generalized for use in other than the
KDC_ERR_PREAUTH_REQUIRED error.  The TypedData structure was defined.
Type tags for TypedData are defined in the same sequence as the
PA-DATA type space to avoid confusion with the use of the PA-DATA
namespace previously used for the e-data field for the
KDC_ERR_PREAUTH_REQUIRED error.

---

From: Tom Yu <[email-masked]>
Date: 22 Sep 2000 21:45:45 -0400

Just so you're warned, this is going to be really long... I have tried
to only quote relevant material to shorten this somewhat.

>>>>> "bcn" == Clifford Neuman <[email-masked]> writes:

bcn> <H3>5.  Message Specifications</H3>

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

The ASN.1 definitions should be collected together somewhere in the
document in the form of a proper ASN.1 module.  It is not correct to
merely give lone type definitions, since the tagging and extensibility
contexts in which they must be interpreted will be missing.  At the
very least, we want something that looks roughly like this at the
head of the definitions:

    Kerberos5 { iso (1) org (3) dod (6) internet (1)
        security (5) kerberos5 (2) } DEFINITIONS
        EXTENSIBILITY IMPLIED ::= BEGIN

(or maybe it should be KerberosV5 and kerberosV5?  I prefer Kerberos5
myself, and it's not going to change bits on the wire in any case.)

Incidentally, the OID in RFC 1510 is incorrect; it shows a value of 5
for the "dod" arc of the OID.  It's also invalid ASN.1 syntax, but
we'll get to that when we get to that later section when it gets sent
out for comment, I think.

bcn> <H4>Optional field in ASN.1 sequences</H4>

bcn> For optional integer value and date fields in ASN.1 sequences
bcn> where a default value has been specified, certain default values
bcn> will not be allowed in the encoding because these values will
bcn> always be represented through defaulting by the absence of the
bcn> optional field.  For example, one will not send a microsecond
bcn> zero value because one must make sure that there is only one way
bcn> to encode this value.

This text is confusing and needs rewriting in terms that more
precisely describe what is going on with respect to ASN.1 syntax.  In
addition, if we really want to force a canonical representation, then
we must mandate the use of the "DEFAULT" construct of the ASN.1
notation, which basically behaves like "OPTIONAL" except that when the
value is omitted in the encoding, the actual value received is the
value following the "DEFAULT" keyword.  The DER rules require that if
the sender transmits a value that is equal to the default, the
encoding omits the value.

This may need some discussion, in particular to identify which fields
would be modified in this manner.  On the other hand, if we change the
notation to use the "DEFAULT" keyword, implementations that send
e.g. a microseconds value of zero rather than omitting the value will
produce an error in a strict parser, so we have to consider that
factor.

The main factors here are the microseconds field in several places.  I
have noted below which ones I know that the MIT implementation omits a
zero microseconds value, as well as where it will only omit a
microseconds value where the corresponding timestamp is missing.

bcn> <H4>Additional fields in ASN.1 sequences</H4>

bcn> Implementations receiving Kerberos messages with additional
bcn> fields present in ASN.1 sequences should carry those fields
bcn> through, unmodified, when the message is forwarded.
bcn> Implementations should not drop such fields if the sequence is
bcn> re-encoded.

We need to make the decision whether to use the implicit extensibilty
syntax of ASN.1 to make this clear from an ASN.1 viewpoint.  Also,
additional fields in ASN.1 composite types need to be separated with
an extension marker, "...", in the actual syntax.

bcn> <H3>5.1.  ASN.1 Distinguished Encoding Representation</H3>

bcn> All uses of ASN.1 in Kerberos shall use the Distinguished
bcn> Encoding Representation of the data elements as described in the
bcn> X.509 specification, section 8.7 [X509-88].

This should probably reference the current ASN.1 BER/DER/CER
specifications, X.690 (1997) rather than X.509.  Actually, we should
update all references to the ASN.1 specs to refer to the current
versions.

bcn> <H3>5.2.  ASN.1 Base Definitions</H3>

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

As per discussion at the Pittsburgh IETF, we should define a
KerberosString, which will be a gross thing that is tagged as a
GeneralString but actually encodes a UTF8String.  Potential text for
inclusion here follows:

    Historical implementations of Kerberos cannot utilize the full
    power of GeneralString.  This ASN.1 type requires the use of
    designation and invocation escape sequences as specified in ISO
    2022 to switch character sets.  In practice, many implementations
    end up encoding ISO 8859-1 (Latin-1) strings into types declared
    as GeneralStrings, which is technically incorrect without an
    invocation escape sequence for the G1 character set of the
    encoding.  Also, DER prohibits the invocation of character sets
    into any but the G0 and C0 sets, which seems to outright prohibit
    the encoding of characters with the high bit set.  Unfortunately
    this seems to have the side effect of prohibiting the transmission
    of Latin-1 characters at all, since the character set defined in
    ISO 8859-1 is a 96-character set and cannot be invoked into G0.

    To reflect current practice and to allow for additional
    internationalization with less difficulty, we declare a
    KerberosString type that may not be represented in fully compliant
    ASN.1 notation, but which comes closest to the intended effect:

        KerberosString ::= [UNIVERSAL 27] IMPLICIT UTF8String
                           -- UNIVERSAL 27 is the tag of a GeneralString

    Note that the ASN.1 specification forbids the use of the UNIVERSAL
    class tag outside of the ASN.1 specification itself.  If the ASN.1
    compiler and utilities to be used by the implementation do not
    permit the use of the UNIVERSAL class tag in an application's
    syntax, the following definition may be used:

        KerberosString ::= GeneralString

    Declaring KerberosString to be a GeneralString must be done with
    caution, as the ASN.1 compiler and utilities may do some
    processing of values on their way to the encoder and from the
    decoder if the ASN.1 complier and utilities actually handle
    transformations between different character string types.

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

These should be modified to use KerberosString.  Whether the SEQUENCE
OF type should be constrained to contain at least one member (see
further discussion below), I'm not sure.  Someone may very well have a
use for a principal that contains zero components.

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

Replace "GeneralString" with "KerberosString"

I think that realms and principals shouldn't contain control
characters, including ASCII NUL.  Whether we want to actually make
explicit language to this effect is debatable.

bcn> <DT>name-string <DD>This field encodes a sequence of components
bcn> that form a name, each component encoded as a GeneralString.
bcn> Taken together, a PrincipalName and a Realm form a principal
bcn> identifier.  Most PrincipalNames will have only a few components
bcn> (typically one or two).

Replace "GeneralString" with "KerberosString".

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

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

The DER encoding rules already require GeneralizedTime to use the UTC
time zone.  The definition of GeneralizedTime prohibits the use of
separators.  We may wish to remove the explicit constraints here, or
perhaps restate the requirements of the ASN.1 spec.

DER permits fractional seconds, but states that trailing zeroes,
including the decimal point if there are no fractional seconds, must
be omitted.  We should retain the prohibition against fractional
seconds, as we do have a microseconds field.  We probably want
something like this:

    KerberosTime ::= GeneralizedTime
                     -- with no fractional seconds

Unfortunately, the formal constraint notation of ASN.1 isn't quite
powerful enough to express this constraint without jumping through
some hoops.  There is the possibility of this:

    KerberosTime ::= GeneralizedTime (SIZE (15))
                     -- the size constraint should force omission
                     -- of fractional seconds

but that is arguably somewhat twisted.  I also just discovered that
the prepublished Technical Corrigendum 2 to X.680 says that size
constraints can't be used on time types anyway.

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

bcn> HostAddresses ::=   SEQUENCE OF HostAddress

This probably wants to be:

    HostAddresses ::= SEQUENCE (SIZE (1..MAX)) OF HostAddress

Constraining SEQUENCE OF types to having at least one member is a good
idea.  Consider the ambiguity of something like:

    Foo ::= SEQUENCE {
        bar INTEGER,
        baz SEQUENCE OF SEQUENCE {
            quux INTEGER,
            foo2 INTEGER
        } OPTIONAL
    }

If we want to represent zero "baz" elements of a value of the "Foo"
type, we can either encode SEQUENCE OF with zero elements, or
completely fail to encode a SEQUENCE OF type at all.  This is not good
in terms of having a canonical representation, and I'm fairly certain
that the DER rules do not address this issue.  Of course, we should
establish what current implementations are doing, but I doubt that any
of them intentionally generate SEQUENCE OF encodings with no elements.

Ken Raeburn points out that there might be a useful semantic meaning
to sending an empty HostAddresses list... that being that no addresses
are ever valid for a ticket, for example, as opposed to the case where
there is no HostAddresses list sent at all, which would indicate that
any addreses are permitted.

The upshot of this is that we should evaluate all all the cases where
we have an optional field that is itself a SEQUENCE OF type and
establish semantics for omission of the field completely versus
including a zero-length field.

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

This should probably be:

    AuthorizationData ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
        ad-type     [0] INTEGER,
        ad-data     [1] OCTET STRING
    }

since I see no obvious semantic use in encoding an empty
AuthorizationData.

bcn> TicketExtensions ::= SEQUENCE OF SEQUENCE {
bcn>            te-type[0]       INTEGER,
bcn>            te-data[1]       OCTET STRING
bcn> }

Likewise, this probably should be:

    TicketExtensions ::= SEQUENCE (SIZE (1..MAX)) of SEQUENCE {
        te-type     [0] INTEGER,
        te-data     [1] OCTET STRING
    }

Insert the following definition before the uses of bit strings:

    KerberosFlags ::= BIT STRING (SIZE (32..MAX))

bcn> APOptions ::=   BIT STRING 

This should be:

    APOptions ::= KerberosFlags

Comments for bit names should remain but have been deleted here.

bcn> TicketFlags ::= BIT STRING 

This should be:

    TicketFlags ::= KerberosFlags

Comments for bit names should remain but have been deleted here.

bcn> KDCOptions ::=   BIT STRING io

This should be:

    KDCOptions ::= KerberosFlags

I'm not sure where the "io" came from, but it's definitely wrong. :-)

Comments for bit names should remain but have been deleted here.

bcn> ASN.1 Bit strings have a length and a value.  When used in
bcn> Kerberos for the APOptions, TicketFlags, and KDCOptions, the
bcn> length of the bit string on generated values should be the
bcn> smallest number of bits needed to include the highest order bit
bcn> that is set (1), but in no case less than 32 bits.  The ASN.1
bcn> representation of the bit strings uses unnamed bits, with the
bcn> meaning of the individual bits defined by the comments in the
bcn> specification above.  Implementations should accept values of bit
bcn> strings of any length and treat the value of flags corresponding
bcn> to bits beyond the end of the bit string as if the bit were reset
bcn> (0).  Comparison of bit strings of different length should treat
bcn> the smaller string as if it were padded with zeros beyond the
bcn> high order bits to the length of the longer string[23].

Strike this whole paragraph and replace with the following:

    ASN.1 bit strings have multiple uses in ASN.1.  The simplest use
    of a bit string is to contain a vector of bits, with no particular
    meaning attached to individual bits.  This vector of bits is not
    necessarily a multiple of eight bits long.  The use in Kerberos of
    a bit string as a compact boolean vector wherein each element has
    a distinct meaning poses some problems.  The natural notation for
    a compact boolean vector is the ASN.1 "NamedBit" notation, and the
    DER require that encodings of a bit string using "NamedBit"
    notation exclude any trailing zero bits.  This truncation is easy
    to neglect, especially given C language implementations that may
    naturally choose to store boolean vectors as 32 bit integers.

    For example, if the notation for KDCOptions were to include the
    "NamedBit" notation, as in RFC 1510, and a KDCOptions value to be
    encoded had only the "forwardable" bit set, the DER encoding must
    only include two bits: the first reserved bit ("reserved", bit
    number zero, value zero) and the one-valued bit (bit number one)
    for "forwardable".

    Existing implementations of Kerberos unconditionally send 32 bits
    on the wire when encoding bit strings used as boolean vectors.
    This behavior violates the ASN.1 syntax used for flag values in
    RFC 1510, but occurs on such a widely installed base that the
    protocol description is being modified to accomodate it.

    Consequently, this document removes the "NamedBit" notations for
    individual bits, relegating them to comments.  The size constraint
    on the KerberosFlags type requires that at least 32 bits be
    encoded at all times, though a lenient implementation may choose
    to accept fewer than 32 bits and to treat the missing bits as set
    to zero.

    Currently, no current uses of KerberosFlags specify more than 32
    bits worth of flags, although future revisions of this document
    may do so.  When more than 32 bits are to be transmitted in a
    KerberosFlags value, future revisions to this document will likely
    specify that the smallest number of bits needed to encode the
    highest-numbered one-valued bit should be sent.  This is somewhat
    similar to the DER encoding of a bit string that is declared with
    the "NamedBit" notation.

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

Like other uses of SEQUENCE OF types, this should probably be:

    LastReq ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
        lr-type     [0] INTEGER,
        lr-value    [1] KerberosTime
    }

bcn> <H4>5.3.1.  Tickets</H4>

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

bcn> Ticket ::=        [APPLICATION 1] SEQUENCE {
bcn>                   tkt-vno[0]                   INTEGER,
bcn>                   realm[1]                     Realm,
bcn>                   sname[2]                     PrincipalName,
bcn>                   enc-part[3]                  EncryptedData, -- EncTicketPart
bcn> 		  extensions[4]		       TicketExtensions OPTIONAL
bcn> }

This should be either:

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

or:

    Ticket2 ::= [APPLICATION x] SEQUENCE { -- tag number TBD
        tkt-vno     [0] INTEGER,
        realm       [1] Realm,
        sname       [2] PrincipalName,
        enc-part    [3] EncryptedData, --EncTicketPart
        extensions  [4] TicketExtensions OPTIONAL
    }

Depending on whether we want to distinguish the different ticket types
by tag in order to allow for backwards compatibility.

bcn> <DT>extensions <DD>This optional field contains a sequence of
bcn> extensions that may be used to carry information that must be
bcn> carried with the ticket to support several extensions, including
bcn> but not limited to plaintext authorization data, tokens for
bcn> exchanging inter-realm keys, and other information that must be
bcn> associated with a ticket for use by the application server.  See
bcn> Appendix C for definitions of common extensions.

bcn> Note that some older versions of Kerberos did not support this
bcn> field.  Because this is an optional field it will not break older
bcn> clients, but older clients might strip this field from the ticket
bcn> before sending it to the application server.  This limits the
bcn> usefulness of this ticket field to environments where the ticket
bcn> will not be parsed and reconstructed by these older Kerberos
bcn> clients.

It should be noted that some implementations may outright crash when
they receive unexpected additional fields.  These should be considered
buggy implementations, but there may be some still in use.

bcn> If it is known that the client will strip this field from the
bcn> ticket, as an interim measure the KDC may append this field to
bcn> the end of the enc-part of the ticket and append a trailer
bcn> indicating the length of the appended extensions field.

There needs to be a reasonable migration strategy here, I think,
possibly including the client setting a particular bit in the
request.  See further discussion towards the end of this message.

bcn> <DT>flags <DD>This field indicates which of various options were
bcn> used or requested when the ticket was issued.  It is a bit-field,
bcn> where the selected options are indicated by the bit being set
bcn> (1), and the unselected options and reserved fields being reset
bcn> (0).

bcn> Bit 0 is the most significant bit.  The encoding of the bits is
bcn> specified in section 5.2.  The flags are described in more detail
bcn> above in section 2.  The meanings of the flags are:

Readers should be refered to X.690 for the official description of the
encoding of bit strings.  Perhaps the first two sentences of the above
paragraph should be deleted.

bcn> <DT>authorization-data <DD>

Do we need to have additional discussion on the particulars of
authorization data at this point, or is the current text actually
acceptable to everyone?  I do not currently have strong opinions on
it, but other people might.

bcn> <H4>5.3.2.  Authenticators</H4>

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

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

I propose adding these definitions:

    Int32 ::= INTEGER (-2147483648..2147483647)
        -- signed values representable in 32 bits
    UInt32 ::= INTEGER (0..4294967295)
        -- unsigned 32 bit values
    Microseconds ::= INTEGER (0..99999)

Then we can redefine an authenticator as:

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

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

The use of the Microseconds type should cause this to be constrained
by the ASN.1 syntax.

bcn> <DT>seq-number <DD>This optional field includes the initial
bcn> sequence number to be used by the KRB_PRIV or KRB_SAFE messages
bcn> when sequence numbers are used to detect replays (It may also be
bcn> used by application specific messages).  When included in the
bcn> authenticator this field specifies the initial sequence number
bcn> for messages from the client to the server.  When included in the
bcn> AP-REP message, the initial sequence number is that for messages
bcn> from the server to the client.  When used in KRB_PRIV or KRB_SAFE
bcn> messages, it is incremented by one after each message is sent.
bcn> Sequence numbers fall in the range of 0 through 2^32 - 1 and wrap
bcn> to zero following the value 2^32 - 1.

Likewise, the use of the UInt32 type should make this more clear.

bcn> <H4>5.4.1.  KRB_KDC_REQ definition</H4>

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

Replace "type" with "tag" in various places.  This should probably
read:

    The KRB_KDC_REQ message has no application tag of its own.
    Instead, it receives an application class tag by being included in
    either the AS-REQ and TGS-REQ type, 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.

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

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

This should be modified to constrain there to be at least one padata
when there are padata included:

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

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

Remove the trailing comma at the end of the line for "padata-value".
For some reason this was in RFC 1510 but didn't get caught.

bcn> KDC-REQ-BODY ::=   SEQUENCE {
bcn>                     kdc-options[0]         KDCOptions,
bcn>                     cname[1]               PrincipalName OPTIONAL,
bcn>                                            -- Used only in AS-REQ
bcn>                     realm[2]               Realm, -- Server's realm
bcn>                                            -- Also client's in AS-REQ
bcn>                     sname[3]               PrincipalName OPTIONAL,
bcn>                     from[4]                KerberosTime OPTIONAL,
bcn>                     till[5]                KerberosTime OPTIONAL,
bcn>                     rtime[6]               KerberosTime OPTIONAL,
bcn>                     nonce[7]               INTEGER,
bcn>                     etype[8]               SEQUENCE OF INTEGER, 
bcn>                                            -- EncryptionType,
bcn>                                            -- in preference order
bcn>                     addresses[9]           HostAddresses OPTIONAL,
bcn>                 enc-authorization-data[10] EncryptedData OPTIONAL,
bcn>                                            -- Encrypted AuthorizationData 
bcn>                                            -- encoding
bcn>                     additional-tickets[11] SEQUENCE OF Ticket OPTIONAL
bcn> }

This has several problems.  The "till" field was required in RFC 1510.
Making it optional now is questionable, since some implementations may
choke on a missing required field.  Also, the "additional-tickets"
field should be constrained to have at least one instance of "Ticket"
if it's present, since I don't see any useful semantic distinction
between omitting additional-tickets completely versus it having zero
members.  The following may work:

    KDC-REQ-BODY ::= SEQUENCE {
	kdc-options             [0] KDCOptions,
	cname                   [1] PrincipalName OPTIONAL,
				    -- Used only in AS-REQ
	realm                   [2] Realm, -- Server's realm
				    -- Also client's in AS-REQ
	sname                   [3] PrincipalName OPTIONAL,
	from                    [4] KerberosTime OPTIONAL,
	till                    [5] KerberosTime,
	rtime                   [6] KerberosTime OPTIONAL,
	nonce                   [7] INTEGER,
	etype                   [8] SEQUENCE OF INTEGER, 
				    -- EncryptionType,
				    -- in preference order
	addresses               [9] HostAddresses OPTIONAL,
	enc-authorization-data  [10] EncryptedData OPTIONAL,
				     -- Encrypted AuthorizationData 
				     -- encoding
	additional-tickets      [11] SEQUENCE (SIZE (1..MAX))
                                        OF Ticket OPTIONAL
    }

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

bcn> This field may also contain information needed by certain
bcn> extensions to the Kerberos protocol. For example, it might be
bcn> used to initially verify the identity of a client before any
bcn> response is returned.  When this field is used to authenticate or
bcn> pre-authenticate a request, it should contain a keyed checksum
bcn> over the KDC-REQ-BODY to bind the pre-authentication data to rest
bcn> of the request.  The KDC, as a matter of policy, may decide
bcn> whether to honor a KDC-REQ which includes any pre-authentication
bcn> data that does not contain the checksum field.

bcn> PA-ENC-TIMESTAMP defines a pre-authentication data type that is
bcn> used for authenticating a client by way of an encrypted
bcn> timestamp.  This is accomplished with a padata field with
bcn> padata-type equal to PA-ENC-TIMESTAMP and padata-value defined as
bcn> follows (query: the checksum is new in this definition.  If the
bcn> optional field will break things we can keep the old
bcn> PA-ENC-TS-ENC, and define a new alternate form that includes the
bcn> checksum).  :

I think it may be better to define a new alternative that includes the
checksum.

bcn>      padata-type     ::= PA-ENC-TIMESTAMP 

This isn't really valid ASN.1.

ASN.1 identifiers corresponding to values must begin with a lowercase
letter, and the value assignment notation is more along the lines of:

    pa-type-ENC-TIMESTAMP INTEGER ::= 2

for example, but the relationship to the field of PA-DATA isn't
obvious to an ASN.1 compiler, of course.  There should be a table of
type names (that will be DER encoded into octet strings) and the
corresponding integers that will go into the integer fields.  This can
be included in the appendix, as is done for RFC 1510, though the table
should include columns for the ASN.1 type names associated with the
values to be encoded into octet strings, the associated integer
values, and (maybe) the ASN.1 identifiers referencing the integer
value, though this last one is only really useful for inclusion in the
text to make it clear what is going on.

bcn>      padata-value    ::= EncryptedData -- PA-ENC-TS-ENC 

This should be something like:

    PA-ENC-TIMESTAMP ::= EncryptedData
                         -- containing encrypted DER encoding
                         -- of PA-ENC-TS-ENC

Or something suchlike.  ASN.1 type names begin with uppercase
letters.

bcn>      PA-ENC-TS-ENC   ::= SEQUENCE { 
bcn>                      patimestamp[0]     KerberosTime, -- client's time 
bcn>                      pausec[1]          INTEGER OPTIONAL, 
bcn>                      pachecksum[2]      checksum OPTIONAL 
bcn>                                         -- keyed checksum of KDC-REQ-BODY 
bcn>      } 

This should probably be:

    PA-ENC-TS-ENC ::= SEQUENCE { 
        patimestamp [0] KerberosTime, -- client's time 
        pausec      [1] Microseconds DEFAULT 0, 
        pachecksum  [2] Checksum OPTIONAL 
                        -- keyed checksum of KDC-REQ-BODY 
    } 

since the pausec field may want to be of type Microseconds to
constrain its value.  It may also want to have "DEFAULT 0" instead of
"OPTIONAL", but that is subject to discussion.  It should be noted
that the MIT implementation does not encode the pausec field if the
microseconds value passed to the encoder is zero.

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

bcn> It may also be used by the client to specify the version of a key that
bcn> is being used for accompanying preauthentication, and/or which should
bcn> be used to encrypt the reply from the KDC.

bcn>      padata-type     ::= PA-USE-SPECIFIED-KVNO 
bcn>      padata-value    ::= Integer
bcn>      } 

Likewise, this is not valid ASN.1.  I also think the trailing
close-brace is a typo of some sort.  We probably want something like
this:

    pa-type-USE-SPECIFIED-KVNO INTEGER ::= 20
    PA-USE-SPECIFIED-KVNO ::= INTEGER

bcn> The KDC should only accept and abide by the value of the
bcn> use-specified-kvno preauthentication data field when the
bcn> specified key is still valid and until use of a new key is
bcn> confirmed.  This situation is likely to occur primarily during
bcn> the period during which an updated key is propagating to other
bcn> KDC's in a realm.

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

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

This field was required by RFC 1510 but is optional here.  To avoid
breaking older implementations, perhaps it should be specified that a
value of midnight, January 1, 1970, i.e. "19700101000000Z", is treated
as a request for maximum endtime.

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

Replace "application code" with "application tag number".

bcn> The KRB_KDC_REP message contains the following fields:

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

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

This should be:

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

to prevent the appearance of an zero-element SEQUENCE OF.

bcn> EncASRepPart ::=    [APPLICATION 25[27]] EncKDCRepPart

Don't put the footnote number in the middle of the tag notation.  It's
potentially confusing.

bcn> EncTGSRepPart ::=   [APPLICATION 26] EncKDCRepPart

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

bcn> <H4>5.5.1.  KRB_AP_REQ definition</H4>

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

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

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

Remove the inconsistent copy of APOptions here, or at least copy the
one from the earlier section on flags.  This conflicts with the
earlier prohibition against use of NamedBit notation.

bcn> <H4>5.5.2.  KRB_AP_REP definition</H4>

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

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

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

This should be:

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

As before, the footnote number being included within the tag is
potentially confusing.  seq-number has been converted to UInt32, which
will constrain it to 32-bit values, and cusec is now Microseconds,
which constrains it to be less than one million.

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

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

We may need to have some discussion about the usage of sub-session
keys, but that may be best held off until we discuss the section on
cryptosystems.

bcn> <H4>5.6.1.  KRB_SAFE definition</H4>

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

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

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

This should probably be:

    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] Microseconds OPTIONAL,
	seq-number  [3] UInt32 OPTIONAL,
	s-address   [4] HostAddress,
	r-address   [5] HostAddress OPTIONAL
    }

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

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

A note should be made to the effect that the usec field should only be
omitted if the timestamp field is also omitted, in line with the
existing MIT implementation behavior.

Since there is a proposed change to remove the requirement to include
s-address, there should be a corresponding change to the tag number.
Applications that want to use the old krb-safe message will then
continue to include the sender address.  New applications may use the
new form.

bcn> <H4>5.7.1.  KRB_PRIV definition</H4>

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

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

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

These should probably be:

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

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

    KRB-PRIV-NEW ::= [APPLICATION x] SEQUENCE { -- tag number TBD
        pvno        [0] INTEGER,
        msg-type    [1] INTEGER,
        enc-part    [3] EncryptedData
                        -- EncKrbPrivPart
    }

    EncKrbPrivPartNew ::= [APPLICATION x] SEQUENCE { -- tag number TBD
        user-data   [0] OCTET STRING,
        timestamp   [1] KerberosTime OPTIONAL,
        usec        [2] Microseconds OPTIONAL,
        seq-number  [3] UInt32 OPTIONAL,
        s-address   [4] HostAddress OPTIONAL, -- sender's addr
        r-address   [5] HostAddress OPTIONAL -- recip's addr
    }

As in the KRB-SAFE message, seq-number is now UInt32; usec is
Microseconds.  A note should be made that Microseconds should only
appear if timestamp is also present; this matches the current MIT
implementation behavior.

bcn> <H4>5.8.1.  KRB_CRED definition</H4>

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

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

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

This should be:

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

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

This prevents the case of sending zero tickets, but this may be of
debatable usefulness.  usec is now of type Microseconds.  There should
be a comment to the effect that usec should only be included if
timestamp is also included, to align with existing behavior.

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

bcn> <H4>5.9.1.  KRB_ERROR definition</H4>

bcn> The KRB_ERROR message consists of the following fields:

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

This should be:

    KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
        pvno            [0] INTEGER,
        msg-type        [1] INTEGER,
        ctime           [2] KerberosTime OPTIONAL,
        cusec           [3] Microseconds DEFAULT 0,
        stime           [4] KerberosTime,
        susec           [5] Microseconds,
        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] KerberosString OPTIONAL,
        e-data          [12] OCTET STRING OPTIONAL,
        ...,
        e-cksum         [13] Checksum OPTIONAL
    }

or possibly

    KRB-ERROR-NEW ::= [APPLICATION x] SEQUENCE { -- tag number TBD
        pvno            [0] INTEGER,
        msg-type        [1] INTEGER,
        ctime           [2] KerberosTime OPTIONAL,
        cusec           [3] Microseconds DEFAULT 0,
        stime           [4] KerberosTime,
        susec           [5] Microseconds,
        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] KerberosString OPTIONAL,
        e-data          [12] OCTET STRING OPTIONAL,
        e-cksum         [13] Checksum OPTIONAL
    }

in order to prevent problems with an unexpected additional field.
There are multiple contexts in which a KRB-ERROR may appear; each of
these contexts probably requires some analysis of whether there will
be a backwards compatibility problem if the extra field appears.

bcn> <DT>e-data <DD>This field contains additional data about the
bcn> error for use by the application to help it recover from or
bcn> handle the error.  If present, this field will contain the
bcn> encoding of a sequence of TypedData (TYPED-DATA below), unless
bcn> the errorcode is KDC_ERR_PREAUTH_REQUIRED, in which case it will
bcn> contain the encoding of a sequence of of padata fields
bcn> (METHOD-DATA below), each corresponding to an acceptable
bcn> pre-authentication method and optionally containing data for the
bcn> method:

bcn> TYPED-DATA   ::=   SEQUENCE of TypeData
bcn> METHOD-DATA  ::=   SEQUENCE of PA-DATA

You probably mean:

    TYPED-DATA      ::= SEQUENCE (SIZE (1..MAX)) OF TypedData
    METHOD-DATA     ::= SEQUENCE (SIZE (1..MAX)) OF PA-DATA

bcn> TypedData ::=   SEQUENCE {
bcn>                     data-type[0]   INTEGER,
bcn>                     data-value[1]  OCTET STRING OPTIONAL
bcn> }

bcn> Note that the padata-type field in the PA-DATA structure and the
bcn> data-type field in the TypedData structure share a common range
bcn> of allocated values which are coordinated to avoid conflicts.
bcn> One Kerberos error message, KDC_ERR_PREAUTH_REQUIRED, embeds
bcn> elements of type PA-DATA, while all other error messages embed
bcn> TypedData.

I think this is ugly.  Is there any other way to do this?  Why do we
need to do this at all?  Why not just use a preauth type?

bcn> While preauthentication methods of type PA-DATA should be
bcn> encapsulated within a TypedData element of type TD-PADATA, for
bcn> compatibility with old clients, the KDC should include PA-DATA
bcn> types below 22 directly as method-data.  All new implementations
bcn> interpreting the METHOD-DATA field for the
bcn> KDC_ERR_PREAUTH_REQUIRED message must accept a type of TD-PADATA,
bcn> extract the typed data field and interpret the use any elements
bcn> encapsulated in the TD-PADATA elements as if they were present in
bcn> the METHOD-DATA sequence.

Since TYPED-DATA and METHOD-DATA are not tagged differently, an
implementation has to hook deep into its ASN.1 parser in order to
establish whether the encoded value is a TYPED-DATA or a METHOD-DATA
(look carefully at the definitions of each type; the only obvious
difference is the context-specific tag number for the first field.)
If there is not a large deployed base, I would suggest something to
the effect of requiring the following type to be DER-encoded within
the e-data field of the KRB-ERROR:

    TypedOrMethodData ::= CHOICE {
	method      METHOD-DATA,
	typed       [0] TYPED-DATA
    }

Which would be on-the wire compatible with what appears to be current
practice, with the possible exception of the strange second
alternative of METHOD-DATA that is in RFC 1510.  Do we know of anyone
acutally using it?  In any case, if people are concerned about the the
additional size of the encoding of "[0] TYPED-DATA", we can always
make it "[0] IMPLICIT TYPED-DATA", though that seems contrary to the
practice of not using implicit tagging for Kerberos types.

bcn> Commentary:

bcn> A statement regarding the carrying of unrecognized additional
bcn> fields in ASN.1 encoding through in tickets was added (still
bcn> waiting on some better text regarding this).

We need to decide whether we will require across-the-board acceptance
and re-encoding of unrecognized additional fields.  This would
correspond to the inclusion of "EXTENSIBILITY IMPLIED" in the module
definition.  Even if we do decide to do this, we need to be very
careful about the backwards-compatibilty reprecussions of arbitrarily
growing protocol elements.

bcn> Ticket flags and KDC options were added to support the new
bcn> functions described elsewhere in this document.  The encoding of
bcn> the options flags are now described to be no less than 32 bits,
bcn> and the smallest number of bits beyond 32 needed to encode any
bcn> set bits.  It also describes the encoding of the bitstring as
bcn> using "unnamed" bits.

I have added some language in my comments above to clarify this
somewhat, I hope.

bcn> An optional ticket extensions field was added to support the
bcn> carrying of auxiliary data that allows the passing of auxiliary
bcn> that is to accompany a ticket to the verifier.

Ticket extensions are a tricky thing.  The client has to handle the
extensions correctly and not crash, and the application server needs
to handle this as well.  This means that somehow, an individual client
needs to communicate to the KDC that it can accept ticket extensions,
and that the KDC needs to have knowledge in its database of which
service principals can handle ticket extensions.

bcn> (I would like to drop the part about optionally appending it of
bcn> the opaque part of the ciphertext.  We are still waiting on some
bcn> text regarding how to assure backward compatibility).

bcn> (Still pending, Tom Yu's request to change the application codes
bcn> on KDC message to indicate which minor rev of the protocol - I
bcn> think this might break things, but am not sure).

Can you be more specific about this?  The only thing I can recall
saying about application tag number changes had to do with making new
types with different application tag numbers for the potentially
incompatible types that would result from adding additional fields to
KRB-ERROR and Ticket, and from making previously required fields
optional in KRB-SAFE and KRB-PRIV.  It may be that it would be
possible to continue using the existing tags for Ticket and KRB-ERROR,
but I would want to see a thorough analysis of the compatibility
issues.

In any case, if we decide to make new types with different
application tag numbers, we need to pick these numbers... hopefully
all less than 31, since that starts running us into the area where we
will need more than one byte to encode the identifier octets in the
encoding.

bcn> The optional e-cksum field was added to the KRB-ERROR message and
bcn> the e-data filed was generalized for use in other than the
bcn> KDC_ERR_PREAUTH_REQUIRED error.  The TypedData structure was
bcn> defined.  Type tags for TypedData are defined in the same
bcn> sequence as the PA-DATA type space to avoid confusion with the
bcn> use of the PA-DATA namespace previously used for the e-data field
bcn> for the KDC_ERR_PREAUTH_REQUIRED error.

I was under the impression that RFC 1510 distinguished between the two
alternatives of METHOD-DATA by means of the error code elsewhere in
the KRB-ERROR message.  In RFC 1510, only the KDC_ERR_PREAUTH_REQUIRED
and KRB_AP_ERR_METHOD error codes had well-defined contents for the
e-data field in a KRB-ERROR.  Are we now allowing for the use of
TypedData to carry arbitrary data in an KRB-ERROR message regardless
of the error code returned?

Additional points for discussions include whether to replace *all*
instances of the INTEGER type with appropriately constrained types
that have smaller ranges; the range of the INTEGER type in ASN.1 is
effectively unlimited.  Candidates for this include integers that may
denote a type for cryptosystems, checkums, etc., as well as nonces.  I
believe that using UInt32 for sequence numbers is reasonable.  It is
debatable whether using UInt32 is acceptable for nonces, since there
may be some advantage to having these be arbitrarily large.  Then
again, I'm not sure too many implementations will handle receiving
nonces that are larger than 32 bits.

---Tom

---

From: [email-masked] (Johan Danielsson)
Date: 25 Sep 2000 14:29:38 +0200

Tom Yu <[email-masked]> writes:

> Consider the ambiguity of something like:
> 
>     Foo ::= SEQUENCE {
>         bar INTEGER,
> that the DER rules do not address this issue.  

You could argue that zero elements are not the same as no elements,
but this shouldn't be a problem.

> Of course, we should establish what current implementations are
> doing, but I doubt that any of them intentionally generate SEQUENCE
> OF encodings with no elements.

We discovered that the MIT implementation couldn't handle zero length
SEQUENCE OF's (it treated variable length and zero length the same, if
I remember correctly). We later discovered that we'd made the exact
same error...

/Johan

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 25 Sep 2000 17:34:56 -0400

> >>>>> "bcn" == Clifford Neuman <[email-masked]> writes:

[...]

> it, but other people might.

I think this is meant for Appendix B; similarly with ticket extension
types. Looking at version 6 of the draft, I would like to talk about
adding serveral authorization and extension data types.

We may have to wait until Appendix B comes out.

What I have in mind:

 - An authorization type meant to restrict TGTs whereby a TGT bearing
   authorization data of this type is limited to obtaining service
   tickets for service principals that match the principal name patterns
   included in the authorization data of this type.

 - An authorization type or an extension type meant for carrying an
   embedded KRB_CRED, or really just a sequence of forwarded/proxied
   tickets; an extension would need an authorization element to sign it
   and/or contain a key that encrypts the embedded KRB_CRED
   (AD-IN-Ticket-Extensions?).

 - A ticket extension or multiple extensions, signed with an
   authorization element, mapping the client principal name to other
   name types (e.g., Unix username for hosts in a given domain, Windows
   usernames (qualified with an NT domain name or Kerberos realm), LDAP
   DN, etc...)

 - A ticket extension to indicate that a service ticket is really a
   pseudo-TGT and the addresses/ports of the corresponding pseudo-TGS.
   The idea being that a user could forward pseudo-TGTs instead of
   TGTs, where the pseudo-TGT is a service ticket for a pseudo-TGS
   running on a host where the user authenticated initially; the
   pseudo-TGS would hold a real TGT for the user and would allow the
   user to observe and/or control ticket issuance to remote services
   impersonating the user.

Don't flame me right away, I can explain :)

[...]

> ---Tom

Nico
--