1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
|
---rfc1510.eratta---as of Auguest 10, 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.
---
3. [19940707] Case of realm names for DNS based realm names,
The following should appear in section 7.1 before the description
of the four classed of realm names (before "There are presently...")
Kerberos realm names are case sensitive. Realm names that differ
only in the case of the characters are not equivalent.
The domain example should be changes from:
domain: host.subdomain.domain (example)
To:
domain: ATHENA.MIT.EDU (example)
The following should be append to the domain name paragraph of
section 7.1 (following "nor slashes (/).")
Domain names must be converted to upper case when used as realm names.
---
4. [19940707] Official name of host is instance for NT-SRV-HST
Append to paragraph 7.2.1:
When a host has an official name and one or more aliases, the
official name of the host must be used when constructing the name
of the server principal.
---
5. [19940722] The protocol is standards track
In the 3rd paragraph of the overview delete:
", and are not being submitted for consideration as
an Internet standard at this time"
as it contradicts the first sentence of the RFC.
|