Subject: Comments on clarifications

From: "Jacques A. Vidrine" <[email-masked]>
Date: Mon, 18 Nov 2002 12:19:46 -0600

[Sorry for the duplicate.  Resending with attachment this time.]

Hello All,

Here are some comments/questions/suggestions on the clarifications.
IMHO this document is in pretty good shape.  Nonetheless, below are
hunks of a diff on the nroff version of the clarifications.  Each hunk
includes explanatory notes.  The entire diff is also attached.  Many
changes are nits --- grammar/spelling/consistency.  If I didn't
comment on the hunk here, it is because it was purely a nit that I
feel requires no explanatation (e.g. missing punctuation).  I put the
most important items at the top, but otherwise the order is just a
result of the document flow.

IMHO most important stuff:
--------------------------
/////////////////////
= Delete text implying that in the future, two names may differ in
  name type only.  If this is supposed to stay, then it needs to be
  noted also in section 6.2.

@@ -2452,7 +2461,6 @@
 for this field are specified in section 7.2. The name-type should be
 treated as a hint. Ignoring the name type, no two names can be the same
 (i.e. at least one of the components, or the realm, must be different).
-This constraint may be eliminated in the future.
 
 .ti3
 name-string

/////////////////////
= It seems the common AuthorizationData elements defined here MUST
  be understood by all implementations.

@@ -2578,7 +2583,7 @@
 .in3
 Each sequence of type and data is referred to as an authorization element.
 Elements may be application specific, however, there is a common set of
-recursive elements that should be understood by all implementations. These
+recursive elements that MUST be understood by all implementations. These
 elements contain other elements embedded within them, and the interpretation
 of the encapsulating element determines which of the embedded elements must
 be interpreted, and which may be ignored.

/////////////////////
= Existing implementations do TCP half-close.  Spell out that is allowed.

@@ -5054,6 +5071,10 @@
 must be prepared to handle the connection being closed after the first
 response.
 
+Either the client or KDC MAY close the TCP connection in only the
+sending direction (half-close) if it does not expect to send any
+further messages.
+
 Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR) sent over
 the TCP stream is preceded by the length of the request as 4 octets in
 network byte order. The high bit of the length is reserved for future

/////////////////////
= Earlier in section 8.1, it says `Implementations SHOULD default to
  requesting addressless tickets'.

@@ -5583,8 +5605,7 @@
 minimum lifetime              5 minutes
 maximum renewable lifetime    1 week
 maximum ticket lifetime       1 day
-empty addresses               only when suitable  restrictions  appear
-                              in authorization data
+empty addresses               Allowed.
 proxiable, etc.               Allowed.
 
 .fi

/////////////////////
= Add a further recommendation to security considerations.

@@ -5654,6 +5675,12 @@
 attackers may try brute force or dictionary attacks against credentials that
 are observed by eavesdropping on the network.
 
+Similarly, it is recommended that principals which have keys derived
+from passwords not be permitted as the target server in a KRB_TGS_REQ,
+since the resulting KRB_TGS_REP will contain material encrypted in the
+principal's secret key suitable for conducting an offline dictionary
+attack.
+
 Each host on the network must have a clock which is loosely synchronized to
 the time of the other hosts; this synchronization is used to reduce the
 bookkeeping needs of application servers when they do replay detection. The

Other stuff:
------------
/////////////////////
= It reads awkwardly to me to say that one `MAY wish to' do something.
  Sure they may :-) I suggest deleting the `wish to' text where it is
  used.

@@ -431,7 +431,7 @@
 
 Implementations of Kerberos, GSSAPI, and SASL [RFC 2222] MUST NOT use DNS to
 canonicalize the host components of service principal names. Application
-authors MAY wish to append a statically configured domain name to
+authors MAY append a statically configured domain name to
 unqualified hosts before passing the name to security mechanisms.
 
 Implementation note: Many current implementations do some degree of

/////////////////////
= It looks like `KDC-issued' is used more often than `kdc-issued' in the
  text to refer to the AD-KDC-ISSUED element.

@@ -460,8 +460,8 @@
 specific access control functions and may utilize files on the application
 server, or on separately issued authorization credentials such as those
 based on proxies [Neu93], or on other authorization services. Separately
-authenticated authorization credentials may be embedded in a tickets
-authorization data when encapsulated by the kdc-issued authorization data
+authenticated authorization credentials may be embedded in a ticket's
+authorization data when encapsulated by the KDC-issued authorization data
 element.
 
 Applications should not accept the mere issuance of a service ticket by the

/////////////////////
= A clause seems to be modifying `Hades' rather than `Kerberos'.
  Reworded to avoid the problem.

@@ -672,9 +672,10 @@
 .ti3
 Kerberos
 .br
-Aside from the 3-headed dog guarding Hades, the name given to Project
-Athena's authentication service, the protocol used by that service, or
-the code used to implement the authentication service.
+The name given to the Project Athena's authentication service, the
+protocol used by that service, or the code used to implement the
+authentication service.  The name is adopted from the three-headed dog
+which guards Hades.
 
 .ti3
 Plaintext

/////////////////////
= I really prefer the construct `X, rather than Y' to `X, and not Y'
  when describing the mutually exclusive conditions X and Y.

@@ -771,8 +772,8 @@
 .ti0
 2.1. Initial, pre-authenticated, and hardware authenticated tickets
 
-The INITIAL flag indicates that a ticket was issued using the AS protocol
-and not issued based on a ticket-granting ticket. Application servers that
+The INITIAL flag indicates that a ticket was issued using the AS protocol,
+rather than issued based on a ticket-granting ticket. Application servers that
 want to require the demonstrated knowledge of a client's secret key (e.g. a
 password-changing program) can insist that this flag be set in any tickets
 they accept, and thus be assured that the client's key was recently

/////////////////////
= The transited field lists realms, not KDCs.

@@ -943,7 +944,8 @@
 In Kerberos, the application server is ultimately responsible for accepting
 or rejecting authentication and should check that only suitably trusted KDCs
 are relied upon to authenticate a principal. The transited field in the
-ticket identifies which KDCs were involved in the authentication process and
+ticket identifies which realms (and thus which KDCs) were involved in the
+authentication process and
 an application server would normally check this field. If any of these are
 untrusted to authenticate the indicated client principal (probably
 determined by a realm-based policy), the authentication attempt must be

/////////////////////
= Section 3.1.1 doesn't describe much about pre-authentication.  5.2.7
  has more info.

@@ -1060,7 +1062,8 @@
 the key is based on a password, this may create a security exposure. So, the
 initial request supports an optional field that can be used to pass
 additional information that might be needed for the initial exchange. This
-field should be used for pre-authentication as described in section 3.1.1.
+field should be used for pre-authentication as described in sections 3.1.1
+and 5.2.7.
 
 Various errors can occur; these are indicated by an error response
 (KRB_ERROR) instead of the KRB_AS_REP response. The error message is not

/////////////////////
= I don't understand why sometimes error conditions are spelled out
  and sometimes just implied.  Should this case be clarified?
= More importantly in this hunk, better describe what to expect in a
  KDC_ERR_PREAUTH_REQUIRED.

@@ -1110,12 +1113,18 @@
 doesn't exist in the KDC's principal database, then an error message with a
 KDC_ERR_C_PRINCIPAL_UNKNOWN is returned.
 
+XXX The behavior when an unknown server is given is not specified
+here.  Is there any possible response other than
+KDC_ERR_S_PRINCIPAL_UNKNOWN ins this case?
+
 If required, the server pre-authenticates the request, and if the
 pre-authentication check fails, an error message with the code
 KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is required, but
 was not present in the request, an error message with the code
