Subject: Re: [ntpwg] Autokey-Protocol Analysis

From: "David L. Mills" <[email-masked]>
Date: Wed, 07 Sep 2011 19:42:12 +0000

Yaakov,

Thanks very much for your sharp eyes on the NTP security analysis 
document www.eecis.udel.edu/~mills/security.html. I have been pecking 
away on this document for some time and do apologize for its somewhat 
fluid evolution. While the discourse has been refined and sharpened 
during the editing process, what may be of interest are Sections 6 on 
conclusions and Section 7 on possible changes in the specification and 
reference implementation.

The Autokey protocol is offered as an example of public key cryptography 
for a ubiquitous time synchronization service for national time servers 
with thousands of clients. The Autokey protocol dance has much in common 
with the TLS handshake protocol; however, using TLS for multiple, 
persistent associations on an embedded system would be extremely 
complicated and resource intensive. THe Autokey protocol is integrated 
with the NTP packet format and packet authentication mechanisms and 
operates in a low profile way.

The changes are summarized as follows.

1. The cookie snatcher vulnerability cannot be fixed if the server is 
required to be stateless. The proposed changes require that the server 
keeps a list of active clients. Each entry on the list includes the IP 
addresses, secret message digest key, and a timeout counter. The client 
rolls a nonce as the messaged digest key, encrypts with the public key 
of the server, and sends to the server. The server decrypts the message 
digest key and saves for future use. Details are in the document.

2. In packets with extension fields, each extension field is protected 
by a signature, but the NTP header itself is vulnerable to modification. 
Since packets with extension fields are used only during the initial 
handshake and the on-wire protocol is resistant  to moderate packet 
loss, packets with extension field are not use for timing purposes. This 
is consistent with the TLS rule against using data before the handshake 
is complete.

3. In the current Autokey protocol, the certificate trail is verified 
according to the X.509 specification; however, the Autokey trusted host 
is designated the certificate authority (CA). This design is consistent 
with an implementation for an embedded system that might not have 
connectivity to a public CA. With only minimal changes, this design can 
be adapted to industry standards where a root certificate is provided by 
an external trusted CA. In addition, a server certificate can be signed 
by the CA and provided to the server. This can be used to sign extension 
fields as required by the protocol. As in the present design, both the 
root certificate and server certificate can be  loaded automatically by 
the protocol.

The above changes are no big deal in the reference implementation. There 
are macros for list construction and manipulation for the rate 
management facilities. An agreement exchange is only a few lines of 
code. I would be happy to make these changes; however, I am now legally 
blind and C language programming is not practical.

I think it would be a good idea to pursue the topic of public key 
cryptography for NTP, whether it is using Autokey or some other 
approach. To do this properly requires an agenda on the part of a 
working group. I would be happy to contribute what help I can give in 
such and adventure.

Dave

Yaakov Stein wrote:

>Dave
>
>I just looked at your updated security analysis page,
>and saw two nits that you would probably wish to clean up.
>
>There is an orphaned "k" at the beginning of the page
>(appears after the <body> but before the first <div>)
>and the letter "N" is missing in the title "TP Security Analysis".
>
>I wouldn't have bothered you about them 
>were they not the first thing people see when going to the page ...
>
>Y(J)S
>
>  
>

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 07 Sep 2011 14:22:30 -0700

Dave,

I'm sure that my crew can handle the code updates and subsequent
testing, and of course we'd be consulting with you.  As soon as
practical I'd also like to see "us" pursue the refinement of the issues
with a Working Group.

H

---

From: todd glassey <[email-masked]>
Date: Wed, 07 Sep 2011 14:44:52 -0700

> practical I'd also like to see "us" pursue the refinement of the issues
Harlan - remember that without audit practice review - the code and its 
new fixes will likely be as much of a problem as the original ones were. 
My proposal is that a formal use and security audit for production 
environments is factored into this technology review to make sure no 
more u-turns are necessary in the implementation effort.

Todd

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

Further I OPT OUT of any and all commercial emailings.

---

From: Stephen Röttger <[email-masked]>
Date: Fri, 09 Sep 2011 13:43:55 +0200

Dave,

> required to be stateless.

Actually, you can fix this vulnerability without introducing states to
the server. As I mentioned before, you can use the clients public key
that is used for encrypting the cookie as an input to the cookie
calculation itself. For example:
cookie = hash(public key, server seed)
In this scenario, the attacker can only snatch the cookie if he uses the
clients public key in the request and therefor needs to know the
corresponding private key to decrypt it.

In the meantime I handed in my thesis and can now make it available to
you. It is written in german, but there will be an english version soon.
You can find it at:
http://www.zero-entropy.de/Analyse_des_NTP-Autokey-Verfahrens.pdf

Stephen

---

From: todd glassey <[email-masked]>
Date: Fri, 09 Sep 2011 09:35:00 -0700

On 9/9/2011 4:43 AM, Stephen Röttger wrote:
> calculation itself.
yes - but adding an OOB SSH type tunnel between the client and server 
for transferring key control and session identity data makes this also a 
no-brainer and fixes most of the other issues too...
> For example:

---

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

Stephen ,

That's a clever way to prevent masquerade using a snatched cookie. But, 
following the cookie exchange extension fields are not used. The server 
is then required to regenerate the client cookie using only the packet 
header and server private cookie. So, how does the stateless server 
regenerate the client cookie in order that the client and server use the 
same message digest key?

Dave

---

From: Stephen Röttger <[email-masked]>
Date: Sat, 10 Sep 2011 22:46:18 +0200

Dave,

You are right, this approach is only possible, if the client appends its
public key to every time request, for example using a new extension
field type.

Stephen

---

From: todd glassey <[email-masked]>
Date: Sun, 11 Sep 2011 08:01:19 -0700

> public key to every time request, for example using a new extension
Again this is why a redirection proxy type controller with a 
session-specific key management instance would work so well...

Todd

---

From: [email-masked]
Date: Mon, 12 Sep 2011 09:19:21 +0200

Dear Todd,

would you please sketch the architecture of such an proxy type controller.

Mit freundlichen Grüßen
Dr. Dieter Sibold
-----------------------------------------------
Physikalisch-Technische Bundesanstalt
Q.42 - Server Administration
Bundesallee 100, D-38116 Braunschweig
Tel: +49-531-592-84 20
E-Mail: [email-masked]

ntpwg-bounces+dieter.sibold=[email-masked] schrieb am 11.09.2011
17:01:19:

> Von: todd glassey <[email-masked]>
> An: [email-masked]
> Datum: 11.09.2011 17:05
> Betreff: Re: [ntpwg] Autokey-Protocol Analysis
> Gesendet von: ntpwg-bounces+dieter.sibold=[email-masked]
>