Subject: Kerberos clock sync

From: "Joel N. Weber II" <[email-masked]>
Date: Tue, 20 May 2003 08:52:30 -0400

It appears to me that the actual issues with clock sync are:

1) If you are using an application protocol which needs a replay cache
   to be secure from replay attacks, the clock on the application
   server is used both to determine which times to reject as being out
   of bounds, and which replay cache entries can be discarded.  If an
   attacker can cause the system clock to run at the wrong rate, but
   is unable to actually make the clock go backward, then replay cache
   entries are discarded at the same ``wrong'' rate as timestamps
   reach the range where they are simply out of the accepted range.

2) It's possible if an application sends a ticket which is rejected
   because of excessive clock skew for that ticket to later be
   replayed when the time is within the allowed clock skew, if the
   time in the ticket is ahead of the time on the application server.
   I don't think clarifications explicitly discusses what happens in
   this case; but I don't think there's a vulnerability here.  It is
   certainly the case that if you aren't using network time sync at
   all, misconfiguration can occasionally cause such a replay to be
   possible.

3) The clock on the application server is used to determine when
   tickets have expired.  If an attacker gains a bit of flexibility in
   manipulating the system clock, stolen tickets can be made to work
   for a significantly longer amount of time.

   In practice, I'm unconvinced that this is a significant problem.
   If I log into a workstation in a cluster, and don't stay for longer
   than a half hour, I've probably still gotten tickets that last 20
   times longer than I was actually going to use them, and the reason
   the system is reasonably secure is that the probability that my
   tickets will get stolen is fairly low.  And if an attacker's only
   option is to make a clock run more slowly, but not backwards, then
   this attack will only be useful for prolonging the life of freshly
   stolen tickets, not for breathing new life into tickets which had
   already expired relative to the system clock on the application
   server.

   If you're using insecure time sync, you probably want sanity
   checking that the rate at which the clock is advancing is within a
   reasonable factor of the computer's hardware clock, to help make
   sure that tickets do expire in a halfway reasonably timely fashion.

4) With insecure network time sync, even with the sanity checks
   mentioned above, it may become significantly easier to execute a
   denial of service attack by simply making the clocks drift too far
   relative to each other.

5) If an attacker can cause the clock to advance too quickly, the
   system administrator is likely going to set the clock back, which
   may create vulnerabilities.  I think the spec should recommend
   changing the host key whenever setting the clock back on an
   application server.

Unless something I've said here is wrong or overlooks an important
issue, I'm unconvinced that ordinary insecure NTP actually causes any
significant security problem for Kerberos; my empirical experience
with the Unix NTP software seems to suggest that it isn't going to
actually set the clock backwards, and there comes a point where the
rate of network time diverges too far from the rate of the system
clock, and the NTP software simply stops making any attempt at
adjusting the clock.  However, some of this may be dependent on
exactly which version of the NTP software and which kernel you're
running, and so checking which sanity checks are done by a particular
version is important before depending on those sanity checks to make a
system secure.

I think the Kerberos spec ought to either document why insecure NTP
with these sanity checks causes significant insecurity, or relax the
requirements for network time sync somewhat.  (On the other hand, I'm
not sure what the meaning of ``the clock synchronization protocol MUST
itself be secured from network attackers.'' actually is: does it mean
that the protocol has to be cryptographically secure, or does it mean
that the way the protocol works needs to have the property that an
attack against whatever network time synchronization protocol is used
will not introduce significant security vulnerabilities in Kerberos?)

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 20 May 2003 07:59:22 -0700

BTW, it is possible to use Kerberos V as a secure time distribution
protocol.  Any valid principal with a valid TGT or long term key can
initiate a KDC-REQ and get the KDC's time back securely in the KDC-REP.

The draft describes how clients can use this feature of the KDC
exchanges to avoid having to have their time synchronized.  The same
does not apply to servers *unless* they can get initial tickets with
their keys (which they generally can).

Unfortunately, the KDC exchanges do not make a very accurate time
distribution protocol.  And it's not very cheap either.  But if you have
only insecure NTP you could use occasional KDC exchanges on the servers
to keep a tab on NTP.

