Adding documentation files...

git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@3831 dc483132-0cff-0310-8789-dd5450dbe970

1 files changed, 64 insertions, 0 deletions

diff --git a/doc/krb5-protocol/rfc1510.errata b/doc/krb5-protocol/rfc1510.errata
new file mode 100644
index 000000000..fff0d9854
--- /dev/null
+++ b/doc/krb5-protocol/rfc1510.errata
@@ -0,0 +1,64 @@
+---rfc1510.eratta---as of June 14, 1994---
+
+1. [19940312] The following lines describes corrections to pseudocode
+   in rfc1510 as of March 12, 1994.
+
+  A: Throughout the pseudocode (section A), flags.ALLOW-POSTDATE should be
+     replaced by flags.MAY-POSTDATE.  kdc-options.ALLOW-POSTDATE is
+     correct, however.
+
+A.2: In the processing for the kdc-options.POSTDATE (imperitive), both
+     the POSTDATED and the INVALID flag should be set. The setting of the
+     POSTDATE flag was inadvertantly omitted.
+
+     You should change:
+
+        if (req.kdc-options.POSTDATED is set) then
+           if (against_postdate_policy(req.from)) then
+                error_out(KDC_ERR_POLICY);
+           endif
+           set new_tkt.flags.INVALID;
+           new_tkt.starttime := req.from;
+        else
+           omit new_tkt.starttime; /* treated as authtime when
+
+     To:
+        if (req.kdc-options.POSTDATED is set) then
+           if (against_postdate_policy(req.from)) then
+                error_out(KDC_ERR_POLICY);
+           endif
+           set new_tkt.flags.POSTDATED;                         <****
+           set new_tkt.flags.INVALID;
+           new_tkt.starttime := req.from;
+        else
+           omit new_tkt.starttime; /* treated as authtime when
+
+A.6: In section A.6, all occursences of kdc-options.POSTDATE (imperitive)
+     should be replaced by kdc-options.ALLOW-POSTDATE and tgt.flags.POSTDATE
+     should be replaced by tgt.flags.MAY-POSTDATE.
+
+     Note that instances of POSTDATED (adjective) are correct.
+
+
+---
+2. [19940614] Processing of the etype filed, described in 3.1.3, and 5.4.1.
+
+If a there are multiple encryption keys registered for a client in the
+Kerberos database (or if the key registered supports multiple
+encryption types; e.g. DES-CBC-CRC and DES-CBC-MD5), then the etype
+field from the AS request is used by the KDC to select the encryption
+method to be used for encrypting the response to the client.  If there
+is more than one supported, strong encryption type in the etype list,
+the first valid etype for which an encryption key is available is
+used.  The encryption method used to respond to a TGS request is taken
+from the keytype of the session key found in the ticket granting
+ticket.
+
+When the etype field is present in a KDC request, whether an AS or TGS
+request, the KDC will attempt to assign the type of the random session
+key from the list of methods in the etype field.  The KDC will select
+the appropriate type using the list of methods provided together with
+information from the Kerberos database indicating acceptable
+encryption methods for the application server.  The KDC will not issue
+tickets with a weak session key encryption type.
+