Proposed modifications to replay cache to prevent false positives

[Roland Dowdeswell]

On 1211311853 seconds since the Beginning of the UNIX epoch
Ken Raeburn wrote:
>

>(Sorry, I guess I didn't actually *finish* this email and sent it  
>off...)
>
>> variable - authenticator-hash == base64-encoded hash string with NUL  
>> terminator
>Plaintext or encrypted version?

I would imagine that a hash of the encrypted authenticator would
be a more useful thing to store as that is what you are attempting
to detect replays of.  It also is less likely to collide than the
plaintext of the authenticator as the encrypted authenticator:

	1.  may be encrypted with different keys if used with a
	    different ticket, and

	2.  has a randomly selected IV.

These facts would substantially reduce the likelihood that
authenticators would collide.  And, in fact, the authenticator
structure in krb5.h:

/* the unencrypted version */
typedef struct _krb5_authenticator {
    krb5_magic magic;
    krb5_principal client;              /* client name/realm */
    krb5_checksum *checksum;    /* checksum, includes type, optional */
    krb5_int32 cusec;                   /* client usec portion */
    krb5_timestamp ctime;               /* client sec portion */
    krb5_keyblock *subkey;              /* true session key, optional */
    krb5_ui_4 seq_number;               /* sequence #, optional */
    krb5_authdata **authorization_data; /* New add by Ari, auth data */ 
} krb5_authenticator; 

does not contain non-optional data which is guaranteed or even
incredibly likely[1] to be different between authenticators.

The IV/key combination however is quite likely to be different
between authenticators especially in conjunction with the other
data.  Even with a 64 bit block size, the infrequent but persistent
replay collisions which I see in the field would not occur if the
randomly selected IVs are chosen with a PRNG which doesn't bzero()
out its internal state to silence unitialised variable warnings.

Using the ciphertext of the authenticator also seems more elegant
to me as that is the actual data which would be replayed to the
server.

[1]	I've certainly seen time collisions in practice and everything
	else that might be randomly generated is marked as optional.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/