Proposed modifications to replay cache to prevent false positives

[Jeffrey Altman]

Ken Raeburn wrote:

> We could retain the checks against the old-style records too, when the
> hash value is not present.  It would be slower, and would continue to
> have false positives if the older implementation wrote out the value
> first, but it would be more secure.  And you're already going to be
> stuck with false positives until all of the applications are switched over.

I believe that in many cases, end users may be willing to open up the
vulnerability window a small amount in order to avoid the false
positives in the applications that have been migrated.   We can make it
be configurable as to which behavior is used.

Clearly we are always going to have false positives in the older
software but I don't think users should have to complete a migration to
the new format in order to avoid any false positives.

>> I would also propose that the "unsigned int" types be replaced in the
>> code base with "krb5_int32" to ensure that 32-bit and 64-bit apps can
>> read/write from the same replay cache file.
> 
> 
> Sounds good.  I think the timestamp may be a trickier issue.

The timestamp question is mighty tricky and I don't have a
recommendation for that one yet.

>> 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.

Jeffrey Altman