Subject: Re: questions on bcn's issue list

From: Sam Hartman <[email-masked]>
Date: Thu, 18 Apr 2002 16:08:39 -0400

>>>>> "John" == John Brezak <[email-masked]> writes:

    John> The KDC should always respond to a request even if it
    John> appears to be a reply. How the KDC creates that response is
    John> an implementation detail that should not be in the RFC.

Ah, so we're dropping the replay detected error completely?

---

From: Sam Hartman <[email-masked]>
Date: Sun, 28 Apr 2002 19:28:10 -0400

Here is a patch to sections 3 and 8.  It does the following:

* Notes that you can use directional addresses to deal with NATs. 

* Makes it clear that sender addresses are required for KRB_PRIV and
  KRB_SAFE

* Introduces an implementation note for krb_cred regarding MIT's not
  encrypting the message all the time.

* Notes that implementations may wish to ignore recipient address
  checks for KRB_CRED.  They really are quite pointless even if you
  buy that address checking is useful

* Adds the directional address type to section 8, although does not
  assign a number to it.

Please proof for clarity and correctness.

I believe this set of diffs completes all the tasks I'm signed up for
on Cliff's list.  If there are other tasks I could help with let me know.

--- krbclar3-1.html	2002/04/28 22:04:12	1.2
+++ krbclar3-1.html	2002/04/28 23:19:21	1.3
@@ -1045,26 +1045,28 @@
 error.  The application verifies that the checksum used is a
 collision-proof keyed checksum that uses keys compatible with the
 sub-session or session key as appropriate, and if it is not, a
-KRB_AP_ERR_INAPP_CKSUM error is generated.  If the sender's address
-was included in the control information, the recipient verifies that
+KRB_AP_ERR_INAPP_CKSUM error is generated.  The sender's address MUST
+be included in the control information; the recipient verifies that
 the operating system's report of the sender's 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.  A failed match for either 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[20] ) 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.
+message.  To work with network address translation, senders MAY wish
+to 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 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[20] )
+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.
 
 <P>
 
@@ -1103,23 +1105,26 @@
 A mismatch generates a 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.  If the
-sender's address was included in the control information, the
-recipient verifies that the operating system's report of the sender's
-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.  A failed match for either 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 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.
+modified, a KRB_AP_ERR_BAD_INTEGRITY error is generated.  The sender's
+address MUST be included in the control information; the recipient
+verifies that the operating system's report of the sender's 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.  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 defined
+in section 8.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 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 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.
 
 <P>
 
@@ -1157,9 +1162,18 @@
 
 <p>
 
-Implementation note: [<b> Regarding unencrypted KRB_CRED messages go
-here.  We need to make sure we understand what MIT does and reconcile
-with Microsoft.</b>]
+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.  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 unencrypted KRB_CRED tokens
+in the GSSAPI exchange.  The Heimdal implementation of Kerberos can
+also accept either encrypted or unencrypted KRB_CRED messages.  Since
+the KRB_CRED message in a GSSAPI token is encrypted in the
+authenticator, the MIT behavior does not present a security problem,
+although it is a violation of the Kerberos specification.
 
 <H4>3.6.2.  Receipt of KRB_CRED message</H4>
 
@@ -1175,11 +1189,18 @@
 
 <P>
 
-If present or required, the recipient verifies that the operating
+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, and 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.  The timestamp and usec
+the recipient's address 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 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 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.
--- krbclar8-1.html	2002/04/28 22:55:34	1.1
+++ krbclar8-1.html	2002/04/28 23:12:35	1.2
@@ -47,6 +47,33 @@
 characters, trailing blank (ascii char 20) filled, with a 16th octet
 of 0x0.  The type of Netbios addresses is 20 (0x14).
 
+<h5> Directional Addresses</h5>
+
+In many environments, including the sender address in KRB_SAFE and
+KRB_PRIV messages is undesirable because  the addresses may be changed
+in transport by network address translators.  However, if these
+addresses are removed, the messages may be subject to a reflection
+attack in which  a message is reflected back to its originator.  The
+directional address type provides a way to avoid transport addresses
+and reflection attacks.   Directional addresses  are encoded as four
+byte unsigned integers in network byte order.  If the message is originated by
+the party sending the original KRB_AP_REQ message, then an address of
+0 should be used.  If the message is originated by the party to whom
+that KRB_AP_REQ was sent, then the address 1 should be used.
+Applications involving multiple parties  can specify the use of other
+addresses.
+
+<p>
+
+Directional addresses MUST only be used for the sender address field
+in the KRB_SAFE or KRB_PRIV messages.  They MUST NOT be used as a
+ticket address or in a KRB_AP_REQ message.  This address type SHOULD
+only be used in situations 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).
+
+
 <H3>8.2.  KDC messages</H3>
 
 <H4>8.2.1.  UDP/IP transport</H4>