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

"Langer, Martin" <mart.langer@ostfalia.de> Mon, 08 March 2021 11:44 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 211813A0BFF for <ntp@ietfa.amsl.com>; Mon, 8 Mar 2021 03:44:16 -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 L6DTbrkYhANy for <ntp@ietfa.amsl.com>; Mon, 8 Mar 2021 03:44:14 -0800 (PST)
Received: from mx1.sonia.de (mx1.sonia.de [141.41.1.237]) (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 A6FA43A0C03 for <ntp@ietf.org>; Mon, 8 Mar 2021 03:44:13 -0800 (PST)
Received: from mx1.sonia.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 46C4D1C800D2; Mon, 8 Mar 2021 12:44:11 +0100 (CET)
Received: from exchange05.resource.sonia.de (exchange05.resource.sonia.de [141.41.8.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.sonia.de (Postfix) with ESMTPS id 25F2E1C800D1; Mon, 8 Mar 2021 12:44:11 +0100 (CET)
From: "Langer, Martin" <mart.langer@ostfalia.de>
To: Miroslav Lichvar <mlichvar@redhat.com>
CC: NTP WG <ntp@ietf.org>
Thread-Topic: [Ntp] Comments on draft-langer-ntp-nts-for-ptp
Thread-Index: AQHXEfmMSKND+BsUuke89/+0bAqpHap52TGAgAAU3aP///w9gIAAEi3j
Date: Mon, 08 Mar 2021 11:44:10 +0000
Message-ID: <df535544ed3b45668ad9f4d70fc82d8e@ostfalia.de>
References: <CACsn0cnz1GfKUKn6q61qmAbs=VPgTGFZnP=kEeQHk9CUxLACXg@mail.gmail.com> <YEX+RYP1vXLgt5f8@localhost> <02fd071141eb4b6ea94a8245af2d75f8@ostfalia.de>,<YEYMnVfIGcbZ3TKP@localhost>
In-Reply-To: <YEYMnVfIGcbZ3TKP@localhost>
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_df535544ed3b45668ad9f4d70fc82d8eostfaliade_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/3wXmsZPgTSFA0F8tHsI0cW9k7jk>
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: Mon, 08 Mar 2021 11:44:16 -0000

To a certain extent, an approach would be possible. But we have to look closely at what it means for security.

Cookies would not work directly. If I understand this correctly, then we also don't need 2 keys (C2S, S2C). If I interpret it right, this prevents a security breach if client/server accidentally generate the same nonce in the AEAD operation. With PTP we don't have this (two-way) AEAD operation, but a HMAC/CMAC calculation for the ICV. However, for CMAC I need to check how it behaves there with the initialization vector.  ...it is not quite simple.

Therefore I am always grateful for any feedback and constructive criticism. ;)

-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: Miroslav Lichvar <mlichvar@redhat.com>
Gesendet: Montag, 8. März 2021 12:38:05
An: Langer, Martin
Cc: NTP WG
Betreff: Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp

On Mon, Mar 08, 2021 at 11:09:49AM +0000, Langer, Martin wrote:
> The multicast connections are not comparable to the broadcast connections in NTP.

I think they are pretty much the same if you assume the NTP client is
making periodic measurements of the delay and not just once on start.

> In NTP, TESLA-secured communication could be broken, because delay attacks are not
> detectable. However, in PTP we have two-way communication (Delay Request/Response)
> during multicast, which can be used to register runtime changes (RTT). However, a formal
> analysis is indeed not available.

The delay measurement has a request and response, but the offset
measurement (using sync messages) does not. Delay messages can be much
less frequent than sync messages. That's quite different from the NTP
client-server mode, where each request has an immediate response.

--
Miroslav Lichvar