Subject: Section 1 diffs for extensibility

From: [email-masked] (Sam Hartman)
Date: Thu, 7 Feb 2002 09:54:08 -0500 (EST)

Here is my preliminary integration of extensibility changes into
section 1 for the WG's comments.  I will send these to Cliff once
finalized.

--- krbrev1-4.html	2002/02/07 14:12:28	1.1
+++ krbrev1-4.html	2002/02/07 14:17:47	1.3
@@ -384,7 +384,133 @@
 options for application authentication (e.g. the PKTAPP proposal) are
 provided.
 
-<H3>1.4.  Environmental assumptions</H3>
+
+<H3> 1.4. Extensibility Model</h3>
+
+In the past, significant interoperability problems have been caused by
+different assumptions about how the Kerberos protocol can be extended.
+However, as the deployed base of Kerberos implementations grows,
+extending Kerberos becomes more important.  In order to insure that
+vendors and the IETF can extend the protocol while maintaining backward compatibility, this specification outlines a framework for extending Kerberos.
+<p>
+Kerberos provides two general mechanisms for protocol extensibility.
+Many protocol messages contain typed holes--sub-messages that contain
+an octet-string along with an integer that defines how to interpret
+the octet-string.  The integer types are registered centrally, but can
+be used both for vendor extensions and for extensions standardized in
+the IETF.
+<p>
+Most messages also contain ASN.1 extension markers.  These markers
+allow fields to be added in future versions of this specification.
+Because tag numbers and order in the sequence need to be agreed on in
+order to maintain interoperability, implementations MUST NOT include
+ASN.1 extensions except when those extensions are specified by IETF
+standards-track documents.
+<p>
+
+<h3>1.4.1. Compatibility with RFC 1510</h3>
+
+Implementations of RFC 1510 did not use extensible ASN.1 types.
+Sending additional fields not in RFC 1510 to these implementations
+results in undefined behavior.  Examples of this behavior are known to
+include discarding messages with no error indications.
+
+<p>
+
+Where messages have been changed since RFC 1510, ASN.1 choice types
+are used; one arm of the choice provides a message compatible with RFC
+1510 and the other arm provides the current, extensible message.  
+
+<p>
+
+Implementations sending new messages MUST insure that the recipient
+supports these new messages.  Along with each extensible message is a
+guideline for when that message MAY be used.  IF that guideline is
+followed, then the recipient is guaranteed to understand the message.
+
+<p>
+
+<h3> 1.4.2. Sending Extensible Messages</h3>
+
+Care must be taken to make sure that old implementations can
+understand messages sent to them even if they do not understand an
+extension that is used.  Unless the sender knows the extension is
+supported, the extension cannot change the semantics of the core
+message or previously defined extensions.
+
+<p>
+
+For example, an extension including key information necessary to
+decrypt the encrypted part of a KDC-REP could only be used in
+situations where the recipient was known to support the extension.
+Thus when designing such extensions it is important to provide a way
+for the recipient to notify the sender of support for the extension.
+For example in the case of an extension that changes the KDC-REP reply
+key, the client could indicate support for the extension by including
+a padata element in the AS-REQ sequence.  The KDC should only use the
+extension if this padata element is present in the AS-REQ.  Even if
+policy requires the use of the extension, it is better to return an
+error indicating that the extension is required than to use the
+extension when the recipient may not support it; debugging why
+implementations do not interoperate is easier when errors are
+returned.
+
+<h3>1.4.3. Receiving Extensible Messages</h3>
+
+Recipients of  unknown message extensions (either in typed
+holes or ASN.1 types) should preserve the encoding of the extension
+but otherwise ignore the presence of the extension.  If the message is
+used later--for example, when a ticket is later used in an
+AP-REQ--then the unknown extensions MUST be included.
+
+<p>
+
+There is one exception to this rule.  If an unknown authorization data
+element type is received by a server either in an AP-REQ or in a
+ticket contained in an AP-REQ, then the authentication SHOULD fail.
+Authorization data is intended to restrict the use of the ticket.  If
+the service cannot determine whether the restriction applies to that
+service then a security weakness may result if the ticket can be used
+for that service.  Authorization elements that are optional can be
+enclosed in the AD-IF-RELEVANT element.
+
+<p>
+
+Many RFC 1510 implementations ignore unknown authorization data
+elements.  Depending on these implementations to honor authorization
+data restrictions may  create a security weakness.
+<h3>1.5. Authenticating Cleartext Portions of Messages</h3>
+
+One of the design goals of Kerberos was to avoid encrypting more of
+the authentication exchange that was required.  This reduces the load
+on the KDC and busy servers.  Also, at the time, it helped with
+certain legal export requirements.  Unfortunately, various denial of
+service attacks and downgrade attacks are possible unless this
+plaintext is somehow protected against modification.
+
+<p>
+
+The extensible varients of the messages described in this
+specification wrap the actual message in an ASN.1 sequence containing
+a keyed checksum of the contents of the message.  Guidelines in
+section 3 specify when the checksum MUST be included and what key MUST
+be used.  Guidelines on when to include a checksum are never
+ambiguous: a particular PDU is never correct both with and without a
+checksum.  With the exception of the KRB-ERROR message, receiving
+implementations MUST reject messages where a checksum is included and
+not expected or where a checksum is expected but not included.  The
+receiving implementation does not always have sufficient information
+to know whether a KRB-ERROR should contain a checksum.  Even so,
+KRB-ERROR messages with invalid checksums MUST be rejected and
+implementations MAY consider the presence or absence of a checksum
+when evaluating whether to trust the error.
+
+<p>
+
+This authenticated cleartext protection  is provided only in the extensible varients of the messages; it is never used whan talking to an RFC 1510 implementation.
+
+
+<H3>1.6. Environmental assumptions</H3>
 
 Kerberos imposes a few assumptions on the environment in which it can
 properly function:
@@ -426,7 +552,7 @@
 
 </UL>
 
-<h3>1.5.  Glossary of terms</H3>
+<h3>1.7.  Glossary of terms</H3>
 
 Below is a list of terms used throughout this document.
 
@@ -598,5 +724,9 @@
 <P>
 
 Discussion related to Name Canonicalization has been dropped.
+
+<p>
+
+Folded in the introduction to extensibility and the authenticated cleartext solution.