OpenSSL in FIPS mode - MD5 hash in replay cache

[Tomas Kuthan]

On 12/22/15 19:29, Greg Hudson wrote:
> On 12/18/2015 07:56 AM, Tomas Kuthan wrote:
>> rcache uses an unkeyed MD5 hash of the authenticator to distinguish
>> between different request with equal client principal, server principal
>> and microsecond time.
> [...]
>> Would it be possible to use SHA-1 instead of MD5?
>
> I might be okay with just changing the hash function, and deciding that
> if you mix versions of MIT krb5 with the same replay cache, you will get
> false negatives.  (That sounds bad, but the story for sharing the same
> replay cache among concurrent processes is already pretty bad.)  I think
> a proper phased transition would be pretty complicated, based on how the
> current code is structured.
>
> It would be nice to use SHA-256 rather than SHA-1, as SHA-1 is itself
> being phased out.  Unfortunately we do not currently have a libk5crypto
> interface for SHA-256 (there is no unkeyed SHA-256 checksum type, and no
> alternative API), so we would have to address that first.
>
> We would like to make more extensive changes to the reply cache (see
> http://k5wiki.kerberos.org/wiki/Projects/Replay_cache_improvements ) but
> do not currently have a timetable.
>

Hi Greg,

thank you for your reply.

Is there a reason not to use a new extension identifier 'SHA1:' as I 
proposed originally?
I acknowledge this is not a proper phased transition, but it would not 
suffer from false negatives.

These false negatives are not unlikely upon upgrades:
1) genuine request comes in
2) current version stores MD5(authenticator) in rcache
3) Kerberos is upgraded
4) replay attempt comes in
5) new version doesn't find SHA1(authenticator) in rcache
=> replayed authenticator is accepted

If we use a different extension identifier, the extension record with 
the old hash will not be regarded and the code will reject the replayed 
authenticator based on the compatibility record without the hash.

I would have also preferred SHA-256 (+ it was pointed out to me in an 
internal discussion twice), but as you say, it is not currently 
available. New checksum type for SHA-256 would be warmly welcomed.

Thanks,
Tomas