[17593] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Re: clock skew and preauth

daemon@ATHENA.MIT.EDU (Simo Sorce)
Mon Apr 16 07:42:12 2012

From: Simo Sorce <simo@redhat.com>
To: Tom Yu <tlyu@mit.edu>
In-Reply-To: <ldv1unoz62p.fsf@cathode-dark-space.mit.edu>
Date: Mon, 16 Apr 2012 07:41:54 -0400
Message-ID: <1334576514.16658.116.camel@willson.li.ssimo.org>
Mime-Version: 1.0
Cc: Stef Walter <stefw@gnome.org>, krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu

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.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

home help back first fref pref prev next nref lref last post