Subject: Proposed clarifications changes to address IESG comments

From: [email-masked] (Sam Hartman)
Date: Fri, 9 Jan 2004 20:18:55 -0500 (EST)

I think this addresses all the comments I believe require text changes besides:

* Id-nits
* Steve's comments about sequence number spaces

Do these changes meet with working group approval?

--- krbclar-draft-04.nroff	2004/01/08 20:09:58	1.1
+++ krbclar-draft-04.nroff	2004/01/10 01:18:01	1.2
@@ -294,7 +294,7 @@
 issue ticket-granting tickets for other realms, but they are
 encouraged not to do so. A client may request that the KDCs not check
 the transited field by setting the DISABLE-TRANSITED-CHECK flag. KDCs
-are SHOULD honor this flag.
+SHOULD honor this flag.
 
 .He "1.2. Choosing a principal with which to communicate"
 
@@ -1268,7 +1268,7 @@
 application specific checksum, an initial sequence number to be used in
 KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in
 negotiations for a session key unique to this particular session.
-Authenticators MAY NOT be re-used and will be rejected if replayed to a
+Authenticators MAY NOT be re-used and SHOULD be rejected if replayed to a
 server[9]. If a sequence number is to be included, it SHOULD be randomly
 chosen so that even after many messages have been exchanged it is not likely
 to collide with other sequence numbers in use.
@@ -1540,7 +1540,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
@@ -1615,7 +1615,7 @@
 ticket-granting ticket for a remote realm, and if no key is shared
 with the requested realm, then the Kerberos server will select the
 realm \'closest' to the requested realm with which it does share a
-key, and use that realm instead.  Thss is theonly cases where the
+key, and use that realm instead.  This is the only case where the
 response for the KDC will be for a different server than that
 requested by the client.
 
@@ -1863,16 +1863,18 @@
 case generates a KRB_AP_ERR_BADADDR error. 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 present but not current, the
-KRB_AP_ERR_SKEW error is generated. If the server name, along with the
-client name, time and microsecond fields from the Authenticator match
-any recently-seen (sent or received) such tuples, the
-KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence number
-is included, or a sequence number is expected but not present, the
-KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and
-usec or a sequence number is present, a KRB_AP_ERR_MODIFIED error is
-generated. Finally, the checksum is computed over the data and control
-information, and if it doesn't match the received checksum, a
-KRB_AP_ERR_MODIFIED error is generated.
+KRB_AP_ERR_SKEW error is generated. Timestamps are not required to be
+strictly ordered; they are only required to be in the skew window.  If
+the server name, along with the client name, time and microsecond
+fields from the Authenticator match any recently-seen (sent or
+received) such tuples, the KRB_AP_ERR_REPEAT error is generated. If an
+incorrect sequence number is included, or a sequence number is
+expected but not present, the KRB_AP_ERR_BADORDER error is
+generated. If neither a time-stamp and usec or a sequence number is
+present, a KRB_AP_ERR_MODIFIED error is generated. Finally, the
+checksum is computed over the data and control information, and if it
+doesn't match the received checksum, a KRB_AP_ERR_MODIFIED error is
+generated.
 
 If all the checks succeed, the application is assured that the message was
 generated by its peer and was not modified in transit.
@@ -2121,7 +2123,7 @@
 There might exist other documents which define protocols in terms of the
 RFC1510 encryption types or checksum types. Such documents would not know
 about key usages. In order that these specifications continue to be
-meaningful until they are updated, if not key usage values are
+meaningful until they are updated, if no key usage values are
 specified then key usages 1024 and 1025 must be used to
 derive keys for encryption and checksums, respectively (this
 does not apply to protocols that do their own encryption independent of this
@@ -2263,7 +2265,15 @@
 SHOULD gracefully handle receiving a message with an unrecognized tag
 anyway, and return an error message if appropriate.
 
-.He "5.1.5. Tag Numbers Greater Than 30"
+In particular, KDCs SHOULD return KRB_AP_ERR_MSG_TYPE if the incorrect
+tag is sent over a TCP transport.  The KDCs SHOULD NOT respond to
+messages received with an unknown tag over UDP transport in order to
+avoid denial of service attacks.  For non-KDC applications, the
+Kerberos implementation typically indicates an error to the
+application which takes appropriate steps based on the application
+protocol.
+
+.He"5.1.5. Tag Numbers Greater Than 30"
 
 A naive implementation of a DER ASN.1 decoder may experience problems with
 ASN.1 tag numbers greater than 30, due to such tag numbers being encoded
@@ -4982,27 +4992,27 @@
 mixed case. DNS on the other hand is case insensitive for queries. Since
 "MYREALM", "myrealm", and "MyRealm" are all different it is necessary that
 only one of the possible combinations of upper and lower case characters be
-used. This restriction may be lifted in the future as the DNS naming scheme
-is expanded to support non-US-ASCII names.
+used. 
 
 .He "7.2.3.2. Specifying KDC Location information with DNS SRV records"
 
-KDC location information is to be stored using the DNS SRV RR [RFC 2052].
+KDC location information is to be stored using the DNS SRV RR [RFC 2782].
 The format of this RR is as follows:
 
-   Service.Proto.Realm TTL Class SRV Priority Weight Port Target
+   _Service._Proto.Realm TTL Class SRV Priority Weight Port Target
 
-The Service name for Kerberos is always "_kerberos".
+The Service name for Kerberos is always "kerberos".
 
-The Proto can be one of "_udp", "_tcp". If these SRV records are to be used,
-both "_udp" and "_tcp" records MUST be specified for all KDC deployments.
+The Proto can be one of "udp", "tcp". If these SRV records are to be used,
+both "udp" and "tcp" records MUST be specified for all KDC deployments.
 
-The Realm is the Kerberos realm that this record corresponds to.
+The Realm is the Kerberos realm that this record corresponds to.  The
+realm MUST be a domain style realm name.
 
 TTL, Class, SRV, Priority, Weight, and Target have the standard meaning as
-defined in RFC 2052.
+defined in RFC 2782.
 
-As per RFC 2052 the Port number used for "_udp" and "_tcp" SRV records
+As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV records
 SHOULD be the value assigned to "kerberos" by the Internet Assigned Number
 Authority: 88 (decimal) unless the KDC is configured to listen on an
 alternate TCP port.
@@ -5816,11 +5826,10 @@
 October 1996, Obsoletes - RFC 1602, Status: Best Current Practice.
 
 .ti 3
-[RFC2052]
+[RFC2782]
 .br
-A. Gulbrandsen and P. Vixie, RFC2052: "A DNS RR for Specifying
-the Location of Services (DNS SRV)," October 1996, Obseleted by
-RFC2782, Status: Experimental
+A. Gulbrandsen,  P. Vixie and L. Esibov., RFC2782: "A DNS RR for Specifying
+the Location of Services (DNS SRV)," February 2000.
 
 .ti 3
 [RFC2253]