Subject: Section 9 Kerberos Revisions for comment

From: Clifford Neuman <[email-masked]>
Date: Wed, 20 Sep 2000 09:12:24 -0700 (PDT)

Here is section 9 of the Kerberos specification for comment.

Clifford Neuman
----
<H3>9.  Interoperability requirements</H3>

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

<P>

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

<H3>9.1.  Specification 2</H3>

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

<H5>Transport</H5>

TCP/IP and UDP/IP transport must be supported by KDCs claiming
conformance to specification 2.  Kerberos clients claiming conformance
to specification 2 must support UDP/IP transport for messages with the
KDC and should support TCP/IP transport.

<H5>Encryption and checksum methods</H5>

The following encryption and checksum mechanisms must be supported.
Implementations may support other mechanisms as well, but the
additional mechanisms may only be used when communicating with
principals known to also support them: This list is to be determined.

<PRE>
Encryption: DES-CBC-MD5, DES3-CBC-SHA1-KD
Checksums: CRC-32, DES-MAC, DES-MAC-K, DES-MD5, HMAC-SHA1-DES3-KD
</PRE>

<H5>Realm Names</H5>

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

<H5>Transited field encoding</H5>

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

<H5>Pre-authentication methods</H5>

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

<H5>Mutual authentication</H5>

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

<H5>Ticket addresses and flags</H5>

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

<P>

Proxies and forwarded tickets must be supported.  Individual realms
and application servers can set their own policy on when such tickets
will be accepted.

<P>

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

<H5>User-to-user authentication</H5>

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

<H5>Authorization data</H5>

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

<P>

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

<H5>Constant ranges</H5>

All protocol constants are constrained to 32 bit (signed) values unless
further constrained by the protocol definition.  This limit is provided
to allow implementations to make assumptions about the maximum values
that will be received for these constants.  Implementation receiving
values outside this range may reject the request, but they must recover
cleanly. 

<H3>9.2.  Recommended KDC values</H3>

Following is a list of recommended values for a KDC implementation,
based on the list of suggested configuration constants (see section
4.4).

<PRE>
minimum lifetime              5 minutes
maximum renewable lifetime    1 week
maximum ticket lifetime       1 day
empty addresses               only when suitable  restrictions  appear
                              in authorization data
proxiable, etc.               Allowed.

</PRE>

---
Commentary:

Requirements for supporting DES3-CBC-SHA1-KD encryption and
HMAC-SHA1-DES3-KD checksums were added.