-KDC_ERR_PREAUTH_REQUIRED is returned and the PA-ETYPE-INFO
-pre-authentication field will be included in the KRB-ERROR message. If the
+KDC_ERR_PREAUTH_REQUIRED is returned and the METHOD-DATA field of
+the KRB-ERROR message will specify which pre-authentication mechanisms
+are acceptable.  Usually this will include PA-ETYPE-INFO and/or
+PA-ETYPE-INFO2 elements. If the
 server cannot accommodate an encryption type requested by the client, an
 error message with code KDC_ERR_ETYPE_NOSUPP is returned. Otherwise the KDC
 generates a \'random' session key[3.3].

/////////////////////
= Split a long sentence.

@@ -2116,9 +2125,9 @@
 exchange external to the Kerberos protococl, usually as part of the
 application protocol. This message is shown in the summary above as message
 0. Note that because the ticket granting ticket is encrypted in the KDC's
-secret key, can not be used for authentication without posession of the
-corresponding secret key, and because the verifier does not give out the
-corresponding secret key, providing a copy of the verifiers ticket granting
+secret key, it cannot be used for authentication without posession of the
+corresponding secret key. Furthermore, because the verifier does not reveal the
+corresponding secret key, providing a copy of the verifier's ticket granting
 ticket does not allow impersonation of the verifier.
 
 Once the verifier's ticket granting ticket has been obtained by the client,

/////////////////////
= The present tense seems more appropriate here.

@@ -2230,8 +2239,8 @@
 Note that in several places, there have been changes here from RFC 1510 that
 change the abstract types. This is in part to address widespread assumptions
 that various implementors have made, in some cases resulting in
-unintentional violations of the ASN.1 standard. These will be clearly
-flagged when they occur. The differences between the abstract types in RFC
+unintentional violations of the ASN.1 standard. These are clearly
+flagged where they occur. The differences between the abstract types in RFC
 1510 and abstract types in this document can cause incompatible encodings to
 be emitted when certain encoding rules, e.g. the Packed Encoding Rules
 (PER), are used. This theoretical incompatibility should not be relevant for

/////////////////////
= For consistency, use `US-ASCII' rather than `ASCII'.  (The former was
  the more popular spelling.)

@@ -2437,7 +2446,7 @@
 
 .fi
 Kerberos realm names are encoded as KerberosStrings. Realms shall not
-contain a character with the code 0 (the ASCII NUL). Most realms will
+contain a character with the code 0 (the US-ASCII NUL). Most realms will
 usually consist of several components separated by periods (.), in the style
 of Internet Domain Names, or separated by slashes (/) in the style of X.500
 names. Acceptable forms for realm names are specified in section 7. A

/////////////////////
= Can a message be sent such that the msg-type field differs from the
  application tag number?

@@ -2511,8 +2519,9 @@
 .ti3
 msg-type
 .br
-this integer field usually is identical to the application tag number
+this integer field is usually identical to the application tag number
 of the containing message type.
+XXX Usually?  Not always??
 
 .in3
 .ti0

/////////////////////
= Correct reference.
= Delete text that adds no addition information, and is possibly
  confusing.

@@ -2538,17 +2547,13 @@
 addr-type
 .br
 This field specifies the type of address that follows. Pre-defined
-values for this field are specified in section 8.1.
+values for this field are specified in section 7.1.
 
 .ti3
 address
 .br
 This field encodes a single address of type addr-type.
 
-.in3
-The two forms differ slightly. HostAddress contains exactly one address;
-HostAddresses contains a sequence of possibly many addresses.
-
 .ti0
 5.2.6. AuthorizationData

/////////////////////
= Comments are in the hunk.

@@ -2650,6 +2655,15 @@
 .ti3
 ad-checksum
 .br
+XXX This paragraph says the checksum is over the "elements" field.
+Are the i-realm and i-sname fields not integrity protected?  What
+impact might this have?
+.br
+XXX Strictly speaking, the "key used to protect the ticket" is already
+the result of key derivation (key usage 2).  Is it intended that the
+derived key is then run through key derivation again?  Probably not.
+But I can't think of wording at the moment to clarify this.
+.br
 A checksum over the elements field using a cryptographic checksum
 method that is identical to the checksum used to protect the ticket
 itself (i.e. using the same hash function and the same encryption

/////////////////////
= Reword the description of AD-AND-OR to spell out more explicitly
  that condition-count may be any value from 1..N (N = number encapsulated
  elements), not just 1 or N.  More explicitly spell out the semantics
  in this case as well.

@@ -2708,9 +2722,10 @@
 }
 
 .fi
-When restrictive AD elements are encapsulated within the and-or element are
-encountered, only the number specified in condition-count of the
-encapsulated conditions must be met in order to satisfy this element. This
+When restrictive AD elements are encapsulated within the and-or element,
+the and-or element is considered satisfied if and only if at least the
+number of encapsulated elements specified in condition-count are satisifed.
+Therefore, this
 element may be used to implement an "or" operation by setting the
 condition-count field to 1, and it may specify an "and" operation by setting
 the condition count to the number of embedded elements. Application servers

/////////////////////
= We really mean mandatory-for-kdc here.

@@ -2724,7 +2739,7 @@
 
 AD elements encapsulated within the mandatory-for-kdc element are to be
 interpreted by the KDC. KDCs that do not understand the type of an element
-embedded within the if-relevant element must reject the request.
+embedded within the mandatory-for-kdc element must reject the request.
 
 .ti0
 5.2.7. PA-DATA

/////////////////////
= If an element is absent, it doesn't have any value :-)  I understood
  what was meant after a second read, but reword it for clarity.

@@ -3322,8 +3337,9 @@
 .br
 This field in the ticket specifies the time after which the ticket is
 valid. Together with endtime, this field specifies the life of the
-ticket. If it is absent from the ticket, its value should be treated as
-that of the authtime field.
+ticket. If the starttime field is absent from the ticket, then the
+authtime field should be used in its place to determine the life of
+the ticket.
 
 .ti3
 endtime

/////////////////////
= `zero-address tickets' aren't described as such anywhere else.
  Use `addressless tickets' instead.

@@ -3349,7 +3365,7 @@
 host addresses. These are the addresses from which the ticket can be
 used. If there are no addresses, the ticket can be used from any
 location. The decision by the KDC to issue or by the end server to
-accept zero-address tickets is a policy decision and is left to the
+accept addressless tickets is a policy decision and is left to the
 Kerberos and end-service administrators; they may refuse to issue or
 accept such tickets. The suggested and default policy, however, is that
 such tickets will only be issued or accepted when additional

/////////////////////
= Delete sentence that isn't really true and doesn't matter anyway.

@@ -3537,9 +3553,7 @@
 
 The padata (pre-authentication data) field contains a sequence of
 authentication information which may be needed before credentials can
-be issued or decrypted. In most requests for initial authentication
-(KRB_AS_REQ) and most replies (KDC-REP), the padata field will be left
-out.
+be issued or decrypted.
 
 .ti3
 req-body

/////////////////////
= Is there supposed to be some distinction between UNUSED and RESERVED
  here?  If not, use RESERVED consistently.

@@ -3634,7 +3648,7 @@
                                     after the starttime in the ticket
                                     has been reached.
 
-   7       UNUSED                   This option is presently unused.
+   7       RESERVED                 This option is presently unused.
 
                                     The RENEWABLE option indicates that
                                     the ticket to be issued is to have
@@ -3651,7 +3665,7 @@
    9       RESERVED                 Reserved for PK-Cross
 
                                     These options are presently unused.
-   10-13   UNUSED                   Option 11 is reserved for future is
+   10-13   RESERVED                 Option 11 is reserved for future is
                                     as opt-hardware-auth.
 
    14-25   RESERVED                 Reserved for future use.

/////////////////////
= I believe TGS_REQ was meant here.

@@ -3746,7 +3760,7 @@
 the TGS_REQ form), is an encoding of the desired authorization-data
 encrypted under the sub-session key if present in the Authenticator, or
 alternatively from the session key in the ticket-granting ticket, both
