Subject: [ntpwg] New draft document for NTS and NTS for NTP

From: Dieter Sibold <[email-masked]>
Date: Tue, 22 Mar 2016 19:52:15 +0100

Please note that we submitted new versions of the drafts mentioned below. We’ve incorporated the negotiation of the MAC algorithm and and the we’ve added some language to the security requirements in the NTS for NTP draft which addresses Harlan’s concern about the not MAC protected key exchange.

> Anfang der weitergeleiteten Nachricht:
> 
> Von: [email-masked]
> Betreff: New Version Notification for draft-ietf-ntp-using-nts-for-ntp-05.txt
> Datum: 21. März 2016 um 15:39:49 MEZ
> An: "Stephen Röttger" <[email-masked]>, "Dieter Sibold" <[email-masked]>, "Stephen Roettger" <[email-masked]>, "Kristof Teichel" <[email-masked]>
> 
> 
> A new version of I-D, draft-ietf-ntp-using-nts-for-ntp-05.txt
> has been successfully submitted by Kristof Teichel and posted to the
> IETF repository.
> 
> Name:		draft-ietf-ntp-using-nts-for-ntp
> Revision:	05
> Title:		Using the Network Time Security Specification to Secure the Network Time Protocol
> Document date:	2016-03-21
> Group:		ntp
> Pages:		23
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-ntp-using-nts-for-ntp-05.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp-05
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-using-nts-for-ntp-05
> 
> Abstract:
>   This document describes how to use the measures described in the
>   Network Time Security (NTS) specification to secure time
>   synchronization with servers using the Network Time Protocol (NTP).
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> Anfang der weitergeleiteten Nachricht:
> 
> Von: [email-masked]
> Betreff: New Version Notification for draft-ietf-ntp-network-time-security-14.txt
> Datum: 21. März 2016 um 15:39:34 MEZ
> An: "Stephen Röttger" <[email-masked]>, "Dieter Sibold" <[email-masked]>, "Stephen Roettger" <[email-masked]>, "Kristof Teichel" <[email-masked]>
> 
> 
> A new version of I-D, draft-ietf-ntp-network-time-security-14.txt
> has been successfully submitted by Kristof Teichel and posted to the
> IETF repository.
> 
> Name:		draft-ietf-ntp-network-time-security
> Revision:	14
> Title:		Network Time Security
> Document date:	2016-03-21
> Group:		ntp
> Pages:		39
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-ntp-network-time-security-14.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-ntp-network-time-security/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-ntp-network-time-security-14
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-network-time-security-14
> 
> Abstract:
>   This document describes Network Time Security (NTS), a collection of
>   measures that enable secure time synchronization with time servers
>   using protocols like the Network Time Protocol (NTP) or the 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 Networks [RFC7384].
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

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

---

From: Dieter Sibold <[email-masked]>
Date: Wed, 23 Mar 2016 21:19:44 +0100

Hi Miroslav

I’ve discussed this today with Kristof and we agreed that this is a good idea. I just studied a estimate of the size of the relevant NTS extension fields. The time_request extension field is supposed to have an approximated size of 80 octets whereas the time_response extension fields has a size around 30 octets. So, both  extension fields have to be larger than its possibly minimum size of 16 octets. To have both extension fields the same size we currently see two approaches

1. The server captures the size of the time_request extension field and zero-pads the time_response extension field to have the same size.
2. The server includes in the time_response extension field the same information as in the time_request extension field. That should achieve the goal also.

I’m yet not sure what is the best method. I tend to prefer the first approach.

Dieter

> Am 23.03.2016 um 07:35 schrieb Miroslav Lichvar <[email-masked]>:
> 
> On Tue, Mar 22, 2016 at 07:52:15PM +0100, Dieter Sibold wrote:
> Hi Dieter,
> are you planning to include also the suggestions I had for NTS in
> symmetric associations and the padding in the time_response message to
> keep lengths of NTP packets symmetric?
> 
> If there are some details that need to be worked out or I can help in
> some other way, please let me know.
> 
> Thanks,
> 
> --
> Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 29 Mar 2016 11:53:04 +0200

> I’m yet not sure what is the best method. I tend to prefer the first approach.

I'd probably prefer the former too.

I'm wondering if it would make sense to define a new "padding-only"
extension field and pad replies with it instead of requiring the NTS
and other extension fields in packets used for synchronization to have
symmetric lengths. It could be also used when a reply has a different
number of extension fields than the request. I'm not sure if that is
expected to happen. This would work only if the required padding was
not smaller than the minimum allowed length of an extension field.

---

From: Danny Mayer <[email-masked]>
Date: Tue, 29 Mar 2016 12:26:51 -0400

> not smaller than the minimum allowed length of an extension field.

The response extension fields should never expect to be the same number
or type as the request extension fields irrespective of the contents of
those extension fields. Part of the reason may be that the responding
server may not be aware of some of the extension fields in the request
and the other may be that the server shouldn't be sending back that
extension field even if it does understand it.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 29 Mar 2016 22:59:24 +0000

Why does this need to be specified in the standard/draft?

It's an implementation detail that can be noted.

Has anybody done any empirical testing and analysis around the packet
symmetry and packet length issues?  Is there expectation that if these
are valid issues, that they are universal in scope?

H