[ntp:hackers] Autokey identity keys

timelord at horizon.com timelord at horizon.com
Mon Nov 5 00:48:32 UTC 2007


>  Say, for arguments sake, changes are made to ntpd that allow
>  one to specify the external nat address for autokey in place
>  of the 192.168.x.y at the endpoint.
> 
>  1) What happens if somebody *else* behind your NAT box
>     tries to do the same thing to the same (external) server? boom...

Autokey servers keep no per-client state (ref: Autokey spec, section
7, page 20), so there's no problem with multiple clients sharing one
IP address; the server doesn't care.

For servers, only one inside machine can be an NTP server: the one
the NAT box is configured to pass port 123 through to.  Thus,
the entire issue doesn't arise.

>  2) Changes such as the above would seem to make masquerade all
>     too easy for evildoers, or the terminally confused.
>
>  3) Wanna explain this one to the auditors? In certain environments,
>     this could be a killer for trying to maintain traceability.

No, it doesn't.  IP addresses aren't secure anyway; that's what autokey
adds.  Besides, leaving the implemenetation code out of the standard NTP
distribution doesn't exactly make it difficult for someone to add it.
Adding a config entry for the feature is a bit of work, but a bit of
hard-coding around the getsockname() call is trivial.

If you can do harm that way, autokey is severely broken.

Think of it as the NTP server is running *on the NAT box*.  The fact
that it passes the packets to another box for back-end processing is
an internal implementation detail.  The NAT box receives and transmits
properly formed NTP packets.  That's all the protocol requires.

The feature request is to allow ntpd to act as a back-end for
such a NAT box.  But clients of the NAT box don't have to know
anything about that.


More information about the hackers mailing list