Perhaps something more detailed could be hashed out and an I-D could be
written (either as informational or BCP).

Answers to your points are below.

On Tue, May 20, 2003 at 08:52:30AM -0400, Joel N. Weber II wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

Correct.

>    all, misconfiguration can occasionally cause such a replay to be

The replay can happen yes, but an attacker doing this replay without
knowing the ticket's session key gains little (though how much the
attacker gains might depend on the application protocol, so it's hard to
say).  Nonetheless this is an issue.

>    sure that tickets do expire in a halfway reasonably timely fashion.

Agreed.  But your computer's clock had better not be too crappy.

>    denial of service attack by simply making the clocks drift too far

Certainly.  Kerberos V does not protect against DoS attacks anyways.

>    changing the host key whenever setting the clock back on an

Yes.  IMO, the recommendation you propose makes sense and is worth
considering.

> version is important before depending on those sanity checks to make a

I've not been too concerned about NTP for much the same reasons, but the
key word here is "too" - I do wish to see users deploy secure time
distribution systems.

> requirements for network time sync somewhat.  (On the other hand, I'm

This is where I disagree.  NTP is not the only time distribution
protocol out there and, as I understand it, there exists such a thing as
secure NTP.  Further, I'm not sure that it is good for the Kerberos V
clarifications draft to say that it's ok to use Kerberos V with insecure
NTP "because ..." - we are not experts on NTP here, we might get the
recommendation wrong.  Further, that would cause clarifications to
contain a normative reference to yet another document, and such
statements might require that we get input from the NTP community.  And
all for what?  What do we gain by having such text in clarifications?

If you wish to write a draft describing the insecurity, or lack thereof
in NTP and how this applies to Kerberos V, go ahead; I for one would
like to see some research on insecure NTP.

> will not introduce significant security vulnerabilities in Kerberos?)

A time synchronization protocol need not use cryptography to be secure.
Consider a physical wire attached to a server which sends 1PPS (one
pulse per-second) signals for time synchronization.

The text you quote is clear enough to me.  Kerberos V implementations
cannot be expected to check that clocks have been synchronized securely
anyways, so I take the text as a general recommendation to both, users,
that they should setup secure time synchronization, and implementors,
that they should provide secure time synchronization technology or
know-how to their users.

Cheers,

Nico
--

---

From: "Joel N. Weber II" <[email-masked]>
Date: Tue, 20 May 2003 15:33:20 -0400

> only insecure NTP you could use occasional KDC exchanges on the servers

Right.  But secure NTP only occasionally does cryptographic checks,
and does most time sync without the cryptographic checks.

I think the only advantage of using kerberos as a time distribution in
conjunction with insecure NTP versus modifying the NTP protocol so
that it can be secure NTP can use kerberos is that you don't need to
find a site that will give you kerberos secured NTP time, but it
shouldn't be a huge burden to expect that sites using kerberos will
provide kerberos authenticated NTP time if that will make kerberos
more secure.

> Agreed.  But your computer's clock had better not be too crappy.

Experience with my kdc's clock slowly failing demonstrated that the
NTP software I am using by default can have a very high tolerance.
(It didn't refuse to correct the hardware clock until it was running
at the wrong rate by a factor of about two.)

After the failure, I installed a clock chip which I knew hadn't been
installed in a computer in at least a couple years, and it already had
the right date.  So accurate computer clocks aren't impossible to get.

Having configuration options to specify the expected drift would
greatly reduce the ability of an attacker to change the rate of clock
advance; I bet with my current kdc's clock, a setting that says that
clock sync software should just exit if the clock is drifting by more
than 1% from network time would not prevent NTP from running, assuming
an absence of attackers.

(There need to be recommendations on how to distinguish between ``my
clock chip is starting to fail'' and ``there are network attackers
trying to induce me to make my configuration less paranoid'', though.)

> Certainly.  Kerberos V does not protect against DoS attacks anyways.

Yep.  The only problem to watch out for is that if a configuration or
an aspect of protocol design makes it significantly more likely that a
human with a limited understanding will do something insecure, you
tend to end up with a system which tends to be less secure in
practice.

