Subject: [ntpwg] I-D Action: draft-ietf-ntp-network-time-security-00.txt

From: [email-masked]
Date: Sun, 07 Jul 2013 15:11:19 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network Time Protocol Working Group of the IETF.

	Title           : Network Time Security
	Author(s)       : Dieter Sibold
                          Stephen Roettger
	Filename        : draft-ietf-ntp-network-time-security-00.txt
	Pages           : 12
	Date            : 2013-06-28

Abstract:
   This document describes the Network Time Security (NTS) protocol that
   enables secure authentication of time servers using Network Time
   Protocol (NTP) or Precision Time Protocol (PTP).  Its design
   considers the special requirements of precise timekeeping, which are
   described in Security Requirements of Time Protocols in Packet
   Switched Network [I-D.ietf-tictoc-security-requirements].

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ntp-network-time-security

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ntp-network-time-security-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

---

From: Kurt Roeckx <[email-masked]>
Date: Mon, 8 Jul 2013 01:18:48 +0200

>    Switched Network [I-D.ietf-tictoc-security-requirements].

Doing a quick reading of this draft, I have a few questions:
- Why isn't this just:
  - Request the X509 certificate of the server
  - Request a signed reply?
  I guess that you feel that an RSA signature is too expensive
  and that you instead want create a session key (cookie) between
  the client and server and just use a MAC function.
- Why does the client need a public key?  It doesn't seem to
  make sense to me to need a key for each client.  This is
  only needed for the cookie generation?  Why isn't there
  something simular to a Diffie-Hellman key exchange used
  instead?

Kurt

---

From: Stephen Röttger <[email-masked]>
Date: Mon, 08 Jul 2013 02:09:45 +0200

Hi Kurt,

>   - Request a signed reply?
The time used to create the MAC/Signature for a time packet will
directly affect its precision. Thus I see two alternatives:

 1. Keep the authentication overhead as low as possible by using a
message authentication code (this is our approach)

 2. Let the server send the time synchronization packet twice: first
without authentication and afterwards with a signature attached. The
client will note the time of arrival of the first packet, but buffer it
until the second packet arrives and he can verify the signature. In this
approach we could use RSA since the time used for the signature creation
will not affect the precision.

We chose the symmetric approach to keep the load on the server as low as
possible since this might affect the precision of time requests arriving
from different clients.

> - Why does the client need a public key?
In the common NTP mode, the client/server mode, the NTP server is
stateless and we wanted to keep it that way. Thus, we need a shared
secret between client and server for the MAC generation that can be
calculated newly by the server every time a request arrives.
We need the public key at the client in order that the server can
encrypt the secret and send it to the client. The public key is also
used as input to the shared secret to prevent an attacker to request the
same secret from the client.
This means, the client is identified by his public key and the shared
secret calculated from this key will only be send to the client in
encrypted form. The specific parts of the protocol look like this:

1. C              PubKey_C ->            S

2. Server calculates secret (cookie): MSB_128 (H(server seed || H(public
key of client)))

3. C    <- Sign(Enc(PubKey_C, cookie))   S

4. C          TimeRequest, PubKey_C ->   S

5. Server again calculates the secret (no state available)

5. C    <- MAC(TimeResponse, cookie)     S

Regards,
Stephen

---

From: Kurt Roeckx <[email-masked]>
Date: Mon, 8 Jul 2013 22:08:42 +0200

On Mon, Jul 08, 2013 at 02:09:45AM +0200, Stephen Röttger wrote:
> directly affect its precision.

I would think it would have more effect on the accuracy that on the
precision.

> possible since this might affect the precision of time requests arriving

I can really see that you want an as low as possible overhead per
packet, and want to assume that a clients sends a large amount of
packets with the same cookie.

If a client has an interval of 1024, and you generate a new seed
every hour, that would mean basicly have 3/4 packets before it
needs to start again.  But the draft currently doesn't mention
anything about how often it needs to change.

> same secret from the client.

There are various methods to establish a shared secret between the
server and the client don't don't require the client to have a
public rsa key.

I'm concerned about people inventing new ways to do something
that's already been done many times, without fully understanding
the security consequences.

For instance, you now have a secret (cookie) that's based on the
concatantion of an other secret (seed) and a public part.  Which
kind of existing attaks can be used to get the either secret from
that?

I understand that not keeping state in the server complicates
things.  But I would really like to see an overview of the
possiblities and the pros and cons for the various options.

Kurt

---

From: Stephen Röttger <[email-masked]>
Date: Mon, 08 Jul 2013 22:53:17 +0200

> I would think it would have more effect on the accuracy that on the
You're right, I didn't know there is a difference. We don't make that
distinction in my mother tongue.

> server and the client don't don't require the client to have a
Yes that's right, but there is no method that I'm aware of in which the
server is not required to keep a state for the client and to remember
the secret.

