On Nov 10, 6:05 pm, Danny Mayer <[email protected]> wrote: > On 11/10/2010 6:11 AM, Harry wrote: > > > > > On Nov 10, 2:59 am, "David L. Mills" <[email protected]> wrote: > >> Harry, > > >> 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: > >>> Hello, > > >>> 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 > > >>> _______________________________________________ > >>> questions mailing list > >>> [email protected] > >>>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 > > 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
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. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
