[ntp:questions] Re: server's address in ntp payload?

Danny Mayer mayer at gis.net
Tue Nov 22 14:44:37 UTC 2005


Brian Utterback wrote:
> You need to keep "what is" and "what could be" straight. When you say
> that something works some particular way, that doesn't mean that is the
> best way of doing it.
> 

I do. There are lots of things that I would like, but I don't get.
Frequently I find I can't do things the way I want because of the freeky
way some O/S has implemented something. I then end up having to kludge
up something just for that O/S. Windows isn't the only one with issues
like this.

> Danny Mayer wrote:
> 
>>Brian Utterback wrote:
>>
>>
>>>I agree that the IP address should not be in the NTP header. I do not
>>>know what should be there, just that something should be that acts as
>>>an authentication token of some sort. Almost all other UDP based
>>>protocols include either a token that identifies the system or the
>>>transaction.
>>>
>>>
>>
>>That's the MAC in the NTP packet.
>>
>>
> 
> Except that the MAC is not a required field. Nor does it generally
> include a transaction ID.
> 

In which case you can't authenticate and you don't need anything special.

>>
>>
>>>The ability to send the UDP packet back with the required
>>>IP address on a multihomed host is not even guaranteed, since such
>>>an ability is only in the SHOULD category and is not in the MUST
>>>category in RFC 1123.
>>>
>>>
>>>
>>
>>That has nothing to do with it. If you get a packet arriving from a
>>different address you should assume it's a different server and will be
>>considered unauthenticated until the authentication is established.
>>
>>
> 
> That's a "is", not a "could be". Why should you assume that it is from a
> different host and not the same host on a different interface? You are
> assuming the that which is to be proved, namely that the IP address is a
> good authentication token.
> 

We follow the rule: "Be liberal about what you receive, be strict about
what you return." The same goes for "how." The IP address is not an
authentication token at all. If you want a really in depth discussion of
the difference between identifiers and IP address, look at the
discussion currently raging in int-area at ietf.org. You may find it
illuminating.


>>
>>
>>>>>been the case that it is easy to get the address from whence a UDP
>>>>>was sent, but there is no portable way to determine to where it was
>>>>>bound.
>>>>>
>>>>>
>>>>
>>>>You can use sendmsg/recvmsg to do this but it's not implemented on all
>>>>platforms and I declined to work all the issues necessary to use it.
>>>>
>>>>
>>>Precisely. There is no portable way to get the IP destination. Why do
>>>you think that is? It's because no reasonable application that is not
>>>dealing in network control itself should need need to know it.
>>>
>>>
>>>
>>
>>It's done in BIND 9, but it would be a challenge in NTP and much more
>>difficult than rewriting the interface code.
>>
>>
> 
> I am not sure what the "It" is here. In all platforms, it is trivial to
> find the source address of an incoming UDP packet. Otherwise sending a
> reply would be impossible. However, it has only recently become easy on
> some platforms and remains difficult to impossible on others. This is
> because it is not necessary for most reasonably designed UDP protocols.
> Even if you wanted to use the IP for authentication, which I still think
> is a bad thing, you only need to find the source address and not the
> destination. If the MAC is not in use, the IP address will not save you
> from a man-in-the-middle attack, and if the MAC is in use, then the IP
> addresses are irrelevant.
> 

Here you need to read the autokey protocol. The addresses are used to
create keys which change every exchange and prevents MIM attacks.

>>
>>
>>>>
>>>>
>>>>>This has led to the super-kludge of binding to all IP addresses
>>>>>on the system as being the best of a bad lot.
>>>>>
>>>>>
>>>>>
>>
>>No, that has nothing to do with it. The binding of all IP addresses is
>>deliberate and has to do with security and to prevent other applications
>>binding to the NTP port.
>>
>>
>>
>>>>Not at all. There are a number of reasons to bind all of the IP
>>>>addresses individually.  It's true in BIND too. In NTP it's even more
>>>>important to bind all addresses since that means another application
>>>>cannot be using the NTP port. You don't want another application setting
>>>>the clock or sending out its own spurious packets.
>>>>
>>>>
>>>I do not know why BIND does it, but my guess is that it  needs
>>>to know what interface a packet arrived on. The whole "grab it
>>>so nobody else can" thing is pretty bogus. It is a complete non-issue
>>>on any UNIX based system. I know you deal with the Windows port,
>>>and I couldn't say what the ramifications on that platform might
>>>be, even there, having an auth token in the NTP header would solve
>>>the problem without binding to all the interfaces.
>>>
>>>
>>>
>>
>>No it isn't bogus and is definitely not a non-issue on any Unix based
>>system. Windows is no different. You ignore the MAC header.
>>
>>
> 
> Explain to me why it is necessary to bind all the addresses on a system
> with a UNIX privilege model. I can not see any scenario where it stops
> any threat for port 123. For ports above 1024, I know of some issues,
> which is why Solaris added the EXCL_BIND socket option. But as I said,
> it is a non-issue on UNIX systems for port 123.
> 

That's not true. Any application in the startup or that gains root
privilege can potentially bind to port 123 on any address. It's bad to
make assumptions on what happens to a system under attack or just
accidentally. I've lost count of the number of times that people end up
running two copies of ntpd on a system not realising that they are.

>>
>>
>>>>You MUST guarantee
>>>>that you return packets ONLY on the same address that the requester
>>>>packet was sent to, you must do authentication using only one address
>>>>and only accept packets between those two addresses that you can
>>>>validate once you have an agreed-upon authentication.
>>>>
>>>>
>>>That is my whole point. It is only because you rely on the IP address
>>>for authentication that you have all of these "MUST" requirements. That
>>>is the flaw.
>>>
>>>
>>>
>>
>>No, you must assume it's a different system sending the packet any other
>>address and must authenticate again.
>>
>>
> 
> Why must you assume it? This is an "Is" again and not a could be.
> 

Because there is no way of knowing otherwise. If there is an identifier
in the protocol, there is no guarantee that it hasn't been spoofed by an
attacker. Normally configured systems will always send out on the same
address. If they are not normally configured you should authenticate on
the new address as well. Otherwise it may be a MIM attack.

Danny




More information about the questions mailing list