-from the padata field in the KRB_AP_REQ. The key usage value used when
+from the padata field in the KRB_TGS_REQ. The key usage value used when
 encrypting is 5 if a sub-session key is used, or 4 if the session key
 is used.

/////////////////////
= If we need to mention the UNIX epoch, then it should probably just
  be an `Implementation note'.

@@ -3771,7 +3785,7 @@
 This field contains the expiration date requested by the client in a
 ticket request. It is not optional, but if the requested endtime is
 "19700101000000Z", the requested ticket is to have the maximum endtime
-permitted according to KDC policy for. This special timestamp
+permitted according to KDC policy. Implementation note: This special timestamp
 corresponds to a UNIX time_t value of zero on most systems.
 
 .ti3

/////////////////////
= Can the KDC choose not to copy some or all of the addresses?

@@ -3803,8 +3817,9 @@
 ticket-granting server. It specifies the addresses from which the
 requested ticket is to be valid. Normally it includes the addresses for
 the client's host. If a proxy is requested, this field will contain
-other addresses. The contents of this field are usually copied by the
+other addresses. The contents of this field are copied by the
 KDC into the caddr field of the resulting ticket.
+XXX Is any other behavior acceptable (besides copying the addresses)?
 
 .ti3
 additional-tickets

/////////////////////
= Comment is in the hunk.

@@ -4195,6 +4210,10 @@
 and should not transmit an Authenticator with a sequence number of
 zero.
 
+XXX Is this truly desired, that the sequence number be omitted when it
+is zero?  So we get messages with ..., seq-number 2^32-2, seq-number
+2^32-1, no seq-number, seq-number 1, seq-number 2, ...?
+
 .ti3
 authorization-data
 .br

/////////////////////
= Clarify that we don't mean that the Kerberos GSS-API mechanism
  inherently does no encryption of KRB-CRED, but rather that there
  exist implementations of Kerberos GSS-API that do no encryption
  of KRB-CRED.

@@ -4514,7 +4533,7 @@
 used for the enc-part field of the KRB-CRED message.
 
 Implementation note: implementations of certain applications, most
-notably of the Kerberos GSS-API mechanism, do not encrypt the KRB-CRED
+notably certain implementations of the Kerberos GSS-API mechanism, do not encrypt the
KRB-CRED
 message when sending it. In the case of the GSS-API mechanism, this is
 not a security vulnerability, as the KRB-CRED message itself is itself
 encrypted inside an Authenticator.

/////////////////////
= Note that TGT-REQ/TGT-REP are for user2user in this table.

@@ -4718,9 +4737,9 @@
 
  15             AP-REP         PDU
 
- 16             RESERVED16     TGT-REQ
+ 16             RESERVED16     TGT-REQ (user2user)
 
- 17             RESERVED17     TGT-REP
+ 17             RESERVED17     TGT-REP (user2user)
 
  18-19                         unused

/////////////////////
= Delete text referencing AF_* constants, as previously discussed.

@@ -4920,11 +4939,6 @@
 All non-negative values are reserved for officially assigned type fields and
 interpretations.
 
-The values of the types for the following addresses are chosen to match the
-defined address family constants in the Berkeley Standard Distributions of
-Unix. They can be found in with symbolic names AF_xxx (where xxx is an
-abbreviation of the address family name).
-
 .in6
 .ti3
 Internet (IPv4) Addresses

/////////////////////
= Delete obsolete notation (or was a reference intended?).

@@ -4934,7 +4948,7 @@
 type of IPv4 addresses is two (2).
 
 .ti3
-Internet (IPv6) Addresses [Westerlund]
+Internet (IPv6) Addresses
 
 IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. The
 type of IPv6 addresses is twenty-four (24). [RFC2373]. The following

/////////////////////
= It sees to me that link-local addresses could be useful in some
  environments.  Why are they not permitted?

@@ -4945,6 +4959,8 @@
    *  the Loopback Address
    *  Link-Local addresses
 
+XXX Why no link-local addresses?
+
 .fi
 IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2.

/////////////////////
= We don't seem to use hex constants much, so don't use them here,
  especially if we're not going to distinguish them from decimal constants.
= Be a little more precise.

@@ -4958,8 +4974,9 @@
 Netbios addresses
 
 Netbios addresses are 16-octet addresses typically composed of 1 to 15
-characters, trailing blank (ascii char 20) filled, with a 16th octet of 0x0.
-The type of Netbios addresses is 20 (0x14).
+alphanumeric characters and padded with the US-ASCII SPC character (code
+32).  The 16th octet must be the US-ASCII NUL character (code 0).
+The type of Netbios addresses is twenty (20).
 
 .ti3
 Directional Addresses

/////////////////////
= Arbitrarily assign directional addresses type 3.  Pick something else
  if there is reason, but just pick something.

@@ -4983,7 +5000,7 @@
 where the sending party knows that the receiving party supports the address
 type. This generally means that directional addresses may only be used when
 the application protocol requires their support. Directional addresses are
-type XX (0xXX).
+type three (3).
 
 .in3
 .ti0

/////////////////////
= Mention the appropriate error code.

@@ -5014,7 +5031,7 @@
 sending port at the sender's IP address. The response to a request made
 through UDP/IP transport must also use UDP/IP transport. If the response can
 not be handled using UDP (for example because it is too large), the KDC must
-return an error forcing the client to retry the request using the TCP
+return KRB_ERR_RESPONSE_TOO_BIG, forcing the client to retry the request using the TCP
 transport.
 
 .ti0

/////////////////////
= Add directional address type.

@@ -5275,6 +5296,7 @@
 Address type                   value
 
 IPV4                             2
+Directional                      3
 ChaosNet                         5
 XNS                              6
 ISO                              7

/////////////////////
= `Public key' does not appear to be a noun in this case, but an
  adjective.  Give it a noun to modify.

@@ -6398,7 +6425,7 @@
 key might be stored on a smart-card, or otherwise obtained independent of a
 password.
 
-The introduction also mentions the use of public key for initial
+The introduction also mentions the use of public key cryptography for initial
 authentication in Kerberos by reference. RFC1510 did not include such a
 reference.

/////////////////////
= pa-etype-info2 was missing.

@@ -6427,7 +6454,7 @@
 A warning regarding generation of session keys for application use was
 added, urging the inclusion of key entropy from the KDC generated session
 key in the ticket. An example regarding use of the sub-session key was added
-to section 3.2.6. Descriptions of the pa-etype-info, and pa-pw-salt
+to section 3.2.6. Descriptions of the pa-etype-info, pa-etype-info2, and pa-pw-salt
 preauthentication data items were added. The recommendation for use of
 preauthentication was changed from "may" to "should" and a note was added
 regarding known plaintext attacks.

Cheers,
-- 
Jacques A. Vidrine <[email-masked]>          http://www.celabo.org/
NTT/Verio SME          .     FreeBSD UNIX     .       Heimdal Kerberos
[email-masked]     .  [email-masked]  .          [email-masked]
--- krbclar-draft-02.nroff	Mon Nov 18 10:05:26 2002
+++ krbclar-draft-02.nroff.edit	Mon Nov 18 10:05:26 2002
@@ -431,7 +431,7 @@
 
 Implementations of Kerberos, GSSAPI, and SASL [RFC 2222] MUST NOT use DNS to
 canonicalize the host components of service principal names. Application
-authors MAY wish to append a statically configured domain name to
+authors MAY append a statically configured domain name to
 unqualified hosts before passing the name to security mechanisms.
 
 Implementation note: Many current implementations do some degree of
@@ -460,8 +460,8 @@
 specific access control functions and may utilize files on the application
 server, or on separately issued authorization credentials such as those
 based on proxies [Neu93], or on other authorization services. Separately
-authenticated authorization credentials may be embedded in a tickets
-authorization data when encapsulated by the kdc-issued authorization data
+authenticated authorization credentials may be embedded in a ticket's
+authorization data when encapsulated by the KDC-issued authorization data
 element.
 
 Applications should not accept the mere issuance of a service ticket by the
