[ntp:hackers] PTB: Doubt about the autokey protocol

Stephen Röttger s.roettger at tu-bs.de
Sat Jun 4 00:24:09 UTC 2011


Danny,

You are right, the attacker has to be able to intercept the
communication to every server. But I think, this is not an unlikely
scenario.
Otherwise, if the attacker can only intercept the connection to one
server, he would not be able to change a clients time, even if autokey
is disabled.

> 2) the middleman acts for all servers and tries to fool the client into
> thinking it has valid time for all servers but then all of the servers
> will appear to be serving time with an almost identical set of
> timestamps in which case all servers will look the same and be
> suspiciously close to each other.

This is not a difficulty for the attacker (if he is a man-in-the-middle
to all servers). He can either vary its response times dependent on the
server he spoofs, or, as I did it in my proof-of-concept code, forward
all requests unchanged to the according server, but change the time
values in the responses using a fixed offset.
In the latter case, the time variations between the servers stay the
same and can not be detected by the client as an attack.

Stephen

On 06/03/11 22:44, Danny Mayer wrote:
> Dave,
> 
> No I don't think that I misinterpreted the reason. I understood about PTB.
> 
> One of my points was that if you are going to be using autokey you are
> trying to ensure that you are getting good reliable time and therefore
> need to make sure that you are using more than one source and that you
> are using autokey for each one.
> 
> Another point is that a backward adjustment, legitimate or not, will get
> ignored because the other sources are telling you that it is a
> falseticker. In such cases a falseticker would be required to restart
> the autorun dance from the beginning, or at least it should be doing
> that. There are several scenarios here:
> 
> 1) the middleman acts just on one server, in which case the packets will
> get thrown out as it will be considered a falseticker;
> 
> 2) the middleman acts for all servers and tries to fool the client into
> thinking it has valid time for all servers but then all of the servers
> will appear to be serving time with an almost identical set of
> timestamps in which case all servers will look the same and be
> suspiciously close to each other. As we know networks are wildly varying
> in their delays and the only way that such a middleman can do this is by
> being on the same subnet as the client which is a hard thing to
> accomplish. Failing that it would be very hard for a middleman to do
> this on multiple subnets. The middleman would also need to make sure
> that the packets did not reach the real server or the real server's
> response packets reach the client since the client will see the packets
> and start to discount the packets coming from what it thinks is one
> place and because the autokey dance values will not agree thereby
> causing the server to be marked as a falseticker.
> 
> The part I'm struggling with is the client cookie and how did the
> middleman get hold of a private key for it to act as a substitute server.
> 
> Danny
> 
> On 6/3/2011 2:55 PM, David L. Mills wrote:
>> Danny,
>>
>> You might have misinterpreted by reason for posting to this list. Dieter
>> is from the PTB, the German equivalent of NIST. His concern is not
>> necessarily on good client practice, but provable defense against a
>> middleman attack. This is one of two vulnerabilities that occur with
>> public key cryptography as applied to NTP. The first is when obtaining
>> client cookie from a server as I described.
>>
>> The second is with old duplicates in broadcast modes and in particular
>> an old duplicate of a autokeys values message. The problem occurs with
>> symmetric and public key cryptography, since an old duplicate cannot
>> easily be distinguished from a legitimate backward adjustment of the
>> system clock.
>>
>> The interesting aspect from an engineering point of view is that, while
>> symmetric key cryptography is in general immune to middleman threats,
>> public key cryptography, not just Autokey, is devilishly hard to avoid
>> middleman compromise. My hope in posting to this list is to stimulate
>> discussion on ways to fix the problem.
>>
>> There are two white papers addressing these issues, "Analysis and
>> Simulation of the NT On-Wire Protocol"
>> www.eecis.udel.edu/~mills/onwire.html and "NTP Security Analysis"
>> www.eecis.udel.edu/~mills/security.html. Your comments are inivited.
>>
>> Dave
>>
>> Danny Mayer wrote:
>>
>>> Dieter,
>>>
>>> There are several things going on here and I'd like to try to clarify
>>> them. I'm copying the NTP working group since it is more relevant to
>>> that list than hackers.
>>>
>>> 1) If you are using NTP you should be using at a minimum 3 separate
>>> sources of NTP packets. The NTP client uses the sources to decide which
>>> is providing the "best" (I don't want to discuss how NTP decides which
>>> is best here) source of time. NTP continually reexamines its sources and
>>> makes that decision regularly. If the client is not using at least 3
>>> sources then they are not worrying about securing the time service.
>>>
>>> 2) A man-in-the-middle attack on autokey needs to intercept NTP Packets
>>> to EVERY server it is using which is a much harder proposition. Each
>>> such server will have its own keys that the middleman would need to
>>> manage.
>>>
>>> 3) I am not clear where the middleman gets its public key. It's not
>>> provided in the protocol and can only be obtained Out-of-band. The
>>> server provides keys, the client doesn't. Am I mistaken in this?
>>>
>>> 4) You say that your student was able to perform such an attack but was
>>> he able to do it without having any information about the servers keys?
>>>
>>> I'll have more to say when I understand this issue a little better.
>>>
>>> Danny
>>>
>>> On 6/2/2011 9:29 PM, David L. Mills wrote:
>>>  
>>>
>>>> Dieter,
>>>>
>>>> The problem I have with your scenario is how to convince the client that
>>>> the middleman client cookie is genuine. The server provides the client
>>>> cookie encrypted with the middleman key, but the middleman has to
>>>> encrypt the client cookie for the client using the client key. That
>>>> requires the response to be signed, but the middleman cannot encrypt the
>>>> signature without the server private key.
>>>>
>>>> Here is another way this could be done. The middleman lives in a
>>>> compromised router on the same Ethernet as the client. It begins by
>>>> simply wiretapping the client cookie request, but allows the client
>>>> request/response to complete. It then repeats the request  with its own
>>>> key and intercepts the response without continuing to the client.
>>>> Subsequently, it masquerades as the server and injects its own values
>>>> while observing the on-wire protocol rules.
>>>>
>>>> It very well may be that the best  approach to this and similar problems
>>>> is a suite of algorithms designed to verify the integrity of the router,
>>>> rather than further complicate the NTP protocol design. This might be a
>>>> topic for discussion on the hackers.ntp.org list.
>>>>
>>>> I'm still not satisfied with the NTP security document. It was first
>>>> written five years ago in somewhat of a hurry as the RFC was submitted
>>>> for review. The document does not lie, but its wording is a bit loose.
>>>> The main thing that needs to be clarified is how the public values can
>>>> be protected against middleman attack. It needs to be tightened and I am
>>>> doing that. now. I will advise when it is ready for prime time.
>>>>
>>>> Dave
>>>>
>>>> dieter.sibold at ptb.de wrote:
>>>>
>>>>   
>>>>> Dave,
>>>>> thanks for your last email.
>>>>> I agree that the usage of the autokey procedure is quite an obstacle
>>>>> for "normal" end users who just want to have the time from their
>>>>> national laboratory. But that is not our primary intention. Although
>>>>> we have quite a high access rate to out time servers the requests for
>>>>> signed time packets is quite small. Therefore, I believe that even if
>>>>> we provide authenticated time service to the public the usage of it
>>>>> would be quite small. Our intention is to investigate if NTP together
>>>>> with autokey provides an robust and secure authenticated time service
>>>>> for applications which depend on authenticated time information by
>>>>> requirements enforced by Germany's Verification Act. For this scenario
>>>>> the technical obstacles of autokey are not a major problem.
>>>>>
>>>>> Nonetheless I also agree that it would be nice if the configuration
>>>>> and usage would be easier.
>>>>>
>>>>> Thanks also for editing of the Security Analysis paper. At this point
>>>>> we still have some issues.
>>>>>
>>>>> At our first question regarding the security of autokey you wrote:
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>> Your analysis left out one crucial fact. The server reply to the
>>>>>> cookie
>>>>>> request is signed by the server using its private key. The client, in
>>>>>> possession of the server public key, can verify the authenticity of
>>>>>> the
>>>>>> reply.
>>>>>>  
>>>>>>       
>>>>> That is ok. But nonetheless, my colleague - Stephen - already
>>>>> performed a man-in-the-middle attack and he was able to compute a
>>>>> valid Message Authentication Code (MAC) for a servers time response.
>>>>> The attack works as follows:
>>>>>
>>>>> First of all the attacker (M) aims to obtain the client cookie C_C for
>>>>> the NTP-Client C. To this end the attacker M performs a
>>>>> man-in-the-middle attack in which he masquerades as NTP-Client C and
>>>>> send a cookie request to the NTP-Server S together with its public key
>>>>> P_M and the IP-address IP_C of NTP-Client C. In response M obtains the
>>>>> client cookie C_C from the server S, which is encrypted with the
>>>>> public key P_M of M and which is meant to be for the NTP-Client C. The
>>>>> attacker M is able to decrypt the client cookie C_C because it is
>>>>> encrypted with its public key P_M. Now M is in possession of the
>>>>> client cookie C_C and will store it.
>>>>> As of now the attacker M will change his role and will masquerade as
>>>>> NTP-Server S. When C sends a time request to the NTP-Server S it will
>>>>> be intercepted by M. Because M stored the client cookie C_C he is now
>>>>> able to verify the client request and to construct a timestamp
>>>>> response with a valid MAC.
>>>>>
>>>>> The problem arises because the NTP packet is bound to the client
>>>>> cookie C_C in which the client identity is only reflected by the
>>>>> clients IP-address IP_C. Therefore M is able to gain possession of the
>>>>> client cookie for C by means of a man-in-the-middle attack.
>>>>>
>>>>>
>>>>> In the moment we do not know if the attacker M is now able to change
>>>>> the time of the client C; but Stephen is investigating this question.
>>>>>
>>>>> Obviously we have to emphasize that this scenario is only possible if
>>>>> the attacker M is able to introduce himself into the communication
>>>>> line between client C and server S.
>>>>>
>>>>> With best regards
>>>>> Dieter
>>>>> -----------------------------------------------
>>>>> Physikalisch-Technische Bundesanstalt
>>>>> Q.42 - Server Administration
>>>>> Bundesallee 100, D-38116 Braunschweig
>>>>> Tel: +49-531-592-84 20
>>>>> E-Mail: dieter.sibold at ptb.de
>>>>>
>>>>> -----"David L. Mills" <mills at udel.edu> schrieb: -----
>>>>> An: dieter.sibold at ptb.de
>>>>> Von: "David L. Mills" <mills at udel.edu>
>>>>> Datum: 30.05.2011 02:26AM
>>>>> Kopie: stenn at ntp.org
>>>>> Betreff: Re: PTB: Doubt about the autokey protocol
>>>>>
>>>>> Dieter,,
>>>>>
>>>>> It looks like the NTP Security Analysis needs some work. I have edited
>>>>> the page and brought it up to date. See especially sections 4 and 5.
>>>>> One issue is whether or not the identity scheme is necessary; for
>>>>> protection from middleman attack; I believe it is. However, there are
>>>>> some rough edges for a national laboratory deployment. A client needs
>>>>> to have the OpenSSL cryptographic library, as well as the Autokey
>>>>> configuration selected at build time. I'm not sure this will be
>>>>> acceptable on a widespread deployment.
>>>>>
>>>>> Another issue that needs to be resolved is whether the client needs to
>>>>> generate host or signature keys and whether a client certificate is
>>>>> necessary. If the client has no dependent clients, it does not need
>>>>> these things, but the current implementation requires them, even if
>>>>> they are not used. What needs here is some software grooming to ease
>>>>> the configuration and deployment on a national scale. This is not hard
>>>>> and could in principle be done by the Google software corps.
>>>>>
>>>>> Dave
>>>>>
>>>>> dieter.sibold at ptb.de wrote:
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>> Dear Prof. Mills and Mr. Stenn,
>>>>>>
>>>>>> I am writing this email because I have a couple of open questions
>>>>>> regarding the security of the autokey protocol.
>>>>>>
>>>>>> First, let me start to explain what we want to achieve by means of
>>>>>> autokey.
>>>>>> The PTB is Germany's national metrology institute. The dissemination
>>>>>> of  time is one of our legal tasks. Since many years this is done via
>>>>>> long-wave transmitter DCF77 and since 1999 we also provide publicely
>>>>>> accessible NTP time servers for the dissemination of UTC(PTB)
>>>>>> successfully.
>>>>>> Within the scope of the new emerging smart grids in energy
>>>>>> distribution systems we are investigating if we could enhance our
>>>>>> time service  in order to provide securely  authenticated time to the
>>>>>> operators of energy distribution networks.  To this end we
>>>>>> investigate if NTP together with the autokey-protocol is
>>>>>> cryptographically sufficient to meet the requirements which are
>>>>>> enforced by Germany's Verification Act.
>>>>>>
>>>>>> After the study of RFC5906 and recording of the communication
>>>>>> messages between NTP-client and NTP-server our student was able to
>>>>>> perform a man-in-the-middle attack. As a consequence he was able to
>>>>>> masquerade as server. You will find the  procedure  described in the
>>>>>> enclosed attachment.
>>>>>> If the described man-in-the-middle attack really breaks the
>>>>>> authentication we have to exclude the autokey-protocol from further
>>>>>> investigations. So I'd very much appreciate if you would be so kind
>>>>>> to comment the described attack.
>>>>>>
>>>>>> Thank you very much. With best regards
>>>>>>
>>>>>> Dr. D. Sibold
>>>>>> S. Röttger
>>>>>> Dr. U. Grottker
>>>>>>
>>>>>> -----------------------------------------------
>>>>>> Physikalisch-Technische Bundesanstalt
>>>>>> Q.42 - Server Administration
>>>>>> Bundesallee 100, D-38116 Braunschweig
>>>>>> Tel: +49-531-592-84 20
>>>>>> E-Mail: dieter.sibold at ptb.de=
>>>>>>
>>>>>>       
>>
>>
>>
> 



More information about the hackers mailing list