Subject: Section 2 diffs clarifying ticket flag extensibility

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

This is intended to address an issue opened at the IETF meeting about
the impact of our extensibility proposal on ticket flags and to
clarify how one should design new flags in the future.

--- krbrev2-6.html	2002/02/07 14:12:00	1.1
+++ krbrev2-6.html	2002/02/07 14:51:47	1.2
@@ -4,12 +4,33 @@
 indicate attributes of that ticket.  Most flags may be requested by a
 client when the ticket is obtained; some are automatically turned on
 and off by a Kerberos server as required.  The following sections
-explain what the various flags mean, and gives examples of reasons to
-use such a flag.  With the excepttion of the ANONYMOUS and INVALID
-flags clients may ignore ticket flags that are not recognized.
+explain what the various flags mean and give examples of reasons to
+use them.  With the excepttion of the ANONYMOUS and INVALID flags
+clients MUST ignore ticket flags that are not recognized.  KDCs MUST
+ignore KDC options that are not recognized.  Unfortunately some
+implementations of RFC 1510 are known to reject unknown KDC options,
+so clients may wish to only send options known to be defined by RFC
+1510 in the non-extensible varients of messages.
+
+<p>
+
+Since KDCs ignore unknown options, clients MUST confirm that the
+resulting ticket meets their needs.  For example, as discussed in
+section 2.8, a client requiring anonymous communication needs to make
+sure that the ticket is actually anonymous.   A KDC that prohibits issuing of anonymous tickets or that does not understand the anonymous option would not return an anonymous ticket.
+
+<p>
+
+Note that it is not in general possible to determine whether an option
+was not honored because it was not understood or because it was
+rejected either through configuration or policy.  Designers of options
+should consider whether the distinction is important for their option.
+In cases where it is, a mechanism for the KDC to return an indication
+that the option was understood but rejected needs to be provided in
+the specification of the option.  Often in such cases, the mechanism
+needs to be broad enough to permit an error or reason to be returned.
 
-<H3>2.1.  Initial, pre-authenticated, and hardware authenticated
-tickets</H3>
+<H3>2.1.  Initial, pre-authenticated, and hardware authenticated tickets</H3>
 
 The INITIAL flag indicates that a ticket was issued using the AS
 protocol and not issued based on a ticket-granting ticket.
@@ -234,6 +255,12 @@
 originate from different users.  Users request anonymous ticket by
 setting the REQUEST-ANONYMOUS option in an AS or TGS request.
 
+<p>
+
+If a client requires anonymous communication then the client should check to make sure that the resulting ticket it actually anonymous.  A KDC that does not understand the anonymous-requested flag will not return an error, but will instead return a normal ticket.
+
+
+
 <H3>2.9.  Other KDC options</H3>
 
 There are three additional options which may be set in a client's
@@ -309,3 +336,6 @@
 Name canonicalization was then removed and set aside for a separate
 document.  Section 2.9.2 and .3 were renumbered to .1 and .2.
 
+<p>
+
+Discussion of how extensibility affects ticket flags and KDC options was added to the introduction.