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. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
