[17595] in Kerberos_V5_Development
Re: clock skew and preauth
daemon@ATHENA.MIT.EDU (Stef Walter)
Mon Apr 16 09:14:46 2012
Message-ID: <4F8C1B3C.4040703@gnome.org>
Date: Mon, 16 Apr 2012 15:14:36 +0200
From: Stef Walter <stefw@gnome.org>
MIME-Version: 1.0
To: Simo Sorce <simo@redhat.com>
In-Reply-To: <1334576514.16658.116.camel@willson.li.ssimo.org>
Cc: krbdev@mit.edu, Tom Yu <tlyu@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On 2012-04-16 13:41, Simo Sorce wrote:
> On Sun, 2012-04-15 at 23:52 -0400, Tom Yu wrote:
>> Greg Hudson <ghudson@MIT.EDU> writes:
>>
>>> I have one concern about this approach, which is that an attacker could
>>> create a false log entry for a successful preauthentication on the KDC
>>> by forging the timestamp in a preauth-required error. That is, you
>>> attempt to kinit at noon; I forge a timestamp of 11pm in the
>>> preauth-required error and capture your preauthenticated request; then
>>> at 11pm I send that request to the KDC to make it look like you
>>> authenticated at that time.
>>>
>>> This isn't necessarily a serious enough vulnerability to worry about
>>> (when the alternative is for preauth to just fail with skewed clocks),
>>> but I want to raise the issue before taking the patch.
>>
>> I think it's OK as long as we clearly communicate the auditing
>> consequences in our documentation and elsewhere. Does anyone see a
>> security consequence besides auditing?
>
> Being able to forge audit events may be annoying but caring for those is
> not as important as having a working system. The tradeoff is more than
> justified to me.
FWIW, I agree.
I would posit that: Sensitive deployments where this is a security risk
should have 'kdc_timesync = 0' in their client krb5.conf files already
(with or without this fix).
Cheers,
Stef
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
