Projects/replay cache collision avoidance - Revision history

TomYu at 04:08, 16 February 2010

2010-02-16T04:08:26Z

Ghudson at 03:22, 20 January 2009

2009-01-20T03:22:01Z

Ghudson at 19:13, 15 January 2009

2009-01-15T19:13:08Z

Ghudson: /* Implementation considerations */

2009-01-14T20:37:14Z

‎Implementation considerations

Ghudson: /* The Proposal */

2009-01-14T20:31:03Z

‎The Proposal

Ghudson: /* How does this provide backward compatibility? */

2009-01-14T20:28:45Z

‎How does this provide backward compatibility?

Ghudson: /* Implementation considerations */

2009-01-14T20:26:09Z

‎Implementation considerations

Ghudson: /* The Proposal */

2009-01-14T20:25:27Z

‎The Proposal

Ghudson: /* The Proposal */

2009-01-14T20:24:52Z

‎The Proposal

Ghudson at 17:54, 14 January 2009

2009-01-14T17:54:56Z

← Older revision		Revision as of 04:08, 16 February 2010
Line 1:		Line 1:
−	{{project-~~completed~~}}	+	{{project-rel\|1.7}}
	== Background ==		== Background ==

← Older revision		Revision as of 03:22, 20 January 2009
Line 180:		Line 180:

	===Approvals===		===Approvals===
		+
		+	Greg Hudson

	===Discussion===		===Discussion===

← Older revision		Revision as of 19:13, 15 January 2009
Line 1:		Line 1:
−	{{project-~~approved~~}}	+	{{project-completed}}
	== Background ==		== Background ==

← Older revision		Revision as of 20:37, 14 January 2009
Line 164:		Line 164:

	Old implementations will read the entire extension records in the new replay cache entry, but ignore the new entries due to the zero-length strings.		Old implementations will read the entire extension records in the new replay cache entry, but ignore the new entries due to the zero-length strings.
		+
		+	When reading in a replay cache, we expect to see "replays" between the old-style and new-style entries written out by new code. These need to be handled by letting records with message hashes supersede those without.

	==Review==		==Review==

← Older revision		Revision as of 20:31, 14 January 2009
Line 108:		Line 108:
	The extension identification scheme allows transition to future enhanced replay cache file formats. We eschew binary encoding because embedded null bytes will cause old implementations to truncate that component of the record because they use <code>strlen</code> to determine the length of the principal name to write out.		The extension identification scheme allows transition to future enhanced replay cache file formats. We eschew binary encoding because embedded null bytes will cause old implementations to truncate that component of the record because they use <code>strlen</code> to determine the length of the principal name to write out.

−	This record would be followed by the existing record consisting of the client
		+	This record would be followed by the existing record consisting of the client and server principal names, the time stamp and the microseconds value. A complete entry therefore takes up two existing records. We cannot assume that the two records will be read in the same order as they were written, as an expunge operation might reorder entries in the file (the MIT krb5 code reverses the order of records in the file, for instance). Therefore, extension records are defined to supersede, rather than augment, the normal style of record.
−	and server principal names, the time stamp and the microseconds value.
−	A complete entry therefore takes up two existing records.

	Hashing the ciphertext is relatively safe given reasonable assumptions about the security of the encryption, and provides additional opportunities to prevent false positives. (The mandatory components of an authenticator might be identical between two successive legitimate requests.)		Hashing the ciphertext is relatively safe given reasonable assumptions about the security of the encryption, and provides additional opportunities to prevent false positives. (The mandatory components of an authenticator might be identical between two successive legitimate requests.)

← Older revision		Revision as of 20:28, 14 January 2009
Line 121:		Line 121:
	=== How does this provide backward compatibility? ===		=== How does this provide backward compatibility? ===

−	New servers reading entries written by new servers will gather the new-style entries in pairs and use the hash in the "new" half of the pair. Since a pair consists of a "new" record followed immediately by an "old" record, the new server can distinguish between an "old" record written by an old implementation from a "new" record written by a new implementation. In this way, the new implementation can ignore "old" records written by a new implementation, avoiding any false positives that might occur by matching the more-ambiguous "old" record, while still correctly matching "old" records written by an old implementation, should that be necessary.
		+	New servers reading entries written by new servers will interpret the hash entries containing the hash values, and use those in preference to the old-style records which do not contain hash values.
−
−	For new servers reading entries written by new servers, the comparisons are made based
−	upon the hashes, then the authenticators. The client and server principal names
−	and the timestamps become irrelevant. If there is an authenticator being used multiple
−	times, it is a problem.

	For new servers reading entries written by old servers, the string fields will be		For new servers reading entries written by old servers, the string fields will be

@@ Line 166: / Line 166: @@
 == Implementation considerations ==
-The <code>krb5_rc_store</code> function is an internal API.  The <code>krb5_donot_replay</code> structure can gain a new member to point to the cleartext of the authenticator.
+The <code>krb5_rc_store</code> function is an internal API.  The <code>krb5_donot_replay</code> structure can gain a new member containing the hash of the authenticator.
 The key to detecting one of these new extension records is finding a replay cache entry that appears to have a zero-length string for the server principal name.  The search mechanism that <code>krb5_rc_dfl_store</code> uses will take into account the authenticator hash.
 Old implementations will read the entire extension records in the new replay cache entry, but ignore the new entries due to the zero-length strings.
 ==Review==

@@ Line 95: / Line 95: @@
       variable       - hex-encoded hash of authenticator ciphertext
       char           - space
-      variable       - ascii decimal length of client principal name
+      variable       - ASCII decimal length of client principal name
       char           - ":"
       variable       - client principal name
       char           - space
-      char           - ascii decimal length of server principal name
+      variable       - ASCII decimal length of server principal name
       char           - ":"
-      char           - server principal name
+      variable       - server principal name
       char           - null terminator
   krb5_int32     - microseconds

@@ Line 86: / Line 86: @@
 existing deployments.
   unsigned int   - 1 (length of sentinel)
@@ Line 98: / Line 94: @@
       variable       - extension identification "HASH:"
       variable       - hex-encoded hash of authenticator ciphertext
       char           - null terminator
   krb5_int32     - microseconds

← Older revision		Revision as of 17:54, 14 January 2009
Line 1:		Line 1:
−	{{project-~~completed~~}}	+	{{project-approved}}
	== Background ==		== Background ==