@@ -672,9 +672,10 @@
 .ti3
 Kerberos
 .br
-Aside from the 3-headed dog guarding Hades, the name given to Project
-Athena's authentication service, the protocol used by that service, or
-the code used to implement the authentication service.
+The name given to the Project Athena's authentication service, the
+protocol used by that service, or the code used to implement the
+authentication service.  The name is adopted from the three-headed dog
+which guards Hades.
 
 .ti3
 Plaintext
@@ -751,11 +752,11 @@
 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 give examples of reasons to use them. With the exception of the
-INVALID flag clients MUST ignore ticket flags that are not recognized. KDCs
+INVALID flag, clients MUST ignore ticket flags that are not recognized. KDCs
 MUST ignore KDC options that are not recognized. Some implementations of RFC
 1510 are known to reject unknown KDC options, so clients may need to resend
-a request without KDC new options absent if the request was rejected when
-sent with option added since RFC 1510. Since new KDCs will ignore unknown
+a request without new KDC options absent if the request was rejected when
+sent with options added since RFC 1510. Since new KDCs will ignore unknown
 options, clients MUST confirm that the ticket returned by the KDC meets
 their needs.
 
@@ -771,8 +772,8 @@
 .ti0
 2.1. Initial, pre-authenticated, and hardware authenticated tickets
 
-The INITIAL flag indicates that a ticket was issued using the AS protocol
-and not issued based on a ticket-granting ticket. Application servers that
+The INITIAL flag indicates that a ticket was issued using the AS protocol,
+rather than issued based on a ticket-granting ticket. Application servers that
 want to require the demonstrated knowledge of a client's secret key (e.g. a
 password-changing program) can insist that this flag be set in any tickets
 they accept, and thus be assured that the client's key was recently
@@ -943,7 +944,8 @@
 In Kerberos, the application server is ultimately responsible for accepting
 or rejecting authentication and should check that only suitably trusted KDCs
 are relied upon to authenticate a principal. The transited field in the
-ticket identifies which KDCs were involved in the authentication process and
+ticket identifies which realms (and thus which KDCs) were involved in the
+authentication process and
 an application server would normally check this field. If any of these are
 untrusted to authenticate the indicated client principal (probably
 determined by a realm-based policy), the authentication attempt must be
@@ -1060,7 +1062,8 @@
 the key is based on a password, this may create a security exposure. So, the
 initial request supports an optional field that can be used to pass
 additional information that might be needed for the initial exchange. This
-field should be used for pre-authentication as described in section 3.1.1.
+field should be used for pre-authentication as described in sections 3.1.1
+and 5.2.7.
 
 Various errors can occur; these are indicated by an error response
 (KRB_ERROR) instead of the KRB_AS_REP response. The error message is not
@@ -1096,8 +1099,8 @@
 MUST be prepared to retransmit responses in case they are lost. If a KDC
 receives a request identical to one it has recently successfully processed,
 the KDC MUST respond with a KRB_AS_REP message rather than a replay error.
-In order to reduce ciphertext given to a potential attacker, KDCs MAY wish
-to send the same response generated when the request was first handled. KDCs
+In order to reduce ciphertext given to a potential attacker, KDCs MAY
+send the same response generated when the request was first handled. KDCs
 MUST obey this replay behavior even if the actual transport in use is
 reliable.
 
@@ -1110,12 +1113,18 @@
 doesn't exist in the KDC's principal database, then an error message with a
 KDC_ERR_C_PRINCIPAL_UNKNOWN is returned.
 
+XXX The behavior when an unknown server is given is not specified
+here.  Is there any possible response other than
+KDC_ERR_S_PRINCIPAL_UNKNOWN ins this case?
+
 If required, the server pre-authenticates the request, and if the
 pre-authentication check fails, an error message with the code
 KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is required, but
 was not present in the request, an error message with the code
-KDC_ERR_PREAUTH_REQUIRED is returned and the PA-ETYPE-INFO
-pre-authentication field will be included in the KRB-ERROR message. If the
+KDC_ERR_PREAUTH_REQUIRED is returned and the METHOD-DATA field of
+the KRB-ERROR message will specify which pre-authentication mechanisms
+are acceptable.  Usually this will include PA-ETYPE-INFO and/or
+PA-ETYPE-INFO2 elements. If the
 server cannot accommodate an encryption type requested by the client, an
 error message with code KDC_ERR_ETYPE_NOSUPP is returned. Otherwise the KDC
 generates a \'random' session key[3.3].
@@ -1210,13 +1219,13 @@
 the policy of the local realm.
 
 .in3
-The flags field of the new ticket will have the following options set if
+The flags field of the new ticket will have the following bits set if
 they have been requested and if the policy of the local realm allows:
 FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE, ANONYMOUS. If
 the new ticket is post-dated (the start time is in the future), its INVALID
 flag will also be set.
 
-If all of the above succeed, the server will encrypt ciphertext part of the
+If all of the above succeed, the server will encrypt the ciphertext part of the
 ticket using the encryption key extracted from the server principal's record
 in the Kerberos database using the encryption type associated with the
 server principal's key (this choice is NOT affected by the etype field in
@@ -1619,7 +1628,7 @@
 exchanged by realms are kept secret, only denial of service results from
 using a false Kerberos server.
 
-(This paragraph changed) As in the AS exchange, the client may specify a
+As in the AS exchange, the client may specify a
 number of options in the KRB_TGS_REQ message. One of these options is the
 ENC-TKT-IN-SKEY option used for user to user authentication. An overview of
 user to user authentication can be found in section 3.7. When generating the
@@ -1944,7 +1953,7 @@
 address matches the sender's address in the message, and (if a recipient
 address is specified or the recipient requires an address) that one of the
 recipient's addresses appears as the recipient's address in the message. To
-work with network address translation, senders MAY wish to use the
+work with network address translation, senders MAY use the
 directional address type specified in section 8.1 for the sender address and
 not include recipient addresses. A failed match for either case generates a
 KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the sequence
@@ -2001,7 +2010,7 @@
 recipient requires an address) that one of the recipient's addresses appears
 as the recipient's address in the message. A failed match for either case
 generates a KRB_AP_ERR_BADADDR error. To work with network address
-translation, implementations MAY wish to use the directional address type
+translation, implementations MAY use the directional address type
 defined in section 7.1 for the sender address and include no recipient
 address. Then the timestamp and usec and/or the sequence number fields are
 checked. If timestamp and usec are expected and not present, or they are
@@ -2046,7 +2055,7 @@
 
 Implementation note: When constructing a KRB_CRED message for inclusion in a
 GSSAPI initial context token, the MIT implementation of Kerberos will not
-encrypt the KRB_CRED message if the session key is a DES or tripple DES key.
+encrypt the KRB_CRED message if the session key is a DES or triple-DES key.
 For interoperability with MIT, the Microsoft implementation will not encrypt
 the KRB_CRED in a GSSAPI token if it is using a DES session key. Starting at
 version 1.2.5, MIT Kerberos can receive and decode either encrypted or
@@ -2066,7 +2075,7 @@
 KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then
 decrypts the ciphertext and processes the resultant plaintext. If decryption
 shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is
-generated. v
+generated.
 
 If present or required, the recipient MAY verify that the operating system's
 report of the sender's address matches the sender's address in the message,
@@ -2074,11 +2083,11 @@
 in the message. The address check does not provide any added security, since
 the address if present has already been checked in the KRB_AP_REQ message
 and there is not any benefit to be gained by an attacker in reflecting a
-KRB_CRED message back to its originator. Thus, the recipient MAY wish to
+KRB_CRED message back to its originator. Thus, the recipient MAY
 ignore the address even if present in order to work better in NAT
 environments. A failed match for either case generates a KRB_AP_ERR_BADADDR
