Proposed modifications to replay cache to prevent false positives

[Jeffrey Hutzelman]

On Friday, May 27, 2005 05:21:56 PM -0400 Jeffrey Altman 
<jaltman at columbia.edu> wrote:


>>> One question that is outstanding is which hash algorithm should be used?
>>
>>
>> I'd suggest SHA-1.  Yeah, we could have collision issues, but if
>> someone's trying to generate authenticators that will produce false
>> replay detections, let 'em.  And any work done to optimize either the
>> replay cache code or the AES/SHA1 cryptosystem will benefit both.
>>
>> Or, truncated SHA-1, to maybe 128 bits (quick to compare on a 64-bit
>> machine).
>>
>> Maybe make it configurable, by writing some identifying value into the
>> record (the server field, maybe).  We wouldn't have to support any other
>> value right now, but maybe having a marker there might help a
>> transition?  Then again, in the long term, we probably want to change
>> the format more drastically anyways, so never mind....
>
> I think we want to avoid the configurability at the moment.   We can
> use the server string as a marker for the type but I think having
> multiple hash types in the file is only going to get us into trouble.

Configurability in this dimension is not that important, at least for the 
moment.  However, _extensibility_ is important.  Don't paint yourselves 
into a corner in which you can't transition from one hash to another.  In 
my mind, this means the hash type would need to be recored in each entry, 
so that future code can handle caches with two hash types, for transition 
purposes.

I'd also suggest including the hash type in the client-principal entry, 
leaving the server entry available for future extension or for use in 
easing a transition to a completely different format.  I'm not saying it'll 
definitely be needed for that purpose, but it can't hurt to leave the 
option open.

As far as the timestamp goes, I would recommend the use of a 32-bit 
timestamp, and transitioning to a new file format sometime in the next 30 
years.

-- Jeff