API for verifying authenticator checksum?

Greg Hudson ghudson at mit.edu
Mon Dec 1 10:47:19 EST 2014


On 12/01/2014 03:03 AM, Peter Mogensen wrote:
>> Be aware that integrity-protecting application data using the
>> authenticator  checksum increases a protocol's dependency on the replay
>> cache, which is inherently imperfect.

> This seems counter-intuitive to me.

The more robust alternative is to do mutual authentication, wait for the
AP-REP, and send the payload encrypted or checksummed in the acceptor
subkey.  This is what a GSSAPI application would do if a modern enctype
is used.  (Well, assuming the application doesn't use prot_ready.)

I wasn't suggesting simply trusting the payload without integrity
protection.

> Or at least... the purpose would not be to integrity-protect the
> application data, but rather to bind the authenticator to the specific
> user-data to not let it be used with other user-data payloads.
> At least for user-data with idempotent or otherwise only-valid-once
> semantics, this would reduce the need for a replay cache.

I don't think idempotence is sufficient.  A payload of "set bank account
balance to $100" is idempotent, but you don't want an attacker to be
able to replay that message after a different payload changed the balance.

But yes, for a certain subset of application payloads, replays are not
an issue, and 0-RTT integrity protection is workable without a perfect
replay cache.


More information about the Kerberos mailing list