-error. Recipients MAY wish to skip the address check as the KRB_CRED message
-cannot generally be reflected back toThe timestamp and usec fields (and the
+error. Recipients MAY skip the address check as the KRB_CRED message
+cannot generally be reflected back to sender. The timestamp and usec fields (and the
 nonce field if required) are checked next. If the timestamp and usec are not
 present, or they are present but not current, the KRB_AP_ERR_SKEW error is
 generated.
@@ -2093,7 +2102,7 @@
 
 (This entire subsection is new) User to User authentication provides a
 method to perform authentication when the verifier does not have a access to
-long term service key. This might be the case when running a server (for
+a long term service key. This might be the case when running a server (for
 example a window server) as a user on a workstation. In such cases, the
 server may have access to the ticket granting ticket obtained when the user
 logged in to the workstation, but because the server is running as an
@@ -2116,9 +2125,9 @@
 exchange external to the Kerberos protococl, usually as part of the
 application protocol. This message is shown in the summary above as message
 0. Note that because the ticket granting ticket is encrypted in the KDC's
-secret key, can not be used for authentication without posession of the
-corresponding secret key, and because the verifier does not give out the
-corresponding secret key, providing a copy of the verifiers ticket granting
+secret key, it can not be used for authentication without posession of the
+corresponding secret key. Furthermore, because the verifier does not reveal the
+corresponding secret key, providing a copy of the verifier's ticket granting
 ticket does not allow impersonation of the verifier.
 
 Once the verifier's ticket granting ticket has been obtained by the client,
@@ -2230,8 +2239,8 @@
 Note that in several places, there have been changes here from RFC 1510 that
 change the abstract types. This is in part to address widespread assumptions
 that various implementors have made, in some cases resulting in
-unintentional violations of the ASN.1 standard. These will be clearly
-flagged when they occur. The differences between the abstract types in RFC
+unintentional violations of the ASN.1 standard. These are clearly
+flagged where they occur. The differences between the abstract types in RFC
 1510 and abstract types in this document can cause incompatible encodings to
 be emitted when certain encoding rules, e.g. the Packed Encoding Rules
 (PER), are used. This theoretical incompatibility should not be relevant for
@@ -2437,7 +2446,7 @@
 
 .fi
 Kerberos realm names are encoded as KerberosStrings. Realms shall not
-contain a character with the code 0 (the ASCII NUL). Most realms will
+contain a character with the code 0 (the US-ASCII NUL). Most realms will
 usually consist of several components separated by periods (.), in the style
 of Internet Domain Names, or separated by slashes (/) in the style of X.500
 names. Acceptable forms for realm names are specified in section 7. A
@@ -2452,7 +2461,6 @@
 for this field are specified in section 7.2. The name-type should be
 treated as a hint. Ignoring the name type, no two names can be the same
 (i.e. at least one of the components, or the realm, must be different).
-This constraint may be eliminated in the future.
 
 .ti3
 name-string
@@ -2493,9 +2501,9 @@
 .fi
 While this results in changes to the abstract types from the RFC 1510
 version, the encoding in DER should be unaltered. Historical implementations
-were typically limited to 32-bit integer values anyway, and assigned numbers
+were typically limited to 32-bit integer values, and assigned numbers
 should fall in the space of integer values representable in 32 bits in order
-to promote interoperability anyway.
+to promote interoperability.
 
 There are several integer fields in messages that are constrained to fixed
 values.
@@ -2511,8 +2519,9 @@
 .ti3
 msg-type
 .br
-this integer field usually is identical to the application tag number
+this integer field is usually identical to the application tag number
 of the containing message type.
+XXX Usually?  Not always??
 
 .in3
 .ti0
@@ -2538,17 +2547,13 @@
 addr-type
 .br
 This field specifies the type of address that follows. Pre-defined
-values for this field are specified in section 8.1.
+values for this field are specified in section 7.1.
 
 .ti3
 address
 .br
 This field encodes a single address of type addr-type.
 
-.in3
-The two forms differ slightly. HostAddress contains exactly one address;
-HostAddresses contains a sequence of possibly many addresses.
-
 .ti0
 5.2.6. AuthorizationData
 
@@ -2578,7 +2583,7 @@
 .in3
 Each sequence of type and data is referred to as an authorization element.
 Elements may be application specific, however, there is a common set of
-recursive elements that should be understood by all implementations. These
+recursive elements that MUST be understood by all implementations. These
 elements contain other elements embedded within them, and the interpretation
 of the encapsulating element determines which of the embedded elements must
 be interpreted, and which may be ignored.
@@ -2590,7 +2595,7 @@
 ignored, might be interpreted as issued directly by the KDC, or they might
 be stored in a separate plaintext part of the ticket. The types of the
 encapsulating elements are specified as part of the Kerberos specification
-because the behavior based on these values should be understood across
+because the behavior based on these values MUST be understood across
 implementations whereas other elements need only be understood by the
 applications which they affect.
 
@@ -2650,6 +2655,15 @@
 .ti3
 ad-checksum
 .br
+XXX This paragraph says the checksum is over the "elements" field.
+Are the i-realm and i-sname fields not integrity protected?  What
+impact might this have?
+.br
+XXX Strictly speaking, the "key used to protect the ticket" is already
+the result of key derivation (key usage 2).  Is it intended that the
+derived key is then run through key derivation again?  Probably not.
+But I can't think of wording at the moment to clarify this.
+.br
 A checksum over the elements field using a cryptographic checksum
 method that is identical to the checksum used to protect the ticket
 itself (i.e. using the same hash function and the same encryption
@@ -2708,9 +2722,10 @@
 }
 
 .fi
-When restrictive AD elements are encapsulated within the and-or element are
-encountered, only the number specified in condition-count of the
-encapsulated conditions must be met in order to satisfy this element. This
+When restrictive AD elements are encapsulated within the and-or element,
+the and-or element is considered satisfied if and only if at least the
+number of encapsulated elements specified in condition-count are satisifed.
+Therefore, this
 element may be used to implement an "or" operation by setting the
 condition-count field to 1, and it may specify an "and" operation by setting
 the condition count to the number of embedded elements. Application servers
@@ -2724,7 +2739,7 @@
 
 AD elements encapsulated within the mandatory-for-kdc element are to be
 interpreted by the KDC. KDCs that do not understand the type of an element
-embedded within the if-relevant element must reject the request.
+embedded within the mandatory-for-kdc element must reject the request.
 
 .ti0
 5.2.7. PA-DATA
@@ -3210,8 +3225,8 @@
                                   later date.
 
                                   This flag indicates that this ticket
-   9       initial                was issued using the AS protocol, and
-                                  not issued based on a ticket-granting
+   9       initial                was issued using the AS protocol, rather
+                                  than issued based on a ticket-granting
                                   ticket.
 
                                   This flag indicates that during
@@ -3322,8 +3337,9 @@
 .br
 This field in the ticket specifies the time after which the ticket is
 valid. Together with endtime, this field specifies the life of the
-ticket. If it is absent from the ticket, its value should be treated as
-that of the authtime field.
+ticket. If the starttime field is absent from the ticket, then the
+authtime field should be used in its place to determine the life of
+the ticket.
 
 .ti3
 endtime
@@ -3349,7 +3365,7 @@
 host addresses. These are the addresses from which the ticket can be
 used. If there are no addresses, the ticket can be used from any
 location. The decision by the KDC to issue or by the end server to
-accept zero-address tickets is a policy decision and is left to the
+accept addressless tickets is a policy decision and is left to the
 Kerberos and end-service administrators; they may refuse to issue or
 accept such tickets. The suggested and default policy, however, is that
 such tickets will only be issued or accepted when additional
@@ -3392,7 +3408,7 @@
 
 Because entries may be added to this field by the holder of
 credentials, except when an entry is separately authenticated by
-encapsulation in the kdc-issued element, it is not allowable for the
+encapsulation in the KDC-issued element, it is not allowable for the
 presence of an entry in the authorization data field of a ticket to
 amplify the privileges one would obtain from using a ticket.
 
@@ -3420,7 +3436,7 @@
 to the application server separately from the authentication exchange.
 Alternatively, such authorization credentials may be embedded in the
 ticket authenticating the authorized entity, when the authorization is
-separately authenticated using the kdc-issued authorization data
+separately authenticated using the KDC-issued authorization data
 element (see B.4).
 
 Similarly, if one specifies the authorization-data field of a proxy and
@@ -3537,9 +3553,7 @@
 
 The padata (pre-authentication data) field contains a sequence of
 authentication information which may be needed before credentials can
-be issued or decrypted. In most requests for initial authentication
-(KRB_AS_REQ) and most replies (KDC-REP), the padata field will be left
-out.
+be issued or decrypted.
 
 .ti3
 req-body
@@ -3634,7 +3648,7 @@
                                     after the starttime in the ticket
                                     has been reached.
 
-   7       UNUSED                   This option is presently unused.
+   7       RESERVED                 This option is presently unused.
 
                                     The RENEWABLE option indicates that
                                     the ticket to be issued is to have
@@ -3651,7 +3665,7 @@
    9       RESERVED                 Reserved for PK-Cross
 
                                     These options are presently unused.
-   10-13   UNUSED                   Option 11 is reserved for future is
+   10-13   RESERVED                 Option 11 is reserved for future is
                                     as opt-hardware-auth.
 
    14-25   RESERVED                 Reserved for future use.
@@ -3674,7 +3688,7 @@
                                     encouraged but not required to honor
                                     the DISABLE-TRANSITED-CHECK option.
 
-                                    This flag is new since RFC 1510
+                                    This flag is new since RFC 1510.
 
                                     The RENEWABLE-OK option indicates
                                     that a renewable ticket will be
@@ -3746,7 +3760,7 @@
 the TGS_REQ form), is an encoding of the desired authorization-data
 encrypted under the sub-session key if present in the Authenticator, or
 alternatively from the session key in the ticket-granting ticket, both
-from the padata field in the KRB_AP_REQ. The key usage value used when
+from the padata field in the KRB_TGS_REQ. The key usage value used when
 encrypting is 5 if a sub-session key is used, or 4 if the session key
 is used.
 
@@ -3771,7 +3785,7 @@
 This field contains the expiration date requested by the client in a
 ticket request. It is not optional, but if the requested endtime is
 "19700101000000Z", the requested ticket is to have the maximum endtime
-permitted according to KDC policy for. This special timestamp
+permitted according to KDC policy. Implementation note: This special timestamp
 corresponds to a UNIX time_t value of zero on most systems.
 
 .ti3
@@ -3792,7 +3806,7 @@
 .ti3
 etype
 .br
-This field specifies the desired encryption algorithm to be used in the
+This field specifies the desired encryption algorithms to be used in the
 response.
 
 .ti3
@@ -3803,8 +3817,9 @@
 ticket-granting server. It specifies the addresses from which the
 requested ticket is to be valid. Normally it includes the addresses for
 the client's host. If a proxy is requested, this field will contain
-other addresses. The contents of this field are usually copied by the
+other addresses. The contents of this field are copied by the
 KDC into the caddr field of the resulting ticket.
+XXX Is any other behavior acceptable (besides copying the addresses)?
 
 .ti3
 additional-tickets
@@ -4195,6 +4210,10 @@
 and should not transmit an Authenticator with a sequence number of
 zero.
 
+XXX Is this truly desired, that the sequence number be omitted when it
+is zero?  So we get messages with ..., seq-number 2^32-2, seq-number
+2^32-1, no seq-number, seq-number 1, seq-number 2, ...?
+
 .ti3
 authorization-data
 .br
@@ -4514,7 +4533,7 @@
 used for the enc-part field of the KRB-CRED message.
 
 Implementation note: implementations of certain applications, most
-notably of the Kerberos GSS-API mechanism, do not encrypt the KRB-CRED
+notably certain implementations of the Kerberos GSS-API mechanism, do not encrypt the
KRB-CRED
 message when sending it. In the case of the GSS-API mechanism, this is
 not a security vulnerability, as the KRB-CRED message itself is itself
 encrypted inside an Authenticator.
@@ -4718,9 +4737,9 @@
 
  15             AP-REP         PDU
 
- 16             RESERVED16     TGT-REQ
+ 16             RESERVED16     TGT-REQ (user2user)
 
- 17             RESERVED17     TGT-REP
+ 17             RESERVED17     TGT-REP (user2user)
 
  18-19                         unused
 
@@ -4920,11 +4939,6 @@
 All non-negative values are reserved for officially assigned type fields and
 interpretations.
 
-The values of the types for the following addresses are chosen to match the
-defined address family constants in the Berkeley Standard Distributions of
-Unix. They can be found in with symbolic names AF_xxx (where xxx is an
-abbreviation of the address family name).
-
 .in6
 .ti3
 Internet (IPv4) Addresses
@@ -4934,7 +4948,7 @@
 type of IPv4 addresses is two (2).
 
 .ti3
-Internet (IPv6) Addresses [Westerlund]
+Internet (IPv6) Addresses
 
 IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. The
 type of IPv6 addresses is twenty-four (24). [RFC2373]. The following
@@ -4945,6 +4959,8 @@
    *  the Loopback Address
    *  Link-Local addresses
 
+XXX Why no link-local addresses?
+
 .fi
 IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2.
 
@@ -4958,8 +4974,9 @@
 Netbios addresses
 
 Netbios addresses are 16-octet addresses typically composed of 1 to 15
-characters, trailing blank (ascii char 20) filled, with a 16th octet of 0x0.
-The type of Netbios addresses is 20 (0x14).
+alphanumeric characters and padded with the US-ASCII SPC character (code
+32).  The 16th octet must be the US-ASCII NUL character (code 0).
+The type of Netbios addresses is twenty (20).
 
 .ti3
 Directional Addresses
@@ -4983,7 +5000,7 @@
 where the sending party knows that the receiving party supports the address
 type. This generally means that directional addresses may only be used when
 the application protocol requires their support. Directional addresses are
-type XX (0xXX).
+type three (3).
 
 .in3
 .ti0
@@ -5014,7 +5031,7 @@
 sending port at the sender's IP address. The response to a request made
 through UDP/IP transport must also use UDP/IP transport. If the response can
 not be handled using UDP (for example because it is too large), the KDC must
-return an error forcing the client to retry the request using the TCP
+return KRB_ERR_RESPONSE_TOO_BIG, forcing the client to retry the request using the TCP
 transport.
 
 .ti0
@@ -5054,6 +5071,10 @@
 must be prepared to handle the connection being closed after the first
 response.
 
+Either the client or KDC MAY close the TCP connection in only the
+sending direction (half-close) if it does not expect to send any
+further messages.
+
 Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR) sent over
 the TCP stream is preceded by the length of the request as 4 octets in
 network byte order. The high bit of the length is reserved for future