> key word here is "too" - I do wish to see users deploy secure time

I'd love to have secure network time, too.  But I don't know of any
public time servers I can get secure time from.

If I had software to do kerberos time + insecure NTP sync, I could get
time in a secure fashion, except that it's not at all clear that any
site that I have kerberos credentials with is actually securely
syncing their kdc's clock.

> all for what?  What do we gain by having such text in clarifications?

What makes the use of insecure NTP acceptable is not any property of
the NTP protocol, but the sanity checks done by the software receiving
the external time information.  If you buy a GPS receiver for every
machine on your network, and plug a GPS into each machine's serial
port, you need the same sort of sanity checks to not get insecurities
in kerberos.  The same is true if you use WWVB instead of GPS.  And I
think my message generally talked about the NTP software, not about
the NTP protocol, but your bringing this up makes me more aware of the
need to explicitly think about that distinction between the NTP wire
protocol and the piece of software that typical unix users happen to
run when they happen to want to use the NTP wire protocol.

I believe it is the responsibility of the kerberos working group, not
the NTP community, to understand what vulnerabilities exist in
kerberos if the clocks on hosts using kerberos are manipulated by
attackers, and to understand the extent to which simple sanity checks
on time data from insecure sources can reduce or eliminate those
vulnerabilities.

> like to see some research on insecure NTP.

What we actually need is a document describing kerberos's
vulnerabilities when using an insecure time source, such as GPS,
WWV/WWVB, or insecure NTP, and what sanity checks a time
synchronization system that relies on an insecure source should make
in order to minimize the vulnerabilities it introduces in kerberos.

Anyway, I'm interested in making an attempt at writing such a
document, and will probably do so next week if time allows.  

> pulse per-second) signals for time synchronization.

OK, I can consider this wire.  It sounds like synchronizing to that
wire isn't going to be ``synchroniz[ing] over the network'', and
therefore, the draft as it is written does not require that anything
special be done to make it secure from attackers.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 20 May 2003 14:52:14 -0700

> provide kerberos authenticated NTP time if that will make kerberos

I think assymetric key cryptography is better suited for secure time
distribution.

[...]
> public time servers I can get secure time from.

You get what you pay for.  If there's enough demand for it I'm sure
someone could offer secure time distribution over the Internet.

> syncing their kdc's clock.

That's ok.  As long as your entire organization drifts together then
drifting is ok.

[...]
> run when they happen to want to use the NTP wire protocol.

You brought this up, not I :)

> on time data from insecure sources can reduce or eliminate those

I'm not sure I agree with this.  Clarifications is clear about the
secure time synchronization requirement, and i think that should
suffice.  Additional text about how the security of Kerberos is affected
by attacks on time distribution that cause clocks to speed up, slow
down, run backwards, jump bacwards or forwards, would be good to have,
but I don't think it's essential for the draft to progress.

Also, I don't think this WG should be responsible for describing "the
extent to which simple sanity checks on time data from insecure sources
can reduce or eliminate those vulnerabilities" because such sanity
checks would belong in the time synchronization system and not in any
Kerberos V implementation; such sanity checks would not be specific to
Kerberos V but rather more general, so they should be described,
perhaps, in a BCP, probably in the STIME WG.

> in order to minimize the vulnerabilities it introduces in kerberos.

As long as this is not a new requirement for clarifications...

> document, and will probably do so next week if time allows.  

I'll be looking forward to it.

> special be done to make it secure from attackers.

Well, whatever is on the other end of this wire had better be secure
itself.  But the thing about this 1PPS signal is that the worst you can
do with it is speed up or slow down receipients clocks, or perhaps you
could get them to stop accepting the 1PPS signal; but you could not
actually cause clocks to run backwards or jump in either direction
through manipulation of this 1PPS signal.

A secure 1PPS bus in combination with insecure NTP would itself be
secure (after any initial bootstrapping phase).  I realize that noone
builds data centers with 1PPS signals for every host.  But that this is
a possible configuration buttresses my point that an in-depth discussion
of this topic is best left to a document other than clarifications.

Cheers,

Nico
--