OpenSSL in FIPS mode - MD5 hash in replay cache
tomas.kuthan at oracle.com
Tue Dec 22 18:30:58 EST 2015
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.
thank you for your reply.
Is there a reason not to use a new extension identifier 'SHA1:' as I
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.
More information about the krbdev