Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp

"Langer, Martin" <mart.langer@ostfalia.de> Sun, 07 March 2021 17:06 UTC

Return-Path: <mart.langer@ostfalia.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BA33A1964 for <ntp@ietfa.amsl.com>; Sun, 7 Mar 2021 09:06:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id db84o3WxngBK for <ntp@ietfa.amsl.com>; Sun, 7 Mar 2021 09:06:03 -0800 (PST)
Received: from mx2.sonia.de (mx2.sonia.de [141.41.1.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143FA3A1959 for <ntp@ietf.org>; Sun, 7 Mar 2021 09:06:02 -0800 (PST)
Received: from mx2.sonia.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4D81E108010F; Sun, 7 Mar 2021 18:05:57 +0100 (CET)
Received: from exchange04.resource.sonia.de (exchange04.resource.sonia.de [141.41.8.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx2.sonia.de (Postfix) with ESMTPS id 8563A1080108; Sun, 7 Mar 2021 18:05:55 +0100 (CET)
From: "Langer, Martin" <mart.langer@ostfalia.de>
To: Watson Ladd <watsonbladd@gmail.com>, NTP WG <ntp@ietf.org>
Thread-Topic: [Ntp] Comments on draft-langer-ntp-nts-for-ptp
Thread-Index: AQHXEfmMSKND+BsUuke89/+0bAqpHap4wuQ/
Date: Sun, 7 Mar 2021 17:05:55 +0000
Message-ID: <f51dfb1db7c843ecaf58efac526d30ef@ostfalia.de>
References: <CACsn0cnz1GfKUKn6q61qmAbs=VPgTGFZnP=kEeQHk9CUxLACXg@mail.gmail.com>
In-Reply-To: <CACsn0cnz1GfKUKn6q61qmAbs=VPgTGFZnP=kEeQHk9CUxLACXg@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [141.41.8.54]
Content-Type: multipart/alternative; boundary="_000_f51dfb1db7c843ecaf58efac526d30efostfaliade_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/JuDH5-O_2Kq42Z6vuNt2zBdnw-w>
Subject: Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Mar 2021 17:06:07 -0000

Hello Watson,

first of all thank you very much for the feedback. It is a challenge for me to design
the protocol. NTS4PTP is much more complex than NTS4NTP because the requirements
are very different. Tomorrow there will probably be an update of the draft which will
include the missing chapters. Here once briefly my comments to your feedback:

1) ..."first concern is that this draft doesn't play nicely with NTS"...
The message/communication structure is indeed a problem. While with NTP we only
have a generic request/response to the NTS-KE, with PTP I have to distinguish between
different message types (e.g. unicast/multicast). While with NTS4NTP the communication
between time server and NTS-KE is implementation specific, with NTS4PTP it has to be
defined. This makes it more complex and currently collides with the "NTS Next Protocol
Negotiatin" record. I am open to any suggestions.


2) ..."second concern is cryptographic"...
For keys, we need to distinguish between multicast and unicast. For multicast we use
a group key. This has to be generated, distributed and managed accordingly by the
NTS-KE. A derivation from the TLS session would therefore not be possible, since all
participants need the same key.

With unicast it would be possible, but it makes it more complicated. Theoretically a PTP
client ('requester') can get up to 10 security associations per request, depending on the
PTP profile. The transport of the security parameters to the grantor (e.g. PTP time server)
is done via an encrypted ticket (similar to the cookie in NTP). The cookie solution as with
NTP cannot be applied to PTP, because the message rate is much higher in PTP and the
grantor is stateful. So tracking protection and parameter outsourcing are not needed.
The keys all have a certain lifetime and have to be updated periodically. For NTS4PTP
this is done by the NTS-KE. With NTS4NTP it is done by the time server. But I still see a
problem with NTS4NTP: The MasterKey is rotated, S2C and C2S are not. This contradicts
a bit the key freshness (if I am right).

But here's a question: in what way is it worse to generate a random number (CSPRNG)
instead of deriving it from the TLS connection (TLS Key Exporter)?


3) ..."Group keys have weaker authentication"...
Yes, with a group key we have poor source authentication. To solve this we would need
an approach with asymmetric cryptography (slow) or delayed key disclosure like TESLA
(vulnerable and complex). I don't know of any better alternatives.


... anyway, thank you very much. Tuesday I'm unfortunately not at the IETF meeting due to an exam.


best regards,
Martin

-------------------
Martin Langer, M.Eng.
Ostfalia Hochschule für angewandte Wissenschaften
- Hochschule Braunschweig/Wolfenbüttel
University of Applied Sciences

Labor Datentechnik, Labor Design Digitaler Systeme
Fakultät Elektrotechnik
Salzdahlumer Straße 46/48
38302 Wolfenbüttel
Germany

Tel.: +49 5331 939 43370
Web: https://www.ostfalia.de/cms/de/pws/bermbach/mitarbeiter/martin-langer


________________________________
Von: ntp <ntp-bounces@ietf.org> im Auftrag von Watson Ladd <watsonbladd@gmail.com>
Gesendet: Freitag, 5. März 2021 20:55:22
An: NTP WG
Betreff: [Ntp] Comments on draft-langer-ntp-nts-for-ptp

Dear WG,

I recognize that this is a pretty early draft and so I'm going to
focus on the aspects that are outlined that I think may be
problematic, rather than nitpick the clear and well written, although
somewhat incomplete text.

My first concern is that this draft doesn't play nicely with NTS. NTS
doesn't have a hierarchical record structure defined, deliberately to
avoid a well-trod class of security and correctness issues. An NTS way
to do this would be to unmake the PTP key grant structure and send a
NTP Next Protocol Negotiation field directly, and use new noncritical
PTP server or group negotiation messages. Obviously it's a bit
complicated by the layering of PTP.

My second concern is cryptographic. Instead of deriving the key from
the TLS handshake, the server sets it. We didn't do this in NTS for
NTP for a reason. The way we do forced key rotations is by getting new
tickets.

Group keys have weaker authentication and security properties than a
tree of unicast associations.

I think this is an important draft that covers a real usecase, but
should try to break the flow of NTS a bit less. I hope these comments
are useful.

Sincerely,
Watson Ladd

--
Astra mortemque praestare gradatim

_______________________________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp