Subject: Re: [ntpwg] [ntp:hackers] PTB: Doubt about the autokey protocol

From: Danny Mayer <[email-masked]>
Date: Fri, 03 Jun 2011 08:34:14 -0400

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
> 
> [email-masked] 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: [email-masked]
>>
>> -----"David L. Mills" <[email-masked]> schrieb: -----
>> An: [email-masked]
>> Von: "David L. Mills" <[email-masked]>
>> Datum: 30.05.2011 02:26AM
>> Kopie: [email-masked]
>> 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
>>
>> [email-masked] 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: [email-masked]=
>>>
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 03 Jun 2011 18:55:37 +0000

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

---

From: Danny Mayer <[email-masked]>
Date: Fri, 03 Jun 2011 16:44:35 -0400

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

---

From: "David L. Mills" <[email-masked]>
Date: Sat, 04 Jun 2011 04:27:31 +0000

Danny,

I'm not disputing what you said, but you are missing the point. This is 
a very technical scenario in a very narrow sense. Assuming a middleman 
can hack into either a server or client network router, the attack I 
described is possible. The technical issue is how to warp the protocol 
so this is not possible. This is independent on whether additional 
means, such as the NTP mitigation algorithms, are available.

Dave

---

From: Stephen Röttger <[email-masked]>
Date: Sat, 04 Jun 2011 02:24:09 +0200

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.

> 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

---

From: todd glassey <[email-masked]>
Date: Sun, 05 Jun 2011 18:00:18 -0700

> communication to every server. But I think, this is not an unlikely
Compromising an aggregation router in a Data Center type application 
implements that attack.  Likewise since most all of the reliable 
reference sources are on off-shoot or end-run type end-user connections 
rather than at Internet hubs, this also mitigates this functional risk 
further.
> values in the responses using a fixed offset.
True which is why its so much more reasonable for instances which need 
trustable time to require private networks for them.
> same and can not be detected by the client as an attack.
True.
>>>>>> -----"David L. Mills"<[email-masked]>  schrieb: -----
>>>>>> An: [email-masked]
>>>>>> Von: "David L. Mills"<[email-masked]>

-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers.

---

From: [email-masked]
Date: Mon, 6 Jun 2011 11:55:47 +0200

Hello,

I want to inform you that we were able to perform our described attack
and finished a piece of proof-of-concept code, that is able to change
a clients time despite autokey is enabled. Currently, it only works
if the client starts it's NTP process after the attacker is in place,
but I think it shows the point.

We think it would be a good mitigation to modify the cookie calculation.
Instead of using the clients IP address, its public key could be used.
Consequently, the attacker would not be able to obtain the cookie for a
client without knowing the clients private key.
This would have the positive side effect, that autokey would work with
NATs and it is the only possibility that we can think of, that leaves
the server stateless and does not add requirements to the client (e.g.
a
certificate from a trusted authority).
On the other hand, it would require the client, to send its public key
with every time request message.

Stephen

-----Danny Mayer <[email-masked]> schrieb: -----

An: "David L. Mills" <[email-masked]>
Von: Danny Mayer <[email-masked]>
Datum: 03.06.2011 14:32
Kopie: [email-masked], Stephen Röttger <[email-masked]>, [email-masked], [email-masked], NTP Working Group <[email-masked]>
Betreff: Re: [ntp:hackers] PTB: Doubt about the autokey protocol

Dieter,

Danny

---

From: "David L. Mills" <[email-masked]>
Date: Tue, 07 Jun 2011 14:37:34 +0000

Stephen,

It would indeed avoid the problem you cite, but that would involve an 
expensive cryptographic computation for every server packet. This was 
considered in the Autokey briefing at the NTP project page, but rejected.

There might still be room for an innovative approach. However, upon 
close examination there are more vulnerabilities, including a 
cut-and-paste attack on the Autokey extension fields. The Autokey dances 
are not the only ones vulnerable to these attacks, but a generic 
solution is really hard to find.

Meanwhile, one of the things we can assume is that the client has a 
secure means to obtain the server public key or certificate. The same 
issue applies to the public identity key if used. This avoids middleman 
attack in the same way as a symmetric key. The issue about the cookie 
exchange and autokey values exchange needs to be looked at more carefully.

All this activity started with a more careful examination of the 
middleman issues. The Autokey project began in 1996, but was only 
finalized in 2005 and generally not actively pursued since the stime 
IETF study group in 20006. In the light of a much more aggressive 
intruder threat today, these issues should be examined in great detail. 
The lessons learned might benefit a wider community.

Dave

[email-masked] wrote:

> the server stateless and does not add requirements to the client (e.g. a
>     Kopie: [email-masked], Stephen Röttger
>     <[email-masked]>, [email-masked],
>     [email-masked], NTP Working Group <[email-masked]>