Will AutoKey setup work on a NAT host behind a firewall?
Harry
I want to employ the AutoKey method of securing NTP.
Basically, I want one host that would act as an NTP client of an
external NTP server, talking AutoKey. This NTP client is to become the
NTP server for other hosts on the intranet. All these hosts are behind
a corporate firewall and are very likely using NAT / IP masquerading
as well. (I can tell NAT / IP masquerading is in use in our
environment because all hosts report the same IP address at
http://www.whatismyipaddress.com.)
I ask this question because I ran into a circa 2004 link (http://
www.ecsirt.net/tools/crypto-ntp.html) that says,
Be Aware!
Before we start building ntpd, one important notice:
NTP with Autokey does not work from a host that is behind a
masquerading or NAT host!
Is this a conceptual / fundamental limitation, or something related to
NTP version? If latter, I'm hoping that it would probably have been
fixed by now.
If AutoKey and NAT don't go together conceptually, what would be my
next best option of securing NTP? Though MD5 method is there but it is
symmetric cryptography and prone to man-in-the-middle attacks... which
is why btw I was hoping to be able to employ AutoKey.
Many thanks,
/HS
David L. Mills
Autokey is not designed to work behind NAT boxes. The Autokey server and
client must have the same (reversed) IP addresses. The intended model is
using two interfaces, one for the Internet side running Autokey, the
other for the inside net on the other side of the NAT box.
Dave
Harry wrote:
>_______________________________________________
>questions mailing list
>ques...@lists.ntp.org
>http://lists.ntp.org/listinfo/questions
>
>
Harry
> >http://lists.ntp.org/listinfo/questions
>
>
Dave, I really appreciate your response to my newbie question.
May I ask (you or other users of this forum)...
1. What, then, would be the next best way (MD5-based symmetric key
mode?) to syncing up a behind-NAT NTP client from an external NTP
server in a tamper-proof manner? I'm not competent/powerful enough to
advise the powers what be in my organization to have an Autokey NTP
client outside our NAT/Firewall; most likely, I'll be told to continue
to operate from behind the NAT/Firewall.
2. What physical/network setup should Autokey-desiring NTP clients
follow? Is it OK, e.g., to have a Autokey client host (AkH) outside
one's NAT network and have all the hosts inside the NAT network use
AkH as a NTP server?
I also skimmed thru your (excellent) book on NTP. I was hoping to find
a mention of NAT in Chapter 9, but didnt. Not complaining, just humbly/
respectfully bringing it up. So, please do elaborate here if you can
on this issue.
Many thanks in advance,
/HS
Danny Mayer
The problem that you are running into is that NAT boxes rewrite
addresses in the packet. Autokey depends on the addresses of both sender
and receiver for the autokey authentication mechanism but because the
addresses get changed the protocol will fail validation. NAT's are evil
and not just for this reason.
Danny
Harry
Then, I wonder why Autokey was designed around IP addresses of
endpoints instead of the digital certificates of endpoints... much
like SSL mutual authentication, which has no problem working with NAT
hosts.
David L. Mills
Symmetric key cryptography works fine behind a NAT box. See the
Authentication Support page in the official NTP documentation on
ntp.org. As I said, the intended Autokey model is for the server and
client to live on the Internet side of the NAT box and have it serve
time to the internal network via a separate interface.
Dave
Harry wrote:
Steve Kostecke
> 1. What, then, would be the next best way (MD5-based symmetric key
> mode?) to syncing up a behind-NAT NTP client from an external NTP
> server in a tamper-proof manner? I'm not competent/powerful enough to
> advise the powers what be in my organization to have an Autokey NTP
> client outside our NAT/Firewall; most likely, I'll be told to continue
> to operate from behind the NAT/Firewall.
Which associations are you attempting to "secure"? LAN client to LAN
server? LAN server to remote time server?
> 2. What physical/network setup should Autokey-desiring NTP clients
> follow? Is it OK, e.g., to have a Autokey client host (AkH)
To keep your terminology consistent with the documentation:
s/Autokey client host/Trust Group Server/
> outside one's NAT network and have all the hosts inside the NAT
> network use AkH as a NTP server?
An NTP Trust Group using AutoKey can not span NAT. So your local NTP
server has to have an interface "inside" the NAT if the Trust Group is
your NTP server and LAN clients.
Your local NTP server must have an interface outside the NAT if the
Trust Group is your NTP server and a remote time server.
Here's Dr. Mills' PowerPoint slides describing the NTP Security Model:
http://www.ece.udel.edu/~mills/database/brief/autokey/autokey.ppt
--
Steve Kostecke <kost...@ntp.org>
NTP Public Services Project - http://support.ntp.org/
Harry
> On 2010-11-10, Harry <simonsha...@gmail.com> wrote:
>
> > 1. What, then, would be the next best way (MD5-based symmetric key
> > mode?) to syncing up a behind-NAT NTP client from an external NTP
> > server in a tamper-proof manner? I'm not competent/powerful enough to
> > advise the powers what be in my organization to have an Autokey NTP
> > client outside our NAT/Firewall; most likely, I'll be told to continue
> > to operate from behind the NAT/Firewall.
>
> Which associations are you attempting to "secure"? LAN client to LAN
> server? LAN server to remote time server?
"LAN server to remote time server."
So, this LAN host will be a client of the remote time server but will
act as a local time server to other hosts on the LAN.
Steve Kostecke
OK.
I have to question the wisdom of using only one remote time server.
As has been stated elsewhere you're better off using a large enough set
of remote time servers (i.e. 4 or more) to allow NTP to detect and
discard "false-tickers" (bad clocks). Multiple time sources also provide
you with redundancy in the event of server failure/connectivity issues.
If this is a case of regulatory compliance then you really ought to have
the budget to solve the problem correctly (with GPS-synced NTP
applicances).
Harry
> NTP Public Services Project -http://support.ntp.org/
Steve, appreciate your response.
My ntp.conf looks like this right now.
server 0.asia.pool.ntp.org
server 1.asia.pool.ntp.org
server 2.asia.pool.ntp.org
I assume, then, that adding a couple more entries should address the
"4 or more" tip of yours and provide me a stable and accurate time...
enough to not necessitate the need for an MD5 authentication. Chuck
Swiger in a parallel incarnation of this question (sorry about that!)
has shared his wonderful insight on the similarity between (non-
maliciously) false and (maliciously) rogue tickers.
David Woolley
> server 2.asia.pool.ntp.org
> I assume, then, that adding a couple more entries should address the
> "4 or more" tip of yours and provide me a stable and accurate time...
> enough to not necessitate the need for an MD5 authentication. Chuck
If you need a high level of trust, you should be using hand picked
servers (as you would have to if you were using authentication).
Harry
wrote:
David, but how would I find out which servers to highly trust and
which ones to not?
Are any graphs or other stats on the past history of a given server
available? These could include the server's uptime, its deviation
(amount of dev, frequency of dev,...) compared to the majority of
others in its pool (or, relative to another arbitrary server (/usr/bin/
diff like capability)) , etc.
The remote ntpd (of the server) already must be constantly building/
updating some such knowledge in its internal memory structures. If
yes, any way to make it dump such knowledge, say, to stdout (or to the
log) of the client?
Steve Kostecke
> On Nov 13, 3:39 pm, David Woolley <da...@ex.djwhome.demon.invalid>
> wrote:
>
>> Harry wrote:
>>
>> > server 2.asia.pool.ntp.org I assume, then, that adding a couple
>> > more entries should address the "4 or more" tip of yours and
>> > provide me a stable and accurate time... enough to not necessitate
>> > the need for an MD5 authentication. Chuck
>>
>> If you need a high level of trust, you should be using hand picked
>> servers (as you would have to if you were using authentication).
>
> ... how would I find out which servers to highly trust and
> which ones to not?
You may want to give weight to servers run by organizations you trust.
You should examine your potential servers (with ntpq -p) and see what
their time sources are.
Choose servers from the Stratum 2 Public Time Server List at
http://support.ntp.org/s2. If you are supporting a large client
population you may choose from the Stratum 1 Public Time Server List;
see http://support.ntp.org/rules for more information.
If your requirements are high consider chosing more than you will
ultimately use and then prune the list after you see which are more
reliable/stable.
> Are any graphs or other stats on the past history of a given server
> available? These could include the server's uptime, its deviation
> (amount of dev, frequency of dev,...) compared to the majority
> of others in its pool (or, relative to another arbitrary server
> (/usr/bin/ diff like capability)) , etc.
There are stats available for Pool Servers. But you're not supposed to
"cherry pick" from the Pool.
> The remote ntpd (of the server) already must be constantly building/
> updating some such knowledge in its internal memory structures. If
> yes, any way to make it dump such knowledge, say, to stdout (or to the
> log) of the client?
ntpd only retains information about the last 8 samples. For more detail
you need to see the server's peerstats and loopstats files.
E-Mail Sent to this address will be added to the BlackLists
> My ntp.conf looks like this right now.
> server 0.asia.pool.ntp.org
> server 1.asia.pool.ntp.org
> server 2.asia.pool.ntp.org
> I assume, then, that adding a couple more entries should address the
> "4 or more" tip of yours and provide me a stable and accurate time...
tos minclock 4 minsane 3 cohort 1
restrict source nomodify
???.airtel.in # UpStream ISP NTP Servers ?
???.bharti.in
pool in.pool.ntp.org iburst # will likely get 2 national servers
# pool 0.in.pool.ntp.org iburst
# pool 1.in.pool.ntp.org iburst
# pool 2.in.pool.ntp.org iburst
# pool 3.in.pool.ntp.org iburst
pool asia.pool.ntp.org # will likely get 3 regional servers
# pool 0.asia.pool.ntp.org
# pool 1.asia.pool.ntp.org
# pool 2.asia.pool.ntp.org
# pool 3.asia.pool.ntp.org
# pool 0.fedora.pool.ntp.org # or whichever OS vendor zone
# pool 1.fedora.pool.ntp.org
# pool 2.fedora.pool.ntp.org
# pool 3.fedora.pool.ntp.org
If it is going to be used by many clients,
why not use GPS or other reference clock?
I would have though the India Time and Frequency Standards Laboratory
and/or India National Physical Laboratory would likely have
stratum one NTP services referenced to their caesium and rubidium atomic clocks;
or from the National Reference clock centers (NRCs),
the Main National Reference clock Centre (MNRC VSNL Mumbai)
and/or the Backup National Reference clock Centre (BNRC Delhi).
It looks like time is also available via through radio clock 10 MHz broadcast,
and through NPLI Teleclock, a service via phone lines (like US NIST ACTS?)
and via STFS over INSAT (Indian National Satellite System),
not to mention via GPS.
--
E-Mail Sent to this address <Blac...@Griffin-Technologies.net>
will be added to the BlackLists.
Harlan Stenn
> pool in.pool.ntp.org iburst # will likely get 2 national servers
> # pool 0.in.pool.ntp.org iburst
> # pool 1.in.pool.ntp.org iburst
> # pool 2.in.pool.ntp.org iburst
> # pool 3.in.pool.ntp.org iburst
One should not need to use the {0,1,2,3}. names when using the 'pool'
directive.
A single "pool FOO.pool.ntp.org iburst" line should be enough.
H
Dave Hart
... assuming you're using 4.2.7. With 4.2.6 or earlier, "pool" spins
up only one association, and uses DNS only at startup. With the new
pool implementation in 4.2.7, each "pool" directive will spin up as
many associations as needed to reach maxclock total associations (pool
prototype associations included). Multiple "pool" directives cause
the associations to spin up faster, and the potential for overshooting
maxclock temporarily is higher. Also, with the new pool code, if a
pool servers stops responding, it will be replaced, re-querying DNS if
needed (if there are no addresses leftover from the last query).
Cheers,
Dave Hart
Harry
will be added to the BlackLists"...
That God is in details is proving once again to be true in this
"simple and trivial looking" service that runs on such a simple "123-
and-snap!" port.
Can't thank you guys enough for all your enlightening information and
insights so far. (Won't be thanking you guys again if you happen to
share something more later, but do know that a big thanks is always
implied.)
Regards,
/HS
Danny Mayer
> On Sun, Nov 14, 2010 at 00:32 UTC, Harlan Stenn <st...@ntp.org> wrote:
>> Somebody wrote:
>>
>>> # pool 0.in.pool.ntp.org iburst
>>> # pool 1.in.pool.ntp.org iburst
>>> # pool 2.in.pool.ntp.org iburst
>>> # pool 3.in.pool.ntp.org iburst
>>
>> One should not need to use the {0,1,2,3}. names when using the 'pool'
>> directive.
>>
>> A single "pool FOO.pool.ntp.org iburst" line should be enough.
>
> ... assuming you're using 4.2.7. With 4.2.6 or earlier, "pool" spins
> up only one association, and uses DNS only at startup.
That didn't used to be true, at least in the original code that was in
4.2.5 which would create up to 10 associations depending on the number
of IP addresses returned by the DNS resolver and how many previous
associations had been set up. Did something change in 4.2.6 to break that?
Danny
Dave Hart
No, thanks, good point. I simply misremembered the old behavior. As
Danny said, the old pool implementation would spin up as many
associations as the DNS query returned addresses, capped at maxclock
(default 10). However, pool.ntp.org changed its behavior in response,
reducing the number of addresses returned per query, on the flawed
theory that pool users don't need more than three servers. So with
4.2.6 and earlier using *.pool.ntp.org, each "pool" directive spins up
3 associations. Using 4.2.7 and later, each "pool" directive solicits
one additional pool server per poll until there are maxclock * 2 total
associations, or there are both (a) at least minclock survivors and
(b) at least maxclock total associations.
E-Mail Sent to this address will be added to the BlackLists
> Danny Mayer wrote:
>> Dave Hart wrote:>>> ... assuming you're using 4.2.7. Â With 4.2.6 or earlier,
>>> "pool" spins up only one association, and uses DNS only
>>> at startup.
Server only does one, pool does as many as IPs are returned
in the DNS query?
>> That didn't used to be true, at least in the original
>> code that was in 4.2.5 which would create up to 10
>> associations depending on the number of IP addresses
>> returned by the DNS resolver and how many previous
>> associations had been set up. Did something change
>> in 4.2.6 to break that?
>
> No, thanks, good point. I simply misremembered the
> old behavior. As Danny said, the old pool implementation
> would spin up as many associations as the DNS query
> returned addresses, capped at maxclock (default 10).
> However, pool.ntp.org changed its behavior in response,
> reducing the number of addresses returned per query,
> on the flawed theory that pool users don't need more
> than three servers. So with 4.2.6 and earlier using
> *.pool.ntp.org, each "pool" directive spins up 3
> associations.
Earlier versions, yes, however many IPs are returned
by the pool query (usually 3).
However pool in.pool.ntp.org only returns 2 IPs per query,
unlike (most ?) other zones.
I don't know why, I would guess due to less total
servers available in that zone?
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>