From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 13 Mar 1997 09:27:17 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Timetravel in NT [-/+]
X-Keywords: daylight [-/+] DST [-/+] timezone [-/+]
In article <5g5ruv$96@lorne.stir.ac.uk>, Sam Nelson <sam@cs.stir.ac.uk> wrote:
>In article <5fnrjl$1m10$1@news-s01.ny.us.ibm.net>, svercek@ibm.net (John Svercek) writes:
>| I need to determint the time in GMT given a future date and timezone
>| (taking into account daylight savingst time). Is there a system function
>| which will do this. If not, I think there exists a system table which
>| contains the rules for every timezone. Where is it so I could write the
>| translator myself.
>|
>This is impossible in any general sense, because in many parts of the world,
>and hence many timezones, the DST switch isn't decided algorithmically and is
>often only decided a year at a time. For example, in the UK at present, there
>are still arguments going on about whether we should `synchronise' with `the
>rest of Europe', i.e., move everything forward one hour, and there are noises
>from France apparently about abolishing DST altogether (now _there's_ a smart
>idea...!).
This is a bit out of date, I am afraid. We changed to an algorithmic
model about 5 years back, and have just changed to the standard EU
change dates. Yes, you are correct that those idiots are weebling
about using an offset timezone ('for efficiency').
But before that, the DST dates and offsets were decided by Parliament
only a few months in advance and, during either WW I or WW II, the
offset was sometimes 2 hours. During the miners' strike in the days of
Wilson, the latter proposed an ad-hoc double summer time for a period
of 3 months to be introduced at 2 months' notice. And, yes, I DO mean
4 changes in a year.
That especially damn-fool idea was jumped on (not least by the diary
makers, who had already printed their stock), but I use Wilson time as
an example of a DST scheme that cannot be handled by any "completely
flexible" DST description languages that I have ever seen.
This posting is intended only to confuse :-)
Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nmm1@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
From: "Greg Schueman" <schueman@ix.netcom.com> [-/+]
Date: 13 Mar 1997 05:32:05 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Commercial NTP for NT Software [-/+]
X-Keywords: HP-UX [-/+] Windows [-/+]
R. Gregory Gantt, Jr. <mail11836@pop.net> wrote in article
<332769DC.1190@pop.net>...
> Are there commercial NTP client software products for Windows NT 4.0
> Server? I have a need to sycnronize NT server clocks from our HP-UX
> based NTP service. My company has restricted use of public-domain
> software, so I need to know what commercial products are available. Any
> ideas?
>
> Greg
>
You can use the Timeserv product from the ResourceKit which implements
Simple NTP
or there are a couple of others. Look on Microsoft's site under Windows
NT, freeware & shareware
for other options.
-Greg Schueman
From: Jeff Mayo <Jeffrey.S.Mayo@cpmx.saic.com>
Date: Thu, 13 Mar 1997 18:54:09 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: XNTP3 for OS/2 [-/+]
X-Keywords: implementation [-/+] SNTP [-/+]
elwegert@mail.delcoelect.com wrote:
>
> Has anyone ported XNTP3 to OS/2 ?
>
> Is anyone aware of a NTP and/or SNTP implimentation for OS/2 with source code ?
I'm afraid that the best I know of is at the Hobbes site. It's a
client-only implementation, and it's just binaries, no source code:
ftp://hobbes.nmsu.edu/os2/network/tcpip/os2ntp11.zip
--
Jeffrey S. Mayo Jeffrey.S.Mayo@cpmx.saic.com
Transcore (formerly JHK)
Voice: (770) 447-6831 Fax: (770) 449-7268
From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 14 Mar 1997 00:04:05 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: XNTP3 for OS/2 [-/+]
X-Keywords: implementation [-/+] SNTP [-/+]
In article <332893A1.4B20@cpmx.saic.com>,
Jeff Mayo <Jeffrey.S.Mayo@cpmx.saic.com> wrote:
>elwegert@mail.delcoelect.com wrote:
>>
>> Has anyone ported XNTP3 to OS/2 ?
>>
>> Is anyone aware of a NTP and/or SNTP implimentation for OS/2 with source code ?
>
>I'm afraid that the best I know of is at the Hobbes site. It's a
>client-only implementation, and it's just binaries, no source code:
>
>ftp://hobbes.nmsu.edu/os2/network/tcpip/os2ntp11.zip
Well, if you have a reasonable set of Unix-like libraries, please
try porting my code - all the core parts should compile without
trouble (or I will be very embarassed). dist/msntp-1.3.tar.gz
on oozelum.csi.cam.ac.uk.
But it is SNTP only and I don't really encourage the use of the
server code.
Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nmm1@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
From: Casper.Dik@Holland.Sun.COM (Casper H.S. Dik - Network Security Engineer) [-/+]
Date: 13 Mar 1997 17:50:45 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP on Solaris 2.5.1 [-/+]
X-Keywords: prefer [-/+]
bwb@etl.noaa.gov (Bruce Bartram) writes:
>When I went and looked into /usr/share/lib/zoneinfo in more detail,
>I read the etcetera file. The basic filenames GMT-4 are in the
>POSIX offset format. For users who prefer the "old style, non-POSIX"
>format, use Etc/GMT-4. I checked that every Etc/ file was the exact match
>for the base file after exchanging + and -.
Well, the "GMT-4" files in the base directories are the wrong ones.
They're not used by Solaris as it first does the POSIX thing.
POSIX style date (internally implemented in libc)
% env TZ=GMT-4 date
Thu Mar 13 21:50:57 GMT 1997
zoneinfo code for POSIX:
% env TZ=Etc/GMT-4 date
Thu Mar 13 21:51:01 Etc/GMT 1997
old broken "GMT-4" zoneinfo file (see how date display this as GMT+4!)
% env TZ=:GMT-4 date
Thu Mar 13 13:51:14 GMT+4 1997
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
From: "Frank Ciotti" <frankc@msn.com>
Date: 15 Mar 1997 05:38:40 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: NTP over asymmetrical links [-/+]
Does anyone know if the problem of synchronizing clocks over
an asymmetrical link has been solved. I looked at the NTP spec
and it appears to compute the offset by averaging the round trip
time. For my application (clients on wireless links), the link speed
at times may be much greater in one direction, than the other.
thanks for any help,
Frank Ciotti
Telxon Corp.
frankc@telxon.com
From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 15 Mar 1997 10:13:59 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP over asymmetrical links [-/+]
X-Keywords: precision [-/+]
In article <01bc3103$b3be7e40$814093cf@frankc-home>,
Frank Ciotti <frankc@msn.com> wrote:
>Does anyone know if the problem of synchronizing clocks over
>an asymmetrical link has been solved. I looked at the NTP spec
>and it appears to compute the offset by averaging the round trip
>time. For my application (clients on wireless links), the link speed
>at times may be much greater in one direction, than the other.
If it is known, it can be allowed for. But does it matter? There are
a lot of people who weeble on about milliseconds, when many systems
need synchronisation only to within a second. If your application is
one of those, then you can probably ignore the delays completely. If
you need a precision that is small compared with the delays, then you
are going to have to be very careful anyway.
Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nmm1@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 16 Mar 1997 10:28:26 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: program versions [-/+]
X-Keywords: bug [-/+] Mills [-/+] RFC [-/+]
In article <01bc2b86$f86df8e0$b0da23c7@sverige>,
Greg Schueman <schueman@ix.netcom.com> wrote:
>Ulrich Windl <wiu09524@rrzc4> wrote in article
><WIU09524.97Mar7122049@rrzc4>...
>> Currently there is no possibility to find out the version of a NTP
>> daemon other than looking at the startup message. xntpdc has a version
>> command, but it only shows its own version. Wouldn't it be wise to
>> have such a thing? Unfortunately it's rather late to start with that
>> now.
>
>Never too late. I think that your suggestion is a very good one. The
>best you can see now is what version of the NTP protocol is being served.
>That doesn't do much good as NTP version 3 has been out a long time.
No, you can't even do that. The version that you get back from xntp is
the version that you send it! This is deliberate, and documented in the
RFC, but I couldn't follow David Mills' arguments as to why it was the
sensible course of action.
There is or was a bug in xntp where it accepted future versions (e.g. 7)
and returned a response. Apparently it is supposed to just drop the
request on the floor. It is also deliberate that there is no way for a
server to respond to a client "Your request was bogus", but I didn't
follow the rationale for that, either.
Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nmm1@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
From: bad@ora.de (Christoph Badura) [-/+]
Date: Tue, 18 Mar 1997 15:55:39 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Timetravel in NT [-/+]
X-Keywords: DST [-/+] implementation [-/+] peer [-/+]
[posted & mailed]
In <5gjjpm$cc@casey.nrd.ups.com> nrd1rls@nrd.ups.com (Richard Siddall Contractor) writes:
> So is the EU change model algorithmic? And if so, could someone
> post a reference I could use to implement automatic DST changing
> from?
I don't know if the EU model is algorithmic. However, you can get a
free table driven implementation that works for most parts of the world
from ftp://elsie.nci.nih.gov/pub/.
Now available in print: Lion's Commentary on UNIX 6th Edition, with Source Code
http://www.peer-to-peer.com/
From: Casper.Dik@Holland.Sun.COM (Casper H.S. Dik - Network Security Engineer) [-/+]
Date: 13 Mar 1997 17:44:31 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP on Solaris 2.5.1 [-/+]
X-Keywords: timezone [-/+]
bwb@etl.noaa.gov (Bruce Bartram) writes:
> missing or broken files if your machine has the same stock timezone
>stuff that mine has. My zoneinfo file GMT-4 seems to be GMT+4.
>In my opinion, the correct solution is to, as root
The timezone files as originally created had teh sign for GMT reversed.
Soalris 2.x uses POSIX rules by default and falls back to zoneinfo
when there's no POSIX match.
So "SunOS 4.x GMT+4" is teh same as "Solaris 2.x GMT-4".
Solaris 2.x shows the correct behaviour. In zoneinfo/Etc you'll
find the correct GMT rules. (See "etcetera" and "backward" for
a readable description of what happened)
>xntpd only uses timezone stuff to print logfile messages or other
>user text output. It runs completely in UTC seconds since 1900
>in the NTP format.
Acccept when you set you system to the wrong local timezone and than
set the clock; ntp will think you're a couple of hours off.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
From: eggert@twinsun.com (Paul Eggert) [-/+]
Date: 18 Mar 1997 00:57:48 -0800 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP on Solaris 2.5.1 [-/+]
bwb@etl.noaa.gov (Bruce Bartram) writes:
> Do you know if Solaris 2.5 version of localtime() is extremely similar
>to the ftp://elsie.nci.nih.gov version ?
No, they're different pieces of code entirely.
Solaris 2.5 localtime has more features (and more bugs).
Also, the Solaris version is considerably slower.
> After becoming more confused by a few more tests, I fall back to
>believing that "zic /usr/share/lib/zoneinfo/southamerica" to make the
>exact local name America/Caracas is the best technique.
Yes, that's the way it's supposed to work.
From: wiu09524@rrzc5 (Ulrich Windl) [-/+]
Date: 17 Mar 1997 12:30:39 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: is SNTP too simple? [-/+]
X-Keywords: RFC [-/+] SNTP [-/+]
As I'm running a SNTP client on my Win95 box too, I browsed the SNTP RFC.
Surprisingly it states that clients ignore the fractional second part.
Despite of that several SNTP clients seem not to ignore the fractional
second part, because the report time corrections below 1 second.
Now I wonder wha ignoring fractional seconds was specified in the RFC;
clients unable to hande it will ignore it anyway.
Comments?
--
Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
From: WhiskerP@logica.com (Peter Whisker) [-/+]
Date: Tue, 18 Mar 97 16:44:40 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: is SNTP too simple? [-/+]
X-Keywords: RFC [-/+] SNTP [-/+]
In article <WIU09524.97Mar17133039@rrzc5>, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> wrote:
>As I'm running a SNTP client on my Win95 box too, I browsed the SNTP RFC.
>Surprisingly it states that clients ignore the fractional second part.
>
>Despite of that several SNTP clients seem not to ignore the fractional
>second part, because the report time corrections below 1 second.
>
>Now I wonder wha ignoring fractional seconds was specified in the RFC;
>clients unable to hande it will ignore it anyway.
>
>Comments?
>
The best (by far) SNTP client for Windows95 that I've seen is Dimension4 from
www.thinkman.com. This will sit on the taskbar and if you turn off errors it
will never annoy you. It is freeware and has no annoying startup screens.
It reports time corrections to within 10ms.
Peter
************************************************************
* Peter Whisker * Logica UK Ltd, Cobham, Surrey, UK
*Any opinions are mine!* http://www.logica.com/ for theirs !
* whiskerp@logica.com * http://public.logica.com/~whiskerp/
For PGP key:Send e-mail to pgp_peter@reepicheep.logica.co.uk
Fingerprint:FD 97 98 9A F4 1E 9C 89 8B 8D FF 73 65 A0 E1 99
From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Tue, 18 Mar 1997 18:11:48 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: [++] Re: Timetravel in NT [-/+]
X-Keywords: DST [-/+]
Richard Siddall Contractor wrote:
> So is the EU change model algorithmic? And if so, could someone
> post a reference I could use to implement automatic DST changing
> from?
The current EU change model is:
Start Daylight Savings Time at 02:00:00 local time, on the last sunday
in March.
End DST at 03:00:00 local time, on the last sunday of October.
Here's my TZ entry:
TZ=MET-1MEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00
Terje
--
- <Terje.Mathisen@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
From: nigel@theplanet.net (Nigel.Metheringham)
Date: 21 Mar 1997 10:41:48 +0000 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Which time protocol NTP or DTS [-/+]
X-Keywords: authentication [-/+] configuration [-/+] DTS [-/+] password [-/+]
rocky@panix.com (R. Bernstein) writes:
>
> Harold Lockhart <hal@platsol.com> writes:
> > The
> > major advantage of DTS is that time is authenticated. This is not a
> > theoretical problem, a couple of years ago some attackers defeated a
> > Securid system by spoofing NTP and doing a replay.
>
> Forgive my ignorance if I don't understand what the terms mean above.
>
> What is a "Secureid system?"
Secureid (see http://www.securid.com/ ) is an authentication system
based on a token which displays a random multidigit passcode. To
login you give your username, password (normally, but that depends on
the configuration), a few digit PIN and the current code from your
token.
The system relies on the authentication server being able to calculate
the correct value that should be on the token, which depends on the
current time. If you can warp the time then you can warp the expected
token code.
A replay attack means that the attacker snooped off the authentication
sequence used by an authorised person, and then replayed that to the
server to get on themselves. This normally cannot be done with
securid, but if time went backwards in between the original
authentication and the attack, then it appears that this can be used
to break the security. At this stage, yes the missiles could be
launching!
> By "defeated" do you mean they managed to
> give some computers the wrong time? How wrong a time? A couple
> minutes? An hour? A year? There was no more damage done than that,
> right? (I'm trying to imagine a scenario by which setting the time
> back an hour causes a nuclear missle to go off, or maybe a check which
> was overdrawn to clear instead.)
Security systems are often crititcally dependant on a consistant (if
not actually accurate) time. If your time is wavering then most of
your logs become fairly useless - I cannot track an attack through a
network unless the timestamps in the logs from different sources
actually mean something.
Nigel.
--
[ Nigel.Metheringham@theplanet.net - Systems Software Engineer ]
[ Tel : +44 113 251 6012 Fax : +44 113 224 0003 ]
[ Friends don't let friends use sendmail! ]
From: chhaces@mmm.com (Carl Haces)
Date: Wed, 19 Mar 1997 08:59:16 -0600 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Commercial NTP for NT Software [-/+]
Is a potentially bad product any better than no product?
Intergraph Software Solutions bundle an NTP package with their PC-NFS
and Disk Access product. It has an ok gui interface, runs as a service
and can generate pretty detailed log files. Based on these log files it
is only version 1.x of NTP. These log files also made me question its
sanity, it looks like it was constantly trying to make large adjustments
to my clock and even after reportedly making a series of small
compensating adjustments the offset it reported was worse! In anycase I
did not pursue it since I really got the product for its NFS function. I
am now using the free binary xntp with the install shield installation.
Carl
Opinions expressed herein are my own and may not represent those of my employer.
From: "Ben Thye" <BThye@sds.net>
Date: Tue, 18 Mar 1997 16:02:18 -0800 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Cadence NTP on NetWare 3.12
X-Keywords: configuration [-/+] Novell [-/+] SNTP [-/+] stability [-/+]
> I'm looking for some information on the Cadence SNTP client for Novell
> NetWare 3.12. I'm running the 30-day evaluation copy on two servers right
> now and they seem to be doing fine.
We have run the Cadence product for about 3 years, and were part of the
beta testing on the SNTP client. I am pretty impressed with the product
overall.
> So, I'm looking for some real-world experiences:
> 1. What about the stability of the product, any abends anyone?
Never! We had 1 ABEND due to a TCP/IP problem, but that was a
configuration issue, not Cadence.
> 2. What about the possible interference with other NLMs on the server?
Have not seen any interference with other NLMs. Also seems friendly on
system resources.
> 3. About 1000 servers are configured as a Sybase database server, does
> anyone have the same configuration (Sybase/Cadence)?
No, we don't run Sybase.
> 4. The installation must be done unattended, so the installer must get
> it's local parameters (i.e., which NTP server to contact) from data files
> already on the server. Any ideas?
Yes, the files can be copied into the correct directories, and the entire
process can be done via a batch file.
> 5. What are the memory requirements?
Hmmm... I would have to look this up, but I think it runs in about 400K or
so.
> Any help would be greatly appreciated,
> thanks
Happy to help.
--
Ben Thye
Suncoast Data Services
Tampa, Florida
E-Mail: BThye@SDS.net
From: WhiskerP@logica.com (Peter Whisker) [-/+]
Date: Wed, 19 Mar 97 09:53:57 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: [++] Re: Timetravel in NT [-/+]
X-Keywords: DST [-/+] timezone [-/+]
In article <332ECCD4.5767@hda.hydro.com>, Terje Mathisen <Terje.Mathisen@hda.hydro.com> wrote:
>Richard Siddall Contractor wrote:
>> So is the EU change model algorithmic? And if so, could someone
>> post a reference I could use to implement automatic DST changing
>> from?
>
>The current EU change model is:
>
>Start Daylight Savings Time at 02:00:00 local time, on the last sunday
>in March.
>
>End DST at 03:00:00 local time, on the last sunday of October.
>
>Here's my TZ entry:
>
>TZ=MET-1MEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00
>
>Terje
>
Are you sure that the time change is not at 0100 UTC across the EU?
This equates to 01:00/02:00 local time in the UK, Ireland and Portugal,
02:00/03:00 in France, Germany etc. and 03:00/04:00 in Greece.
The comprehensive timezone file for europe as published by
ftp://elsie.nci.nih.gov lists the EU change time as 1:00 UTC since 1995.
(see below)
# EU rules are for the European Union, previously known as the EC, EEC,
# Common Market, etc.
# Rule NAME FROM TO TYPE IN ON AT SAVE
LETTER/S
Rule EU 1977 1980 - Apr Sun>=1 1:00u 1:00 S
Rule EU 1977 only - Sep lastSun 1:00u 0 -
Rule EU 1978 only - Oct 1 1:00u 0 -
Rule EU 1979 1995 - Sep lastSun 1:00u 0 -
Rule EU 1981 max - Mar lastSun 1:00u 1:00 S
Rule EU 1996 max - Oct lastSun 1:00u 0 -
# W-Eur differs from EU only in that W-Eur uses standard time.
Rule W-Eur 1977 1980 - Apr Sun>=1 1:00s 1:00 S
Rule W-Eur 1977 only - Sep lastSun 1:00s 0 -
Rule W-Eur 1978 only - Oct 1 1:00s 0 -
Rule W-Eur 1979 1995 - Sep lastSun 1:00s 0 -
Rule W-Eur 1981 max - Mar lastSun 1:00s 1:00 S
Rule W-Eur 1996 max - Oct lastSun 1:00s 0 -
Peter
************************************************************
* Peter Whisker * Logica UK Ltd, Cobham, Surrey, UK
*Any opinions are mine!* http://www.logica.com/ for theirs !
* whiskerp@logica.com * http://public.logica.com/~whiskerp/
For PGP key:Send e-mail to pgp_peter@reepicheep.logica.co.uk
Fingerprint:FD 97 98 9A F4 1E 9C 89 8B 8D FF 73 65 A0 E1 99
From: mbrett@rgs0.london.waii.com (Marc Brett) [-/+]
Date: 19 Mar 1997 11:24:08 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: [++] Re: Timetravel in NT [-/+]
X-Keywords: DST [-/+]
Terje Mathisen (Terje.Mathisen@hda.hydro.com) wrote:
> Richard Siddall Contractor wrote:
> > So is the EU change model algorithmic? And if so, could someone
> > post a reference I could use to implement automatic DST changing
> > from?
> The current EU change model is:
> Start Daylight Savings Time at 02:00:00 local time, on the last sunday
> in March.
> End DST at 03:00:00 local time, on the last sunday of October.
> Here's my TZ entry:
> TZ=MET-1MEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00
> Terje
> --
> - <Terje.Mathisen@hda.hydro.com>
> Using self-discipline, see http://www.eiffel.com/discipline
> "almost all programming can be viewed as an exercise in caching"
And the UK keeps in sync with the same rule, although the local times are
altered so that it switches at the same instant.
TZ=GMT0BST-1,M3.5.0/01:00:00,M10.5.0/02:00:00
--
Marc Brett Western Atlas
Marc.Brett@waii.com +44 181 977 6279
From: kees@echelon.nl (Kees Hendrikse) [-/+]
Date: Fri, 21 Mar 1997 09:32:55 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Time Servers [-/+]
In <3331D0E7.272C@acm.org> David Ross <rossde@acm.org> writes:
(..)
> When I trace the Internet jumps to the server, I see 13-17 jumps with 15
> the most common count. The trace indicates that I am communicating with
> UCLA from southern California through Chicago. This tells me that
> geographic closeness definitely does not provide Internet closeness.
Geographical closeness isn't very related to network closeness; For
example, from where I sit now I can see the buildings of Twente University
(Enschede, Netherlands), the geographical distance is a about 200 meters.
Traceroute shows that I'm closer to some routers in London than to these
buildings across the street...
What you need to do is select about 10 timeservers that are likely to
be close and use traceroutes and ping to find out how close they really
are. Running pings to each server for a day or so with 10 minutes between
packets gives nice min/mean/max values.
By the way: check out if your provider is running time services. Some do,
but don't advertise the fact. Ask the sysadmins.
--
Kees Hendrikse | email: kees@echelon.nl
|
ECHELON consultancy and software development | phone: +31 (0)53 48 36 585
PO Box 545, 7500AM Enschede, The Netherlands | fax: +31 (0)53 43 37 415
From: Michael Livingston <mlivings@mail.bcpl.lib.md.us>
Date: Thu, 20 Mar 1997 15:23:21 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp,comp.unix.osf.osf1
Subject: Controlling local clock synchronization drift
X-Keywords: fudge [-/+]
How do I control the drift of an NTP server using the local clock
synchronization driver.
I'm running the xntpd that came with our Digital UNIX 3.2C system. I
don't know what version of NTP Digital is using. At the moment the only
line in /etc/ntp.conf is:
server 127.127.1.0
All of our NTP clients (10 at this point, but soon to be many more) are
ultimately based on this one server, and we're loosing about 4 seconds per
day.
>From Digital's man page it appears that the "fudge 127.127.1.0 time1"
command will allow me to adjust the local clock's drift. However the man
page is not clear about the units of the time1 value. Digital's Tech.
Support is telling me something entirely different from the man page.
From: eggert@twinsun.com (Paul Eggert) [-/+]
Date: 21 Mar 1997 19:57:50 -0800 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Time Zone name in Denmark
X-Keywords: DST [-/+] timezone [-/+]
dscf@danisco.dk (Carsten Foss) writes:
> Can anyone tell me the correct timezone names for Denmark ???
``Central European Time'' (CET) is the most commonly used English name.
For daylight-saving time, it's ``Central European Summer Time'' (CEST).
The widely used tz package formerly used the abbrevations MET and MET DST,
but these abbreviations were rarely found in the real world,
and the tz package now uses `CET' and `CEST' for central Europe
(see <ftp://elsie.nci.nih.gov/pub/>). The Danish Standards Association
recommends `CET' for POSIX compliance
(reference: POSIX 1003.1-1996 [ISO/IEC 9945-1: 1996], page 614, line 105).
Poul-Henning Kamp writes that ``Mellemeuropaeisk tid'' (MET)
is the most commonly used Danish name for standard time.
I don't know the daylight-saving time name.
> I've seen some German's use MEST for Middle European Summer Time,
> is that a valid name ??
The most commonly used German names are ``Mitteleuropaeische Zeit'' (MEZ)
and ``Mitteleuropaeische Sommerzeit'' (MESZ).
From: schimpf@gradient.com (Brian Schimpf) [-/+]
Date: 21 Mar 1997 15:54:45 GMT [-/+]
Newsgroups: comp.protocols.time.ntp,comp.soft-sys.dce,ibm.austin.dce
Subject: Re: Which time protocol NTP or DTS [-/+]
X-Keywords: DTS [-/+]
In article <wih209apbjy.fsf@panix.com>, rocky@panix.com (R. Bernstein) says:
>
>Harold Lockhart <hal@platsol.com> writes:
>> The
>> major advantage of DTS is that time is authenticated. This is not a
>> theoretical problem, a couple of years ago some attackers defeated a
>> Securid system by spoofing NTP and doing a replay.
>
>Forgive my ignorance if I don't understand what the terms mean above.
>
>What is a "Secureid system?" By "defeated" do you mean they managed to
>give some computers the wrong time? How wrong a time? A couple
>minutes? An hour? A year? There was no more damage done than that,
>right? (I'm trying to imagine a scenario by which setting the time
>back an hour causes a nuclear missle to go off, or maybe a check which
>was overdrawn to clear instead.)
>
>What does "doing a replay" mean?
I'm not familiar with the specific incident Hal is referring to but I
can try to address some of your questions. A replay attack in general
refers to an attacker making copies of a legitimate network transmission
and then resending it at a later time, possibly after making some modifications
or sending it to a different destination. Systems attempt to protect against
replay attacks by placing things like sequence numbers or timestamps in
the protocol exchange. Sequence numbers require both sides to maintain
common state, so timestamps are a nice alternative. But timestamps have
the disadvantage of requiring the two systems to have clocks that tell the
same time within some reasonable bounds.
I believe the point Hal is making is that if I want to conduct a
replay attack against a specific system I might be able to do so if I can
change that system's clock so that it indicates a time consistent with
the timestamp in the message I'm going to (re)send. Might this cause
a nuclear missle to go off? Gee, I hope not. But it might allow me to
conduct a financial transaction I would not otherwise be allowed to
perform, or authenticate myself to a system and get a set of credentials,
etc.
"SecurID" is a commercial name of a token card system provided
by Security Dynamics Inc. I'll leave any discussion of IP spoofing to folks
who understand that better than I do.
Thanks,
Brian
Brian Schimpf
Gradient Technologies Inc.
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 24 Mar 1997 09:31:04 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP on linux?
X-Keywords: Linux [-/+] update [-/+]
In article <E7IrK3.M9M@world.std.com> moshier@world.std.com (Stephen L Moshier) writes:
> Does xntpd work on linux? More specifically, does the kernel support
> work with xntp3-5.89? Using a linux kernel version 2.0.29, libc version
> 5.4.17, Intel 486 or 586 hardware, I get the following strange
> behavior.
xntpd does work with Linux 2.0, and some distributions deliver a
working version (Like S.u.S.E. 4.4.1 in Germany (see
www.suse.com)). The binary tgz is freely downloadable (once you know
where it is ;-))
>
> 1. No matter what value /etc/ntp.drift contains, xntpd starts up with
> -77.857 pll frequency according to the kerninfo command of xntpdc.
OK, this is a hardware problem: "+-77.whatever" is a "magic indicator"
that the maximum skew has been reached. Either increase tickadj to
widen the range, or correct tick. For x86 adding one to tick is
equivalent to compensating 100ppm. Thus if you are "between 50 and
100" it's better to adjust tick by one.
The thing depends on the motherboard: My last had about 120ppm skew, my new
one has about 17, and we have a HP 9000/H60 here that has below 1!
>
> 2. pll frequency changes over time, typically to between -150 and
> -170 (don't know whether it converges). No matter what this value,
Oops! You need to correct your tick ny even 2!
> the hourly update always writes -77.857 into /etc/ntp.drift.
>
> 3. Calling __adjtimex manually with a value for timex.freq and a control bit
> timex.modes = MOD_FREQUENCY does get that value through as shown by pll
> frequency.
Maybe Harlan could add some code to xntpd to give a warning once the
skew limit for the specified tickadj has been reached!?
(With tickadj == 5us you can ony add 500us per second on Linux. If
your clock drifts more, you'll have to change something)
From: Vin McLellan <vin@shore.net> [-/+]
Date: Mon, 24 Mar 1997 15:12:43 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Which time protocol NTP or DTS [-/+]
X-Keywords: authentication [-/+] configuration [-/+] DTS [-/+] FAQ [-/+] password [-/+]
>>> The
>>> major advantage of DTS is that time is authenticated. This is not a
>>> theoretical problem, a couple of years ago some attackers defeated a
>>> Securid system by spoofing NTP and doing a replay.
I've been involved with the vendor of this ACE/SecurID technology since
before there was a product, and, to the best of my knowledge, the
"attack" described above never happened and could not happen. Bellovin
and Cheswick, in their great book on firewalls, suggested it might be
possible several years back... and since then, rumors have dolled up the
theory in several guises.
The basic defense against replay in ACE/SecurID systems is a secured
file in the ACE authentication server which records each pseudo-random
token-code at it is used. An ACE/Server never authenticates a SecurID
token-code which has previously been submitted by that token/user... no
matter what any clock says!
Attributions in this thread are a little confusing -- but as I
understand it, someone posted the note above and then Harold Lockhart
<hal@platsol.com> asked for some explanations:
>>Forgive my ignorance if I don't understand what the terms mean above.
>>
>>What is a "Secureid system?" By "defeated" do you mean they managed to
>>give some computers the wrong time? How wrong a time? A couple
>>minutes? An hour? A year? There was no more damage done than that,
>>right? (I'm trying to imagine a scenario by which setting the time
>>back an hour causes a nuclear missle to go off, or maybe a check which
>>was overdrawn to clear instead.)
>>
>>What does "doing a replay" mean?
Among several helpful folks who responded, Nigel Metheringham
<nigel@theplanet.net> wrote:
> Secureid (see http://www.securid.com) is an authentication system
>based on a token which displays a random multidigit passcode. To
>login you give your username, password (normally, but that depends on
>the configuration), a few digit PIN and the current code from your
>token.
As in Nigel's URL, the correct name is SecurID. A SecurID token is
time-synched to an ACE autentication server, but it is _always_ used in
a two-factor authentication mode: with the user being authenticated
required for provide _both_ the 6-8 digit pseudo-random tokencode (off
the LCD built into the face of the credit-card sized SecurID,) and a
user-memorized PIN of 4-8 digits or alphanumeric characters. Some
unusual configurations might require an initial password as well, but
only the token-code and PIN get passed to the ACE/SecurID authentication
server.
The SecurID token-code is a keyed hash. In the token (and at the
Server) it is created by putting "Current Time," and a
user/token-specific "secret key," through a irreversible hash or one-way
function. At the ACE/Server, the two are matched for one factor of the
authentication. Separately, the PINs are matched for a second factor of
authentication. There are also a variety of modes in which the PIN is
further protected, from SSL pipes to PinPad SecurID tokens (which
require the user to key the PIN directly into the token where it is
added to the pseudo-random token-code for transmission.)
[SecurIDs are widely-used world-wide. Originally, the relative ease of
using a SecurID, as compared to the two-factor alternatives -- S/key and
a variety of challenge-response token/calculators -- allowed Security
Dynamics (SDTI) to dominate the international Fortune 1000 market with
ACE/SecurID systems. A SecurID user can type in his PIN and the SecurID
token-code -- just like a long traditonal password. C/R tokens require
more mess and fuss. But SDTI has also traditionally led the industry
into new technology, and with its 1996 purchase of RSA Data Security,
SDTI has announced plans to integrate user authentication and PKC key
and cert management services.]
As Nigel explained:
>The system relies on the authentication server being able to calculate
>the correct value that should be on the token, which depends on the
>current time. If you can warp the time then you can warp the expected
>token code.
The core of an ACE system is a patented mechanism to keep track of the
relative "drift" or imprecision of a token's clock chip -- relative to
the "Current Time" of the clock used by the ACE authentication server.
The relative drift of each token is recorded in the ACE user database
(along with the user's PIN and the token-specific secret key,) and the
delta is used to adjust the "Current Time" used in calculating (hashing)
the token-code to be matched against whatever token-code is submitted by
a particular user seeking to be authenticated.
Note that the time-synch between the server and any particular token is
a closed system; they need not be accurate GMT, only aware of each
other. Where the server's host is required to be accurate for other
services, an absolute (atomic) or authenticated time-signal is
recommended.
>A replay attack means that the attacker snooped off the authentication
>sequence used by an authorised person, and then replayed that to the
>server to get on themselves. This normally cannot be done with
>securid, but if time went backwards in between the original
>authentication and the attack, then it appears that this can be used
>to break the security....
As Nigel noted, this normally cannot be done with SecurID. If time was
"rolled backwards" -- however that might be done -- a "replay" of a
SecurID token-code would be rejected by the ACE/Server because it would
produce a PRN which had previously been submitted by that user and which
would be in the secured file of "used" token-codes.
If anyone has any further questions about ACE/SecurID, feel free to
ask. I might also refer you to my SecurID FAQ at <www.securid.com>.
Surete,
_Vin
From: Harold Lockhart <hal@platsol.com> [-/+]
Date: Tue, 25 Mar 1997 17:38:28 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp,comp.soft-sys.dce,ibm.austin.dce
Subject: Re: Which time protocol NTP or DTS [-/+]
X-Keywords: authentication [-/+] configuration [-/+] DTS [-/+] firewall [-/+] peer [-/+] RFC [-/+] UDP [-/+]
R. Bernstein wrote:
>
> Harold Lockhart <hal@platsol.com> writes:
> > The
> > major advantage of DTS is that time is authenticated. This is not a
> > theoretical problem, a couple of years ago some attackers defeated a
> > Securid system by spoofing NTP and doing a replay.
>
> Forgive my ignorance if I don't understand what the terms mean above.
>
> What is a "Secureid system?"
As someone else pointed out, the correct spelling is "SecurID", which is
a product of Security Dynamics.
>By "defeated" do you mean they managed to
> give some computers the wrong time? How wrong a time? A couple
> minutes? An hour? A year? There was no more damage done than that,
> right? (I'm trying to imagine a scenario by which setting the time
> back an hour causes a nuclear missle to go off, or maybe a check which
> was overdrawn to clear instead.)
>
> What does "doing a replay" mean?
>
The incident I referred to was mentioned to me in casual conversation by
a knowledgable person. Since this has aroused so much interest, I am
trying to verify the incident and get more details.
Securid, is a distributed authentication system. Like many other
distributed authentication systems, including Kerberos and any Public
Key system that use CRLs, it depends on the various computers in the
network having roughly the same idea of what the current date and time
is. SecurID uses the current time as a part of the cryptographic hash it
computes both in the token card and at the authentication server.
My understanding of the attack on SecurID (which may not be correct) was
that some attackers had captured some authentication messages and later
altered the time on some systems, including the SecurID (ACE) server and
resent the messages, allowing them to authenticate under someone else's
id. I was told that the method of altering the time was to impersonate
(or spoof) the identity of an NTP server.
Vin McLellan (who apparently is an employee of Security Dynamics) has
written that this attack should not work, because the ACE server keeps a
copy of every previous used authentication string. I am in no position
to dispute this, but it seems to me that after a couple of years you
would have a pretty big database to search.
> If I read things right (and I might not) there is no IP address
> encoded in UDP packet specified in Appendix A of the NTP Version 3
> Specification RFC 1305. So the "spoofing" was at the IP level,
> correct?
>
> I know everyone talks about how easy it is to spoof IP addresses,
> say on the Internet. I wonder though how many people have tried to do
> so.
I was using the term spoofing in the general sense of impersonation.
Since (standard) NTP does not use strong authentication it is possible
for an attacker to emit messages that appear to come from an authentic
NTP server. Depending on the network configuration involved, this could
be easy or hard.
> In the LAN/WAN where I work, IP spoofing of NTP peers or servers can't
> happen for a long period.
It is only necesary for the time to be wrong for a fraction of a second.
> We do not use multicasting or broadcasting
> NTP, so they'd have to "spoof" the IP of a timeserver/peer probably in
> use. Either our routers wouldn't allow it because there'd be an IP for
> the MAC addresses in their cache, or the routers would scream loudly,
> packets would be lost and there probably would be network problems
> which the network people would soon investigate.
>
> In sensitive areas, such as on our firewalls, we use static
> routing. So it is real real hard to "spoof" an IP address inside our
> company from the outside---I certainly haven't been able to do it and
> I've tried. Both hardware and software disallow this; the hardware
> includes not just a firewall computer but a couple of screening
> routers as well.
>
> Is there someplace where this breach or such attacks is better
> documented?
If I am able to obtain additional information about this breach, I will
post it.
However, use of insecure time presents real risks in any serious
security environment. Besides interferring with an authentication
protocol, altering the time could invalidate the audit trail or
circumvent date/time authorization checks.
Hal
=================================================================
Harold W. Lockhart Jr. Platinum Solutions Inc.
Chief Technical Architect 8 New England Executive Park
Email: hal@platsol.com Burlington, MA 01803 USA
Voice: (617)273-6406 Fax: (617)229-2969
=================================================================