> kind of existing attaks can be used to get the either secret from
The security of this depends on the security of the cryptographic hash
function that is used. In particular the pre-image resistance and the
second pre-image resistance.
Pre-image resistance guarantees, that we will not be able to find an
input that produces the given output. This means, that we will not be
able to find a value for the server secret that will produce a given cookie.
Second pre-image resistance on the other hand guarantees that while
given a fixed hash input, we will not be able to find a second input
that produces the same hash. Thus, it will not be possible to find a
second RSA key that will result in the same cookie (which is further
complicated since an attacker will not know the cookie itself).

I understand your concerns and I would probably see it the same way:
don't invent something new if there is already a solution for the
problem, especially with cryptography. But as long as we keep the server
stateless and still want to use symmetric cryptography, I don't see any
alternatives.
In my opinion, the protocol itself is relatively simple and I would
really appreciate it if a few people with cryptographic experience would
take a look at it (especially the part summarized in my last email).

Stephen

---

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 10 Jul 2013 10:32:36 -0400

Folks,

I meant to cross post this to tictoc for your information as well. 
Please review and comment.

Karen

-------- Original Message --------
Subject: 	[ntpwg] I-D Action: draft-ietf-ntp-network-time-security-00.txt
Date: 	Sun, 07 Jul 2013 15:11:19 -0700
From: 	[email-masked]
To: 	[email-masked]
CC: 	[email-masked]

Abstract:

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 12 Jul 2013 19:12:02 +0000

Stephen,

I may have missed the beginning of this thread.  I  looked at the 
document, but some of the details are missing.  There is a long history 
of NTP security algorithms beginning with a technical report in 1996.
The document was updated in 2006, but was delayed in the IETF 
publication process for several years, and finally published as 
RFC5906.  There have been several enhancements to the autokey protocol 
described in RFC5906  since then, as documented in the NTP software 
release notes.  One of these was to augment the hash algorithms to 
include SHA and all of the other algorithms provided in the OpenSSL library.

One of the messages on this thread suggested sending an unsecured 
message followed by a secured copy.  The idea apparently is to provide 
accurate time with the first message as verified by the second.  This 
feature has already been implemented in the NTP software, now called 
interleave mode.  The interleave modes are documented on  the  NTP 
project page linked from the  NTP home page and in the software release 
notes.

There is a good deal of information and position papers at the NTP 
project page linked from the NTP home page.  One of these contains a 
security analysis of NTP, including the "cookie snatchers" and related 
hazzards.  The NTP security model is designed for stateless servers.  
One of the goals of the present work described on this thread is to 
eliminate these hazzards while preserving the stateless model.  There is 
in priciple a capability to change this model and allow some state 
peculier to each client.  If so, one or another of the 
station-to-station (STS) protocol or one of its derivitives.  This 
protocol involves public certificates and the Diffie-Hellman agreement 
algorithm.  In any case, it would be advisable to use this protocol in 
the NTP symmetric modes.

There was a discussion on this thread about validating the public 
certificate valid time interval.  This is not possible unless the 
recipient has a reliable clock.  However, a reliable clock requires two 
things:  a valid signature on the cookie response, and a reliable time 
confirmed by the NTP algorithms and possibly several servers. 

A further requirement in the security model. is to reduce or eliminate 
errors due to dropped or replicated packets, or packets crossed in 
flight. This might be due to a middleman attack or DoS attack. There is 
an extensive discussion on these issues together with serious 
simulations in the white paper about the on-wire protocol on the NTP 
project page.  This applies to both the RFC5906 protocol, as well as the 
protocol discussed in this thread.

It is important that whatever protocol is adopted, that the resources 
required of  NTP or PTP for that matter, be absolutely minimal.  In 
RFC5906 there is no requirement for DNS or TCP or any protocol dependent 
on either of these protocols.  It would seem that using SSH to retrieve 
certificates is not a good idea.  In the NTP implementation, 
certificates are stored in a cache so that certificates can be replaced 
with new ones or from different sources as they become available.  Thus, 
it is possible only to verify continuity of the valid ranges as 
certificates are retrieved.  Absolute validity can be determined only 
after the client clock has been synchronized.

I'm very glad that this discussion has flourished.  I hope that RFC5906, 
or some part of it, can be useful.  In any case, it is important to 
discuss the architecture issues and assumptions of the supporting 
services.  This is especially important for national time servers with 
upwards of several thousands client requests per second. 

Dave

---

From: Kurt Roeckx <[email-masked]>
Date: Sun, 28 Jul 2013 16:40:31 +0200

> take a look at it (especially the part summarized in my last email).

I can't see anything obvious wrong with it, but would also really
like to see feedback from people who have more expierence with
this than I do.

Kurt