@@ -5239,7 +5260,7 @@
 PA-ENC-TIMESTAMP                2
 PA-PW-SALT                      3
 [reserved]                      4
-PA-ENC-UNIX-TIME                5        (depricated)
+PA-ENC-UNIX-TIME                5        (deprecated)
 PA-SANDIA-SECUREID              6
 PA-SESAME                       7
 PA-OSF-DCE                      8
@@ -5275,6 +5296,7 @@
 Address type                   value
 
 IPV4                             2
+Directional                      3
 ChaosNet                         5
 XNS                              6
 ISO                              7
@@ -5378,7 +5400,7 @@
 KDC_ERR_KEY_EXPIRED            23   Password has expired 
                                           - change password to reset
 KDC_ERR_PREAUTH_FAILED         24   Pre-authentication information was invalid
-KDC_ERR_PREAUTH_REQUIRED       25   Additional pre-authenticationrequired [40]
+KDC_ERR_PREAUTH_REQUIRED       25   Additional pre-authentication required
 KDC_ERR_SERVER_NOMATCH         26   Requested server and ticket don't match
 KDC_ERR_MUST_USE_USER2USER     27   Server principal valid for user2user only
 KDC_ERR_PATH_NOT_ACCPETED      28   KDC Policy rejects transited path
@@ -5583,8 +5605,7 @@
 minimum lifetime              5 minutes
 maximum renewable lifetime    1 week
 maximum ticket lifetime       1 day
