[36644] in Kerberos
Re: API for verifying authenticator checksum?
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Dec 1 10:47:36 2014
Message-ID: <547C8D87.9060103@mit.edu>
Date: Mon, 01 Dec 2014 10:47:19 -0500
From: Greg Hudson <ghudson@mit.edu>
MIME-Version: 1.0
To: Peter Mogensen <apm@one.com>, kerberos@mit.edu
In-Reply-To: <547C20EB.6040609@one.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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
