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

Danny Mayer mayer at ntp.org
Fri Jun 3 20:44:35 UTC 2011


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