-empty addresses               only when suitable  restrictions  appear
-                              in authorization data
+empty addresses               Allowed.
 proxiable, etc.               Allowed.
 
 .fi
@@ -5605,7 +5626,7 @@
 authorization. Applications should not accept the issuance of a service
 ticket by the Kerberos server as granting authority to use the service,
 since such applications may become vulnerable to the bypass of this
-authorization check in an environment if they inter-operate with other KDCs
+authorization check in an environment where they inter-operate with other KDCs
 or where other options for application authentication are provided.
 
 Denial of service attacks are not solved with Kerberos. There are places in
@@ -5617,8 +5638,8 @@
 many kinds of denial of service attacks: denial of service attacks on the
 network which would prevent clients from contacting the KDC; denial of
 service attacks on the domain name system which could prevent a client from
-finding the IP address of the Kerberos server; and denial of service attack
-by overloading the Kerberos KDC itself with repeated requests.
+finding the IP address of the Kerberos server; and denial of service attacks
+that overload the Kerberos KDC itself with repeated requests.
 
 Interoperability conflicts caused by incompatible character-set usage (see
 5.2.1) can result in denial of service for clients that utilize
@@ -5654,6 +5675,12 @@
 attackers may try brute force or dictionary attacks against credentials that
 are observed by eavesdropping on the network.
 
+Similarly, it is recommended that principals which have keys derived
+from passwords not be permitted as the target server in a KRB_TGS_REQ,
+since the resulting KRB_TGS_REP will contain material encrypted in the
+principal's secret key suitable for conducting an offline dictionary
+attack.
+
 Each host on the network must have a clock which is loosely synchronized to
 the time of the other hosts; this synchronization is used to reduce the
 bookkeeping needs of application servers when they do replay detection. The
@@ -5662,7 +5689,7 @@
 network, the clock synchronization protocol must itself be secured from
 network attackers.
 
-Principal identifiers must not recycled on a short-term basis. A typical
+Principal identifiers must not be recycled on a short-term basis. A typical
 mode of access control will use access control lists (ACLs) to grant
 permissions to particular principals. If a stale ACL entry remains for a
 deleted principal and the principal identifier is reused, the new principal
@@ -5701,7 +5728,7 @@
 subkey), the server must utilize a replay cache to remember any
 authenticator presented within the allowable clock skew. All services
 sharing a key need to use the same replay cache. If separate replay caches
-are used, then and authenticator used with one such service could later be
+are used, then an authenticator used with one such service could later be
 replayed to a different service with the same service principal.
 
 If a server loses track of authenticators presented within the allowable
@@ -6386,7 +6413,7 @@
 .ti0
 B.1 Changes to Section 1
 
-Discussion was added to section on regarding the ability to rely on the KDC
+Discussion was added regarding the ability to rely on the KDC
 to check the transited field, and on the inclusion of a flag in a ticket
 indicating that this check has occurred. This is a new capability not
 present in RFC1510. Pre-existing implementations may ignore or not set this
@@ -6398,7 +6425,7 @@
 key might be stored on a smart-card, or otherwise obtained independent of a
 password.
 
-The introduction also mentions the use of public key for initial
+The introduction also mentions the use of public key cryptography for initial
 authentication in Kerberos by reference. RFC1510 did not include such a
 reference.
 
@@ -6427,7 +6454,7 @@
 A warning regarding generation of session keys for application use was
 added, urging the inclusion of key entropy from the KDC generated session
 key in the ticket. An example regarding use of the sub-session key was added
-to section 3.2.6. Descriptions of the pa-etype-info, and pa-pw-salt
+to section 3.2.6. Descriptions of the pa-etype-info, pa-etype-info2, and pa-pw-salt
 preauthentication data items were added. The recommendation for use of
 preauthentication was changed from "may" to "should" and a note was added
 regarding known plaintext attacks.
@@ -6456,7 +6483,7 @@
 implementations conforming to this specification will be extensible with the
 addition of new fields in future specifications.
 
-Text was added describing time_t=0 issues in the ASN.1. Text was also added,
+Text was added describing time_t=0 issues in the ASN.1. Text was also added
 clarifying issues with implementations treating omitted optional integers as
 zero. Text was added clarifying behavior for optional SEQUENCE or SEQUENCE
 OF that may be empty. Discussion was added regarding sequence numbers and
@@ -6472,7 +6499,7 @@
 
 Descriptions of commonly implemented PA-DATA were added to section 5. The
 description of KRB-SAFE has been updated to note the existing implementation
-behavior of of double-encoding.
+behavior of double-encoding.
 
 There were two definitions of METHOD-DATA in RFC 1510. The second one,
 intended for use with KRB_AP_ERR_METHOD was removed leaving the SEQUENCE OF

---

From: Tom Yu <[email-masked]>
Date: Mon, 18 Nov 2002 16:08:37 -0500

>>>>> "nectar" == Jacques A Vidrine <[email-masked]> writes:

nectar> /////////////////////
nectar> = Add a further recommendation to security considerations.

nectar> @@ -5654,6 +5675,12 @@
nectar>  attackers may try brute force or dictionary attacks against credentials that
nectar>  are observed by eavesdropping on the network.
 
nectar> +Similarly, it is recommended that principals which have keys derived
nectar> +from passwords not be permitted as the target server in a KRB_TGS_REQ,
nectar> +since the resulting KRB_TGS_REP will contain material encrypted in the
nectar> +principal's secret key suitable for conducting an offline dictionary
nectar> +attack.
nectar> +
nectar>  Each host on the network must have a clock which is loosely synchronized to
nectar>  the time of the other hosts; this synchronization is used to reduce the
nectar>  bookkeeping needs of application servers when they do replay detection. The

Note that AS_REP is similarly vulnerable... a client may normally
request any service principal in an AS_REQ; it is not limited to
requesting a TGT principal.

nectar> Other stuff:
nectar> ------------
nectar> /////////////////////
nectar> = It reads awkwardly to me to say that one `MAY wish to' do something.
nectar>   Sure they may :-) I suggest deleting the `wish to' text where it is
nectar>   used.

nectar> @@ -431,7 +431,7 @@
 
nectar>  Implementations of Kerberos, GSSAPI, and SASL [RFC 2222] MUST NOT use DNS to
nectar>  canonicalize the host components of service principal names. Application
nectar> -authors MAY wish to append a statically configured domain name to
nectar> +authors MAY append a statically configured domain name to
nectar>  unqualified hosts before passing the name to security mechanisms.
 
nectar>  Implementation note: Many current implementations do some degree of

nectar> /////////////////////
nectar> = It looks like `KDC-issued' is used more often than `kdc-issued' in the
nectar>   text to refer to the AD-KDC-ISSUED element.

nectar> @@ -460,8 +460,8 @@
nectar>  specific access control functions and may utilize files on the application
nectar>  server, or on separately issued authorization credentials such as those
nectar>  based on proxies [Neu93], or on other authorization services. Separately
nectar> -authenticated authorization credentials may be embedded in a tickets
nectar> -authorization data when encapsulated by the kdc-issued authorization data
nectar> +authenticated authorization credentials may be embedded in a ticket's
nectar> +authorization data when encapsulated by the KDC-issued authorization data
nectar>  element.
 
nectar>  Applications should not accept the mere issuance of a service ticket by the

