Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!voder!pyramid!decwrl!shelby!UDEL.EDU!Mills
From: Mills@UDEL.EDU
Newsgroups: comp.protocols.kerberos
Subject: Re:  some comments on Kerberos
Message-ID: <8905180942.aa06665@huey.udel.edu>
Date: 18 May 89 13:42:50 GMT
Sender: daemon@shelby.Stanford.EDU
Organization: The Internet
Lines: 50

Cliff,

Thanks for your comments. Here are a few comments in response.

My model for users/servers in NTP is that the users ARE the servers -
there is no intended distinction, other than keying compartments and
subnet hierarchy. You might want to declare the servers at the leaves
of the tree to be users and the rest to be servers, but that is
dangerous, since a failure can reorganize the tree and change leaves
into nonterminal nodes and vice versa.

NTP peers do keep the last message, more precisely, the last originate
and the last transmit timestamp. This is sufficient to (a) authenticate
the original sender and (b) detect and discard replays.

It is hard to distinguish normal network delay dispersions from deliberate
hostile delays. The various filtering and selection algorithms have been
developed to deal with this issue, but the peformance must be evaluated
statistically. Our experience is that they do a pretty good job in the
existing Internet, but we have no way to know if somebody out there is
tinkering with delays just to force us to develop better algorithms or
similar nasty agenda. In any case, the local-clock mechanism described
in the document and in use at all servers I know about prevents the clock
being set backwards or even forwards beyond a selectable sanity interval
(currently 1000 seconds).

Your suggestion on using selectable algorithms, as well as keys, is intriguing.
I argued against that on the basis that clock synchronization should be a
ubiquitous service, since it relies so heavily on redundancy and diversity
to detect falsetickers, prevent timewarps and improve accuracy. Having pockets
of less robust time in order to reduce vulnerability strikes me as less of
a time synchronization protocol than an event ordering protocol. Perhaps NTP
in its present form represents a compromise between these two objectives.

There are some technical issues about the authentication mechanism I am
hoping the Privacy Task Force will comment upon. The use of a default key
in order to initialize the association and also to provide a debuggning
aid for new implementations (we found that feature absolutely wonderful)
may represent a vulnerability, as may the scheme where the key selection
is determined by association mode, as well as key identifier. These gizmos
were incorporated to simplify key management and network monitoring.

We still need to explore how to align NTP with the Kerberos paradigm and
how to manage key distribution, perhaps along the lines suggested for
private mail. Heck, we are still sloshing Steve Deering's multicast
issues. NTP seems to have the right characteristics to become a litmus
test for many of these distributed protocol issues now coming up in Internet
research.

Dave