Further complicating matters, the ASN.1 type is "AD-KDCIssued".

nectar> /////////////////////
nectar> = A clause seems to be modifying `Hades' rather than `Kerberos'.
nectar>   Reworded to avoid the problem.

nectar> @@ -672,9 +672,10 @@
nectar>  .ti3
nectar>  Kerberos
nectar>  .br
nectar> -Aside from the 3-headed dog guarding Hades, the name given to Project
nectar> -Athena's authentication service, the protocol used by that service, or
nectar> -the code used to implement the authentication service.
nectar> +The name given to the Project Athena's authentication service, the
nectar> +protocol used by that service, or the code used to implement the
nectar> +authentication service.  The name is adopted from the three-headed dog
nectar> +which guards Hades.
 
I think that the modification "Aside from the 3-headed dog guarding
Hades, Kerberos is the name..." maintains more of the original sense
of the clause.

nectar> /////////////////////
nectar> = Can a message be sent such that the msg-type field differs from the
nectar>   application tag number?

nectar> @@ -2511,8 +2519,9 @@
nectar>  .ti3
nectar>  msg-type
nectar>  .br
nectar> -this integer field usually is identical to the application tag number
nectar> +this integer field is usually identical to the application tag number
nectar>  of the containing message type.
nectar> +XXX Usually?  Not always??
 
There are implementations that send a msg-type inconsistent with the
application tag number for EncKDCRepPart -- both EncASRepPart and
EncTGSRepPart end up being encoded with application tag 26, but the
msg-type integer field ends up reflecting what the application tag
should have been.  I believe this is mentioned as an implementation
note.  If not, it should be.

nectar> /////////////////////
nectar> = Is there supposed to be some distinction between UNUSED and RESERVED
nectar>   here?  If not, use RESERVED consistently.

nectar> @@ -3634,7 +3648,7 @@
nectar>                                      after the starttime in the ticket
nectar>                                      has been reached.
 
nectar> -   7       UNUSED                   This option is presently unused.
nectar> +   7       RESERVED                 This option is presently unused.
 
nectar>                                      The RENEWABLE option indicates that
nectar>                                      the ticket to be issued is to have
nectar> @@ -3651,7 +3665,7 @@
nectar>     9       RESERVED                 Reserved for PK-Cross
 
nectar>                                      These options are presently unused.
nectar> -   10-13   UNUSED                   Option 11 is reserved for future is
nectar> +   10-13   RESERVED                 Option 11 is reserved for future is
nectar>                                      as opt-hardware-auth.
 
nectar>     14-25   RESERVED                 Reserved for future use.

nectar> /////////////////////
nectar> = Comment is in the hunk.

nectar> @@ -4195,6 +4210,10 @@
nectar>  and should not transmit an Authenticator with a sequence number of
nectar>  zero.
 
nectar> +XXX Is this truly desired, that the sequence number be omitted when it
nectar> +is zero?  So we get messages with ..., seq-number 2^32-2, seq-number
nectar> +2^32-1, no seq-number, seq-number 1, seq-number 2, ...?
nectar> +
nectar>  .ti3
nectar>  authorization-data
nectar>  .br

Some existing implementations do not distinguish between an absent
optional integer field and a present optional integer field containing
a value of zero.  So yes, for compatibility with these broken
implementations, passing through sequence number zero means that you
should omit the sequence number fields when the sequence number
reaches zero.

nectar> /////////////////////
nectar> = Note that TGT-REQ/TGT-REP are for user2user in this table.

nectar> @@ -4718,9 +4737,9 @@
 
nectar>   15             AP-REP         PDU
 
nectar> - 16             RESERVED16     TGT-REQ
nectar> + 16             RESERVED16     TGT-REQ (user2user)
 
nectar> - 17             RESERVED17     TGT-REP
nectar> + 17             RESERVED17     TGT-REP (user2user)
 
nectar>   18-19                         unused
 
Hm.  That does bring up the question of whether Ticket should be a
PDU, if we may move towards having TGT-REP contain a Ticket, it makes
less sense to allow a bare Ticket to be a PDU.

====================

Other sections of the large diff seem mostly ok to me, though I need
to look at the authoriation data bits more closely, as I do not fully
understand them.

---Tom

---

From: "Jacques A. Vidrine" <[email-masked]>
Date: Mon, 18 Nov 2002 16:02:29 -0600

> requesting a TGT principal.

Yes, of course you are right.  Perhaps s/KRB_TGS_REQ/KRB_KDC_REQ/.

[...]
> Hades, Kerberos is the name..." maintains more of the original sense

That's spot on --- a much better solution than I had suggested.

> note.  If not, it should be.

Yes, there is a `Compatibility note' to that effect.  
But, this is a slightly different issue.  The comment I quote above is
describing the `msg-type' field, which the EncKDCRepPart doesn't have.
It is only present on PDUs, and in all cases I believe it should match
the application tag number.

> should omit the sequence number fields when the sequence number

I missed something.  If the existing broken implementation (recipient)
does not distinguish between the two cases, then why must the sender
use one encoding or the other?  Or is it actually that this broken
implementation barfs when it gets one representation or the other?

[...]
> to look at the authoriation data bits more closely, as I do not fully

For what it is worth, I think that if AD-IF-RELEVANT, AD-KDCIssued,
AD-AND-OR, AD-MANDATORY-FOR-KDC are only `SHOULD' but not `MUST', then
security-critical applications cannot use them safely.  If they cannot
use these safely, then there doesn't seem much point in defining them.
(I don't have experience backing this up.  It just seems that such
composition elements are critical to maintaining identical semantics
across implementations.)

Thanks for the feedback, Tom!

Cheers,

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 18 Nov 2002 16:11:10 -0600

> less sense to allow a bare Ticket to be a PDU.

I was going to comment on this last week but decided not to on account
of user-2-user: as long as we don't define messages for the user-2-user
exchange then we need to "allow" the use of Ticket as a standalone
Kerberos type for inclusion in messages defined by other protocols.

Nor can we define u2u messages now and declare Ticket to not be a pdu;
but then, what difference does labelling it a pdu or not make?  (that's
why I quoted "allow" above).

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 18 Nov 2002 16:16:18 -0600

> composition elements are critical to maintaining identical semantics

They *can* use them safely as authorization data are critical by default.

But by not making support for these authz-data containers mandatory we
risk interop problems: client reqs containing AD-IF-RELEVANT(blah, blah)
will be rejected by servers that fail to understand AD-IF-RELEVANT,
regardless of whether they understand "blah, blah", whereas the ideal
behaviour would be that comprehension of "blah blah" has no bearing on
whether the request is accepted or not, since that is what
AD-IF-RELEVANT is for.

Better to require support for these than not, IMO.

Cheers,

Nico
--

---

From: "Jacques A. Vidrine" <[email-masked]>
Date: Mon, 18 Nov 2002 16:46:41 -0600

> They *can* use them safely as authorization data are critical by default.

It doesn't seem so:

``If an unknown authorization data element type is received by a
  server other than the ticket granting service either in an AP-REQ
  or in a ticket contained in an AP-REQ, then authentication SHOULD
  fail.''

``Implementation note: Many RFC 1510 implementations ignore unknown
  authorization data elements. Depending on these implementations to honor
  authorization data restrictions may create a security weakness.''

``Unless encapsulated in a known authorization data element amending
  the criticality of the elements it contains, 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 authentication
  SHOULD fail.''

I think s/SHOULD/MUST/, here and in similar places.
  
> Better to require support for these than not, IMO.

Agreed.

Cheers,

---

From: Sam Hartman <[email-masked]>
Date: Tue, 19 Nov 2002 10:15:52 -0500

Hmm, it sounds like we need to discuss authorization data at the
meeting today; I thought some of those shoulds were musts and both you
and Nico have pointed out significant problems.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Nov 2002 09:46:12 -0600

I will not be there, but Wyllys will be.

Nico